ADS-B woes

M0RVB January 30, 2026

I have been running an ADS-B decoder here for many years now and feeding flightradar24. However, yesterday I got an email alert that the decoder was offline. it seemed ok locally as the status said it was connected but it was no seeing any aircraft. This was last night but there were plenty of aircraft near enough. On further checking via the flightradar24 website it seemed the maximum distance seen was just 2 miles. One aircraft took off from the local airport and the decoder did see it, but only for a short while.

So, off into the loft. I swapped the dbv dongle. No change. I took the preamp out of curcuit. No change. I installed the latest fr24feed. No change. Hmmm. Then it was time for bed...

This morning I checked the collinear using the TinyVNA and it showed it was fine. I swapped the antenna lead that came with the dongle for an adapter type. No change!

Back to the software then. I have not changed the setup for ages, in fact not since I migrated the decoder from a Pi to a Linux box. And it was always fine until now.

Shutting fr24feed and dump1090-mutability down I tested the dongle via rtl_adsb. it saw lots of data. Ok... so the hardware is fine, the software is not. I ran dump1090-mutability --interactive and it showed many aircraft, so that's ok. But on running fr24feed it somehow knobbles dump1090 and sees no aircraft again.

Next, I purged both fr24feed and dump1090-mutability and reinstalled each. Same thing, no aircraft. So I purged them again and purged lighttpd as well for good measure. And started from scratch.

apt install lighttpd
apt install dump1090-mutability - and select Yes to run at boot
lightly-enable-mod dump1090
service lighttpd force-reload
dpkg-reconfigure dump1090-mutability - and set the latitude and longitude and other options, mostly choosing the defaults

Then I installed fr24feed from the .deb again and enabled it. Editing /etc/fr24feed.ini I changed this to use the beast local port - previously it just used dvbd:

receiver="beast-tcp"
host="127.0.0.1:30005"
fr24key="..."
bs="no"
raw="no"
mlat="yes"
mlat-without-gps="yes"

Then running fr24feed made it all work again. I am waiting for the stats on the flightradar24 status page to update but it is seeing aircraft out to 150 miles. The preamp is not yet back in circuit so that will get better.

Why the software decided to fail is unknown. Note that it took a bit of searching to figure all of the above out, in particular information found at https://forum.flightradar24.com/forum/radar-forums/flightradar24-feeding-data-to-flightradar24/12105-how-to-set-up-a-feeder-using-64-bit-ubuntu-linux-on-intel-platform/page4

You should also read:

M0RVB February 26, 2025

MeshCom woes

(MeshCom woes indeed but not MeshCom's fault!) As mentioned before I have been fiddling with a RAK setup and MeshCom. I had MeshCom running on both the RAK and a T-Beam device, the former connected by Ethernet adapter and running as Internet gateway, the latter by wifi and connecting to the gateway via RF. My aim was to run the RAK node in the loft connected to the 70cm collinear that is already up there and power it from one of the shack Netgear Ethernet switches. However, it has been running on the shack desk powered over USB because of the issue with the PoE board. Also, it was freezing at random intervals and so I have been using 'cu' to log the console debugging information to file to see if there was any error messages. The board would run like that form one or two days then freeze with no obvious cause - no errors, except twice it froze after a few APRS callsign error messages. Given this and given the plan to run it off a Netgear switch I planned to monitor it and use SNMP to toggle the PoE on the relevant port if it froze. That…

M0RVB April 26, 2020

Even more PC woes

So the Ethernet interface on the shack PC decided not to work at all today. It's managed by the network-manager stuff so no ideas why it had decided to go funny. Actually, it has been off colour for a few weeks now as at boot it does not see the Internet i.e. it fails to find a route but does see locally. Anyway, I've never liked network-manger, I would far rather get control of it all myself. I realise it's there for a reason but I favour a more handraulic approach. After battling it into submission and removing it from the startup scripts editing /etc/networks/interfaces has cured its tantrum. For now anyway! But I am wondering what is up with the PC now as USB failures yesterday and then a collapse of networking today... everything important is backed up so no worries there. However, I am not of the camp that these things fail slowly as I have had PCs running for years and years before. I may well use this as an excuse to get a midi-tower system I can dual boot (Windows and Linux) and get a couple of PCI cards into.

M0RVB April 25, 2020

Random PC woes

This morning the rig would not go into transmit via wsjt-x. It worked fine last night up to when everything was shut down and there were no changes to anything, hardware or software. Rebooting the PC made no difference. CAT control was working both ways and it was receiving FT8 fine. I noticed that transmitting would sometimes change the rig settings e.g. from data to non-data. I tried the flrig / fldigi combination but transmitting via this messed the FT450D’s settings up in that it was rapidly triggering tx and the rig decided to engage its internal tuner. Plugging the two USB connectors into the front USB sockets on the PC made it work but the transmit levels are mad - ALC is triggering and the rig does not generate any decent power with this turned down. ALC is on a knife-edge where it goes from very little power / no ALC via the SignaLink TX control to 50% ALC and proper power output with nothing in between. Fiddling with the audio settings on the PC and in wsjt-x makes little difference. But changing the Mode to Data/Pkt in Settings -> Radio does improve the ALC business. This was set…