[Top][All Lists]

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

RE: [Discuss-gnuradio] Posted: Enhanced GMSK demodulator

From: Long, Jeffrey P.
Subject: RE: [Discuss-gnuradio] Posted: Enhanced GMSK demodulator
Date: Fri, 6 Jun 2008 09:30:27 -0400


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. :)


-----Original Message-----
From: address@hidden
[mailto:address@hidden On Behalf Of
Steven Clark
Sent: Thursday, June 05, 2008 5:53 PM
To: Gregory Maxwell
Cc: gnuradio mailing list
Subject: Re: [Discuss-gnuradio] Posted: Enhanced GMSK demodulator

On Thu, Jun 5, 2008 at 5:28 PM, Gregory Maxwell <address@hidden>
> On Thu, Jun 5, 2008 at 3:25 PM, Steven Clark
<address@hidden> 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
>> 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
> 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.


Discuss-gnuradio mailing list

reply via email to

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