PiAware master process (piaware) is running with pid 936.
PiAware ADS-B client (faup1090) is running with pid 2715.
PiAware mlat client (fa-mlat-client) is running with pid 5228.
Local ADS-B receiver (beast-splitter) is not running.
airspy_adsb (pid 1828) is listening for connections on port 30005.
faup1090 is connected to the ADS-B receiver.
piaware is connected to FlightAware.
the Mode-S Beast serial port is producing data on localhost:30005.
Somehow I managed to get the planes displayed on SkyView when I use the Airspy BUT no data is uploaded to flightaware.
Also in log (flightaware webpage is showed “no messages received in the last 5 minutes”.
Still on local network I can see the detected planes and the message rate.
Any idea why?
Airspy command is
sudo ./airspy_adsb -c 127.0.0.1:30005:beast -c -p -n -g 19 -w 4 &
I use port 30104 but this could be my setup.
You are sending the traffic to the MLAT port.
This is why you see the traffic on dump1090 but FA doesn’t see any.
Check out this post
I was able to increase my overall message rate by about 20% using the Airspy Mini and Nevis amp with ceramic filter over the FA Pro Dongle with Fa Filter. Thanks to all who contributed to this thread as I would not have been able to make this setup work without your posts!
Were you able to get your Airspy Mini to process data by reproducing the steps as described by @jonhawkes2030? Do you maybe have some additional tips or advice? I am trying to achieve the same but have not been able to yet.
Post 4 and 5 were the key for me. I think the key is starting with a fresh Piaware SD card image, I could never get it to work on an SD image that had been running. I always got a conflict with port 30005.
Expand file system, setup wifi, feeder id etc as you normally would by editing piaware-config.txt or using command line sudo piaware-config
From post 4, follow jonhawkes2030 steps down to editing /etc/rc.local except that I used:
sudo piaware-config receiver-type relay
read in another post this only works on an SD card image
From post 5, I used mtindor’s command line and added the “&” that seems to be missing at the end. It worked perfectly and MLAT picked right up. Put the line below in your /etc/rc.local
As the latest edition of the Airspy ADS-B program (v1.19) is out I decided to give it another try with a new Pi3B+ and it appears to be working a lot better with a few changes to the start-up lines I’ve seen in other post. It is [ sudo ./airspy_adsb -c 127.0.0.1:30104:beast -l 30001:AVR-STRICT -f 1 -g 18 -p -n -w 4 d 6 & ] and by also installing Dump1090-mutability and PiAware v 3.5.3 add-on package it is also working well for mlat.
Some of the issues that I have had in the past such as a large percentage 60+% of “ADS-B rejected” (as seen on Virtual Radar Server statistics page) using port 3005 in beast mode have been eliminated by use of the AVR-STRICT command and using AVR to feed port 30001 of Dump1090-mutability in –net only mode.
Also utilizing decimation of 6 on the airspy seems to let it acquire better decodes of fringe aircraft while decreasing the bandwidth used which is a win\win and is keeping the cpu at no higher than 20-25% with the Pi gui running showing top, netstat and piaware logs running
I am getting quite a few more Mode-S and ADS-B messages and constantly see additional planes on VRS in my traditionally weak directions NW to SW which is really nice
There are still a couple items that I see that I haven’t been able to figure out due to my lack of understanding as follows:
If I send the Airspy decodes to dump1090-mut’s port 30001 why is the messages received count (both ads-b and mode-s) on dump1090-mut’s output port 30005 higher than where it comes in on 30001 as shown on the Virtual Radar Server stat’s page?
Why is the airspy_adsb command of [-c 127.0.0.1:30104:beast ] required to make it work. Shouldn’t all of this be possible using just dump1090-mut interfacing with Piaware’s mlat-client after receiving data on port 30001 from the Airspy?
Thx @jonhawkes2030
I saw your post #4 and just now tried it and it worked but for the life of me I don’t understand how dump1090-mut is receiving any information. I can see airspy_adsb receiving info through port 30104 using netstat but for the life of me I don’t understand how dump1090-mut is getting any information from the airspy. I’m obviously missing something.
I saw the info on the Airspy quickstart site as well and what I’m getting out of all of this is that the “message routing” portion of dump1090-mut/dump1090-fa has the ability to separate the data from mlat and ads-b going to port 30104 to send the adsb info to port 30005 and piaware also strips out the mlat to send to ports 30105 and 30106 which isn’t apparent on the block diagram from FA.
@jonhawkes2030 I hope this makes sense after but looking closer I’m thinking that by putting the feed from the airspy to port 30104 it is received by port 30002 “message routing” and sorted out from there. I had the method in my head from setting up uat978 where dump978-maint.sh was sending the info thru nc to 30001.
It’s working which is the main thing but I just want to fully understand the process.
30001 is TCP the input for AVR information. Dump978 only provides this type of information.
There is no timing information in AVR so you can feed other receivers in using this port if your want to consolidate feeders.
The directions on the diagram are data flow not connectivity information. This is the cause of the confusion.
I have noticed that I get a 15% better message rate with rev 39 of airspy_adsb, vs the current rev 42. I reverted back to 39 as I still had a copy on my SD card.
Anyone noticed an MLAT problem in the last time with the Airspy? Mine is running on an Tinkerboard and from time to rime Im getting an Red MLAT icon. Maybe is also network dependant… Also using an GPS receiver just to be sure that everything is fine with the clock…
The clock is taken from the dongle(Airspy/RTL etc), not GPS/GNSS. GPS is only used for position.
If you don’t have enough aircraft in view, it can go red.
Also, if the CPU heats up too much MLAT can also be affected.
Any answer on this? I am just starting experimenting with airspy / xU4 combo. I have has some issues with the initial scripts mentioned here causing some web portal issues so I am trying to find a stable OS that will prevent these.
