[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Brett Trotter
Subject: [Discuss-gnuradio] 8b/10b for GMSK
Date: Sun, 4 Feb 2007 02:32:30 -0800 (PST)

After coming up with some scripts to generate thousands of 200-byte random
files and attempt to transfer them over a GMSK link, I isolated 5 of 10,000
'files' that cause the packet to be dropped (when the MTU is big enough to
hold the entire 200 bytes- which should be all the time)- most likely due to
repeated zeros or ones that cause a loss of sync. Upon debugging the output
after the whitener, it does appear that there are instances of around
12-zeros in the packets that don't work.

It seems that a reasonably simple solution would be to replace or augment
the whitener with an 8b/10b encoding (per Widmer/Franaszek's 5b/6b+3b/4b)
which also would allow for a beginning and end of packet comma symbol for
synchronization. The 8b/10b could replace the whitener completely, but I
read that passing it through the whitener and then the 8b/10b yields better
spectral properties/dc balance.

I found dozens of Verilog/VHDL implementations by googling, but none in
software. I computed some tables and was part way into making some code but
am at a couple of question marks that need to be answered.

1) If I do somehow finish this (I'm not that great at Python just yet,
though am very familiar with other languages- so I can definitely finish
with the help of google), would this be something that would be committed to
the tree (eg- do Matt/Eric/Johnathan, etc think this is the appropriate
2) if (1), what is the bit and byte order over the wire for GMSK so that I
can make sure I formulate the characters/packets in the right order.
3) if (1), someone more familiar could probably implement this in minutes or
perhaps a couple of hours, whereas it'll take me the better part of a day or
two- is anyone interested in helping me reduce the number of question marks
and think through doing this correctly?

Another viable option might be applying the TMDS method (XOR/XNORing)
creatively to this medium. The way I read it, the clock signal is only for
frequency reference so I don't see a reason why we cant use TMDS on a
clock-less medium if we don't care about blanking periods, etc.

Please let me know if I'm off my rocker or if I'm pointing in the right

I look forward to your thoughts/comments.
View this message in context: 
Sent from the GnuRadio mailing list archive at Nabble.com.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]