The adsbexchange-netcat_maint.sh script has a bug and it's really not running the netcat command line when it's sent to background and detached from STDIN. In order for it to work correctly, the flag "-d" should be added to the first nc command to tell it not to wait for input from STDIN. I accidentally discovered this problem when I tried to set up a custom feed and the script was just sleeping all the time when it was sent to background but otherwise running fine when it was in the foreground. It seems that I have been only sending MLAT to ADS-B Exchange all along due to this issue. I hope this helps. Flavio
Yup. We noticed netcat was not working quite right on disconnects as well. Changed to socat in the new images.
If you downloaded the link in the other thread .. No I'm using the same version. I even downloaded it, unzipped it, and burned a new SD card. This change is for netcat. Dan's new piware 3.5.3 and ADSBexchange image both use socat now.
I didn't notice such kind of problems with netcat script. If it is called on startup (ADSBx MLAT client installation as described in How to feed/ Getting Started). I've tested modified scripts on at least 3 of my stations. No difference between original script and modified to -w 300 or -d. But I'm using custom setups from scratch, all components installed step by step (Grafana is installed on Debian stretch machine and working). Any feedback is welcome, let's try to make image as perfect as possible. Marcin
He might be referring to the JP setup script from git. Dan and I need to make sure people know we didn't write that because it has almost no error checking. Netcat has issues when it drop the connection to adsbexchange.com because we're piping the data. So one side stays up and the other doesn't or might fail to reconn. socat seemed to eliminate this and it was suggested on git the jp replace it - but he seems to have disappeared.
Fork his install. If there is no other way... Most of the times users are making mistakes during modification of scripts (not saved, Pi not restarted etc.). Improve your image, when I'm back home I'll try it. Be sure that every bug will be reported
Try to stop for a moment the dump1090 service: sudo service <dump1090-flavour-in-use> stop and then look at process list: ps -ef you will notice the first instance of netcat's pipe has died meanwhile the second instance is still there. With the -w option, that orphaned process waits just x seconds and then successfully exits, allowing to respawn a new pipe when you will restart dump1090...without the -w option it will stay there forever.
I'll try to simulate it tomorrow, thanks for information. Anyway for many users such kind of discussion is like reading a book about quantum physics written in Chinese . They expect plug and play solution.
Hello! I adapted the "JP setup script from git" to include -w 300 -d on the netcat line That seems to be working. But I cannot figure out if I am sending the mlat correctly. I have two mlat processes: piaware 881 root 885 I thought the second process was to deconflict with the piaware mlat, but I cannot tell if this is configured properly. I see two receivers on the mlat map within the 5km offset, but one is named and the other has a string that I can't trace back to this feeder. mlat for the piaware seems to be working properly. I tried to put in the output from ps -ef but think Cloudflare is blocking something. v/r, C-F
Everything looks good, piaware mlat-client is running, adsbx mlat-client is running too. (piaware user is piaware, adsbx user is root - search this forum, there is explanation why). So far so good. Do you see your feeder on sync-matrix?
Ah, so I found the issue. Missing the sign in the longitude. Feed location was showing up in Asia. I think it will take an hour or so to verify on the coverage map page? The sync matrix for Eastern US is a bit much for this little chromebook for some reason. But in looking into all of this, one thread mentioned that connecting both mlat processes to the same local 30104 port would cause jumping around in the display. That seemed to be part of the desire to separate the mlat processes. I am seeing the jumping around on the piaware display for one of the helicopter mlat only traces. That aircraft doesn't appear at all on the custom ads-b exchange feed. So, by fixing the location, but not separating the ports - did I just inject error into the feeds? Or is that just an output to a local display and only used when looking at the piaware map? v/r, C-F
MLAT can be inaccurate and depends highly on the time sync between feeders seeing the same transmission, so they can solve for the most likely location of the transmitter (aircraft) in relation to the feeders based on signal strength.
