High performance VHDL ADS-B decoder open sourced

I am open-sourcing a high performance hardware accelerated ADS-B decoder that is compatible with the bladeRF ( a full SDR that has been used in FA’s FlightFeeders in the past ). The decoder, and all relevant VHDL, C, and MATLAB design files are available open source on Github, https://github.com/Nuand/bladeRF-adsb. The decoder is able to squeeze every last bit of performance out of the 12bit 40MSPS frontend. The decoder has a range of >270miles, can resolve many bit errors, and correct for packet collisions; these features that have only been available in commercial decoders until now. The decoder runs on the FPGA instead of the CPU, meaning that even a RapsberryPi is able to handle the decoder’s maximum performance. The decoder is compatible with the dump1090 visualizer, however it simply passes fully decoded hex packets to dump1090 for displaying flights.

Current ADS-B decoders such as dump1090 process all of the incoming radio signals in software on general purpose CPUs such as Intel i7 desktop processors or embedded ARM processors on RaspberryPis. To allow dump1090 to process samples in realtime, several CPU intensive operations that would significantly boost the range of the receiver cannot be performed. One such operation is decoding ADS-B frames when multiple transmitters are talking. Another example is bruteforcing the incoming signal to fix one or two bit errors in a packet. We experimented trying to improve dump1090’s performance however we found that even a very recent Intel i7 cannot perform these operations in realtime. Fortunately, these operations can be parallelized and made to run in realtime when implemented on an FPGA. As an example, a bladeRF x115 can fit around ADS-B 170 decoder units, where each one of those decoder units can process data faster than an i7. In practice the ADS-B FPGA implementation, can outperform a cluster of Intel i7s. This is all because the decoder units are very efficient, and run many range boosting computations in parallel.

The decoder runs on any bladeRF including the bladeRF x40 and bladeRF x115. Any low noise amplifier works with the bladeRF, however there is a bladeRF specific LNA available, the XB-300, 50% off with coupon code ADSB.

The source code and documentation are being released in conjunction with a multi-part series that explains the applied DSP theory and FPGA implementation of the ADS-B decoder for those that are interested. The first article starts off with a quick background of applied digital signal processing, and how and why it relates to high performance ADS-B decoders. The next article will be a MATLAB based deep dive into ADS-B, and flight phenomenon that affect RF. The series can be found here, http://www.nuand.com/adsb/

sounds really interesting!

did you perform one-to-one tests against eg raspi with dongle or radarcape?

cheers
tom

…the bladeRF ( a full SDR that has been used in FA’s FlightFeeders in the past )…

Any reason why it is no more used in FlightFeeder?

Yikes!!

Definitely graduate level ADS!

Reading the license, I don’t think it could be called Open Source. There is no Open Development allowed.


1. Source code may not be modified...
2. Evaluation of software may not last for longer than 30 working days...


1 Like

Interesting…

I got a altera Cyclone ii lying around somewhere in the house, but too bad it does not have Radio Receiver, else I would be interesting to see how it works

Agreed it sounded neat but I stopped looking after first reading the license as well. If I am reading this correctly this might as well be closed source. It appears to be open sourced much like how Microsoft open sourced Windows for large enterprises. You can look but you can’t touch… Also am I correct in concluding after reading the following lines in your license that this needs licensed after 30 days? An open source trial version available on GitHub is a new one for me… Then again it may not be of much use without their hardware which at that price I hope would come with a license for the software.

Evaluation of software may not be deployed on more than 5 devices or
last for longer than 30 working days from the time of first use of the Software.

Closed source - not open. Too bad. Time to move on. Maybe they will correct that and make is really make it open.

1 Like

sorry - but i think to discuss what kind of ‘open source’ it is - leads to nowhere.

the only thing of interest first is - whether it outperforms pi+dongle+dump significantly - if not who cares about open source or not …

You lack understanding of how any of the software you use came into existence and is improved upon.

Oh it will out perform your RPi I am sure if you are willing to pay US$600.00+.

Only reason I point out the license is the fact it is a little shady to come out and say look we open sourced our code on GitHub then stick a blatantly commercial license on it not allowing you to do anything with it. “Open sourcing” software this way is like someone winning the use of a sports car for 30 days but you need to buy the car first before you are allowed to use it for only 30 days and on top of that not be able to share the experience with your friends during or after your test drive…

