Forum: GNU Radio Re: Problem in framer_sink

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
C369ebbe1655201988e376af57460f23?d=identicon&s=25 Achilleas Anastasopoulos (Guest)
on 2007-03-11 19:38
(Received via mailing list)
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 Rondeau 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
D0072e69d706bb3ca211d33a1b536e2c?d=identicon&s=25 Johnathan Corgan (Guest)
on 2007-03-11 23:01
(Received via mailing list)
Achilleas Anastasopoulos 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 Corgan
Corgan Enterprises LLC
http://corganenterprises.com
745d8202ef5a58c1058d0e5395a78f9c?d=identicon&s=25 Eric Blossom (Guest)
on 2007-03-12 20:10
(Received via mailing list)
On Sun, Mar 11, 2007 at 02:59:58PM -0700, Johnathan Corgan 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
C369ebbe1655201988e376af57460f23?d=identicon&s=25 Achilleas Anastasopoulos (Guest)
on 2007-03-13 22:02
(Received via mailing list)
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
D0072e69d706bb3ca211d33a1b536e2c?d=identicon&s=25 Johnathan Corgan (Guest)
on 2007-03-13 22:26
(Received via mailing list)
Achilleas Anastasopoulos 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 Corgan
Corgan Enterprises LLC
http://corganenterprises.com
C369ebbe1655201988e376af57460f23?d=identicon&s=25 Achilleas Anastasopoulos (Guest)
on 2007-03-13 22:51
(Received via mailing list)
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
This topic is locked and can not be replied to.