I’ve added a link to
http://gnuradio.org/trac/wiki/Enhanced_GMSK_Demodulator from
http://gnuradio.org/trac/wiki/OurUsers
Summary:
[…] offers an enhanced GMSK demodulator that I believe to be
superior to the GNURadio standard gmsk demodulator. It should be a
drop-in replacement for the existing demodulator in designs, except
that the transmitted data needs to be differentially encoded (you will
NOT, however, need a differential decoder on the receive side). The
enhanced demodulator should offer better bit error rate (BER)
performance, especially for lower bandwidth-bittime (BT) products,
such as the GSM standard BT=0.3, and in lower SNR conditions.
Please check it out and comment…
On Thu, Jun 05, 2008 at 03:25:29PM -0400, Steven C. wrote:
enhanced demodulator should offer better bit error rate (BER)
performance, especially for lower bandwidth-bittime (BT) products,
such as the GSM standard BT=0.3, and in lower SNR conditions.
Please check it out and comment…
Steven,
If you were to generate a patch that had your demodulator show up as a
new demod called, say, gsm_demod_alt2 that hooked it into the existing
framework with this new name, we could add it to the tree and it would
get more testing without having to overwrite the known implemenation
in the tree. As currently written, yours looks like an all-or-none
proposition that requires a change in the modulator too. Adding a
version of modulator that did the differential encoding would be
good too.
In gmsk_alt2.py:
class gmsk_mod_alt2(gr.hier_block2):
# I’m guessing this does the diff enc, then connects to the existing
gmsk_mod…
…
class gmsk_demod_alt2(gr.hier_block2):
…
modulation_utils.add_type_1_mod(‘gmsk_alt2’, gmsk_mod_alt2)
modulation_utils.add_type_1_demod(‘gmsk_alt2’, gmsk_demod_alt2)
Thanks,
Eric
On Thu, Jun 5, 2008 at 3:25 PM, Steven C. [email protected]
wrote:
[snip]
It should be a
drop-in replacement for the existing demodulator in designs, except
that the transmitted data needs to be differentially encoded (you will
NOT, however, need a differential decoder on the receive side).
Why?
All the cases I can think of would be most logically implimented with
the same interface (encoded or non-encoded) on both the encoder and
decoders.
If it’s just an arbitrary decision then perhaps it should be changed
before it enters the tree and people build other radios expecting that
particular interface.
Ive noticed that the papers you cited only take in “real” data and not
“complex.” Is this true? Is this true for your implementation?
Isaac
Steven C.-2 wrote:
NOT, however, need a differential decoder on the receive side). The
Discuss-gnuradio Info Page
–
View this message in context:
http://www.nabble.com/Posted%3A-Enhanced-GMSK-demodulator-tp17677732p17691518.html
Sent from the GnuRadio mailing list archive at Nabble.com.
Steven-
Did you actually find that the decision threshold needs to be biased? I
actually implemented the 2 bit differential detector on a custom asic
that was targeted at streaming audio(in 2004) and during the
simulations I found that moving the bias point did very little for
performance. Maybe in a floating point environment it makes a little
difference? I agree that it has superior performance over other
techniques, due to that asymmetric increase in eye opening. Did you
happen to notice that the math is actually performing a dot(or cross I
forget which) product between two vectors separated by 2 bit times? I
think I learned that from Lindsey’s book. I think he calls these
techniques differently coherent. Its the best bang for your buck if you
want a robust demod without worry about carrier recovery. Unfortunately
the startup company where I did the design (Aura Communications) is
gone but the chip lives on in the acquiring company so it wasn’t a
complete waste of time. 
-Jeff
On Fri, Jun 6, 2008 at 8:56 AM, isaacgerg [email protected]
wrote:
Ive noticed that the papers you cited only take in “real” data and not
“complex.” Is this true? Is this true for your implementation?
Isaac
I think they do in fact take in complex. How would one do a 90deg
phase shift of real data? In any case, my implementation works with
the complex baseband coming from the USRP. After the complex multiply,
a complex-to-float block is used. For one-bit diffdetect, you base
your decision on the imag (sin) component, for two-bit you look at the
real (cos) component.
-Steven
On Thu, Jun 5, 2008 at 5:28 PM, Gregory M. [email protected]
wrote:
the same interface (encoded or non-encoded) on both the encoder and
decoders.
If it’s just an arbitrary decision then perhaps it should be changed
before it enters the tree and people build other radios expecting that
particular interface.
It is not an arbitrary decision – it is required. I do agree that it
seems weird, but it is just a quirk of the way the math works out for
a 2-bit differential detector that it removes a differential encoding
in the process.
The Simon & Wang paper explains it better than I can:
“The dashed lines around the differential encoder indicate that it is
present for a two-bit differential detector but absent for a one-bit
differential detector at the receiver. As discussed in [16], this
differential encoding operation is required for the two-bit detector
in order that hard decisions made on the detector output reflect
decisions on the true input data sequence and not a differentially
decoded version of it as would be the case without the differential
encoder at the transmitter input.”
If you can’t get your hands on the Simon & Wang paper, let me know and
I can send you a copy of it.
-Steven
On Fri, Jun 6, 2008 at 9:30 AM, Long, Jeffrey P. [email protected]
wrote:
forget which) product between two vectors separated by 2 bit times? I
think I learned that from Lindsey’s book. I think he calls these
techniques differently coherent. Its the best bang for your buck if you
want a robust demod without worry about carrier recovery. Unfortunately
the startup company where I did the design (Aura Communications) is
gone but the chip lives on in the acquiring company so it wasn’t a
complete waste of time. 
-Jeff
Jeff-
That’s interesting about the threshold. Do you remember what BT you
were using? The lower the BT, the more asymmetric the eye and
therefore the more you need to bump up the threshold to have it still
be near the center of the eye. The optimum threshold also depends on
SNR…increasing slightly as Eb/N0 increases. I didn’t muck around too
much with the threshold, I just eyeballed the charts at the end of the
Simon&Wang paper and picked a value (0.1) that seemed close to the
most common cases. It should be somewhere between 0.0 and 0.2 for
certain.
-Steven
Steve-
You know what, you might be right here. I am starting to remember that
it could be BT dependent. My application called out for a BT of .5
which is not too severe(we didn’t really have ACI issues) so in reality
the threshold might be good enough right thru the center. With
something more severe .35 or less maybe it makes sense to move the
threshold up. It might also be dependent on how much quantization and
oversampling you have at that point. With not much resolution in time
or amplitude it might not make much of a difference.
-Jeff