Re: [Discuss-gnuradio] 8b/10b for GMSK

[Johnathan Corgan]

Johnathan Corgan wrote:

> There is an alternative that Eric and I have conceived that would be 
> a temporary workaround. It would not solve the original problem but 
> would at least allow upper level protocols that do re-transmission to
> recover from the failure.  I'll talk about that once I've got it 
> coded, tested, and into my developer branch.

This has been implemented, checked into a developer branch, and
successfully tested.

A new command-line parameter has been added to both tunnel.py and
benchmark_tx.py, --use-whitener-offset. It defaults to false so existing
behavior is unchanged.

A new 4-bit field has been added to the existing packet header, above
the 12 bits already used for the length field. This field holds an
integer (range 0-15) that represents an offset value.

When transmitting, this value (which defaults to zero), determines the
offset into the whitening array which is XORed with the payload data to
form the whitened data for submission to the modulator.

When the --use-whitener-offset option is set, this offset is
incremented for each transmitted packet, and stored in the new 4 bit
field.  Thus, even identical packets, when transmitted successively,
result in completely different "on the air" data.

The receiver extracts the offset value from the header and uses it to
recover the original data.  In the case where the offset option is not
used, the offset is always set to zero, so the receiver behavior is then
unchanged.

If a received packet fails CRC because of some pattern-specific
synchronization problem, and if the upper protocol layers cause a
retransmission, then the re-transmitted packet will have a different
whitened bit pattern, allowing it to go through.

While this doesn't solve the underlying problem, whatever that may be,
it does give a workaround for users who have to get past this issue
while we are debugging it.  Unfortunately this workaround is only for
people who are using higher level protocols which use retransmission to
recover from link errors.  This of course includes TCP, which is the
underlying protocol for the majority of users.

I've verified that my prior failure test cases now "work", in the sense
that the upper layers just continue as if the bad packets were dropped
due to noise.  This includes ssh, scp, ftp, and https, each of which I
could reliably make to fail with the old code and now succeed with the
new workaround.

The code is in the developer branch:

http://gnuradio.org/svn/gnuradio/branches/developers/jcorgan/digital

...which is based on a snapshot of the trunk as of a couple days ago.

We haven't decided whether this will make it into the trunk.  We'd much
rather make a real fix.

Johnathan Corgan
Corgan Enterprises LLC
http://corganenterprises.com