I’m really curious to know why most people use dump1090 on their Raspberry Pi.
My setup is: AirNav Flightstick connected to a Rockchip motherboard with ARMBIAN for decoding and for the feeders (FR24, FA, and RB). I’m using readsb on an Ubuntu Server for tar1090 and graph1090 that receives data from the ARMBIAN (beast_in).
My first software on the Rockchip was dump1090, and it worked very well, but I wanted to try readsb, just like on the Ubuntu server.
The improvement was huge. CPU usage dropped from 30% to 15%, and the messages ratio increased significantly, as you can see in the graph (the change was on the 17th).
I think it is a matter of convenience, most users just want to have a system up and running.
When the software is offered in a bundled way they install the SD card image and of they go with dump1090. Most people will use the SD card installation since they are up and running within a fair amount of time.
FR24 offers their own variation of dump1090 and that is also fulfilling its purpose when you just use their installer.
The other way around when installing adsb.im you will get readsb as the base of the system. That isn’t as well known to the broader public as FA or FR24. In terms of use ADSB.im is easier to maintain once setup but most people don’t want to change a driving car (as a figure of speech) while moving.
Most people just want a system that runs and some fancy graphs to look at, there is a small group that want to push their systems to the limit to see what they can get out of it. That’s the target group for readsb
Another way to see the improvement is that on TAR1090 there used to be a difference of +/- 10 between aircraft seen and their positions.
Since I set readsb as the decoder, the difference is only 1-2.
There is no general improvement in decoding I don’t think. (and if there is it’s not that big)
It’s pretty easy to mistake a change in traffic with some program (or hardware) being better.
As for the CPU usage, that’s usually just not a factor for most people
Could be that you’re hitting some USB zero copy bug in an older version of the rtl-sdr driver … you’re running on a somewhat rarely used CPU probably (rockchip)
Possibly it’s just the extra code introduced into dump1090-fa to support the new FA Pro Stick / higher sample rate decoding.
readsb likely won’t support that (but it’s not that complicated to run some decoder like dump1090-fa / stream1090 and feed the data into readsb for display with tar1090)
Maybe your MLAT is working now and previously it wasn’t?
I’ve built readsb (with dump1090-fa as the base at some point) mostly for extra functionality that’s not available in dump1090-fa.
But that functionality is mostly around aggregation (with some exceptions).
So for most people it’s not gonna be a huge difference.
Are you saying that readsb is simply dump1090-fa with some minor modification? Okay, you’re the creator, but that explanation still doesn’t convince me. How do you explain the improvement in received messages then? It’s a very obvious improvement.
MLAT has always worked well before and after.
As for the CPU usage, with dump1090-fa it was always at least 25% (at night) and around 30% during the day. Now 10/15%
The traffic is always constant. I’m in Badalona, about 20 km from BCN LEBL, with a good view of the Mediterranean (the Balearic Islands have a lot of traffic).
The flightstick is the AirNav one (green).
Anyway, I’m never switching from readsb to any other software.
Maybe the dump1090-fa decoder has changed for the worse … i haven’t checked the code / compared performance in 3 years probably
But also: trust me when i say that traffic pattern changes have a big influence on all statistics.
So for real comparison you’d need to decode the same signal with both (which they’re not really well set up for currently … as in software splitting of the data).
Positions per second on the 19th doesn’t seem to be any more than with dump1090-fa … so just consider that.
Yes… but my surprise wasn’t with the positions, but with the messages.
If you look closely, you’ll see that it’s very close with Aircraft Seen, which wasn’t the case before.
The 19th shouldn’t be taken too seriously, as I was struggling with the configuration because I couldn’t see the MLATs on tar1090, which is fed by readsb (Ubuntu), until I discovered --forward-mlat for the NET_OPTIONS of the main readsb. I had to perform several reboots until I found the solution.
Unless you have two virtually identical sites and then make one change (only), and compare side-by-side, it’s impossible to guess why your stats have changed.
I’m not comparing the number of planes, I’m pointing out that the number of messages is now similar to the number of planes seen, and that makes no difference whether I receive 100 planes or 100,000,000.
I’m comparing CPU usage, which has dropped from 30% to 15%.
WTF!!! hahaha
When did I ever say that Messages per second equals Aircraft Seen?
Explained for everyone: I’m saying that the number of valid messages has increased and that the line on the graph is at the same level as the ADS-B seen line.
The problem is probably that I don’t speak English and I’m using a translator. I’m sorry.
Hey, I’m not someone who uses forums to argue. I’m just sharing my experiences.
@wiedehopf dice que el código no producirá una diferencia tan dramática. Así que debe haber algo más sucediendo.
He’s said more, but yeah, okay.
It’s also possible that the way it handled data between software was different before and now. It could be a million things.
So, okay, I’ll disregard the graphs, but I will take note of the dramatic drop in CPU usage.
with ARMBIAN for decoding and for the feeders (FR24, FA, and RB). I’m using readsb on an Ubuntu Server for tar1090 and graph1090 that receives data from the ARMBIAN (beast_in).
How do you explain the improvement in received messages then? It’s a very obvious improvement.
