FlightAware Discussions

Piaware 3.6.3 - altitude, speed, and vert_rate missing when fed from UAT

[EDIT] I’m leaving this post as-is, other than this initial note: I realize I was looking at the wrong dump1090 instance of mine, and so this is not really an issue, other than the “uat2json” program does not create an aircraft.json that PiAware 3.6.3 likes very much.

I wasn’t sure if this should specifically be in this category, or under “General”, but either way…

I’ve been feeding data from my UAT receiver (dump978-rssi) into dump1090 via port 30001, and I hadn’t noticed until just recently that the speed, altitude, and vertical rates were missing on the map. (I recently set up ModeSMixer2 as well, and am feeding that, and noticed all that data is there, no problem).

This seems to be a bug/issue with the planeObject.js file, in fact.

After finding this thread - PiAware 3.6.2 and alkissack/Dump1090-OpenLayers3-html does not show speed nor altitude - I used the hint in there to modify planeObject,js to fall back to plain old “altitude”, “speed” or “vert_rate” if they are defined, and no other “better” version exists.

I also had to “fake” the Groundspeed and Vertical Rate, since those pull only from .gs and .baro_rate (respectively) in the script.js in order to display the detail frame, and I didn’t feel like editing that file, too.

Was there some reason this fallback was removed in the web UI code?


1 Like

You are probably using a new SkyView webinterface with an old dump1090.
Don’t think it would have anything to do with UAT in particular.

I didn’t necessarily like that change but it made sense because the old json field names were ambiguous with new fields being added.

Did you modify the webinterface or is it just a straight up dump1090-fa installation?

1 Like

Heh, good question… which made me double check what I was doing.

So, I just realized I was looking at the other dump1090-fa web interface (just the HTML) that lives on my actual UAT receiver… this one is simply reading an aircraft.json that is written by uat2json… which only has the “basic” values saved (since I think that’s all dump978 outputs, anyway).

I apologize for the incorrect premise of my issue!

I suppose this “hack” will only be needed if someone is trying to read a more generic (old) aircraft.json, but using the newer web UI.

I also suppose the proper way to really see “only my UAT traffic” would be to run another dump1090 instance on the UAT machine and feed it from dump978 as well. A bit of a resource waste, but whatever… :wink:

Thanks for making me realize this is not any sort of dump1090-fa issue, but rather the fact that I’m trying to cobble together the dump1090-fa front end with a more genericly-written aircraft.json file :slight_smile:



If you are unsure how to run a second instance of dump1090-fa, you can use this:

It accepts beastdata on port 29004 and avr data on 29001.
You would need to change the configuration (/etc/default/combine1090) so that the SOURCES line is empty like this:


And use sudo systemctl restart combine1090 to restart the data redirection.

That way it won’t display any data unless you feed it some for example with this command:

$ rtl_sdr -f 978000000 -s 2083334 -g 48 - | \
  ./dump978 | \
  ./uat2esnt | \
  nc -q1 localhost 29001

(mentioned here: https://github.com/mutability/dump978#uat2esnt-convert-uat-ads-b-messages-to-mode-s-ads-b-messages)

If you want to send the 978 data to multiple dump1090 instances you can do it like this:

$ rtl_sdr -f 978000000 -s 2083334 -g 48 - | \
  ./dump978 | \
  ./uat2esnt | \
  tee >(nc -q1 localhost 29001) | nc -q1 localhost 30001

Thanks for the response - but I’m pretty well-versed in how to do this, I was just looking at the wrong machine, and got carried away w/ wanting to edit the .js files :wink:

I ended up just running an actual instance of dump1090-fa on my UAT machine, and feeding it locally (port 30001). This allows me to see “only UAT traffic” at a glance, if I want.

My UAT scripts are a little over-the top (I have all sorts of error checking, and retry timing backoff, etc), but generally the same as what you’re doing.

Perhaps the biggest difference is that I instead write the rtl_sdr output to a named pipe (FIFO ‘file’). I then run a separate ‘cat’ process that reads the FIFO that feeds dump978-rssi which then splits and writes to a log file, and then also (via uat2esnt) feeds the local dump1090 (socat) as well as my main dump1090 (again via socat)… and to be concise, I also feed an instance of modesmixer2 on the UAT machine as well, just for fun (for now).

Generally speaking, it looks like this:

Process one:

rtl_sdr -f 978000000 -s 2083334 -g 48 /tmp/uat/978_pipe

Process cluster two:

cat <>/tmp/uat/978_pipe | \
 dump978 | \
 tee -a /home/pi/uat/dump978.log | \
 uat2esnt | \
 tee >(socat -u STDIN TCP4: >(socat -u STDIN TCP4: | \
 socat -u STDIN TCP4:

the ‘<>’ for the ‘cat’ process is NOT a typo, but rather just a trick to ensure it never gets an EOF if the rtl_sdr process stops feeding the FIFO (e.g. it crashes or just restarts otherwise). Otherwise, it wreaks havoc on all the chained commands and you need to do some cleanup, etc.

(edit: the other note is port 31001 is what I have modesmixer2 listening on :slight_smile: )

Each of these is wrapped in its own “maint” script.

I’m happy to share this suite of scripts if anyone wants.


1 Like

Do you actually use a gain of 48? Or was that just an example?

Just being curious, no UAT traffic in Europe.

On UAT the transmitters power is so little, and usually there are not so many UAT airplanes around, that you need all the gain you can get. I did run with the same value mine.
PS: Maybe with a better antenna, like FA one it would need less.

wouldn’t you run -10 for maximum gain?

Hey wiedehopf,

I use 48 for now – my UAT antenna is a very good one (DPDProductions), but it’s currently inside, so I need high gain when testing :slight_smile:

I’ll play w/ gain later, once I get it outside nice and high.


1 Like

I think 48 is max gain for rtl-sdr. 0 is auto.
This is different from the dump1090 application.

1 Like

I’d be quite interested in your suite of scripts. I’ve got UAT978 feeding and managed with some not very elegant scripting I threw together… Your scripts sound considerably more comprehensive than anything my free time would currently allow for. BTW, in the grand scheme of things, I’m just down the road from your kfft site!

@cwesley - oops sorry just noticing this reply… I’ll try to get them packaged up a little nicer (and strip out some of my site-specific stuff).

The only other automated setup is the one in ADSB Project scripts.