FlightAware Discussions

Support for Stratux v3 UAT SDR

Stratux offers a low power UAT SDR. Support for this would be helpful in a dual-frequency setup.

Thought it was just a standard rtl-sdr compatible device with programmed serial number.

With the serial number the Stratux image can distinguish the two dongles.

Have you tried using it with piaware?

1 Like

The radio uses a TI CC1310 chip instead of the RTL2832. In the Stratux code they have a separate file for handling this dongle ( main/lowpower_uat.go). The card does not show up when you run rtl_test and does not get recognized by piaware.

1 Like

AFAIK it’s not a SDR, it’s actually got the demodulator on board. If you can make it produce data on 30978 in the common dump978 format (I believe stratux is still using the same format as my original dump978 / dump978-fa, which should be fine) then piaware & skyview978 should be able to use data from there. The software to bridge from the dongle to a tcp port doesn’t exist right now though AFAIK (basically, something analogous to beast-splitter which does that job for a Mode-S Beast)

edit: I looked at the stratux code and it doesn’t seem like it would be too painful to build something to handle the dongle - the dongle just looks like a serial port which produces decoded UAT messages in a custom format, the host does the FEC but that’s about all.


I have some proof-of-concept code for this now, so support may turn up in a future release of dump978 if it works out OK


There’s some experimental support at https://github.com/flightaware/dump978/tree/stratux-dongle
Run dump978-fa with --stratuxv3 /dev/uatradio
It seems to work OK so far. The stratux dongle does seem to have trouble with higher gain antennas / noisy environments though - it was deaf when using a FA 978MHz antenna with no filter, but worked OK with a filter in place.

1 Like

Got it working. I built the package and installed that. It looks like piaware-config will need updating to support the option for this radio.
I’m using the stratux antenna at the moment and got a few hits, but only in a short range. Thanks for the quick turnaround!

Yeah the sdcard image / configuration half of it is not there yet.

How was the test performed on the UATRadio? I’ve found that it is more sensitive and less tolerant to very strong transmitters. The SDRs seem to do better when overloaded. This only ever seems to happen when I have a UAT transmitter in the room with the UATRadio on the bench.

I did some ad-hoc testing at FA HQ in Houston when I was visiting earlier in the year; nothing systematic, just putting it up in a window (29th floor) in parallel with a dump978-based receiver and seeing what it heard.

I did notice possibly the same thing with overload, but not even with “very strong” transmitters, just with more antenna gain. Hooking it up to a FA 978MHz antenna, I got almost no data; but half-disconnecting the N connector suddenly produced data. Using the provided antenna (looks similar to your typical 2.4GHz wifi antenna; substantially shorter than the FA antenna, so less gain) instead worked OK. Putting a splitter in the antenna path also worked OK. In the time available I didn’t work out whether it was a physical connection problem or an overload problem. The Houston office is a noisy RF environment so it may be that too.

1 Like

Thanks for the response. A very strong signal in my case meant a ~14 dBm output transmitter, low gain TX antenna, same room. We (Stratux) tested the UATRadio sensitivity and it decoded messages 3-6 dB lower, depending on long or short messages. An area with a lot of test equipment, especially with loud LO’s, can definitely skew the results. It definitely shows a big improvement in flight tests.

1 Like

I suggest to do this. Install a program Called HDSDR onto a laptop or computer near by. Use the dongle that you use for ADSB/UAT reception and plug it in to the computer, set up the program and run it on 1090 MHZ to actually see the signals on 1090 mhz. Run the gain all the way up to max to see how much overload you have. Also take into consideration that using a raspberry Pi (any model) The Pi will produce huge amounts of of RF interference. I also feel that if your dongles are too close to the Pi, they will actually absorb RF interference generated from the Pi. I had the CATV technician in my house two months ago and he swept the house with his analyser and he pointed that my shelf that my Pi’s are on is a hot spot for interference. So to add to this conversation, we dont take into consideration the ammount of self generated interference we actually produce.

Hey @obj trying to do some testing with this dongle but am running into trouble following the installation directions here.

For some reason libsoapysdr-dev is not found and no amount of updating seems to find it.

Please show the output of the following command:

cat /etc/os-release | grep PRETTY

I faced same problem on Armbian Buster, and solved it like this:

(1) Downgraded apt from Buster to Stretch

## First created a backup of sources.list
sudo cp /etc/apt/sources.list /etc/apt/sources.list_backup  

## Next replaced all occurance of buster by stretch 
sudo sed -i 's/buster/stretch/g' /etc/apt/sources.list  
sudo apt-get update  

(2) Installed required dependencies

sudo apt-get install soapysdr-module-rtlsdr soapysdr0.5-2-module-all  

(3) Restored apt to Buster

## used backup to restore
sudo cp /etc/apt/sources.list_backup /etc/apt/sources.list  
sudo apt-get update  
1 Like

That’s only a problem if you install by package.

If you compile from source it shouldn’t be a problem.

Compiling by source code also requires first installing the dependencies, which failed to install on Armbian Buster. Downgrading apt source from Buster to Stretch solved the problem.

1 Like

No, I tried v 3.7.2

No I did not try v0.6 because the installation specifically mentioned v0.5-2.

The installation of dump978-fa failed with following warning:

requires soapysdr-module-rtlsdr soapysdr0.5-2-module-all | soapysdr0.5-2-module but it is not going to be installed. You have held broken packages

This problem has arisen because the library package builders are making version number part of package name.

For packages whose names dont have version number are easy to install. Just issue commands like below will install the latest version of the package:

sudo apt install lighttpd
sudo apt install chromium

I have faced same problem with set-gain script which uses php to execute set-gain commands from client (browser on desktop) to server (raspberry pi). They keep on changing name of php-cgi as follows:

Jessie: php5-cgi
Stretch: php7.0-cgi
Buster: php7.3-cgi

The script fails to install the php-cgi if install command does not contain correct versioned name. As a result I was forced to add this code in the automated installation script:

echo "Detecting Distro Version....."
CODENAME=`lsb_release -sc`
if [[ ${CODENAME} == "jessie" ]];
 echo "Detected" ${CODENAME}"....";
 echo " Installing php5-cgi....";
 sudo apt install -y php5-cgi;

elif [[ ${CODENAME} == "stretch" ]];
 echo "Detected" ${CODENAME}".... ";
 echo " Installing php7.0-cgi....";
 sudo apt install -y php7.0-cgi;
elif [[ ${CODENAME} == "buster" ]];
 echo "Detected" ${CODENAME}".... ";
 echo " Installing php7.3-cgi....";
 sudo apt install -y php7.3-cgi;

1 Like