Well if you don’t use an LNA in the signal chain then it’s usually a reasonable setting for 1090 MHz.
(Flightaware sticks have an LNA so gain needs to be lowered)
2 Likes
What you do to get UAT in VRS is pipe dump978 into dump1090 then out to VRS.
dump978 command:
rtl_sdr -d 0 -f 978000000 -s 2083334 -g 0 - | /home/pi/adsb-receiver/build/dump978/dump978/dump978 | tee >(/home/pi/adsb-receiver/build/dump978/dump978/uat2json /var/www/html/dump978/data) | /home/pi/adsb-receiver/build/dump978/dump978/uat2esnt | /bin/nc -vq1 127.0.0.1 30001
dump1090-fa config:
–net-only disables RTL-SDR, relays data from dump978
RECEIVER_OPTIONS=“–device-index 0 --gain -10 --ppm 0 --net-bo-port 30005”
DECODER_OPTIONS=“–max-range 360”
NET_OPTIONS=“–net --net-only --net-heartbeat 60 --net-ro-size 1000 --net-ro-interval 1 --net-ri-port 30001 --net-ro-port 30002 --net-sbs-port 30003 --net-bi-port 30004,30104 --net-bo-port 30005”
JSON_OPTIONS=“–json-location-accuracy 1”
Took me forever to figure out how to do it, the “–net” was key, tells dump1090 to accept incoming data (I think the documentation says it does by default, but I found it needed to be specified explicitly). I also am running 2 separate instances of dump1090 (one is "main 1090"and other is for the 978 relay) on 2 separate rasp-pis, I do this to see 2 separate feeds in VRS so I know which is 978 and which is 1090 (and also because antenna placement issues).
978 is outputting “raw” (/bin/nc -vq1 127.0.0.1 30001) and 1090 is taking is taking raw-input (–net-ri 30001). To do this on one machine / dump1090 instance and feed UAT to FA, I don’t know. I’d love see what someone can come up with and see it posted back to here. Thanks and your welcome.
That is the old dump978.
As it seems that UAT is irrelevant outside the USA, why should we upgrade to v3.7.1 or are there other upgrades/changes we can benefit from?
1 Like
What’s the difference with the “new” dump978 and where does one get it from? Thx
In your post you have given the following path:
/home/pi/adsb-receiver/build/dump978/
which shows you have installed it by JProchazka’s adsb-receiver project script. This is old dump978
The new dump978 is named dump978-fa, and you have to install it by
(1) Building its package from source code
OR
(b) Write latest Piaware SD card image 3.7.1 to your microSD card
Yes, I haven’t upgraded anything, really for the amount of UAT I see in my area, I don’t even run that receiver full time. I’d imagine what I’ve described would point to a way of interfacing dump978 to VRS, either via relay thru dump1090 or directly through. The FA versions don’t really seem to be much different under the hood from the mutability forks, other than how they take their configs. As I stated previously, I’d be very much interested in seeing how others have interfaced dump978 into VRS, other than a fleeting comment and a screenshot (which was all I had to go on, enabling my belief that it was indeed possible).
For 1090, 3.7.1 has the usual minor bugfixes, plus some improvements to Comm-B decoding and a refreshed aircraft database. dump1090/debian/changelog at v3.7.1 · flightaware/dump1090 · GitHub (some of these decoding changes also affect piaware itself, even if you’re not using dump1090-fa)
https://discussions.flightaware.com/t/uat-translation-from-dump978-fa/49735/11
I used uat2esnt for mine just fine now along with socat. No extensive modifications, just used cron to run a script on startup.
In VRS, are you able to see a distinction between UAT and ADSB traffic?
No… it shows up just as ADS-B and Mode-S would. On the map however I can select just that receiver for it and display only that.
Got a note saying in effect my Piaware was older than dirt and should update to 3.71.
apt-get update
apt-get dist-upgrade loaded 3.7.1
Lots of curious messages in piaware.log, part after ‘got’ changes
error uploading ADS-B message: expected integer but got “35000 4 A”
Does this sound familiar?
Try restarting piaware. This means you have a newly installed piaware on disk but the old version is still running for some reason.
Unless the number of flights in my area increased at the same time as the upgrade, looks like 3.7.1 is decoding more planes than the previous version.
dump1090-fa hasn’t changed.
If anything my guess would be the statistics or the conditions for data to be sent to FA have changed.
The changelog would seem to suggest otherwise:
I should have said: The demodulation of the raw message hasn’t changed.
The decoding of position messages or altitude messages also didn’t change.
For BDS5,0 and 6,0 there are more fields required before the message is accepted.
So at best this reduces the number of decoded messages.
My guess is that the increased statistics are due to weather and seaon.
I think you are correct.
My stats are just showing the usual daily / seasonal changes. No noticeable change when I updated to 3.7.1
1 Like
Got the email recommending an update to 3.7.1. Currently running 3.6.3. Tried the recommended method of ‘Upgrade and restart PiAware’, but the following messages then showed up in the log:
[2019-06-01 18:08 CDT] manual update (user-initiated via their flightaware control page) requested by adept server
[2019-06-01 18:08 CDT] run-apt-get(2268): Automatic updates not available for OS debian:9 (Debian GNU/Linux 9 (stretch))
[2019-06-01 18:08 CDT] performing manual update, action: piaware
[2019-06-01 18:08 CDT] skipping action piaware
[2019-06-01 18:08 CDT] *** running command '/usr/lib/piaware/helpers/run-apt-get update' and logging output
[2019-06-01 18:08 CDT] update request complete
[2019-06-01 18:08 CDT] child process 2268 exited with status EXIT 1
Should I just do an ‘apt update piaware’ to get the latest version? Not that it matters, but I am running on an ‘Orange Pi PC Plus’.
Thanks!