Using a Software Defined Radio (SDR) to decode APRS packets

[plugger]

For some time now I've been exploring different ways of receiving and decoding APRS packets from the GPS transmitters I use (AltusMetrum and Big Red Bee) for backup telemetry, telemetry logging, and redundancy. Effectively all of my past work in this space has used handheld radios (in my case a Yaesu VX-8GR and a cheap Baofeng) to provide the radio link and in the Yaesu's case decoding of APRS packets. You can read about those efforts here.

GPS, APRS, and serial (or how I came to realise that redundancy and data are both good things)

More recently I've been playing with Software Defined Radios (SDRs) for non-rocketry related purposes such as decoding weather satellite transmissions and decoding POCSAG traffic. Last week I finally had the epiphany that this work is directly applicable to rocketry in terms of decoding APRS packets.

So take the TeleGPS for example. I always configure my AltusMetrum hardware with GPS to transmit APRS packets once every 5 seconds alongside the already enabled AltOS telemetry transmission. I like this as it gives me a 'fallback' in case I'm having issues with Altus Telemetry and it gives me a independent way to confirm that the unit has GPS lock and is transmitting coordinates. Below is what that transmission looks like in SDR++, a open source SDR application that has waterfall capabilities. The thin lines are the AltOS telemetry transmissions and the fatter/more square transmissions are APRS packets.



Given we know that APRS are AX.25 packets transmitted via AFSK at 1,200bps we can use rtl_fm to listen to the frequency our transmitter is transmitting on and then pipe that audio into multimon-ng which demodulates the AFSK1200 transmission and displays the APRS packets in output, as seen below.



Obviously my transmitter didn't have GPS lock but you can clearly see the Lat/Long/Altitude values as well as battery voltage and my unit's serial number. I'm pretty sure the "U" value is number of satellites the receiver has lock with.

To do this I'm using a RTL-SDR v3 SDR which costs $30. This unit has a SMA F connector which allows one to use the same antennas they already own and use for tracking rockets. In my tests I used a Nooelec RaTLSnake UHF/VHF stubby antenna which cost $16.

This requires a computer running Linux to use rtl_fm and multimon-ng but it's the cheapest and simplest way I've found to decode APRS packets. Moving forward I'm going to look into piping the output into a guified GPS app to get a map overlay of coordinates. And given how low overhead rtl_fm and multimon-ng are I could run this on a Raspberry Pi Zero board to have a compact battery powered handheld solution.

 

[Crayok]

Very cool Plugger

The world of SDR is huge along with wide availability of open source software. You may have seen the Dire Wolf software that does the audio decoding of the packets and provides the c source, if you want to play. another benefit if the tones are off it can adapt. there are a few mapping software hooks for dire wolf too.

https://github.com/wb2osz/direwolf

Also if you are doing Linux check out GNURADIO

https://github.com/gnuradio/gnuradio

you can configure decoding here right from the IQ stream if you have a good enough computer.

enjoy!
David

 

[Crayok]

Had to run down a take a picture of my setup.

Pi3 with screen, running direwolf and setup to digipeat via the Baofeng. The Baofeng I use because I can make it crossband repeat 433.925 (or your receive freq) and retransmits to the local 144.390 APRS area this way I can use, or anybody can use, their local mapping for APRS. I could use the small screen on the pi to show the maps too but opted to use my existing setup. For me this was simpler.

The pi will run on the battery pack for a few hours. A pi zero should also be able to do the same thing.
David

 

[plugger]

Very cool Plugger

The world of SDR is huge along with wide availability of open source software. You may have seen the Dire Wolf software that does the audio decoding of the packets and provides the c source, if you want to play. another benefit if the tones are off it can adapt. there are a few mapping software hooks for dire wolf too.

https://github.com/wb2osz/direwolf

Also if you are doing Linux check out GNURADIO

https://github.com/gnuradio/gnuradio

you can configure decoding here right from the IQ stream if you have a good enough computer.

enjoy!
David

Thanks for the posts David, I really appreciate it! I'm certain I could do with with GNU Radio but tbh that would require me to 'build out' the radio receiving and decoding (from how I understand it). It's incredibly powerful but I'd have to make it work instead of using a bash one liner to spit out what I'm after.

I was also across Dire Wolf but hadn't considered using it. And you're right about it's ability to magically decode slightly off packets, a mate of mine was blown away by it when he used it. I just went over to their Github page, this is very encouraging!

So I should be able to yank out multimon-ng and drop in Dire Wolf as it's already got rtl_fm support inbuilt. That would then allow me to use the already existing software hooks for mapping that Dire Wolf has to plot the coordinates over a map! Thanks so much for the tip.

That's an incredibly cool digipeater setup you've got there!

 

[plugger]

I was able to look back into this on Friday night and get DireWolf to work as a drop in replacement for Multimon-ng. So I'm able to listen with rtl_fm and pipe that into DireWolf to decode the APRS packets with the following command.

rtl_fm -M fm -f 434850000 -s 22050 | direwolf -n 1 -r 22050 -b 16 -

Which can be seen below.