https://www.youtube.com/watch?v=4FFG1NqKzCg)

[quote=“jprochazka”]

Oh it will out perform your RPi I am sure if you are willing to pay US$600.00+.

Only reason I point out the license is the fact it is a little shady to come out and say look we open sourced our code on GitHub then stick a blatantly commercial license on it not allowing you to do anything with it. “Open sourcing” software this way is like someone winning the use of a sports car for 30 days but you need to buy the car first before you are allowed to use it for only 30 days and on top of that not be able to share the experience with your friends during or after your test drive…

https://www.youtube.com/watch?v=4FFG1NqKzCg)
i’m not sooo shure that it will outperform - i did so much testing the last year and there was nothing that really outperformed my raspi/dongle/amp/antenna combo. nearly zero more aircrafts and only a couple of messages more. that’s why i first want to see how it performs before i spend a single thought about their software license :slight_smile: btw $600 is about the same radarcape costs.[/quote]

A bladeRF is one of the better SDR’s out there and should perform better than any dongle out there for the facts he stated.
Also keep in mind this software is of no use to anyone not using a bladeRF.

all theory - which came not true in my own testings up today …

click to enlarge:
https://dl.dropboxusercontent.com/u/39745369/ads-b_site_s.jpg

You’re comparing antennas attached to an RTL-SDR. You’re not testing the receiver at all.

o man - tested different dongles, radarcape, airspy, etc.

Unfortunately I have not be able to do a real range test of this system. Some simple math says that an antenna mounted at 0 feet in elevation should be able to hear a plane (flying at 35k ft) about 230 miles away. On top of this there are tunneling and scattering effects that can provide an additional boost of 20 to 40 miles. An antenna mounted at an elevation of 400 feet should be able to hear planes about 270 miles away (10 extra miles per 40 feet of elevation). In effect the range of this decoder is limited only by the curvature of the earth. However the real gains come from the fact that bit errors and collisions can be detected and corrected. The VHDL decoder can decode multiple packets simultaneously, while dump1090 will only “latch” on to one ADS-B packet at once. This is important because as the number of planes increases in a square relationship with any increase in range, which means that the amount of time packets aren’t likely to be colliding also decreases. To effectively decode all incoming packets within even a 200 mile range, the decoder needs to be able to “latch” on to a signal with sufficient SNR even if it is currently decoding another incoming packet. This decoder not only boosts range but it does its best to decode every packet within that range.

https://nuand.com/calculations.png

Also the license is being cleaned up a bit more to allow modification and distribution, sorry about that oversight!

The other factor relating to packet collisions is that the number of transmissions increases due to traffic density because TCAS replies also use 1090MHz. The more planes there are, the closer together they are, the higher the packet rate. If you have many planes close together, such as arriving and departing a major airport, there will be more air-air traffic than somewhere where they are evenly spaced over a wide area.

You can see the effect in this graph from some data I collected:

Really good stuff. I have noted that differing strategies and settings may be best depending upon the primary type of traffic that is monitored, i.e. arrival/departure or en route. I am very close to a major airport and am very interested in your results. What are the axis labels for the graph?

I have noticed something that I call a “ground plane bloom” where I will see a multitude-fold increase in the number of aircraft visible on the surface and then within a minute or so they will all have disappeared again. At first I thought this phenomenon was hardware related but I have two system running that use different dongles/amps/filters/antennas and both will see this occur. You may have given me a clue as to what I am witnessing.

As an old radar man, we had the advantage that our antenna was directional, and thus limit the area of reception.

But this is also a good method for passive systems. That is, if your station is composed of three directional beams (with low sidelobes and backscatter) to cover 360 degrees, then each receiver can reduce its collision replies.

Since receivers and computers are cheap, it would benefit the ground station to use three directional antennas, and combine the computers output at a server.

In one system where we passively listened to enemy emissions, we had two antennas - one on each side of the tail. Each antenna had a separate receiver and processor, and only at the computer were the UDP network detection’s correlated and combined for display on the radar scope.

When we used to fly over Central America, we’d often see targets over 400 miles away that were over the horizon. This “ducting” was quite common in the Caribbean. Then too, the target densities were much lower, than say flying over Atlanta :slight_smile:

Omni antennas - Just say no! :slight_smile: