[Top][All Lists]

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

Re: [Discuss-gnuradio] FSK modulation/demodulation for Universal Access

From: Nick Foster
Subject: Re: [Discuss-gnuradio] FSK modulation/demodulation for Universal Access Transceiver
Date: Thu, 26 May 2016 18:50:10 +0000

Everyone's tips here are great. A minor clarification:

UAT is not Mode S. UAT is 978MHz FSK at 1.041667Ms/s. Mode S (and thus, ADS-B) is 1090MHz PPM OOK at 1Ms/s. I'm unaware of any existing Gnuradio UAT implementations, although there are a couple of prototype scratch-built decoders (https://github.com/mutability/dump978 for instance) that could be used for reference.

UAT is intended for civil aviation applications and (usually) provides local traffic synthesized from ATC sources (TIS-B) as well as weather (radar and forecast) services (FIS-B).

The best advice I can offer when getting started writing Gnuradio applications is to know what you're expecting before you try something, and be rigorous in your experimentation. At every step of the demodulation process be looking at the raw data, and be able to explain why it looks like it does.


On Thu, May 26, 2016 at 11:32 AM Andy Walls <address@hidden> wrote:
On Thu, 2016-05-26 at 11:04 -0400, address@hidden

> Date: Thu, 26 May 2016 11:03:55 -0400
> From: Olivier Goyette

> Hi everyone,
> I'm currently doing an internship at school and i'm working with USRP N210
> and GNUradio. It's been a month since I began working with these 2 tools,
> so excuse me if I may sound noob, but I really need some help. I've been
> asked to start thinking about developing an UAT for civil aviation. I've
> read a ton of standards and papers concerning this new technology, so I
> won't relate it all over here, but the main thing about it is that it uses
> FSK mod/demod for the information to be transmitted and received.
> I'm currently stuck on a problem that's been haunting me for the last 2
> weeks and that's why i'm asking for your guidance. When I run the mod/demod
> on simulation(attached #1), everything works fine. I'm sending
> *abcdefghijklmopqr
> *and on the receiving side i got the same thing.

Isn't simulation great. ;)

>  Now the problem is that
> when i'm trying to send it via the USRP with a cable between RX and
> TX(attached #2), i only get gibberish on the receiving side !

The real-world always ruins things!

> What have I done wrong ? I don't get why it's not working.

Three things:

1. On Tx you only appear to be using 1 sample/symbol.  That doesn't let
you do any pulse shaping.

2. On Rx you appare to be using only 1 sample/symbol, which makes symbol
clock recovery nearly impossible.

3. On Rx you're not performing symbol clock recovery  (M&M clock
recovery block or PFB clock recovery block).

4. On RX you're performing neither coarse nor fine frequency

5. Your USRP is unhappy with your configuration of the USRP blocks:
"The hardware does not support the requested Tx sample rate:
Target sample rate: 0.000001 Msps  (<- 1 sample per second?!)
Actual sample rate: 0.195312 Msps  (<- 195.312 ksps is the slowest the USRP can go apparently)"

> Thank you for your time, your help will be more than welcome

As Marcus said, yo can look at Nick Foster's gr-air-modes to see how he
handles Mode S/ADS-B (which is ASK/OOK).

You can also look at Nick's gr-ais, which is a GMSK receiver (GMSK is
GMSK with a modulation index of 0.5).

This set of class notes talks about receiver timing synchronization:

Also fred harris' article "Let's Assume the System is Synchronized" is
good reading about receiver synchronization (although not specifically
geared towards FSK):


> Olivier

Discuss-gnuradio mailing list

reply via email to

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