Re: Mode S and ADS-B

GNU Radio
1

Hello,

I am making good progress.

The first couple of weeks or so (months?) I was collecting information.
I managed to get some design articles about Mode S transponders,
various protocol specifications, and comments. I was able to decode
some packets by sight using the oscilloscope program. The bit timing is
very tight. Thanks go to Matt E. for designing a board that can
handle a 4 MSPS sampling rate. It was now coding time! I reviewed some
GNURadio design guidelines and how to write a module.

Of course the name is most important. I decided on a subdirectory off
gnuradio named gr-mode-s. gr-transponder would make it look like
sending as well as receiving. My project is focused on Mode S data and
derivatives (TCAS, ACAS, ADS-B, TIS-B, etc). I am open to a better name
as the mode-s name forced me to use the prefix of mode_s for things.

I decided to use gr-pager as the model as it is the closest to what I
want to do. I eliminated some blocks but may put them back in. I
basically have a slicer, decoder/framer, and parser C++ blocks. I use
python code to put the blocks together into a mode S decoder superblock.

I appreciate the autoconf/automake and the whole gnuradio build scheme.
For a programmer who has only done small gcc projects it looks like
it is real work to do things from scratch. I was able to figure out
what most of the autoconf/automake files are for. I replaced the pager
prefixes with mode_s, add the required .m4 files, etc. I was amazed
that I got my new project integrated into the build tree quickly. The
major part of the time was spent getting my code to work.

So I am jumping up and down with joy as I can now decode Mode S. I can
now work on improving the slicer, add decoding of the messages, etc. It
seems like I am not getting hundreds of miles of range due to the
antenna setup but I get enough to work on the decoders.

A future to-do is to submit my code. I guess I need to join the patch
list.

It would be neat if I could get hardware that is smaller sized. Maybe a
USRP Jr board that allows one receiver or one receiver and one
transmitter board, I could also use one with a LFRX board and dedicate
it to my AR5000.

73 Eric

2

Eric A. Cottrell wrote:

GNURadio design guidelines and how to write a module.
python code to put the blocks together into a mode S decoder superblock.
now work on improving the slicer, add decoding of the messages, etc. It
seems like I am not getting hundreds of miles of range due to the
antenna setup but I get enough to work on the decoders.

A future to-do is to submit my code. I guess I need to join the patch list.
You can ask Eric to get you a svn account.
Then you can make your own private branche of gnuradio with your work in
progress (usually called wip)
As soon as things stabilize in your branche it can be easaly integrated
back into trunk.
But as long as you working on it, interested people can try out the
latest version of your code.

See for example my svn subdirs:
http://gnuradio.org/trac/browser/gnuradio/branches/developers/nldudok1
I have a digital-wip branche which is work in progress for digital QAM
stuff
and
general-wip which is my work in progress for general gnuradio things
(latest addition is gr-cxadc, a driver for cx2388x capture cards to use
as a general purpose high-speed ADC frontend as a cheap alternative for
an USRP)

Greetings,
Martin

3

Cory Papenfuss wrote:

Martin

Has there been some progress on that front then?  I've been lurking

here for awhile, but last time I looked into this I don’t think the TV
-capture cards were viable. The BT8xx chips still have holes in the
data, right? CX2388x can stream baseband without VBI holes?
Yes they can.

Look in the mailinglist for TV card SDR:
http://lists.gnu.org/archive/html/discuss-gnuradio/2007-04/msg00134.html
http://lists.gnu.org/archive/html/discuss-gnuradio/2007-04/msg00042.html

How Chee page on this:

My page on this:
http://www.olifantasia.com/projects/gnuradio/mdvh/cx2388x/cxadc/

SVN files are in
http://gnuradio.org/trac/browser/gnuradio/branches/developers/nldudok1/general-wip
cxadc is the kernel driver
gr-cxadc is the gnuradio driver/glue
gnuradio-examples/cxadc are the example scripts

In short:
We can capture without gaps from the video-input.
There is a gr-cxadc gnuradio glue driver so you can use it right from
gnuradio scripts as input (just like usrp)

