Topics

adsbdec : an opensource adsb decoder for airspy R2 and mini

TLeconte
 

If you need  an opensource adsb decoder for airspy R2 or mini, take a look at my new github project :
adsbdec

It's quite basic : it only send raw format output to stdout or an TCP socket, but it is sufficient to feed VRS or other servers.

prog
 

On Mon, Oct 15, 2018 at 01:15 AM, TLeconte wrote:
If you need  an opensource adsb decoder for airspy R2 or mini, take a look at my new github project :
adsbdec

It's quite basic : it only send raw format output to stdout or an TCP socket, but it is sufficient to feed VRS or other servers.
Thanks for sharing. Interesting how you sum the I's and Q's before demod.
You can easily evolve it from IQ to Real data. This will save a lot of CPU and give you twice the current clock. Other tricks are also possible once you go Real.
Good stuff.

TLeconte
 

On Mon, Oct 15, 2018 at 01:23 AM, prog wrote:
Thanks for sharing. Interesting how you sum the I's and Q's before demod.
Thanks to have the curiosity of looking at the code and spotted its only one originality.

You can easily evolve it from IQ to Real data. This will save a lot of CPU and give you twice the current clock. Other tricks are also possible once you go Real.
eh you're right !
Summing the iq vector before computing  magnitude  is equivalent to the very basic dsp  practice of using two filters in quadrature and squaring and summing theirs output to detect a modulated pulse.
I just modified the code, only a few lines to change.
It does not really save lots of CPU because now I do all the following work at two times the clock.

Now, I have to rewrite the network code. It was a rapid try and have to sophisticate it a little.

But, I have a question : do you know any spec of adsb pulse shape ?
All I have is  0.5us duration  with rise and decay time between 0.05 and 0.1 us , not really a shape ...
Experimentally, I saw very often, not symetric, distorded shape, but I don't think there is really something to win by equalization.







prog
 

On Wed, Oct 17, 2018 at 10:08 PM, TLeconte wrote:
But, I have a question : do you know any spec of adsb pulse shape ?
All I have is  0.5us duration  with rise and decay time between 0.05 and 0.1 us , not really a shape ...
Check the ICAO website for the exact specification. In fact, there's no pulse shaping whatsoever. The RF signal is just switched on and off at precise intervals. The resulting RF might have some spectral leakage due to this fast switching, but you should still be able to filter it. Your previous IQ implementation is the equivalent of a moving-average LPF applied to I and Q separately. This removes some of the leakage and improves the SNR.

Experimentally, I saw very often, not symetric, distorded shape, but I don't think there is really something to win by equalization.
Try analyzing the distortion, and apply different filters or a combination of many filters at different stages. My decoder has a BPF applied to the real signal at 20MSPS (or 12MSPS). But, if you go this route and still want your program to run on things like a Raspberry Pi, you will probably need highly optimized code (and a few tricks that are not in the book). In any case, it's a very interesting recreational subject.

Have fun!

TLeconte
 

I just released a V1.0 https://github.com/TLeconte/adsbdec/releases/tag/V1.0
Since my first post , i rewrite network output code with a dedicated thread, fix lots of bugs in packet validation code and slightly change the matched filter.

prog
 

On Sat, Oct 27, 2018 at 12:22 PM, TLeconte wrote:
I just released a V1.0 https://github.com/TLeconte/adsbdec/releases/tag/V1.0
Since my first post , i rewrite network output code with a dedicated thread, fix lots of bugs in packet validation code and slightly change the matched filter.
You can get rid of I and Q variables. The matching filter works fine with Real signals. Good job!

Benchmark time: Did you compare with airspy_adsb?

sergsero
 

Hello,
Thank you very much for your work.

Could you clarify, given the changes in the code to released yesterday V1.0, is it correct that the value of #define AIR_SAMPLE_RATE in air.c for airspy R2 must be 10000000 instead of 20000000?
To avoid the message 'did not find needed sampling rate' on stdout.

Also may be useful to make specify the value of gain as an external parameter, in order to avoid overloaded when using a high-efficiency antennas.

Best regards,
sergsero

prog
 

On Sun, Oct 28, 2018 at 08:24 AM, sergsero wrote:
Could you clarify, given the changes in the code to released yesterday V1.0, is it correct that the value of #define AIR_SAMPLE_RATE in air.c for airspy R2 must be 10000000 instead of 20000000?
Note that all Airspy One units support 20MSPS and 12MSPS real.

TLeconte
 

On Sat, Oct 27, 2018 at 08:25 PM, prog wrote:
Benchmark time: Did you compare with airspy_adsb?
I use a NVIDIA JETSON TX1:
Linux tegra-ubuntu 3.10.96-tegra #1 SMP PREEMPT Sat Jan 14 13:20:56 PST 2017 aarch64 aarch64 aarch64 GNU/Linux
and others exotic boards; It's why I wrote an open source decoder (and for the fun too)

TLeconte
 