As @Crayok mentioned, DireWolf supports multiple hooks for connecting to mapping software. I chose to have a go with Xastir, primarily because it's already available in the default Debian 10 package repos. DireWolf supports the AGWPE network protocol on port 8000, so once it's running you can just tell Xastir to use it as an interface and it'll start seeing the coordinated being outputted by DireWolf.



Honestly, I didn't expect it to be quite so easy. Thanks for the tip David!

Moving forward, I'm going to see what options Xastir has and what other mapping apps are available. I think having topological and street map overlays would be a nice to have from a 'planning my recovery' perspective. I'd also like to feed in the GPS location of the ground station (laptop, raspberry pi, whatever) with a USB GPS module. It seems like Xastir should support this out of the box.

I'll do some flight tests to compare the ability to decode packets between my RTL-SDR and my Yaesu VX-8GR. That'll have to wait till next year when fire bans are lifted though. I expect comparable performance and I also expect with an appropriate LNA and filter a SDR combined with DireWolf could perform significantly better when compared to my Yaesu.

Finally, because the SDR is frequency flexible 2M and 70cm transmissions can be decoded by this method. So effectively I can use this with all AltusMetrum GPS transmitters (with APRS enabled of course), Big Red Bee 2M and 70cm GPS transmitters, as well as Eggtimer GPS units with this software stack.

BRB 900MHz units use ZigBee FHSS radios and Featherweight GPS uses LoRA on 900MHz (single channel at least) but appears to not support APRS/NMEA strings. So both of those are outside the scope of this system.

 

[Crayok]

Honestly, I didn't expect it to be quite so easy. Thanks for the tip David!

I am glad the tip helped! Nicely done. What you may find with the smaller SDR dongles, they are not very sensitive and in the real world when the rocket is down the signal strength drops to zero if you are using the Altus Metrum stuff I believe the transmit power is 100mW or so, not a lot of RF budget to play with. I upgraded to the SDR play modules and it is way better for sensitivity but at a greater cost of course. And better antennas...

https://www.sdrplay.com/

Moving forward, I'm going to see what options Xastir has and what other mapping apps are available. I think having topological and street map overlays would be a nice to have from a 'planning my recovery' perspective. I'd also like to feed in the GPS location of the ground station (laptop, raspberry pi, whatever) with a USB GPS module. It seems like Xastir should support this out of the box.

The reason I digipeat to the APRS network is for the reasons above. A while ago we had a few folks on our recovery team for a two stage project that would be coming down in multiple sections, each section had location telemetry plus each recovery vehicle had APRS, out and in.. On one map we could see where everybody and everything was, very cool. Now we just needed the two stage to go as planned...

Our down link was 900Mhz for the data telemetry (maxstream/digi modems FHSS) and used a micro controller to reencode the stream to the APRS format and tx out, Now if we started with the APRS protocol it would have been simpler.

@Steve Shannon has the same idea to have one transmission packet standard in another thread:
https://www.rocketryforum.com/threa...ization-for-gps-trackers.169122/#post-2197047

and APRS would seems to fit, whether your retransmitting on APRS or just using it point to point. It offers the ability/flexibility to transmit what we need plus offers data compression for more reliability in congested environments. It is a well proven and understood protocol.

I have not used Xaster very much, back in the day was using MS Mappoint with some extra software and Packet Engine Pro, really nice maps. Very outdated but no requirement for connection to the world for map data.

 

[plugger]

I am glad the tip helped! Nicely done. What you may find with the smaller SDR dongles, they are not very sensitive and in the real world when the rocket is down the signal strength drops to zero if you are using the Altus Metrum stuff I believe the transmit power is 100mW or so, not a lot of RF budget to play with. I upgraded to the SDR play modules and it is way better for sensitivity but at a greater cost of course. And better antennas...

I'm not surpirsed the SDRplay unit provides you with good results given it's inbuilt LNA. But I think you'd be surprised at just how sensitive the RTL-SDR v3 dongles are in real world usage. I have a AirSpy Mini as well as a HackRF One and the RTL-SDR is just flat out better than both of them from a sensitivity perspective. Librespace recently did a comparison of SDRs for the SatNOGS project which highlights just how sensitive those units are; the results can be seen below.


Full paper can be found here.

I've got a cheap SPF5189z LNA from Ali as well as a NooElec LoNA already and I've got another wideband LNA coming later in the month. I figure I'll be getting comparable performance to your SDRplay once I have one of those in line with the RTL-SDR. Plus I'm fairly well stocked with Yagi's, which should help.

The reason I digipeat to the APRS network is for the reasons above. A while ago we had a few folks on our recovery team for a two stage project that would be coming down in multiple sections, each section had location telemetry plus each recovery vehicle had APRS, out and in.. On one map we could see where everybody and everything was, very cool. Now we just needed the two stage to go as planned...

@Steve Shannon has the same idea to have one transmission packet standard in another thread:
https://www.rocketryforum.com/threa...ization-for-gps-trackers.169122/#post-2197047

and APRS would seems to fit, whether your retransmitting on APRS or just using it point to point. It offers the ability/flexibility to transmit what we need plus offers data compression for more reliability in congested environments. It is a well proven and understood protocol.