Tuning any tuner on the TV-card is not implemented in the gr-adc glue
yet, I am working on that.

(If you want to use the tuner you also have to connect an IF-output of
the tuner to the video-input.)

How Chee has used the 10.7 Mhz 200 kHz wide if-output of his card.
I am working on the pcHDTV3000 card which has a 8 MHz wide IF output at
44 Mhz.

I am currently working on enabling tuning for any tuner which is on the
tv-card.
The goal is that the code will support any tuner out-there so you could
even replace a tuner without if to a tuner with if-output.

I have been using the code with an external tuner frontend and did some
experiments with fm-receiving, which just works fine.

Greetings,
Martin

4

Martin D. wrote:

Greetings,
[Discuss-gnuradio] TV card SDR
gnuradio-examples/cxadc are the example scripts

Hello,

What are the sampling rates for these cards? Can they go up to 8 or 10
MSPS? If so I might be able to try them out with Mode S.

73 Eric

5

I have a digital-wip branche which is work in progress for digital QAM stuff
and
general-wip which is my work in progress for general gnuradio things
(latest addition is gr-cxadc, a driver for cx2388x capture cards to use
as a general purpose high-speed ADC frontend as a cheap alternative for
an USRP)

Greetings,
Martin

Has there been some progress on that front then? I’ve been
lurking here for awhile, but last time I looked into this I don’t think
the TV -capture cards were viable. The BT8xx chips still have holes in
the data, right? CX2388x can stream baseband without VBI holes?

Thanks,
-Cory

–

  • Cory Papenfuss, Ph.D., PPSEL-IA
  • Electrical Engineering
  • Virginia Polytechnic Institute and State University
6

Eric A. Cottrell wrote:

alternative for

MSPS? If so I might be able to try them out with Mode S.
You could try them out.

Standard is 28.63636.0 MSPS which is normally converted using a built-in
samplerateconverter to 27 MSPS.
(The samplerateconversion is configurable but this is not implemented in
the driver yet)
So you can capture up to 14 Mhz wide signals.

I “overclocked” mine to run at 32.0 MSPS to be able to use a tuner with
a 44 Mhz IF freq.
(with 28.63636 MSPS you have a niquist boundary at 42.95 Mhz which is
right in the 40 - 48 Mhz bandpass of the 44 Mhz IF)

You must also know that the ADC is 10 bits of which you standard only
get the high 8 bits, so you don’t have a very high dynamic range.
(using some tricks it should be possible to get the full 10 bits at
halve the samplingrate)

I must say this is still work-in-progress quality.

A lot of these tv-cards do not have a tuner with a suitable IF-output
(if any) or only a “narrow-band” 200 kHz If at 10.7 MHz.
The IF-output level usually also is much too low (1 to 100 mv) for the
video-input (1 V) to use the complete dynamic range. Amplification needs
top be added to get better sensitivity and dynamic range.

To have the most fun, you also really want a tuner with a 8 Mhz wide IF
at the right IF-freq.

For now I get the best results when using an external microtune tuner
with a 5.75 Mhz IF.

I am working on getting the built-in thomson tuner of my pcHDTV3000
cx2388xx tv-card usable.

So the main work ahead is finding out which tuners are suitable, how to
connect them to the video-input (amplification) and how to tune them.

The end-product will not be equivalent to an usrp but it will be a
low-budget way to do SDR with gnuradio on quite a broad frequency range.
(0-50 Mhz using direct sampling and 50-860 Mhz using tuner)

If there is interest I am willing to supply premodified cards with the
tuner replaced with a suitable model.
(As soon as we have a good working setup)

Greetings,
Martin

7

Hello,

I got Mode S and ADS-B receiving working. I dump the messages to
standard output for redirect to a simple log file. Simple programs take
the log and decode it into English. I have not decoded all the messages
yet like Airborne Velocity.

