I’m not sure if I’m having MLAT problems or not. To me it seem ok. Local piaware log show nothing out of the ordinary, mlat client is connected and syncronized with around 50 other receivers.
But when I look at the logs under “configuration” I sometimes get a line that says that I’m not syncronized with any receivers.
I’m running on Debian Stretch, Airspy mini (20Mhz sample rate, bitpacking since FA seem to dislike 20Mhz MLAT). The hardware should be sufficent, Intel NUC, core i5 processor, 8 GB ram, 15 to 17% CPU load (multi purpose server). Since I live in rural parts of Sweden I seldom see more than 55 aircrafts and 650 messages/sec.
In that particular log fragment, you’re not hearing any ADS-B aircraft at all; without an aircraft to use as a common reference point, mlat can’t synchronize.
The beast protocol clock is always 12 MHz independent of the sample rate setting.
(-m for mlat is a bit misleading, it applies to the clock on the other protocols though)
So no need for bit packing
(that’s USB bandwidth related, you should be able to safely turn it off)
As obj already said the MLAT seems perfectly fine.
Not ADS-B reference aircraft, no MLAT
Removed ‘-p’ and restarted airspy_adsb and dump1090-fa. Took some time for the client to sync with other receivers. Stayed synced for some time, then dropped the sync and turned red on the FA stats page
MLAT aircrafts does not update as they should on local skyview.
Nothing logged by airspy_adsb (running with -v) and nothing about MLAT problems in the piaware log.
Turned on -p again and all seem to be working again (except that I still get the “not syncronized…” message from time to time despite having MLAT airplanes within range with 0 in the Age-column in Skyview).
But MLAT positions are reported to FA-servers and my MLAT stats increase in resonable steps during the day so I guess things are working as they should, synced or not
Either use the map and zoom in very far to place the marker precisely.
Or enter 4 or 5 decimal digits for latitude and longitude.
It needs to be precise.
Anyway -p shouldn’t hurt either so if it somehow improves MLAT for you go for it.
Maybe the Intel board has a bottleneck on the USB connection though this would be very strange.
(Does it have multiple maybe different colored USB ports?
Try the blue 3.0 ports if it has those. While the airspy is not 3.0, the chips behind it usually have more bandwidth available)
What is the airspy configuration you use?
Relaying messages via dump1090-fa is preferred because it reduces load.
(shouldn’t be any problem with this hardware and only 700 msg/s but still)
Re-entered my lat and long again (I re-checked and I added two more decimals, now I use 6 instead of 4).
20Mhz improves reception/detections a bit on my system, but apparently I need -p to keep MLAT working. Not a problem using it, but it is strange that I need it…
It may be a bottleneck, but when I got the airspy I checked the USB bandwidth and it passed without any problems. The NUC is 4 years old, no USB 3, just 2 2.0 ports (and probably one chip handling both ports).
I run the airspy with these arguments:
airspy_adsb -v -b -p -l 29999:beast -l 47806:asavr -c localhost:30104:beast -g 20 -m 20
Dump1090-fa connects to 30104 and I connect VRS and FR24 to dump1090-fa (FR24 running on a RPi3 so I can get MLAT since they don’t support MLAT on anything else but RPi:s).
Maybe it’s time to look at an Odroid or a new NUC…
Have you tried lower gain?
If you are using an external LNA, 17 is likely a better number. (that is a whopping 9 dB less)
The position count <40 nmi seems really low.
Maybe it’s just your location though.
I get very few aircrafts closer than 40 Nm.
As you see from the distribution on the coverage graphs, the bulk is at 80-120 Nm (that’s where Swedens largest airport is located). 120+ Nm covers some of the routes from UK/western EU to Finland, Russia and eastern Asia. And below 80 Nm is mostly domestic traffic in Sweden and Norway and some transatlantic flights.
It’s a challenge trying to get good range and squeeze as much messages as possible out of every single aircraft I can when you live in rural Sweden. High gain, good SNR, good filters and an Airspy Mini has produced both better range (250-350 Nm, almost 200Nm average in all directions) and high message rates (average 12-13 messages/aircraft/second over 24 hrs).
I’m currently running week-long tests trying to find the proper gain for my location. Now when the trees are green there are other requirements compared to when they are bare or when they are covered with lots of snow.
In a country full of them there are no options
Trees and snow, only a month during spring and 2 during fall that we are free from both…
FA antenna and RTL-SDR LNA (works better than Uputronics at my site…).
Lots of 3G/4G towers (they send with higher power since they need to cover larger areas than city-based transmitters) and a couple radio/tv-transmitters pollutes my airspace. The filter (saw) in the Uputronics LNA didn’t block all signals. RTL-SDR LNA does a better job at this at my site.
I have the impression besides not being able to supply with a USB cable the rlt-sdr LNA is just better.
FA antenna and rtl-sdr LNA you might lose some close in signals with a gain of 20.
But if you focus on distant signals and the higher gain improves that i can understand.
(Wouldn’t be sure it’s really an improvement though)
Anyway your coverage is great!
I’m inconvenienced by some hills so i didn’t even really bother upgrading my antenna from a simple quarter wave ground plane so far.
The RTL-SDR LNA is a pretty good piece of hardware. Decent hardware design and effective filtering. It lacks the build quality of the Uputronics, but it’s one third in size and fits in a smaller box. It’s worth the cost and the wait (2 weeks from China via Luxemburg to Sweden, so no duty or taxes ).
I’m trying gains from 21 to 15. One week per setting. Input some values in Excel, make some graphs and find the best compromise of reach and messages/sec. I have done some shorter tests before (1 day per gain level) and from that experiment it seem like 18 and below means shorter reach and less messages. That’s why I’m giving it a week per gain level.
I’m pretty satisfied with the coverage. May cut down some branches on nearby trees to get more range and messages from SW to NE (you can see on the polar plot where my two giant maple trees blocks. The trees are more than 200 years old so a light trimming is all I will do to them). There are som distant hills in that direction, but I guess that I will gain at least 50 Nm by trimming some branches. I can’t use Heywhatsthat since I live too far north for their service
I have that antenna on the watchlist It’s been there for some time and it’s not impossible that it will find it’s way to my roof The DPD one is nice and it will match the airspy perfectly. But then I will need to extend my TV-antenna mast, drill a new hole in the wall (drilling through 50cm well insulated wooden walls standing on a ladder 10m up is a challenge…) and buy 15m of LMR400 cable. It will be rather expensive…
5 messages since midnight that says “Clock unstable”. I have a tellstick connected to the other USB port, that may be the culprit. Perhaps I should look into moving Domoticz and the 1-wire system to another computer…
The airspy gets quite hot, but not alarmingly so. I have strapped a heatsink from a discarded graphics card onto it. Works ok. I have a peltier cooler in the scrap bin that I’m thinking of mounting on the airspy. That should keep it cool, but it will require a powersupply from a PC to power the cooler. The case of the airspy will probably be around -10C or so if the cooler works as expected
I will mount a 120mm fan that will circulate the air around the NUC and airspy during the summer. The cpu is at 65C now and will probably be hotter during our (short) summer. If I can get the air circulating around the unit it will help some…
The peltier cooler worked perfectly for overclocking various CPU’s, but they where not in an enclosure, so yes, it will probably be a Bad Thing to do
The tellstick sends and receives short bursts of signals. May be that when several gadgets (temp sensors and wind sensors) send at the same time that it will lock-up the USB bus, but that’s just guesses. I have not read the source code so I really don’t know what the tellstick-daemon does to the USB bus when it’s in use. There are only the two ports and they are on the back. If I’m lucky there might be a header on the MB that is connected to a separate chip. Will look into that.
Probably easier to buy new hardware and make a dedicated ADSB-computer (I used to have a RPi3 for this but as we know that’s not the best hardware for the airspy if you want to run it at 20Mhz).
Perhaps. It’s a small form factor and Intels own design, so it may be hard to find something that fits. I know that the hdd is an M2 device (usually connected to a PCI-3 bus) and that there are some unused connectors on the MB. But it’s been ages since I opened it up. But it’s a good tip
Opened it up today and found some things…
The best find was a USB 3 port. Not visible from the outside since it was hidden behind the lid/front. The cutout was badly done, but I fixed it with a scalpel. So now I have the airspy on a separate USB 3 port. No bitpacking and no messages about unstable clocks this far…
There was also two pci-mini slots. Good to know if I need to connect another airspy in the future
The DPD one is nice and it will match the airspy perfectly. But then I will need to extend my TV-antenna mast, drill a new hole in the wall (drilling through 50cm well insulated wooden walls standing on a ladder 10m up is a challenge…) and buy 15m of LMR400 cable. It will be rather expensive…
