Trying to get a SDRplay RSP to work and have been getting kicked off of FA MLAT as I keep getting the “Server status: clock unstable” error on PiAware using the SDRplay dump1090-mut with an API in it for the RSP. Other than that it seems to be about the same results as a RTL-SDR that’s running next to it on a splitter. According to a post I saw in which OJ said that it is caused by dropped samples on the USB bus as it shows up as the intervals between messages from the receiver being way off compared to the same messages being received by other receivers.
I’ve been talking with one of the programmers at SDRplay and he doesn’t seem to see any problems on his end and I have tried the following based on other similar discussions here on FA.
Tried 3 different USB cables between Pi and RSP’s
Tried both a RSP1 and a RSP1A
Made sure the settings were for lowest bandwidth i.e --bwMode 0 (for 1.536), --normal (Ignore settings and set up RSP for ZeroIF 2MHz Demod), No oversample or any other bandwidth user.
Disconnected Ethernet cable from Shared USB\Ethernet port and connected to WiFi with Pi close to WiFi.
Connected both Ethernet cable and WiFi.
Connected with just WiFi.
Tried all 4 usb ports
Tried other known good power supplies
As the command line string item --dev-sdrplay is the only thing that tells it to work with a RSP I have also tried it with a RTL-SDR on it without that switch and it works fine with no errors.
During the night when traffic falls below 175-200 msg/sec (30-40 planes) it will connect to the MLAT server and works fine.
One more item is MLAT seems to be working ok when connected to ADSBexchange and only occasionally I will see a sync error on their mlat matrix and then it goes away.
Are there any routines that can be run on the Pi to tell if it is indeed losing samples on the usb bus?
This is interesting. The RSP1 does not have a TCXO, the RSP1A does. Unless there is another cause for the clocking errors, it could indicate the RSP1A TCXO is not working properly.
I had a similar situation happen to me a couple of weeks ago. With a Pro Stick plus, I was seeing similar errors. I purchased another one, and the errors went away. It may have been a coincidence, but keep that for future reference.
It is hard to know where the timing problem is coming from. Most of the time it has to do with the USB connection dropping packets but there are a few others that I have seen.
RPI 2 USB drivers are flaky and will sometimes skip USB packets. This doesn’t effect RPi 3 boards.
The receiver is skipping packets. This is usually a hardware problem on the specific board. Only way to know is if you switch out for another receiver.
The connection to FlightAware is bad. UDP is used and if you have too much packetloss then you can get bumped off MLAT.
The clock chip is not a TCXO type. I would say over 95% of the cheap RTL dongles with normal XO clocks are good enough for MLAT. There are a few that have XO clocks that drift too much and will lose timing.
MLAT will be around after 2020. Most of the planes people want to track will be on ADS-B though.
I’m running the Pi3b so item 1 should be ok. I get the exact results using 3 different RSP’s so that kinda knocks out number 2 and 4 as the clock in the RSP1A is TCXO and the RSP1’s are known to be extremely stable and I have tried 3 different units. For Item 3 correct me if I’m wrong but if I have 2 Pi’s feeding the same router would’t both of them get errors if there was a bad flightaware connection.
I tend to lean toward an issue with the Mirics chip API that is used as when I change the start string and run a RTL-SDR on it everything works perfect (It’s just a branch of1090-mut with a piaware add-on and a Mirics API). Problem is I don’t know of any way of checking the packets at the USB level.
You can do a “ping piaware.flightaware.com” to check your connection to the FlightAware server. This will tell you if you are dropping any packets and how long a packet takes to reach the destination.
You can check your packet loss for the entire network interface with “sudo ifconfig”.
I forgot to mention that I heard of decoding software that puts out bad message timestamps. The messages have to have a consistent timestamp with other received messages and the timing compared to other local MLAT sites is checked on the FlightAware side. If the decoder program you are using is sending bad timestamps then this is a decoder software issue. Maybe another person on the forums has decoding software that works with MLAT on the RSP1? This might just be a software version issue.
Yes, the previous version did have the “timestamps out of order” problem that I documented and pointed out to SDRplay and on this version it has not reappeared. I will try the [sudo ifconfig] and see what comes up.
I’d really like to get this working well as “Andy” (The SDRplay coder involved with this) has it doing quite well otherwise. They created an algorithm that runs to assess the best gain reduction level to use which seems to beat my best attempts of “gain optimization” so far and the new RSP1A is a 14 bit decoder at this bandwidth. He has asked for feedback on any issues so I’m trying to do what I can to help.
I ran the ping to flightaware for an hour while the “clock unstable” error was on with no errors. Also no errors seen on the “sudo ifconfig” multiple times.
I previously did a FA search on “SDRplay” and “RSP” before this post but really haven’t seen any success stories so far.
I think I probably need to start a new post along the lines of your statement of “Maybe another person on the forums has decoding software that works with MLAT on the RSP” and see if anybody has had success with it.
I have an RSP1A as well, great receiver, but it’s overkill for ADS-B. Knowing now that its version of Dump1090 may have issues, I think switching to a Prostick+ or RTL-SDR Blog v3, may give you better results and less headaches.
@Dxista
I also have RTL-SDR’s doing ADSB 1090 and UAT 978 as well as AIS tracking. I’m currently comparing the RSP1A to the RTL-SDR using a splitter rated to 2.5 GHz. Overkill possibly but as I have 2 RSP1’s and a RSP1A I thought I’d find out how well it works. Also as SDRplay has asked for feedback on their fork of dump1090-mut I thought it would be fun to participate.
