Hello Marcus,
You sent the forwarded email a
few months ago.
The benchmark stuff doesn't, as far as I know, have FEC in it. I think Tom was referring to single-bit errors in the so-called "accesscode" at the beginning of the frame. If there are bit errors there, then the frame is necessarily discarded, since it's not *recognized* as a valid frame. But apart from that, if the frame sequence is valid, then the packet is "recognized", and punted up through the RX packet callback mechanism, which means there could still be bit errors in the payload section of the packet.
We implemented a CRC checking block in the benchmark_rx code using binascii.crc32 python code. We observed a very interesting thing in the following portion of the benchmark_rx code:
def rx_callback(ok, payload):
global n_rcvd, n_right
(pktno,) = struct.unpack('!H', payload[0:2])
if ok:
n_right += 1
Whenever the packet was received as 'OK' (i.e. 'OK = True') and n_right increased, the packet also passed our CRC check. Every packet that did not pass our CRC check was also not received as 'OK' (i.e. 'OK = False' in those packets). Our CRC checking portion is completely independent of the main benchmark_rx code. We just look at the received data and see if there is any bit error or not.
Now, if the above the mentioned portion of the code does not do CRC checking on its own, how does it completely match with our CRC based results? Does it mean that errors occur in bursts. Therefore, whenever there is any single bit error in the data, there are errors in the header as well ??
Your feedback will be very appreciated.
I'll let other people who are more familiar with the code comment.
My comments from months ago were from a cursory inspection of
code that I don't use, or have any particular vested-interest in.
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
|