Re: FSK demodulation

On Thu, Jun 19, 2014 at 12:35 PM, Marcus Müller
[email protected]
wrote:

Hi Marc,

Currently, I am trying to implement correlation receiver using FIR
filters. I am looking into polyphase filterbank channelizer to implement
correlation, but currently unable to do so because I currently do not
know how to assign taps for channelizer.

I should have pointed you at Tom’s article on PFB channelizers and
synthesizers [1].

Thanks, nice article! I am going to test it soon.

people actually trying to implement stuff!

ADC in N210 is sampling at 100Msps, so you are saying that I can get
processing gain (better SNR) if I set the USRP sink sample rate higher
than
IMsps i.e usrp_sink.sample_rate(3.125e6) instead of
usrp_sink.sample_rate(1e6) . Right ?

Also I read [1] that if I oversample by 2 then I gain 3dB in SNR, if
oversample by 4 I gain 6dB in SNR and so on, is that TRUE ? If this is
true
I can get a lot of SNR improvement because ADCs are operating at
100Msps.

… encourage you to read a lot of books [1] and papers on this.

Thanks for the link, nice stuff.
If you find something interesting, don’t hesitate to add a new heading
like “FSK demodulator technology” and add the references there; I think
this list is something that could use broader usage :slight_smile:

Sure! I 'll do that.

discontinuity is somewhat physically impossible[2]. So these modulations
get the spectrum of a phase-jumping system, smoothed by the spectral
shape of the pulse shaping.

Thanks for the detail. Also, I got FSK modulator working using the VCO
:slight_smile:

Marc
[1]
http://www.dsprelated.com/showmessage/72731/1.php

Hi Marc,
On 20.06.2014 09:38, Marc Miller wrote:

ADC in N210 is sampling at 100Msps, so you are saying that I can get
processing gain (better SNR) if I set the USRP sink sample rate higher
than IMsps i.e usrp_sink.sample_rate(3.125e6) instead of
usrp_sink.sample_rate(1e6) . Right ? Also I read [1] that if I
oversample by 2 then I gain 3dB in SNR, if oversample by 4 I gain 6dB
in SNR and so on, is that TRUE ? If this is true I can get a lot of
SNR improvement because ADCs are operating at 100Msps.
As long as your noise stays uncorrelated, and your signal samples do the
opposite, you will have this processing gain; so yes, this is basically
what is done.

So, the limiting factors here
a) the fact that you have but GigE between your host and your USRP,
meaning that you can’t do more than
1e9b/s / (16 b/sample) / (2 sample/complex) = 31.25Msample/s over that
link at all, and since the the USRP can only do integer fractions of the
100MHz master rate, this will effectively be 25MS/s [1]; but even more
b) the fact that millions of samples are just really much data to
process, and if you can’t keep up with the sample rate, then at some
point, UHD will have to drop samples, which will greatly distort your
signal.

Thanks for the detail. Also, I got FSK modulator working using the VCO :slight_smile:
Keep this going! The nice thing about GNU Radio is that you can test
your modulator in software only by replacing your USRP sink by your
receiver flow graph, usually adding a throttle[2!] to limit the CPU
usage. Have you tried looking at the spectrum of the signal you
generated, e.g. with the QT GUI waterfall sink [3]? There is BER probes,
so you can test and compare different implementations of your receiver.

I think this is a good point to drop you off to your own
experimentation, and study of the effects coming up. Have fun!

Greetings,
Marcus

[1] You can configure the device to just send 8 bit samples, but that
will limit the SNR because it introduces quantization noise, and is
usually the opposite of what you want to do in a bad-SNR situation
[2] you never use throttle in a flowgraph with hardware, because the
hardware will be there to limit your sample flow. I only mention this
because we see this mistake so often.
[3] Remember to set the Generate Option in the Options Block to QT, if
you use QT sinks.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs