Forum: GNU Radio ADS-B and Mode-S Transponders

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Eric A. Cottrell (Guest)
on 2007-03-24 19:18
(Received via mailing list)
Hello,

Yet another project I am interested in.  Number 157 on the list. 8)

ADS-B is an interesting system that allows aircraft to send position and
other information.  It uses the 1090 MHz Transponder frequency.
http://www.garmin.com/aviation/adsb.html

ADS-B is more progressed over in Europe.  It is in a testing phase on
the East Coast of the US.  It is out of range from my QTH.
http://www.garmin.com/aviation/Safe_Flight_21_v0.69a.pdf
The UAT is used for general aviation on a frequency of 978 MHz.

I was interested in the SBS-1 which decodes Mode S and ADS-B.
http://www.kinetic-avionics.co.uk/sbs-1.php

The design uses SDR techniques.  It appears the decoding is done in a
Xilinx Spartan.  http://www.tech-software.net/inside_sbs1.php
There are other interesting things on the website.
http://www.tech-software.net

Some interesting info about the data being encrypted and delayed
5 minutes over TCP/IP.  So no direct Linux support.
http://www.kinetic-avionics.co.uk/forums/viewtopic...

I talked to someone with the SBS-1 and they said there is some ADS-B
activity as some US aircraft fleets have it installed.

I thought that the USRP and DVB tuner board could also receive ADS-B and
Mode S.  I did not know if my discone and long coax run would work.  So
I did some experiments.

I used the fft and oscilloscope programs to check for activity.  I did
see activity on 1090 MHz.  I then modified the oscilloscope program to
do AM detection with the gr.complex_to_mag() function.  I saw various
pulse trains that look correct.  There were some short ones that look
like old transponders and longer ones that look like Mode S.  I found
the range of good gain settings was narrow (31 to 35) with 33 to be the
best.  I found the decimation of 16 gave good pulse shapes.  The pulse
timings are in 500 nS units so you need 250 nS sample times at least.
This is the data format. http://www.tech-software.net/adsb_decode1.php

The next step is to write a decoder block that takes in the samples and
prints out type and raw data to the standard output.

73 Eric
Eric B. (Guest)
on 2007-03-25 21:52
(Received via mailing list)
On Sat, Mar 24, 2007 at 01:17:28PM -0400, Eric A. Cottrell wrote:
> http://www.garmin.com/aviation/Safe_Flight_21_v0.69a.pdf
> Some interesting info about the data being encrypted and delayed
> I used the fft and oscilloscope programs to check for activity.  I did
> prints out type and raw data to the standard output.
This is great!  Looking forward to what you come up with!

Eric
Eric A. Cottrell (Guest)
on 2007-03-25 22:23
(Received via mailing list)
Eric B. wrote:
>
> This is great!  Looking forward to what you come up with!
>
> Eric
>
Hello,

I was able to modify the oscilloscope sink to trigger at a signal level.
 I noticed a lot more activity after the proper triggering.  I do not
get really strong signals except when aircraft are nearby. :)

This is a good example for the USRP since the data is at 1 Megabit per
second and not possible over a sound card interface.

The Mode A and C transponders uses Pulse AM with the presence of pulses
in defined timeslots determining the data with framing pulses at the
start and end.  Mode S uses Pulse Position Modulation (PPM) with a
preamble.  I included a png of the first part of a Mode S packet.  The 4
pulses at the start are the preamble.

Most of my thinking will go into how to implement this within the
GNURadio style.  Do I make a more general case or a specialize case? I
noticed GNURadio has some framing and bit sync blocks I need to look at
more.

PPM is decoded by comparing the amplitude values in the 1 time period to
the 0 time period.  This is like FSK but uses time instead of frequency.
The timing is such that each 1 uS of time is a symbol.  There are 4
symbol states.  I am remapping 0 and 1 as the valid data values.  I need
some decision logic to determine the presence of a pulse.  The block
also needs pulse sync logic. So the block takes in samples and outputs
symbols.

The next block looks for the preamble pattern and valid data frames by
looking at the timings of valid (0, 1) versus invalid (2,3) symbols.  It
outputs valid data frames.

I get the impression that this is the general flow for digital decoders
in GNURadio although the framing is usually separate from the decoding.
 Am I on the right track with this?

73 Eric
Matt E. (Guest)
on 2007-03-27 07:26
(Received via mailing list)
>
> The Mode A and C transponders uses Pulse AM with the presence of pulses
> in defined timeslots determining the data with framing pulses at the
> start and end.  Mode S uses Pulse Position Modulation (PPM) with a
> preamble.  I included a png of the first part of a Mode S packet.  The 4
> pulses at the start are the preamble.
>
>

Very cool.

> Most of my thinking will go into how to implement this within the
> GNURadio style.  Do I make a more general case or a specialize case? I
> noticed GNURadio has some framing and bit sync blocks I need to look at
> more.
>

Those are a good place to look.

> PPM is decoded by comparing the amplitude values in the 1 time period to
> the 0 time period.  This is like FSK but uses time instead of frequency.
> The timing is such that each 1 uS of time is a symbol.  There are 4
> symbol states.  I am remapping 0 and 1 as the valid data values.  I need
> some decision logic to determine the presence of a pulse.  The block
> also needs pulse sync logic. So the block takes in samples and outputs
> symbols.
>

Yes, there are a few blocks which do similar things.  Look at the GMSK
code in particular.


> The next block looks for the preamble pattern and valid data frames by
> looking at the timings of valid (0, 1) versus invalid (2,3) symbols.  It
> outputs valid data frames.
>
> I get the impression that this is the general flow for digital decoders
> in GNURadio although the framing is usually separate from the decoding.
>  Am I on the right track with this?
>

Yes, you are.  Let us know how it is going!

Matt
This topic is locked and can not be replied to.