978 Mhz UAT in the US

Ok. I’m going to start slow and hopefully I won’t kill anything through the process. Now to order an antenna and pickup a 40ft power pole…

I have done both, but have 1.0.10… going to uninstall and try again.

Still only getting 1.0.10 this morning when re installing. Would also be nice if the Andoid version had the ability to be updated, restarted, and show the version from the ADS-B stat page like the PiAware version does.

Cheers!
LitterBug

Try again now. Looks like 12 had a problem with the manifest. We corrected it and rolled the version to 13.

OK, got the update now and it is running in 978/UAT only mode. High winds here today and not much GA up at the moment. Will keep an eye on it to see how it does compared to my Pi 978 config.

Cheers!
LitterBug

I think I have it up and running.

Right now I’m just testing… It’s all running as root and brought to life via rc.local .


/usr/bin/rtl_sdr -f 978000000 -s 2083334 -g 48 - | /usr/local/dump978/dump978 | /usr/local/dump978/uat2esnt | /bin/nc -q1 main-dump1090-server-ip-address 30001 &

I have the main dump1090-mut Pi with 30001 open. I have confirmed with


$nc -zv main-dump1090-server-ip-address 30001
Connection to main-dump1090-server-ip-address 30001 port [tcp/pago-services1] succeeded!

On the dump978 Pi, dump978, uat2esnt and nc are all running, but how can I confirm it’s truly working?
The dump978 Pi only has the OEM antenna and it’s inside…coupled with inherently lower traffic. As a result, I’m not going to see a crazy jump in traffic reported on the map…(No eureka moment).

Is there a way to eves drop on the main/dump1090-mut pi’s 30001 port to confirm those occasional messages are making it through?

Once I know the basics of the software is setup, I can de-root it and make it safer. Then, move it outside with a good antenna.

If you just want to check that there are some messages flowing, you could splice in a “tee”.
Both dump978’s output and uat2esnt’s output are text (not human-readable, but it is at least plain ASCII) - one line per message.

$ rtl_sdr … | dump978 | tee raw_uat_messages.txt | uat2esnt | nc … &
$ tail -qf raw_uat_messages.txt | uat2text

(for bonus points you could do this with a named FIFO rather than a real file)

We’ve just pushed version 1.0.14 to the beta group. It now relies less on an initial GPS fix to get started. We’ve also confirmed that our servers are receiving UAT data with this version.

The app will start fine without an initial GPS fix and work silently to get one. Until it does, the map may not show your receiver position (the black dot) and you may resolve fewer aircraft positions.

Also, even though we are receiving UAT data now, you may still not see it indicated in your stats pages. We’re working quickly here to get those pages updated to include your UAT data.

The thing to test in 14 is the 1090/978 toggling. v14 has further optimizations, but admittedly, it may be too much, depending on your device. If you notice that the app appears to be “stuck,” just unplug and replug the dongle - and then let us know. We’ll back off the optimization a bit before going to production.

Nice! I have started it up. Time will tell if it’s picking up anything. Thanks!

It’s working!!


> sudo tail -qf raw_uat_messages.txt | ./uat2text
HDR:
 MDB Type:          0
 Address:           AD333B (ICAO address via ADS-B)
SV:
 NIC:               9
 Latitude:          +35.9001
 Longitude:         -79.2731
 Altitude:          7900 ft (barometric)
 N/S velocity:      156 kt
 E/W velocity:      -22 kt
 Track:             351
 Speed:             157 kt
 Vertical rate:     0 ft/min (from geometric altitude)
 UTC coupling:      yes
 TIS-B site ID:     0

HDR:
 MDB Type:          0
 Address:           AD333B (ICAO address via ADS-B)
SV:
 NIC:               9
 Latitude:          +35.9008
 Longitude:         -79.2732
 Altitude:          7900 ft (barometric)
 N/S velocity:      156 kt
 E/W velocity:      -21 kt
 Track:             352
 Speed:             157 kt
 Vertical rate:     0 ft/min (from geometric altitude)
 UTC coupling:      yes
 TIS-B site ID:     0

HDR:
 MDB Type:          0
 Address:           AD333B (ICAO address via ADS-B)
SV:
 NIC:               9
 Latitude:          +35.9068
 Longitude:         -79.2742
 Altitude:          7900 ft (barometric)
 N/S velocity:      157 kt
 E/W velocity:      -20 kt
 Track:             352
 Speed:             158 kt
 Vertical rate:     0 ft/min (from geometric altitude)
 UTC coupling:      yes
 TIS-B site ID:     0

....edited this down to make it shorter.  You get the idea.

Now time to move on to the next step…

Any chance that a PiAware beta is coming with UAT capability? Just finding the Android version to be more $$$ and hassle than it’s worth for what little traffic there is. There would be a much larger volume of feeders able to provide the data from PiAware as well.

Regards,
LitterBug

Obj’s software works as-is, right now. The UAT side is a little bit of a processor hog, but if you’re running a Pi 2, I don’t think you’ll have an issue running dump978 (+converters/adapters), dump1090-mut, and piaware-mut on a single Pi.

Yeah, I am running Obj’s UAT on a Pi2, But you would think that they would be pushing it to a bigger install base rather than to a new platform…

Cheers!
LitterBug

Litter I have had the same thought. Wouldn’t this be primarily for tablets?

Who knows, maybe the FlightFeeder for Android is a testbed for another product for use in the cockpit…

Cheers!
LitterBug

The updated Android app with UAT support has been released to the public today.

play.google.com/store/apps/deta … ightfeeder

As soon as they do I have a funny feeling a new Pi, antenna, etc will appear at my home :wink:

I just need to combine my Pi B+ 1090COCO R820T with my Pi2 978COCO R820T2 for an all in one solution. I get 5 to 40 UAT ADS-B planes a day from my location with a range of 100+nm

Cheers!
LitterBug

PS: I don’t count all the TIS-B and the Flightfeeder for Android app doesn’t either.

Does anyone have the commands to test dump978 and get it to send its output to dump1090 (then to Flight aware)?

I have a second dongle configured for dump978 and don’t see any traffic. I am in Brooklyn, near the Hudson so expect to see several aircraft per day sending out UAT978 info.

pi@tardis ~/build/dump978 $ sudo rtl_sdr -d 1 q -f 978000000 -s 2083334 -g 48 - | \

./dump978 |
./uat2esnt |
nc -q1 localhost 30001 &
[1] 2564
pi@tardis ~/build/dump978 $ Found 2 device(s):
0: Realtek, RTL2838UHIDIR, SN: 00000001
1: Realtek, RTL2838UHIDIR, SN: 00000001

Using device 1: Generic RTL2832U OEM
Found Rafael Micro R820T tuner
Exact sample rate is: 2083334.141630 Hz
[R82XX] PLL not locked!
Sampling at 2083334 S/s.
Tuned to 978000000 Hz.
Tuner gain set to 48.00 dB.
Reading samples in async mode…

I have googled for the answer but haven’t found a lot of detail for using dump978.

dump 1090 works very well. I get aircraft out to 90NM with the antenna sitting next to my basement window
I will move the setup to the attic when I can run a cat5e/6 cable to power it via POE(I don’t want to run it over WIFI and I don’t have power in the attic).

If you run a rtl_sdr | dump978 pipeline with nothing following it, you should see some raw messages (one line per message, hex encoded) if it’s working.

The “PLL not locked” probably means your dongle is having trouble tuning to 978MHz though. Odd, a R820T should be fine at 978MHz.