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.
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.php?=&p=22004
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
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 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
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