On Sun, Oct 28, 2018 at 08:24 AM, sergsero wrote:
Could you clarify, given the changes in the code to released yesterday V1.0, is it correct that the value of #define AIR_SAMPLE_RATE in air.c for airspy R2 must be 10000000 instead of 20000000?
To avoid the message 'did not find needed sampling rate' on stdout.
Yes the correct value is 10000000, even if I use real value at 20Mp/s , the airspy_get_samplerates libairspy function return values for IQ stream and I compare its  results with AIR_SAMPLE_RATE

When did you get 'did not find needed sampling rate' ?

Also may be useful to make specify the value of gain as an external parameter, in order to avoid overloaded when using a high-efficiency antennas.

Sure. I forgot that. Will add a parameter for sensitivy gain

TLeconte
 

On Sun, Oct 28, 2018 at 08:24 AM, sergsero wrote:

Also may be useful to make specify the value of gain as an external parameter, in order to avoid overloaded when using a high-efficiency antennas.

stupid me .
The option already exist (-g) I just not document it ...

Jim T
 

Just seen you request for pulse shapes.  The Annex 10 Vol 4 spec is contained in the attached pdf.

Not very helpful regarding the actual shape but, it's what they require of airborne equipment.

Hope it helps

TLeconte
 

On Sat, Oct 27, 2018 at 08:25 PM, prog wrote:
You can get rid of I and Q variables. The matching filter works fine with Real signals. Good job!
Thanks, but I'm a little slow.
I just realize, that, if I use an odd length filter, half the coefficients will be 0, so I could collapse the two I/Q filter into one, summing alternatively for I and  Q.
Works great, with even better results, on my input test files  than before.

prog
 

On Wed, Oct 31, 2018 at 09:26 PM, TLeconte wrote:
half the coefficients will be 0
That's a "happy coincidence" that only happens when you sample at a multiple of the pulse rate.

TLeconte
 

On Sun, Oct 28, 2018 at 08:24 AM, sergsero wrote:
Could you clarify, given the changes in the code to released yesterday V1.0, is it correct that the value of #define AIR_SAMPLE_RATE in air.c for airspy R2 must be 10000000 instead of 20000000?
To avoid the message 'did not find needed sampling rate' on stdout.
It seems I just understood what happens with this sample rate problem :

I design & test adsbdec with a possibly  old libairspy lib coming from my Linux distrib.
It seems that this lib have a problem with airspy_get_sample, that always return 10/5 Mps whatever is the sample type.
I thought It was normal behavior and workaround it.
Now, I switch to a x86_64 platform and use a libairspy compiled from the last sources, and this version return correct sample rate depending of the sample type.
I commit changes to all my airspy projects on github (arcarsdec,vdlm2dec,airwav and adsbdec) to work with this libairspy  version .

Hope this helps

prog
 

On Tue, Nov 13, 2018 at 10:11 PM, TLeconte wrote:
It seems I just understood what happens with this sample rate problem :

I design & test adsbdec with a possibly  old libairspy lib coming from my Linux distrib.
It seems that this lib have a problem with airspy_get_sample, that always return 10/5 Mps whatever is the sample type.
I thought It was normal behavior and workaround it.
Now, I switch to a x86_64 platform and use a libairspy compiled from the last sources, and this version return correct sample rate depending of the sample type.
I commit changes to all my airspy projects on github (arcarsdec,vdlm2dec,airwav and adsbdec) to work with this libairspy  version .

Hope this helps
Thanks for the update. Btw, the latest firmware supports some sample rates that are not listed. For example, the Airspy Mini supports 10 MSPS IQ (20 MSPS Real) and the Airspy R2/R0 support 6 MSPS IQ (12 MSPS Real). You can try forcing one sample rate and check the return value. If the call fails, you can set the device default.
Note that when setting the sample type to one of the real modes (int16 real, float real or uint16 raw), you should double the sample rate. For example 20 MSPS instead of 10 MSPS.
Also, note that the spectrum is inverted in Real mode - This matches the negative Low-IF image.

TLeconte
 

On Wed, Oct 17, 2018 at 10:32 PM, prog wrote:
Try analyzing the distortion, and apply different filters or a combination of many filters at different stages. My decoder has a BPF applied to the real signal at 20MSPS (or 12MSPS).
About filtering, I just try to play with IF bandwidth (Yes again)
By setting register 10 to 0xBF and register 11 to 0x06, I got a  near symmetrical ~6Mhz bandwidth, that seems largely sufficient for adsb.
It seems that it improves things a little. It's difficult to say for sure, because range depends a lot from the traffic,  but  at least did not hurt at all.

prog
 
Edited

On Fri, Nov 23, 2018 at 01:34 PM, TLeconte wrote:
About filtering, I just try to play with IF bandwidth (Yes again)
By setting register 10 to 0xBF and register 11 to 0x06, I got a  near symmetrical ~6Mhz bandwidth, that seems largely sufficient for adsb.
It seems that it improves things a little. It's difficult to say for sure, because range depends a lot from the traffic,  but  at least did not hurt at all.
Anything over 2MHz would work, but I just leave the IF bandwidth to the default value.
Note that the IF spectrum is not centered because the architecture is Low-IF. If you reduce the bandwidth, make sure you retune the LO so that the center of the IF spectrum matches 1090 MHz.