Tick: Sat Apr 28 08:43:52 2007
Extended Squitter A/F: a6b55a Extend Cap: Unassigned 5
Airborne Position O ln: -70.949388 la: 42.521745 Alt: 6100
All-Call Reply A/F: a6b55a Extend Cap: Unassigned 5
Short Altitude A/F: a6b55a Airborne No Downlink Request Alt: 6100
Tick: Sat Apr 28 08:43:54 2007
Extended Squitter A/F: a6b55a Extend Cap: Unassigned 5
Airborne Velocity

I was having problems with GNURadio stopping while trying to receive
from the USRP. It seemed like the USB stream would stop. I thought it
was the laptop so I setup a Core 2 Duo system. The problem still
occurred. I “fixed” the problem by removing the TVRX board from RXB and
moving the DVB board from RXA to RXB. Now I can log all day.

One neat little program I use makes a kml file out of the positions and
I use Google Earth to see how good the range is. I can only receive
stuff up to 20 or so miles out. There are a number of Aircraft with
ADS-B that use Boston or fly over on the way to Europe.

As I am reading technical articles and other information I see the
techniques progressed as 1090 MHz got more crowded and more powerful DSP
chips became available. Mode S started out using simple receivers with
pulse edge timing or centered sampling of pulse amplitudes. A radar
site sends interrogations at their Pulse Repetition Frequency so the
maximum reply rate was under 450 per second. FRUIT became a problem as
more sites came on-line and aircraft started using 1090 MHz for TCAS.
FRUIT as in False Replies Uncorrelated In Time. Basically overlapping
of different Mode S signals or Mode S with Mode A/C pulses. One
interesting article outlines using 10 or 8 MSPS for the sampling rate
and using factors such as amplitudes of pulses being within 3 db of each
other and the effects of beat frequencies of interfering Mode S signals
to determine if a bit is a one or a zero. So this is turning into an
interesting DSP and data decoding experiment.

I suspect that I am in a high FRUIT environment and my limited range is
due to the basic receiver techniques I am using and the Discone Antenna.
I am currently implementing a better receiver in code and may put up a
1090 MHz antenna with a preamp.

Another interesting project is to also receive the 1030 MHz
interrogations and figure out the range and bearing of Mode S aircraft
by the timing between the interrogations and replies.

73 Eric

8

Great news indeed, but still no code in svn?

9

Eric A. Cottrell wrote:

Hello,

I got Mode S and ADS-B receiving working. I dump the messages to
standard output for redirect to a simple log file. Simple programs take
the log and decode it into English. I have not decoded all the messages
yet like Airborne Velocity.
This is great news.
Have you already got an svn accoupt so you can commit your code into a
development branche.
Or is your code available in an other way?

Greetings,
Martin

10

Now that the vmware player beta supports USB2.0 for the USRP has anyone
built a vmware image with gnuradio + gEDA + SVN, etc.?

Thanks,
Clark

Exercise your brain! Try Flexicon.

11

On Sat, May 05, 2007 at 02:09:39PM -0400, Michael D. wrote:

Michael, send me a link to your tarball off list, and we’ll host it
somewhere on gnuradio.org. Please include a README outside of the
tarball.

Eric

12

On May 3, 2007, at 10:30 PM, Clark P. wrote:

Now that the vmware player beta supports USB2.0 for the USRP has
anyone built a vmware image with gnuradio + gEDA + SVN, etc.?

I have an Ubuntu Edgy Eft VM for VMWare with GNU Radio from SVN
installed; it’s a little out of date, but it works and can easily be
updated (I’m doing that right now). The virtual HD is 8 GB, but that
could be reduced easily to save on size (I just copied it from
another install that -did- require about 8 GB of HD space).

I don’t have gEDA installed since it doesn’t seem critical to GNU
Radio compilation or execution.

I like using the VM: it’s greatly convenient to for testing simple
things such as the look of a GUI between (in my case, natively on)
OSX, Linux (32-bit), and Windows (32-bit). Also: I’ve never gotten
into 64-bit OS, but that could be done in VMWare as well since it
supports both 32- and 64-bit computing (while the other competing
programs do not, or so the reports state) … can be useful for
debugging those darn lib64 versus lib issues that pop up on the list
every now and then.

