Hey, My mlat-client doesn't seem to want to connect to the feeding server most of the time, sometimes it does but then the connection gets dropped and it takes forever to connect again. I've stopped the service and mlat-client and resorted to running it manually (in tmux) to see the output, here's what it looks like: Code: /usr/bin/mlat-client --input-type dump1090 --input-connect localhost:30005 --lat <removed> --lon <removed> --alt 496ft --user Sgtpanda --server <feedurl>:31090 --no-udp --results beast,listen,30107 Fri Oct 26 21:16:07 2018 mlat-client 0.2.6 starting up Fri Oct 26 21:16:07 2018 Listening for Beast-format results connection on port 30107 Fri Oct 26 21:16:07 2018 Connected to multilateration server at <feedurl>:31090, handshaking Fri Oct 26 21:16:08 2018 Accepted Beast-format results connection from ::ffff:127.0.0.1:45522 Fri Oct 26 21:17:07 2018 Disconnecting from <feedurl>:31090: No data (not even keepalives) received for 60 seconds Fri Oct 26 21:17:07 2018 Connected to multilateration server at <feedurl>:31090, handshaking Fri Oct 26 21:17:27 2018 Lost connection to <feedurl>:31090 Fri Oct 26 21:17:27 2018 Reconnecting in 30.0 seconds and then that just repeats, sometimes my client disconnects due to no data, sometimes it loses connection, rarely it will actually connect and then I see the server header. Edit: I had to remove the feeding url because the forum thought it was spam, I'm using feed(dot)adsbexchange(dot)com
MLAT server can accept limited amount of connections. You have to accept that. If your internet connection is slow or amount of data is low you'll be kicked-out from server.
Just let it run. MLAT server will accept it. Where are you located? Is ZeroTier installed on your Pi?
I have the very same experience as SGTPANDA. My Pi receivers are on DSL lines and they do send a relevant "amount of data" (assuming you refer to the X out of Y MODE S entries in Log - which has an average of 75% of Y being used by ADSBx MLAT) Other receivers in the same region are online for days, at the same time, with a very bad MLAT footprint. When these come online (MLAT sync), mine get canned. On sundays my receivers work like a charme. Come weekdays (which is the only reason I run them - in order to fetch MLAT of extreme military rounds in this region during weekdays) my feeders get kicked out, most of the time. I don´t think it´s due to the internet connection or to the amount of data. They used to work fine for years and just recently flaked out, no change of settings etc. Just letting them run will not necessarily lead to a reconnect. My feeders were MLAT offline for days in a row. For no apparent reason. Just the eternal re-conncet cycle. Even the one that I set up with Zerotier and that was handled by James, briefly, was kicked out again, just two days after I set it up as an exclusive ADSBx feeder (ADSB image). The combo image flakes out MLAT wise as well. I didn´t even bother to make that available via Zerotier as I don´t think it helps in this regard. The setup is fine on these receivers. No need to Zerotier into these for anybody.
Ed Itor -> Germany. Combo image MLAT won't work anymore with out fix mentioned here:https://www.adsbexchange.com/forum/...e-working-mlat-requires-manual-update.618956/ If you use 3.6.3 FA base and script method. That will work. Or ADSBx image. MLAT is overloaded in that area. People sit and watch every second of connections. My guess is Ed has other problems, since he said his Grafana Dashboard doesn't work periodically.
I had patched the ComboImage according to above even before you posted it in this forum - we were in email contact for this. (By the way: looking up mlat-client man, I noticed mlat-client is actually expecting values in meters, not in feet, by default, unless you pass "ft" with your numeric altitude value to mlat-client - correct?). However, it is not the problem. Both receivers get kicked off the sync similar to the initial log file excerpt above. Others aren´t. I can be sure that my receivers won´t be online at the same time (2 receivers). I can be sure my two receivers, which worked flawlessly for over two years here, won´t be MLAT online most of the day. It is not a question of MLAT coverage, not of internet connectivity, not a timing issue (when they are in the sync matrix, they have nice green sync status with most receivers) Only on Sundays they are to be seen MLAT online for a longer stretch of time. So question remains: What is the logic behind kicking off receivers. It can´t be only number of connected receivers, it can´t be "amount of data", must be something else because a few dozen receivers in coverage-4 never go offline (meaning: kicked off regularly - according to sync and coverage map). Sync-4 has been overloaded for years now. What is needed to fix this?
feet or meters -- doesn't matter ... RF travels at the speed of light and MLAT is a probability. lat lon with in a few miles is even ok.. because RF travels at near light speed in atmosphere ... having the clocks synced is most important than worrying about the difference between feet and meters ... In other words, RF signals travel through coax at about 87 percent of the free space value of the speed of light, or 299,792,458 meters per second x 0.87 = 260,819,438.46 meters per second. 186282.3970512 miles per second ... 186.282397 miles per millisecond ... miles ...
No worries, I just wanted to point out a possible mistake in your post where you tell folks to enter altitude in ft manually. Sure, doesn´t matter. What´s much more frustrating is that my feeder is just converting electricity into nothing! It´s been busy with handshaking with the MLAT Server of ADSBx, doing not much more. After some hours of handshaking, it briefly gets connected to MLAT Server, appears in sync-4 then gets kicked off right away, they handshakes for a few hours again, and then gets included in sync-6. This is a repeated pattern. There is absolutely no sense to this. This receiver worked just fine. Since it as has the exlusive ADSBx image on it, I will just turn it off as well, as it´s just doing nothing much more than becoming the target of kick outs from MLAT. The connection issue to Grafana was probably more an issue of the actual internet connection I used at the time when accessing that receiver remotely. You can say, a slow mobile connection does not seem to be sufficient to keep SSH sessions alive or to connect to Grafana. So again, the receiver itself is on a DSL-like connection and has no connection issues. When it is in sync-4, it has excellent sync and the logfiles show that about 75% of its MLAT is being uses by ADSBx. It has a very good MLAT footprint of ED-R 401 MVPA NE - a military super zone that sets new standards, in terms of opaqueness and lack of democracy, in north east Germany. And I do believe that this is the actualy reason why its constantly being kicked out and prevented from contributing to MLAT coverage in north east Germany. As said, other receivers are constantly online. Never get kicked. In sync-4. So questions remain: What is the logic behind these kick-outs of receivers, what´s the pattern? What is needed to finally solve the overload problem of European ADSBx MLAT? Why do most of receivers stay connected in sync-4 while a few get, most of the time, canned, although they used to work flawlessly for years. Just reminding you: you could not fix this issue when you had Zerotier access to the receiver. It got kicked off the sync just two days after installing the ADSBx image from scratch on a new SD. So it´s not the SD, it´s not the Pi, it´s not the internet connection, it´s not FA parts of software, it´s not lack of range, it´s not offline, ever. What´s the point to keep feeding to ADSBx then?
Maybe years ago, when your feeder used to work fine, we weren't as many as we are now. Adsbexchange community has grown little by little, so we simply reached the critic threshold and the MLAT server farm can't deal with it. I'm from center Italy, same sync zone, and I'm used to see all my feeders costantly kicked out of MLAT matrix, as well as my neighbours, it doesn't matter how good is our coverage or our connection , it is just a matter of "too much for that MLAT software and hardware". Anyway, it wouldn't take too long, in a couple of years we will get rid of MLAT.
You let me into one PI, the other you said you couldn't for whatever reason. I was able to login for a few minutes at most then you took it offline and starting fucking with it again. You do realize it is feeding ADS-B data., it's not 'just using electricity for nothing'. You changed names, you've ranted about some CDN, you've done everything but make it easy to assist. Put ZeroTier on it and stop fucking with it and I will look at it when I have time. I had it feeding a custom port, you couldn't even leave that alone for more than 10 seconds. ,, I don;t know what to tell you. I'm starting to think this is all 100% user error.
I moved global slices around to see if we can spread load better. Eastern Europe/UK: Longitude -28 to Longitude 2 Western Europe: Longitude 3 to Longitude 13 Everything West of Berlin is now on Asia: Longitude 14 to 179 401-ED-2_d67017_1.26vlan This guy still won't stay out of MLAT 6 matrix. So that has to be user error on the config.
Coverge looks much better now, so many new feeders on map. James please update region names and boundaries on Feeder Statistics site. I can't find proper name for new region 5 (East of 13 degrees?) . I don't want my feeders to be in Asia.
Moved to ... Eastern Europe/UK: Longitude -28 to Longitude 2 Western Europe: Longitude 3 to Longitude 12 Everything West of Berlin is now on Asia: Longitude 13 to 179
Should we split Berlin .. make it East and West Germany .. We can limit the bandwidth and connections so the East German feeders have to queue up.
