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

[Brett L. Trotter]

Johnathan Corgan wrote:
> 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
> 

Yay- congratulations- transferred 100MB successfully and all of my
'stumbler' packets- even with UDP.

I'm going to continue work on the 8b/10b, because I still think that's
the closest 'real' solution to the issue- and the overhead isn't as
severe as repeating 1500 byte packets- especially when you consider that
ethernet and many other mediums use this specific implementation of
8b/10b. Worst case, it can be an option in the python that most people
can leave turned off.

FYI: Am achieving nearly 100kb/s with -r 800k on a BasicTX