discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] CPFSK mod/demod + strange behavior


From: Mark Napier
Subject: Re: [Discuss-gnuradio] CPFSK mod/demod + strange behavior
Date: Fri, 10 Jun 2016 12:46:04 -0400

Hello Olivier,

I'm also pretty useless on GNUradio, I'm a hardware guy.

However, I did get simulations going in Matlab/Simulink for a few variations of the UAT Rx/Tx.  Let me say that this is not a channel for the faint of heart.  The dump978 code manages to do a Rx with marvelous simplicity.  I see a few places in the code I think could be optimized, esp. the RS decode, but that's picking nits.  It is very well done given the limited BW of the RTL-SDR.

The thing you are missing about the RRC filter is that it isn't used here.  A root-Nyquist filter is done for phase/amplitude modulation where you wanted a matched filter at the RX/TX and want a RC response over the channel.  That doesn't appy to FSK.

What *is* done is that the bits are converted to +-1 at the (25/24) MHz bit rate, or baseband sample rate.  Then those samples have to be up-converted to the rate of your NCO.  Lets say for instance 6.25Msps since that is factor of 16 to the 100Msps DAC rate of an N210.  So at the bit sample instant you want the signal into the NCO to have a value that will give a 312 kHz.  Note there will be some over/under-shoot at anything other than the sample instant: that is the nature of the signal.  Then that is used to frequency modulate the complex NCO running  at 6.25Msps.

So here is where the RC filter comes in.  You need to up-sample by 6.  The output of the complex NCO needs to meet the frequency mask shown in the spec.  One way to do that is with an RC filter for interpolation.  Garmin says they are using an RC filter with an alpha = 0.5.  It does work.  I come up with a different scheme since I am using CIC filters for interpolation.  The result is the same: the output frequency band meets the mask.  Also, on the RX side the pulses have been shaped so that there is little ISI.  There are measurements in the UAT compliance tests for that too.  In the setup for the instrument there is mention of an RC with alpha = 0.5, but that sets up the instrument.  The RX FSK signal is *not* being filtered in the time domain with an RC or RRC filter.  FSK modulation really isn't a linear process.  I have the simulations to prove it.

The advice others have given is right:  get the modulation working dumping into a file and post process to see what you have.  Get that right 1st and then battle the UHD.

Have fun,

Mark Napier




Message: 8
Date: Thu, 9 Jun 2016 15:24:37 -0400
From: Olivier Goyette <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] CPFSK mod/demod + strange behavior
Message-ID:
        <address@hidden>
Content-Type: text/plain; charset="utf-8"

My flowgraph is based on what I've read throughout the different forums on
the internet because :

1- I'm a newbie to GRC and GNUradio in general
2- It's my first time trying to develop a telecomm application
3- I'm using a RRC filter because it's a requirement stated in the
documentation I have about UAT.

Take a look at the references I joined. Those are every links I've been
through trying to understand what is FSK and all the process behind.
Maybe you will be able to tell me what' wrong ?!

2016-06-09 15:04 GMT-04:00 Achilleas Anastasopoulos <address@hidden>:

> Why are you using the RRC filters?
>
> I hope you are realizing that filtering a CPFSK signal is not the same as
> filtering its instantaneous frequency (which is a PAM signal with
> rectangular pulses).
> As a result, the next question is why in your poly-phase filter you are
> using RRC filter taps?
>
> Achilleas
>
> _______________________________________________
> Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>

reply via email to

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