In testing, USRP <-> USB2 <-> GNU Radio does provide 32 MBps r/w, so
that’s not a limiting factor. CPU speed is good (claim 95% of full
rate), and disk I/O is OK (using the virtual HD as a native-OS file;
supposed to be almost “full speed” when using an actual partition of
disk dedicated to the VM).

The primary down-side is that graphics display update rates aren’t
great - this providing most of the slow-down when running GNU Radio
GUIs that otherwise look and work well on their native platforms.

It’s quite simple to make and pass along the files for a VMWare
player for GNU Radio, though I don’t know how large the resulting
directory will be (after tar and bzip2) … but it’s a thought for
quickly getting folks up and running in GNU Radio w/o all the hassle
of installing libraries and such, making sure the USRP is recognized
by udev, etc…

Also, where to host the VM tarball? - MLD

13

Boris Maryshev wrote:

Great news indeed, but still no code in svn?

Hello,

I am planning post-Dayton for svn. Things are not complete.

I got some panel mount N connectors and made up a simple 1/4 wave
groundplane for 1090 MHz. I tie-wrapped a 40 foot or so extending tent
pole to my back deck and was able to go 10 feet above the Discone. The
1/4 wave on the pole added about 20 miles of range over the Discone. I
also tried my AOR 5000 with the out-board IF Output amplifier into the
LFRX daughterboard and was able to get about 100 mile range on the
discone and 120 mile range on the 1/4 wave. I also got some surface
position reports from Logan. With Google Earth most of the surface
positions were located on Runways. One was in a East Boston
neighborhood but it is likely due to INS errors. Most planes takeoff
down the centerline of the runway but some are way off.

Instead of getting ready for the Dayton trip, I spent yesterday evening
using NEC to make a curly coil colinear with 1/4 wave and 5/8 wave
elements. I have not built it yet.

I implemented the new preamble detection and it works better. I need to
do the bit error detect and correction part. I thought I was getting a
lot of bit errors on some messages. I reread my background information
and found the interrogator id is XOR with the CRC. On other messages
the airframe id is XOR with the CRC. Reminds me of RDS used on the FM
broadcast band. The ADS-B and ACAS messages have an interrogator id of
zero so they are easier to check. I did a quick check of the file
generated using the AOR 5000 with the 1/4 wave antenna and found all 15
possible interrogator ids in use. I looked at the all-call replies of a
few aircraft and it was not unusual for the transponder to respond to
multiple radars.

Because I have interest in doing other aircraft receivers, I am thinking
of calling the project directory gr_air. I was also thinking about
gr_aero but people may mistake it for the Windows Vista video sink.
Mode S has a different meaning for the AMSAT crowd so it is not a good
choice.

73 Eric

14

Hew How Chee wrote:

Is the Microtune tuner still available in the market ?
Or are there any other alternatives (tuner with low IF
output)
They are very obsolete. I know Matt has been able to get a few, but he
is also running out of them.

You don’t need a low-IF output as long as the frequency of the IF is not
near a multiple of the niquist freq (half the sampling freq)

What you DO need is a large signal of the IF output. 1 Volt pp would be
ideal.

I have been looking at some Philips alternatives (I don’t know the
types/names out of my head.) which look promising.

has been used up.
I have a dual-core AMD athlon 64 X2 3800+ (2x2 Ghz)
I think only one CPU is used by gnuradio.
I haven’t looked at the processor percentages in detail.

I did have to relax the channelfilter-parameters to get it to run in
realtime.
(Ideally the filter should be a 100 kHz low-pass which results in a 200
kHz wide channel)

When using 27 MSPS sampling rate and you want a 100 kHz lowpass you get
an enourmous amount of filtertaps.
By widening the filter and relaxing the max-ripple you get away with
less filtertaps in exchange for a too wide filter.
This results in less channel selectivity.

This is what you want:
chan_filt_coeffs = optfir.low_pass (1, # gain
cxadc_rate, # sampling
rate
80e3, # passband
cutoff
115e3, # stopband
cutoff
0.1, # passband
ripple
60) # stopband
attenuation
This is the best my processor can do:
chan_filt_coeffs = optfir.low_pass (1, # gain
cxadc_rate, # sampling
rate
80e3, # passband
cutoff
1.5115e3, #
stopband cutoff
100.1, # passband
ripple
60) # stopband
attenuation

