Regarding protecting the length field,
a rate 1/2 linear block code can always be used.
The way it is now it is a repetition code which
offers little protection.
Achilleas
Hey all,
I finally figured out the problem where my receivers would stop
receiving packets. It had nothing to do with hardware gain, thanks to
Tom R. for pointing me off of that path.
So the gr_framer_sink_1 is a little screwed up. (As a reminder,) The
packet format is:
[ ACCESS_CODE(<=64 bits) | LEN(16) | LEN(16) | DATA ]
where the length field is in bytes. It works as follows:
After detecting access code, if the two length fields are identical, try
and create a packet. I was sending packets of size 128, (length
0b0000000010000000), and every once in a while both 1s would get flipped
and it would try and create a packet of size 0; due to a bug in the code
this entered an unrecoverable state in the state machine. (I’m sending a
patch to patch-gnuradio.)
Now, I see two problems in this code - no whitening and no integrity
check. Thoughts on whether we should add one or both of these? Neither
is a guaranteed fix, but given my particular problem, it appears that
whitening might be a good idea. Especially noting that most MTU sizes
are less than ~2300 bytes, meaning that it’s very likely that the upper
5 bits of each length field will be 0.
-Dan
Achilleas A. wrote:
Regarding protecting the length field, a rate 1/2 linear block code
can always be used.
The way it is now it is a repetition code which offers little
protection.
As-is there is no FEC in in the digital packet code anyway. When we add
that, we’ll likely do it for the complete header and payload at the same
time. In the mean time it’s simple enough and effective (when combined
with the payload CRC) to at least detect and drop corrupted packets on
receive.
–
Johnathan C.
Corgan Enterprises LLC
http://corganenterprises.com
Eric,
there are many options. One is a (31,16) BCH code
with 3 bits error correction capability.
It would have been nice to have a generic BCH encoder/decoder
block that can also do mixed error correction/detection…
In the absence of that, we can always use a rate 1/2 convolutional code
off the self.
Achilleas
Achilleas A. wrote:
there are many options. One is a (31,16) BCH code
with 3 bits error correction capability.
When the --use-whitener-offset option is chosen, we’re actually using
all 16 bits of the field (the upper nibble is the 4-bit whitener
offset), so we’d need a (32,16) code, if such a thing exists.
–
Johnathan C.
Corgan Enterprises LLC
http://corganenterprises.com
On Sun, Mar 11, 2007 at 02:59:58PM -0700, Johnathan C. wrote:
time.
I don’t think so. We need to be able to reliably determine the length
of the packet (which we get from the header), to find the end of the
packet.
I think Achilleas’ suggestion of a rate 1/2 block code for the header is
the way to go. Achilleas, do you have a specific suggestion? Golay
would protect 12-bits. Any off-the-shelf code that does a good job on
16-bits of payload?
Also, splitting the PHY layer framing from the handling of the payload
CRC / FEC allows upper layers to be independent of the low-level
framing mechanism.
Eric
no problem: put 0 as the 32nd bit :-), or
extend the code by one bit (this is pretty standard in block codes).
In the case of rate-1/2 CC you just run the encoder for 16 steps so you
get exactly 32 bits out.
Achilleas