I have not used Xaster very much, back in the day was using MS Mappoint with some extra software and Packet Engine Pro, really nice maps. Very outdated but no requirement for connection to the world for map data.

I like your digipeat use case, that actually makes a lot of sense. And that's part of the reason why I'm doing this as well, I want a reasonably cheap and reliable way to track a couple stages and have a guified map overlay to assist in recovery. I also want a backup APRS telemetry system with logging for flights. So it made sense to start exploring these options.

And I agree that APRS fits for the one transmission packet standard thread Steve started. But even when units support NMEA / APRS sometimes it's not easy to decode that DIY given some units (BRB 900 for instance) use Frequency Hopping. I'm sure this could be done in software but I'm not to keen on 900MHz full stop, so I'm not too concerned about it. And for simple Lat./Long. and Altitude telemetry APRS is very nice, but it is analog and inefficient. Moving to packet radio for telemetry is obviously the way forward for higher frequency telemetry as well as more data within the stream. But given the multitude of radios out there for FM packet radio I'm not sure how one would go about organising a packet standard. I'm no expert though, so maybe someone has more knowledge will come around and sort this out.

 

[Crayok]

I'm not surpirsed the SDRplay unit provides you with good results given it's inbuilt LNA. But I think you'd be surprised at just how sensitive the RTL-SDR v3 dongles are in real world usage. I have a AirSpy Mini as well as a HackRF One and the RTL-SDR is just flat out better than both of them from a sensitivity perspective. Librespace recently did a comparison of SDRs for the SatNOGS project which highlights just how sensitive those units are; the results can be seen below.

Wow a lot of work doing the comparisons, although I have not seen the 2.5 db for the Duo (I have the RSP1A ) so maybe that is a bit better. Thanks for the link and recent information!

Both smaller/cheaper SDRs I have run the R820T/2 so they are noisier/less sensitive than the RSP1A. Mind you build and component selection really plays a big role. I have found some of the cheaper LNA's are really noisy, lots of filtering helps and of course band passing for the freq you want which your get in the higher cost sdr's The hack one has band filtering does it not? Been really looking at that one from a transceiver perspective, lots of flexibility and power.

Part of doing Rockets and electronics is to find alternate solutions!!

And I agree that APRS fits for the one transmission packet standard thread Steve started. But even when units support NMEA / APRS sometimes it's not easy to decode that DIY given some units (BRB 900 for instance) use Frequency Hopping.

Yes FHSS is an issue. Last couple of launches some flyers with the not very sensitive receivers had to RDF to the signal to get a better signal level for the manufacturer receivers. One had the FHSS modem, ok what channel where they on, nope did not know. Possible to RDF if no others TXing but here in Alberta there is piles of SCADA sites all over and they use 900Mhz too, so it was useless to RDF even on one of the hopping freqs, still have not found that rocket.

David

 

[Crayok]

APRS is very nice, but it is analog and inefficient. Moving to packet radio for telemetry is obviously the way forward for higher frequency telemetry as well as more data within the stream.

Most if not all new amateur radios are digital now and I imagine will start to shift, if it was not already, to using the digital side and include error detection and correction, now just need to pick one format or modulation. D-star seems to be the one for digital data transfer.

https://en.wikipedia.org/wiki/List_of_amateur_radio_modes

dB

 

[plugger]

The hack one has band filtering does it not? Been really looking at that one from a transceiver perspective, lots of flexibility and power.

I'm going to make the assumption that you meant HackRF One. Just a quick caveat, please be aware that it is by far the WORST sdr I own for sensitivity purposes. I bought it so I could play with S-Band satellite transmissions due to the fact that most other SDRs stop working at around 2GHz. But in the amateur satellite communities they refer to them as DeafRFs. My experience with it supports this as well. That said for frequencies higher than 2GHz it's by far and away the most cost competitive option. But you get what you pay for. I got mine from AliExpress to minimise cost as well but invariably I'll end up getting a LimeSDR Mini in 2022.

Yes FHSS is an issue. Last couple of launches some flyers with the not very sensitive receivers had to RDF to the signal to get a better signal level for the manufacturer receivers. One had the FHSS modem, ok what channel where they on, nope did not know. Possible to RDF if no others TXing but here in Alberta there is piles of SCADA sites all over and they use 900Mhz too, so it was useless to RDF even on one of the hopping freqs, still have not found that rocket.

I've also tried to do this with an RF Explorer and a 900MHz Yagi. Misery ensued and the rocket is still MIA. I would not recommend!

 

[waltr]

I've also tried to do this with an RF Explorer and a 900MHz Yagi. Misery ensued and the rocket is still MIA. I would not recommend!

the RF Explorer is a great instrument but is not sensitive so not considered a 'receiver'. Haven't tried putting an LNA in front to increase sensitivity but should help.

 

[Crayok]

I'm going to make the assumption that you meant HackRF One.

Yes the HackRF One. It was 8 bit too.

 

[plugger]

the RF Explorer is a great instrument but is not sensitive so not considered a 'receiver'. Haven't tried putting an LNA in front to increase sensitivity but should help.

When you only have one thing in the box that will even receive on 900MHz, you use what you got!