Yeah, the only filtering of military and private flights is done on the FA web site itself. dump1090 is just doing raw receiving.
nothing to do. The only way to keep command working on boot is typing the socat command inside rc.local (see image attached)
Interesting .. and now it's working no issue on reboot? but it will fail if one or more side disconnects ... It needs to be in a while loop rc.local should run things as root too .. odd that you have to put sudo try running the script with sudo from rc.local
it might be that you didn't make it executable? chmod a+x nameofscript.sh It doesn't look like I told you to make it exectuable - sorry sometimes I forget these things being linux user and coder to get script to run chmod a+x the .sh script Code: #!/bin/bash while true do /usr/bin/socat -u TCP:192.168.1.50:30005,nodelay TCP:localhost:30004,nodelay sleep 30 done save it as name.sh You have to make it executable chmod a+x name.sh then in rc.local Code: /home/pi/name.sh &
May be the script is not executable, under ls command it appear grey colored like not each other script... I'll try to make it executable following your instructions! Thanks again for your help
Yup ... it should be green colored or at least not gray.. executable not set probably Code: sudo chmod a+x filename.sh
I am a noob to ADSB, so forgive me as I am still trying to figure things out. I was trying to get my 978 Mhz UAT traffic setup and couldn't figure out why it wasn't working. Eventually I discovered that in the adsbexchange-dump1090_maint.sh script that the --net-ri-port was set to 0 and I had to change it to 3001 in order to pipe in my UAT traffic to the local dump1090 instance. What is the reason for disabling --net-ri-port? Everything seems to be working fine with it re-enabled, but I would like to know of any downsides to this approach. I also noticed that the unused adsbexchange-978_maint.sh script on this image would feed all dump978 directly to the adsbexchange server instead of going through the local dump1090 first. I can see the benefit of having a dedicated 978 custom feed using this method. Is that why it is written that way? I wish there were some kind of stats (local or server-side) though. I guess in order to get separate stats for 1090 and 978 I really need to run each on its own pi? Thanks a lot.
You don't need 2 separate Pi but you do need 2 individual SDR. dump978 isn't fully baked - tho Dan and I have it pulling from the towers in PHX and it works well. On my most recent build that includes a private vlan for all pi, a bunch of bug fixes, a cellular dongle script (t-mobile $30/year IoT), and even more bug fixes - I have 978 setup to enable. I suppose you could feed it into dump1090 then have dump1090 feed adsb exchange. Code: #!/bin/sh if [ -f "/tmp/adsbx-params" ]; then . /tmp/adsbx-params else echo "DUMP978 ERR: Configuration file does not exist." exit 0 fi if [ ${UAT} = "yes" ]; then while true do sleep 30 if [ -z ${UATPORT} ];then UATPORT=30005 fi rtl_sdr -f 978000000 -s 2083334 -d 1 -g 48 - | /home/pi/dump978/dump978 | /home/pi/dump978/uat2esnt | socat TCP:feed.adsbexchange.com:$UATPORT done else exit 0 fi I believe you will need to pipe that into dump1090 https://github.com/mutability/dump978 Warning: This one is particularly experimental. uat2esnt accepts 978MHz UAT downlink messages on stdin and generates 1090MHz Extended Squitter messages on stdout. The generated messages mostly use DF18 with CF=6, which is for rebroadcasts of ADS-B messages (ADS-R). The output format is the "AVR" text format; this can be fed to dump1090 on port 30001 by default. Other ADS-B tools may accept it too - e.g. VRS seems to accept most of it (though it ignores DF18 CF=5 messages which are generated for non-ICAO-address callsign/squawk information. You'll want a pipeline like this: Code: $ rtl_sdr -f 978000000 -s 2083334 -g 48 - | \ ./dump978 | \ ./uat2esnt | \ nc -q1 localhost 30001
I do have it working with 2 SDRs. What I meant by 2 separate Pi is the ability to differentiate my stats for 978 vs 1090 traffic. As of now, it all goes into dump1090 and looks the same. Do you think it is better to just send it directly to the adsbexchange servers? I think I have the latest version I see here, 1.24c. Are you talking about an unreleased version coming up? Thanks a lot.
Upcoming image, yes. You aren't going to see anything substantially different than dump1090 unless someone is broadcasting on UAT. If you are near an airport - you may get some traffic that is out of line of sight but still inside the 'puck' of the 978 tower receiving a 1090mhz broadcast from an aircraft and thus traffic data broadcast by the tower and received by your SDR. This is the relay traffic that the tower provides - and should be in sync with the dump1090 traffic. Ground stations only broadcast in response to ADS-B Out aircraft • FAA sends a customized traffic product to each Out aircraft • 30nm in diameter around the Out aircraft and within 3500 ft. • If you’re close to an ADS-B Out aircraft (in the “hockey puck”) you could see traffic. But it’s for the other aircraft. So your line of sight SDR tuned to 978 with see all the traffic data for these 'pucks'. What you might pick up is Mode C traffic from the ADS-B tower on 978Mhz, if and only if a 1090 mhz plane has a Mode C target within the 1090 mhz aircraft 'puck'. This is from a pilot's perspective, but assume You is your SDR. So your SDR will see that Mode C aircraft rebroadcast on 978 mhz.
Just wanted to update on my Raspberry Pi 3 regarding changing the retention of data from the default 4hrs. I have been gradually increasing the ram retention, and I'm now up to 9hrs with no noticeable impact on the Pi other than approaching 40% memory left. I am going to try 10hrs and 12hrs over the coming days.
Another question for the forum! My image is feeding a custom port to ADSBx. I can see the data on port 51291 no problem, and I've registered to assign it to me. But, I've been running the Pi headless. I connected an HDMI cable today, and there's a bunch of error messages displaying. It currently keeps repeating the following: But my adsb-exchange.txt file has the correct port set. Where is it getting 31090 from?
That's fine. No Binary formatter is prometheus, or grafana, I can't remember which. (nothing to worry about - it's doing what it's supposed to do - parsing the text scraper). 31090 is mlat-client trying to connect to mlat server. This happens when MLAT server is overloaded - it will eventually connect. Nothing to do there.
We're having a lot of issues with delayed data from feeders. So working on how to handle that when global clock drifts and by how far do we let it.
Hey folks, Just wanted to let you know I've had the Grafana data retention set to 24hrs for a while now (well over a week) and there's no sign of the Pi failing or having issues. The attached image shows 24hrs worth of data, and gives a much better visual representation of the data is is capturing in relation to time. The stats show the Pi is still all safely within green limits, and no problems.
