An interesting little problem. Firstly the system; an Odroid XU4, running an Airspy, utilising wiedehopf’s set up option, which includes the running the Flightaware install of piaware and dump 1090 procedure. Piaware ver 3.7.1.
Everything appears to be running ok. 3 green boxes in my site information and apparent recording of the limited MLAT flights showing in collection graph and control panel log showing MLAT signals being used. BUT the site information data in the right column line Multilateration (MLAT) showing supported / enabled but not showing synchronized with ## nearby receivers. I have 2 other units set up, a Radarcape and raspberry 3+, both showing at the same time the number of nearby receivers sync’d etc.
I am not sure what problem is causing the apparent sync’d MLAT system but not showing how many it has sync’d with… ?? Ideas ??
PiAware master process (piaware) is running with pid 987.
PiAware ADS-B client (faup1090) is running with pid 3280.
PiAware ADS-B UAT client (faup978) is not running.
PiAware mlat client (fa-mlat-client) is running with pid 25527.
Local ADS-B receiver (dump1090-fa) is running with pid 2925.
dump1090-fa (pid 2925) is listening for connections on port 30005.
no program appears to be listening for connections on port 30978.
faup1090 is connected to the ADS-B receiver.
faup978 is NOT connected to the ADS-B UAT receiver.
piaware is connected to FlightAware.
got ‘couldn’t open socket: connection refused’
dump1090 is producing data on localhost:30005.
If you expect synchronization (i.e. there are other nearby mlat-enabled receivers and ADS-B traffic in view) but you’re not seeing it, that generally means that the receiver timing is wildly wrong, by more than 100ppm. I’d guess either the airspy decoder or the odroid are having problems and dropping data.
The only other thing, I have just re imaged the card yesterday, in wiedehopf’s odroid / airspy set up option, which includes the running the Flightaware install of piaware and dump 1090 procedure using the airspy, in the FA instructions it states:
"If you don’t already have ADS-B receiver software such as dump1090 installed, then you can install FlightAware’s version of dump1090 by executing the following command.
sudo apt-get install dump1090-fa
Do I need to do this using an airspy, because I have loaded that script in the process and wonder if there is a clash between the airspy set up and dump1090FA //
I’m running an RPi4 and Airspy mini. When the dongle is connected directly to the USB port on the RPi everything works as expected. If I connect the Airspy to a (rather expensive) powered USB 3.0 Hub I experience the same problem, MLAT fails to sync. If I connect the Airspy via a USB extender cable (shielded, with ferrites), MLAT works ok.
In all cases the Airspy gets enough voltage (5V). No information in the logs about dropped packages etc.
I can only use the top-most USB 3 port of the RPi4, the bottom one provide too low voltage for the Airspy to work properly.
It seem (to me) that the combo (Airspy and single-board-computers) is quite sensitive to voltage problems. I have never had any problems when using “real” computers with proper power supplies.
I also saw some improvement when using a 1m USB extension cable that was properly shielded and with ferrite beads. The noise floor dropped a little (giving better SNR) when using the cable to move the Airspy away from the RPi4.
airspy-conf configures dump1090-fa to run in net-only mode. (airspy-conf script to be used after installing dump1090-fa)
It’s mainly for the local map you wouldn’t have without it.
Also to serve beast data to various feeders, the airspy_adsb application is CPU limited on the RPi 3 and connecting many feed clients to it increases CPU usage.
Thus dump1090-fa is serving to redistribute the beast data locally.
What airspy configuration are you using?
Try disabling bit packing and using 12 MHz. That’s generally safest in regards to dropping samples.
You can check the log:
sudo journalctl -u airspy_adsb
But not all lost samples are shown there, the dongle can drop samples internally and there really isn’t any way to detect that except for MLAT not working.
Do you have any other USB devices connected to the Odroid?
Are you using the builtin bias-t?
Also make sure the station coordinates are set precisely (3 or 4 decimal digits, altitude in correct units and relative to correct reference), that’s a common reason for MLAT not to work well.
I get the impression the web dialogue to set the location should specify that you need to zoom in and place the marker exactly where the house/antenna is
Curious how much of the MLAT position error is due to not so precise configured locations!
Ok: the odroid is powered off a 240 / 5 v adaptor, so I don’t think there will be a power issue. The airspy is connected to I am not sure which usb port, but I will now go and have a look re that suggestion. I have not had an error message re any location issue, but it is to 5 decimals. Results of journalctl:
Aug 31 17:47:43 odroid systemd[1]: Started Airspy ADS-B receiver.
Aug 31 17:47:43 odroid airspy_adsb[4531]: Listening for asavr clients on port 47806
Aug 31 17:47:43 odroid airspy_adsb[4531]: Listening for beast clients on port 47787
Aug 31 17:47:43 odroid airspy_adsb[4531]: Acquired Airspy device with serial 644064DC231A91CD
Aug 31 17:47:43 odroid airspy_adsb[4531]: Decoding started at 12 MSPS
Aug 31 17:47:55 odroid airspy_adsb[4531]: Push client connected to localhost:30004 (beast)
Aug 31 17:48:38 odroid airspy_adsb[4531]: Caught signal 15
Aug 31 17:48:38 odroid systemd[1]: Stopping Airspy ADS-B receiver…
Aug 31 17:48:38 odroid airspy_adsb[4531]: Decoding stopped
Aug 31 17:48:38 odroid airspy_adsb[4531]: Push client disconnected from localhost:30004 (beast)
Aug 31 17:48:38 odroid systemd[1]: Stopped Airspy ADS-B receiver.
Aug 31 17:48:42 odroid systemd[1]: Started Airspy ADS-B receiver.
Aug 31 17:48:42 odroid airspy_adsb[4633]: Listening for asavr clients on port 47806
Aug 31 17:48:42 odroid airspy_adsb[4633]: Listening for beast clients on port 47787
Aug 31 17:48:42 odroid airspy_adsb[4633]: Acquired Airspy device with serial 644064DC231A91CD
re the fa1090 clash, didn’t think that would be an issue, that is the way I set it up on the first script load. I have sample rate set to 20, will now change to 12.
My options set currently: OPTIONS= -v -f 1. Airspy is the only usb connection to the odroid.
Well, the Odroid having enough power doesn’t mean it’s making all that power available at the USB socket.
You’d have to have one of those in line USB power meters to really assure good power is getting to the Airspy.
Normally you should be able to run 20 MHz on the Odroid without issues.
What’s the ambient temperature?
(I personally have a 12 V computer case fan running on 5 V cool down my RPi and Airspy. That’s not strictly necessary but having electronics not run as hot is always nice)
As someone stated, the different USB sockets might work better or worse. Mostly because some probably make better or worse electrical contact. Might also be that the chip limiting/regulating the voltage might be a different one.
Which LNA are you running? I’d assume you are using an external bias-t?
I had used an OrangePi One with wiedehopf install script and airspy mini, it all worked all right.
The Debian was Stretch from Armbian site, it has a version for Odroid too: https://www.armbian.com/download/?tx_maker=hardkernel
Default release is Buster, for Stretch go down at “All download options”.
Just the way the USB is implemented and the CPU governor. Maybe a long shot… I know that on my OrangePi, their default OS was junk, I had more success with Armbian.
Ok 24 hours, not dropped any reports re sync’d receivers. Have looked at the above, interesting comments and some feedback from here.
The power supply is a dedicated Odroid XU4 240v set up. My OS is from hard kernel Ubuntu 18.04.1 (20181203).
Interested in the comments re OS Sonic, was the file you used the stretch server??
The ambient temp for the core today and it is about 3:50pm, has been 62c. Outside temp 2 metres away from the enclosure is 24.3c. The enclosure is ventilated, but not fan supported. Prior to this 24 hours I added some ventilation holes as I was concerned about the temp of the box, we are just coming into spring summer and we can get up to 42c outside. The added holes definitely made a difference between before and after yesterday. The enclosure has foam insulation inside on the walls and the bottom of the lid. The floor of the enclosure is not insulated. It is a bit tight, with radarcape, odroid, 3 uptronic amps and a power board and associated power addapters x 4. I have been thinking about a bigger enclosure, even a properly constructed ventilated with or without fans. Just to give it a bit more air space around things.
I am using an Uptronic ceramic LNA powered via the mini usb power slot, off a 2 amp 5 volt adaptor.
Whilst drafting this reply, I have experimented with putting it back to 20, dropped the sync’d receivers instantly, resumed 12, they were back. Ambient temp during all that is 61c.
Are you really saying the air temperature in the enclosure is 61C?
That’s going to seriously reduced the lifespan of every power supply and device in there.
First measure you can take is add a case fan to at least move the air around inside the enclosure.
And rather than having insulation, it would be better to have a second box without a bottom as a sun shade, with some vents at the top.
As you add more electronics the insulation will keep the heat produced in.
I’m not at all surprised you are having problems, the Airspy Mini runs quite hot even at 12MHz with an air temperature of 20C.
I’m using mine in an attic where it gets up to maybe 45C, and i have put a fan across the RPi supporting it and the pi. Also used some sticky tape heatsinks on the Airspy Mini.
I guess the equipment is located at a remote place?
Otherwise using some coax to get the signal inside the house would make sense to me.
Only the LNA needs to be close to the antenna.
