Table of Contents
Feeding HFDL data to the OARC Flight Tracker
We're now accepting HFDL data into the aggregator. This data will not be full of the information that ADS-B is. You'll get a position and a track, a hex and a callsign, and that's about it. Not even altitude. The update rate is quite slow - sometimes every 30 minutes or so. This technology is old and is being phased out in favour of higher data rate satellite transmissions. However, until we get more feeds in other countries or someone to do Satellite ADS-C this is the best way for us to add some more planes to the map. We may look into ACARS as well, which should work with this new setup.
Requirements
- An SDR - this may require extra drivers, SoapySDR, or similar
- A suitable Linux system, probably a Raspberry Pi (I haven't looked into doing this on Windows yet - can you help?)
- dumphfdl installed
- A HF antenna you can leave listening - if you are transmitting also from your QTH this may be an issue for you without an antenna switch or SDR isolator or something
Installation
First you need to install dumphfdl. The instructions are marvellous and there's no point me replicating them. Here's the repo: https://github.com/szpajder/dumphfdl
Secondly you'll need to make sure your SDR is working. If you're using an RTL-SDR in direct sampling mode then you should be ok by default on Raspbian, but I use an RSP1a for HF so I've no experience with doing that. I use that through SoapySDR and the appropriate extra module for SDRPlay devices. I believe an Airspy HF can be used also, or possibly other devices.
Configuration
Decoding/Feeding
The best way to run dumphfdl is under screen so that you can detach from it and come back to it later. Outputs can be sent to the screen, to an onward server such as OARC's, or your local readsb for display on your local tar1090 map. If you're doing ADS-B already you'll have these, if you're not you'll need to install and configure those (more later).
You will also need to pick a family of frequencies (here's a good list) to listen on that gets the most traffic for you - this will of course change during the day. There are solutions for this, such as this excellent script that you can hack about to your own requirements: https://github.com/wiedehopf/hfdlscript/
For a manual running, I've built up a command line as follows. I've split it up into a few lines here for readability, but you can run it on one line or put it in a bash script or whatever:
screen -S hfdl dumphfdl --soapysdr driver=sdrplay,serial=2006054C97 --sample-rate 250000 --station-id MP-EGPH2 \ --output decoded:basestation:tcp:mode=client,address=localhost,port=34567 \ --output decoded:text:file:path=- \ --output decoded:basestation:tcp:mode=client,address=adsb.oarc.uk,port=32009 \ --gain-elements IFGR=20,RFGR=2 \ 8825 8834 8843 8851 8885 8886 8894 8912 8921 8927 8936 8939 8942 8948 8957 8977
Firstly I choose the -S option for a screen and a name of hfdl to allow for easy reattaching without having to remember a screen ID number.
I then pick my SDR and sample rate of 250,000 kbps, enough to fit my entire frequency list within the passband. I'm also specifying a name, but it isn't supported by the OARC site.
Next come my outputs for the decoded data, the first being a Basestation-format output over TCP to my local readsb on a port I've configured for it. This is the SBS Jaero in port, and we'll reconfigure that in readsb shortly.
I'm then sending a text output to stdin, denoted by using - as a file path.
Finally, a Basestation-format output is also being sent over TCP to the OARC aggregator on the SBS Jaero in port that I have configured on there.
The gain elements are SDR dependent - you'll need to check some documentation on how you use your SDR with Linux here. The SoapySDRUtil command may provide some useful information here if you run it and scan your system for attached SDRs.
The last section is my list of frequencies in kHz, separated by spaces. You can fit as many as you want into the passband of your SDR, as long as your system can process that much data.
Reconfiguring readsb for local display
Obviously if you're not running readsb already for ADS-B decoding you'll need to install it from the repo linked above first, as well as tar1090. Virtual Radar Server is also an option, although you may need to check your output format to make sure it gets in ok - I'm only covering tar1090 here.
For configuring for HFDL input we just need to check the readsb config file to see if we're specifying the right input port for our data. If not we can add that in as an option and restart the service to make the change. Open /etc/default/readsb in a text editor such as nano (use sudo).
In one of the options strings, usually the NET one, you'll want to check for –net-sbs-jaero-in-port, add it if its not there, and choose a value for it that you'll also use in the dumphfdl command above.
When that's done:
sudo systemctl restart readsb
Any decodes with a valid position and ICAO hex should now show up on the map! You can now run your above dumphfdl command and start viewing/feeding your data.