Because it is a different program doing different things written in a different language with different support libraries.
If you’re willing to spend some time making the two programs more consistent, or documenting how it works, then I’m more than happy to apply your changes; just make a pull request on github.
If you can explain the problem you’re having, maybe somebody can help. Are you using a piaware sdcard image, or are you using a dump978-fa package install? The configuration you need to do is different for those two cases.
The general problem of “I have two rtlsdr dongles, how do I distinguish them?” is not specific to dump978-fa or dump1090-fa at all; it’s a limitation of the hardware and the librtlsdr library and it affects basically any case where you have two of these connected to the same machine. If the dongles came with unique serial numbers out of the box then things would be much easier - but they don’t, so it needs some manual work.
OK, where to start…
First, your tag says that you are part of the FlightAware Staff. That means that you get paid to develop and document this stuff. I don’t. So, making a code pull and doing your job is a bit beyond my paygrade.
I typically build my systems from scratch where I tend to add a number of support utilities to see how the hardware is dealing with what is going on. I prefer to have the full distribution image to start with.
Then Webmin, atop, and ntopng for starters. It gives me a much better feel for how linux is configured too. Graphs1090 is an excellent utility too. So, my install of piaware was via a wget pull of piaware-repository_3.8.1_all.deb. Your system classifies this Pi as “Feeder Type: PiAware (Debian Package Add-on) 3.8.1".
I serialized the radios very early on in the build process. That was not the problem. I also performed the various piaware-config commands to supposedly configure the radios. Then the head banging began. 1090ES would come up, but UAT978 would not… Let me correct this: UAT978 would not come up consistently. Moved radios to different USB ports; plug one in; change to the other; reboot; test some more, repeat, etc. It came down to the point where I found that if I plugged in the 1090ES radio and waited for the reboot to complete, and then plugged in the UAT978 radio, everything would eventually come up. Not exactly what I would call a stable situation. Search the Forums, search the internet, search the world and I finally ran into this post thread. It seems that piaware-config does not do anything with my feeder type. Why not? Then I finally see a reference in this thread to /etc/default/dump978-fa and /etc/default/dump1090-fa. My guess is that piaware-config somehow modifies these files at some point in the piaware image version ONLY. I suppose this must be an undocumented ‘feature’!
I’m well aware that dump1090-fa and dump978-fa do different things. That does NOT mean that your choice to use a different programming language was actually necessary. And the definition of the parameters you are reading from the /etc/default files does NOT have to be different either. You could have easily kept the syntax the same and make whatever conversions necessary inside of your code (if even needed). I come from a big shop environment where not keeping the syntax the same wherever possible would never pass software review. So, the problem now is that this stuff is in production and making it consistent will require double coding so that the old vs new syntax will both work correctly. From what I understand, you had a hand in writing dump1090-fa, so I’m surprised that you would do this to dump978-fa.
The January 2020 ADS-B rule has had an impact in this area where there are lots of class B and C airports around. Some GA aircraft have chosen to install UAT but not an extensive amount. Enough that I see some most every day. I’m not an expert with the internals of either dump process but I suspect that dump1090-fa is more involved where it needs to handle four different types of 1090 communications. The interesting thing is that dump1090-fa is much more efficient that dump978. UAT978 is usually consuming 15% CPU with no traffic at all yet 1090ES only uses about 10% with a more than a dozen targets to process. (RPi 4 w/ 4gb memory and high speed storage)
There is another issue that I’m seeing that should probably be addressed. I’m seeing what I will call ghosting where a UAT978 target is displayed on SkyAware978 but also shows up as a MLAT target on SkyAware1090. It is much easier to see if you’re using tar1090 and showing both protocols. This is off topic, so moving it to a new tread is probably more appropriate.
I take your point that the documentation is out of date; it’s definitely a weak point. I see that the advanced config page doesn’t make it clear that many of the uat-* options are (analogously with the rtlsdr-* options) only used in a sdcard install. I didn’t actually write that documentation, but I can raise a ticket to get it looked at. These forums tend to have better documentation. Sorry that you had trouble there.
If you do have further problems, posting a new thread here with specific defailts is definitely the way to go.
Most of the CPU work in both dump978 & dump1090 is in the initial DSP work which has to work constantly at the full sample rate regardless of how many messages actually turn up. The DSP work for UAT is somewhat more expensive because of the modulation used. The per-message cost is small in comparison.
That’s normal and expected for aircraft which have Mode S and UAT transponders. When we eventually get a combined 1090+978 map sorted out I expect we’ll merge the data in the cases where the same ICAO address is present (tar1090 can… maybe do that already?)
Getting an error on the console when setting those options would be very nice.
Hmmm … maybe i’ll dive into the tcl once more and see if i can make that happen.
I might be discarding MLAT in that case.
Not sure what i do, yeah i probably discard the MLAT if a recent non MLAT position is there.
Actually just checking my code.
I solved it very badly if at all.
If any of the 2 jsons has a seen_pos < 1.8 (no clue how i made up that number), that data is used and the plane is assigned to that receiver.
Following that data only from that receiver is used until the other receiver has seen_pos < 1.8
That probably means it might currently use both MLAT and UAT positions and somewhat randomly switch between them.
To be honest that all was a stopgap measure, i wasn’t too concerned over getting it absolutely correct.
Edit:
Just built something in to only switch away from using UAT data to MLAT 1090 data if the UAT position is older than 5 seconds.
Trying to set up dual dongles (1090 and 978 ) on a PI ZeroW running 7.2.
I’m connected to the system and can see the current status.
I assume I am doing this with the keyboard and dongle connected through a USB hub, since the ZeroW only has 1 available usb port after powering up.
I have a 4 port micro usb hub on the way, but is this process applicable on a PI Zero W or do I need to be running on a regular PI 3/4 device?
Guessing I’m being really dense, but I can’t get connected to my PI zero 2w to re serialize my 2 dongles. I have an Orange and a Blue version from flight aware. Trying to set up both on a Zero 2w. I can communicate to the PI to type in the commands but I’m getting no response. I tried/ Putty/Teraterm and the connection gets “refused”. SSH is set up on port 22, Changing the serials to 978 and 1090 is the final step to getting both running on one unit. I have them running individually just fine. So what am I missing? Is there a “sudo” program I need to have on my SD card?
