[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] 8b/10b for GMSK
From: |
Brett L. Trotter |
Subject: |
Re: [Discuss-gnuradio] 8b/10b for GMSK |
Date: |
Mon, 05 Feb 2007 10:56:36 -0600 |
User-agent: |
Thunderbird 1.5.0.9 (X11/20061219) |
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