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.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 24.03.2007 18:18
on 25.03.2007 19:52
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
on 25.03.2007 20:23
Eric Blossom 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
on 27.03.2007 05:26
> > 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