---- The format of the data output can be found in this document The date in Port 30003 messages is always the Linux system date. The timestamp instead is a GPS timestamp when the configuration is set to GPS timestamps and system time when the Radarcape operates in legacy 12 MHz time stamp mode. Due to the low efficiency and high processor load caused by this protocol, please do not use Port 30003 unless really necessary. A better way of getting the same data is the deltaDB service. On Linux, a very simple method how to access the TCP stream of Port 30003 is socat: --- Ugh .... relying on users to keep system clocks correct sounds like a nightmare all over again. GPS time would be nicer option, but how many going actually configure it. So ... we can do this, VRS talks basestation. Any reason to use the Radarcape if you have a Pi as well?
It looks like the damn thing has stopped working again. I just got an email stating "ADSBHub station 'ENNO_9' is inactive 1 day" ---- [email protected]:~$ sudo service mlat-client status ● mlat-client.service - LSB: Multilateration client Loaded: loaded (/etc/init.d/mlat-client) Active: active (exited) since Sat 2019-02-02 15:25:08 UTC; 4 days ago Process: 350 ExecStart=/etc/init.d/mlat-client start (code=exited, status=0/SUCCESS) Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable. [email protected]:~$
Hmm, I am a bit confused. I think this is another feeding, which I setup when I installed the RPi with multi site feeding. I was then told to go to adsbx and make a account, and add a new receiver, which I did. And I think this is the one in question. Can I delete ENNO_9 from my account ? And is there any way to add surgravvegen_02 to my account ?
There is nothing like accounts on ADSBx. Just username in mlat script. If you want to use custom port and see your name there claim this port as described here: https://www.adsbexchange.com/how-to-feed/custom-feed-how-to/ ADSBHub is another story, contact them and ask for solution.
The RadarCape is an excellent receiver which provides better timestamps and better reception of overlapping messages. It is fully compatible with Beast data format (well, Gunther INVENTED the Beast format)..... So just use the correct port and Beast formats for the feed.... /M
I've been talking with Gunther about adding beast output as a default feeder. Ball is in his court. Maybe if people start asking.
I'd like to say Hello from Stuttgart, Germany! As I like to share my ADS-B data with your service I set up Saturday and Sunday "Scharnhausen-01" twice. On Saturday 14th Sept 2019 with RPi to see how things works. And on Sunday 15th Sept 2019 with my Radarcape (the original unrestricted Jetvision version). Now I'm not sure which one finally is the registered on your system? The RPi has no dump1090 installed but could take data from my Radarcape. I think it is much easier and "better" to share the data direct from the source Radarcape. I read James and MDA are very experienced with this matter. From the available ports I guess Port 10006 Binary formatted raw data with all Mode-S data formats (CRC pre-checked, no Mode-A/C) would be the most effective? This port 10006 I used during Setup your script onto the Radarcape. What can you "see" from me on your side? Do you receive also MLAT data from me? Is there a way to monitor what data you are receiving from me? Questions over questions from a newbie. EDIT: spelling mistakes corrected
The port the setup queries for is not the local but the server side port. (The naming is a little confusing) The local port which you need to change is currently not that easy to change. But i've made a pull request on github. After that change editing the configuration file will be sufficient. In regards to which port to use, i don't know that.
The code change that i wrote is not yet in the main repository. If you want to try, do the following: Code: cd /tmp git clone https://github.com/wiedehopf/adsb-exchange.git cd adsb-exchange sudo bash setup.sh Then edit /etc/default/adsbexchange: Code: sudo nano /etc/default/adsbexchange You are running this on the radarcape, then the IP will be 127.0.0.1, but you can also use another IP. According to https://wiki.jetvision.de/wiki/Radarcape:User_Services_and_Interfaces you should use port 10004, Mode AC messages are not useful to adsbexchange. In the line starting with INPUT= change 127.0.0.1:30005 to 127.0.0.1:10004 You can also use another IP if the adsbexchange script is not running on the radarcape. Ctrl-O and Enter to save Ctrl-X to exit Then restart the adsbexchange services: Code: sudo systemctl restart adsbexchange-feed adsbexchange-mlat After about 5 minutes you should see the status change on this website: https://adsbexchange.com/myip/
Thank you wiedehopf! A connection is displayed on the myip page: Route: beast_front Port: 30005 Backend: beast_back Connected: cons-10-51070 Age: 35m30s Nevertheless I configured it to port 10006 for now. I guess the Radarcape wiki is not up to date. These are the TCP Data Ports available as I can read it on the status page of the internal Radarcape web server: Port 10002 Mirror of the data as it comes from the FPGA (see FPGA settings) Port 10003 Binary formatted raw data with all Mode-S and Mode-A/C data formats (CRC pre-checked) Port 10004 Binary formatted raw data with DF-11, DF-17 and DF-18 only Port 10005 Binary formatted raw data of aircrafts without position Port 10006 Binary formatted raw data with all Mode-S data formats (CRC pre-checked, no Mode-A/C) Port 30003 Port 30002 (JSON format periodic output) However, my data (Scharnhausen-01) seems not to be used yet, because -for example- some airplanes on the ground of the Stuttgart airport are not displayed, which I can receive.
echo "show sess all" | socat stdio unix-connect:/run/haproxy/admin.sock | grep "213.153.90.177" -B 4 -A 4 0x60b3a00: [17/Sep/2019:06:00:21.710436] id=4700745 proto=tcpv4 source=213.153.90.177:44904 flags=0xce, conn_retries=3, srv_conn=0x327eb10, pend_pos=(nil) frontend=MLAT_front (id=17 mode=tcp), listener=? (id=1) addr=167.114.60.74:31090 backend=MLAT_back_4B (id=531 mode=tcp) addr=172.19.2.2:38930 server=mlat-c (id=1) addr=172.19.4.5:31092 -- 0x3dbbaf0: [17/Sep/2019:14:29:22.311051] id=5116075 proto=tcpv4 source=213.153.90.177:37208 flags=0xce, conn_retries=3, srv_conn=0x3390460, pend_pos=(nil) frontend=beast_front (id=2 mode=tcp), listener=? (id=1) addr=167.114.60.74:30005 backend=beast_back (id=539 mode=tcp) addr=172.19.2.2:60570 server=cons-10-51030 (id=336) addr=172.19.5.10:51030
Seems to work, MLAT does not though. http://adsbx.org/sync/feeder.html?4B&Scharnhausen-01 Hmm i think the problem is that the setup script starts/restarts the mlat-client before the configuration file is written. Sorry @James But should be fixed relatively easily.
