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

[Brett L. Trotter]

Johnathan Corgan wrote:
> Brett L. Trotter wrote:
>
>   
>> Yay- congratulations- transferred 100MB successfully and all of my 
>> 'stumbler' packets- even with UDP.
>>     
>
> You're using FSP (which goes over UDP), correct?  FSP has a retry
> mechanism, so good.  Glad it's working now!
>   
I used FSP for the 'stumblers' but did the 100MB with scp (though the
FSP did work for the 'stumblers'- I'll test FSP on the big file here
momentarily)
>   
>> 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-
>>     
>
> Well, only the "stumbler" packets get repeated, and as you found, there
> were only five in 10,000 that you tried. So your overhead isn't 100%,
> it's no different than if your channel dropped one in 2000 packets. (For
> those following, the problem before resulted in a complete link failure,
> as the retransmitted packets on the connection would always fail CRC.)
>   
True enough, but that was also with random data- ordered data could
yield either significantly higher hangup rate or perhaps none at all.
8b/10b seems like a good generic robustness idea- as I said, I'll
implement it and test it, and if anyone wants to turn it on, cool beans.
>   
>> Worst case, it can be an option in the python that most people can
>> leave turned off.
>>     
>
> An 8b/10b line coding scheme would probably be best implemented as a
> standalone hierarchical block that a developer could choose to use or
> not as part of a flow graph implementing a transmit and receive path.
>   
Sounds like a good plan and more or less what I had in mind.
>   
>> FYI: Am achieving nearly 100kb/s with -r 800k on a BasicTX
>>     
>
> Is that bytes or bits per second?
>   
89-94 kibibits per second, nifty! (And thats not accounting for SCP
overhead)
> --
> Johnathan Corgan
> Corgan Enterprises LLC
> http://corganenterprises.com
>
>