Hi! Thanks for sharing your knowledge about CRC. In real life, parallel CRC is more practical than serial CRC, which can only process one bit of data at a time. So, can you talk about parallel CRC, like CRC32, with an 8-bit input data width? Additionally, I’ve heard about "magic numbers" in CRC. Normally, at the receiving end, the redundant data is zero, which indicates no error in a typical CRC. However, there are other "magic numbers" like 0xc704dd7b in CRC32. I’m having trouble understanding these different "magic numbers." Can you explain more about the concept of CRC "magic numbers"? Again, thanks a lot for sharing. You made the basics of CRC clear to me :)
Hi! Thanks for the video. I have a question about the flow: For an N- bit message and an M-bit divisor. 1. The N- bit message is being sent over the course of N clock cycles. Simultaneously the reminder is being calculated in the TX and in the RX. 2. After the first N clocks the TX trasmits the M-bit reminder. At this point in time, the LFSR in the RX should have the same reminder as was calculated in the TX. What happens on the RX side at that moment? If we stop shifting the LFSR and capture the next M bits of the reminder we will be able to compare them at the end of transmission (N+M cycles) to validate the correctness of the TX/RX. I didn't understand your comment at the end about how to verify/use the reminder that is being sent after the message. Thanks!
Hi! Thanks for sharing your knowledge about CRC. In real life, parallel CRC is more practical than serial CRC, which can only process one bit of data at a time. So, can you talk about parallel CRC, like CRC32, with an 8-bit input data width?
Additionally, I’ve heard about "magic numbers" in CRC. Normally, at the receiving end, the redundant data is zero, which indicates no error in a typical CRC. However, there are other "magic numbers" like 0xc704dd7b in CRC32. I’m having trouble understanding these different "magic numbers." Can you explain more about the concept of CRC "magic numbers"?
Again, thanks a lot for sharing. You made the basics of CRC clear to me :)
Yes i would strongly request the same
Hi! Thanks for the video.
I have a question about the flow:
For an N- bit message and an M-bit divisor.
1. The N- bit message is being sent over the course of N clock cycles. Simultaneously the reminder is being calculated in the TX and in the RX.
2. After the first N clocks the TX trasmits the M-bit reminder. At this point in time, the LFSR in the RX should have the same reminder as was calculated in the TX.
What happens on the RX side at that moment?
If we stop shifting the LFSR and capture the next M bits of the reminder we will be able to compare them at the end of transmission (N+M cycles) to validate the correctness of the TX/RX.
I didn't understand your comment at the end about how to verify/use the reminder that is being sent after the message.
Thanks!
I would be great if you can comment on how these packets being sent/received are organized