What also works for me is:
chan_filt_coeffs = gr.firdes.low_pass ( 1,
cxadc_rate,
125.0e3, #cutoff (you would want 100.0e3)
50.0e3 #transition wide, you would want 20.0e3 to 40.0e3 here
)

I know that a few years back when I was experimenting with a bt878 as
capture source (also 27 MSPS) I also ran into this.
Then I had a AMD duron 800 Mhz
For that processor I had to widen the filter to 1.6 Mhz to get it to run
in realtime.

This is when I started my attemt to build a GPGPU decimating FIR-filter
to run the filter on my videocard.
I never submitted the code because the results were a bit disappointing.
This is mainly because FIR-filters on a GPU are very much bandwidth
limited and my videocard only has a memory bandwidth of 6 Mbyte/sec.
You also have the AGP bottleneck of getting data onto the videocard.

With current videocards this could be a viable option again because
current videocards have much higher memory bandwith and PCI-express is
much
better at transporting data to and from the videocard (readback is much
better).

So I think a TV-capture card with a GPGPU decimating freq-translating
fir-filter and for the rest the normal gnuradio distribution would run
in
realtime on a lot of machines if they have a fast videocard.

Greetings,
Martin

15

Eric B. wrote:

which just works fine.

Excellent! Glad to hear you got a new machine :wink:
Yes, I am very happy with it.
But as allways, within no time I am working on the limits of the new
machine.
I am still considering a Cell-based machine (PS3).
Did you even got around to playing with that?

Are you using gr.fir_filter_ccf or gr.fft_filter_ccc?
I am using gr.freq_xlating_fir_filter_fcf
which uses:
gr_fir_fcc

The cx2388x TV capture card is a real source so I don’t use filters with
complex input like ccf or ccc.

(There’s no fft_filter_ccf since the cost for complex taps is the same
as float taps in the FFT version. _ccc will accept real taps in the
argument list and convert them to complex automagically.)
But I can’t connect a float input stream to gr_fft_filter_ccc directly.
I would have to put a float2complex block in front.
Even better a unsigned_char to complex or short to complex, (also not
yet there yet, I know)
I would also have to do the freq translation manually in front by
manually multiplying with a sinus sig_source with the right freq.

If might be more efficient to make a gr.freq_xlating_fir_filter_fft_fcf
which does all in one step

But I don’t know if an FFT version will also be much more efficient
very high decimation factors.
(I use a decimation of 100). The number of taps might run the cpu out-of
its cache, which is something fftw doesn’t like.
On the other hand log(N) is much better then N with high N.

I would have to try and do some profiling.

But for now just first get the tv-card tuner working.

No premature optimization. (I learned this from you)

Greetings,
Martin

16

I have a VMWare image of Ubuntu 7.04 (“Fiesty”) with GNU Radio’s
latest SVN installed and all the components working (that can work on
Linux). I’ve updated the Wiki with the install info on both Ubuntu
6.10 (“Edgy”) and 7.04.

This VM has been test only with Fusion (for MacOS X, right now in
beta), and thus I need others to test it out on VMWare players for
Linux and Windows. I also need someone to host it, as it’s larger
than I can get on any of my student accounts - just under 1 GB as a
bzip2 file. Any volunteers for hosting and/or testing? - MLD

17

On Mon, Apr 16, 2007 at 08:24:46PM +0200, Martin D. wrote:

you are using and how many percent of the CPU power
has been used up.

I have a dual-core AMD athlon 64 X2 3800+ (2x2 Ghz)
I think only one CPU is used by gnuradio.
I haven’t looked at the processor percentages in detail.

Excellent! Glad to hear you got a new machine :wink:

Are you using gr.fir_filter_ccf or gr.fft_filter_ccc?

(There’s no fft_filter_ccf since the cost for complex taps is the same
as float taps in the FFT version. _ccc will accept real taps in the
argument list and convert them to complex automagically.)

Eric