For a couple of years, I have been running a Pi2+ setup using jprochazka’s setup script along with a manual install of FR24 and in all that time, I never had any issues at all. I could just leave the setup running, leaving the PiAware software to update itself to v3.6.3.
Yesterday, using the exactly same hardware, location details etc. I decided to install the PiAware 3.6.3 image onto a new SD Card and then manually add FR24.
Granted, Flightaware gave me a brand new site number (which means I start again from day 1, which is unfair) and whilst everything was running smoothly - both PiAware and FR24, I then suddenly noticed mlat keeps dropping out - showing the red error on my FlightAware site page.
It shows that I am Supported/Enabled but not sending data - this is confirmed by my combined feed on VRS.that mlat just stops.
So, I restart dump1090 and all is fine for a few minutes, then mlat stops again.
I can confirm that my location has not changed and that identical Lat and Lon have been applied into my new site number.
Any ideas what may be wrong, or shall I just put my old SD Card in that had jprochazka’s script in from several years ago?
Hard to say maybe you bumped a connection or the power supply didn’t like being plugged in and back out?
MLAT problems are often power supply problems.
Thanks for this tip about former station numbers. Now back on my former station number
As for the Pi2+ mlat power issue. I have put a fan blowing cold air onto the Pi and separated the power supply of the Pi and Amp on to separate plugs and seems to be running smoothly at present.
I’ll watch it for the next day or so adding a “ping” cron job into the Pi and I might upgrade to a Pi3+ if it’s running out of CPU.
I was still having mlat issues - mlat would disconnect after a short time. Power wasn’t an issue after giving the Pi2 with a dedicated 2.1amp power supply and the amp its own 2.1amp supply.
So, today, I bought a brand new Pi3 Mod B+ and after giving my Pi3 its static IP address. Booted it up with the PiAware 3.6.3 image and so far so good.
I am to believe that as the Pi2 has a 900mHz processor and the Pi3 has a quad core 1.4 processor. I would suffice to say that it was a cpu issue. Probably running hot and at 100%
My new Pi3, I have added heat sinks, a cooling fan and is running perfectly well with a low cpu percentage and temperature.
Sometimes the USB hub is a problem as well, hard to say what the issue was.
What image did you use for the new SD Card?
I remember some USB problems with certain kernel version combine with certain RPi versions.
Sorry i failed to mention this but when using a current image that isn’t normally a problem.
(Stretch should work fine)
Yes, I am in the middle of England and traffic around me is very busy for the majority of the day and I can easily be tracking in excess of 150 at any one time. My stats will give an idea how busy I am and my radius range is over 250nm. With some BizJets flying above FL400, my range goes over 300nm.
As stated at the very beginning of my issue, I originally was using jprochazka’s github script setup on my SD Card for a few years but the last couple of days, I wanted to start using PiAware image and so, I installed the PiAware image onto a new SD Card, then manually added Flightradar.
However, it seems that the PiAware image software along with Flightradar was creating issues with my Pi 2 and so, I bought a new Pi 3 Mod B+ and everything is working great now, with no issues.
Regarding the Power Issue. I wasn’t using a USB hub, I was using a 5v 2.1amp Max plug that had two USB ports in it, which with two USB’s in it - one for Pi2 and the other for my amp, it could only provide 1amp to each USB. So, hence buying a separate 5v 2.1amp, so that each device had its own power supply.
Anyway, as indicated above, with the new Pi3 Mod B+ everything is running smoothly
Oh power for the LNA.
I thought you meant power for the receiver.
If you really want to avoid power issues the 5.2 V power supplies are best.
(Canakit is only available in the US so you are basically stuck with the “Official Raspberry Pi power supply”)
As long as you set up FR24 correctly (don’t use dvbt config option, use beast(tcp)) it shouldn’t be a problem.
I updated to 3.7.1. The 1090 on the Airspy (which also serves as a bias tee) is connected to the Odroid N2. I also consolidated the 978 orange FA dongle to the N2.
Now, MLAT for 1090 works as long as I don’t have DUMP978-FA running. When I stop the process, MLAT works as expected. When I start DUMP978-FA, MLAT starts dropping the synchronized servers. After about 15 minutes the status changes to the dreaded “not synchronized with any nearby receivers”.
I am using the Odroid 12V 2A power supply (which cost me all of $5.50 --a steal). Might this be the problem? Anything else maybe? I attached the Airspy USB utilization that shows when 978 is running and when it is not. Is there a way to check the power supply hypothesis?
If you’re going all the way down to “not synchronized” then that means the airspy is dropping a lot of data (so much so that mlat can’t find pairs of ADS-B position messages with even roughly similar timings to do synchronization - effectively dropping >100ppm will do this). I’d suspect you’re hitting USB limits.
I would have expected the N2 to handle an rtl-sdr dongle in addition to the airspy.
(USB bus wise)
But that may not be the case.
If you have a powered USB hub you can try that to rule out power problems on the USB ports with that.
(Using it for the 978 dongle should suffice)
I’m not sure how the USB chip or chips of the N2 are layed out.
You can try using a different USB port for the 978 dongle.
If the ports are somehow paired by 2 then using another port might solve the problems.
A better measure than MLAT synchronization is checking the airspy_adsb log for lost samples:
This is since the reboot last night (I thought maybe a reboot would solve the issue)
– Reboot –
May 24 18:48:40 odroid systemd[1]: Started Airspy ADS-B receiver.
May 24 18:48:41 odroid airspy_adsb[2110]: Listening for beast clients on port 29999
May 24 18:48:41 odroid airspy_adsb[2110]: Listening for asavr clients on port 47806
May 24 18:48:41 odroid airspy_adsb[2110]: Acquired Airspy device with serial XXXXXXX
May 24 18:48:41 odroid airspy_adsb[2110]: Decoding started at 20 MSPS
May 24 18:48:53 odroid airspy_adsb[2110]: Push client connected to localhost:30104 (beast)
root@odroid:~#
That is the end of the log-file.
I confirmed this morning again that starting dump978-fa and skyview978 causes the outage.I suppose I can try starting just dump978-fa alone without skyview. Let me try that.
I added the powered USB hub for the 978 dongle (AirSpy directly into the N2): no change. The moment I start dump978-fa the MLAT for 1090 stops. On the FA My ADS-B page, the MLAT is green. But it won’t synchronize:
May 26 18:10:02 odroid piaware[25646]: mlat-client(25841): Receiver status: connected
May 26 18:10:02 odroid piaware[25646]: mlat-client(25841): Server status: not synchronized with any nearby receivers
May 26 18:10:02 odroid piaware[25646]: mlat-client(25841): Receiver: 383.2 msg/s received 153.0 msg/s processed (40%)
May 26 18:10:02 odroid piaware[25646]: mlat-client(25841): Server: 0.0 kB/s from server 0.0kB/s TCP to server 1.8kB/s UDP to server
May 26 18:10:02 odroid piaware[25646]: mlat-client(25841): Aircraft: 36 of 47 Mode S, 49 of 53 ADS-B used
The only MLAT calculation I participate in is FA. No other MLAT is processed. I have tried restarting piaware, dump1090-fa, the Airspy software. To no avail. I get between 150 and 250 MLAT aircraft reported per day, and less than 100,000 positions (~5%). So, not a ton.
My understanding is that dump978 does not use MLAT at all. I have not explicitly turned it off in the settings (and I do not know how to do this). Does the Airspy use have something to do with it? The 978 antenna is attached to the orange FA dongle.
Just for fun, I tried to switch on the MLAT for FR24. Worked like a charm.
Thanks. I am able to start and stop it. The version I use is compiled from scratch to ARM64 (from your notes here). It seems to do something, though no aircraft in the last hour.
