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.
Thanks,
Shantharam
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
