I upgraded from a rtlsdr v3 to an Airspy mini a few days ago and managed to get it running ok using the latest piaware image 3.6.3 following the helpful instructions on this forum:
I found that the RPI3B+ cpu% was getting quite high during peak times so decided to put my Ordroid XU4 into service to see how that would cope, but just cannot get port 30104 to work - always get ‘errno111’ when I connect to FA servers.
I am running Armbian 5.59 Odroidxu4 Debian stretch_next4.14.66 together with piaware and Dump1090-fa add on programs and they work fine when using the rtlsdr so I know that side of things is ok - just fails when using the airspy.
I have tried using both the sudo piaware-config receiver-type ‘relay’ or ‘other’ commands, but still no joy.
command line being used for airspy is:
sudo ./airspy_adsb -c 127.0.0.1:30104:BEAST -l 30005:BEAST -l 30001:AVR -g 21 -p -w 4 –d 1 –f1 -x -m12 & which works fine with the airspy mini and sd image 3.6.3 - its running now!!
With dump1090/piaware running, but before you start airspy_adsb, what does running
sudo netstat -an | grep 30104
look like?
You should see a line like this:
tcp 0 0 0.0.0.0:30104 0.0.0.0:* LISTEN
If you don’t see that, it’s something related to dump1090.
Also, can you prune your command line a bit for testing?
You don’t need the “-l 30005:BEAST -l 30001:AVR” and “-w 4 –d 1 –f1” bit right now. Add in a “-v” and drop the “&” for testing. You’ll see additional airspy_adsb start-up messages that may be helpful.
Is dump1090-fa even running right now after you changed the receiver type?
If it’s not the airspy will not be able to connect to it and that is then the problem.
The kinda unintuitive solution would then be to first make sure dump1090-fa does not use 30005 port (change maybe multiple occurences of 30005 in /etc/default/dump1090-fa to let’s make it 30305 for simplicity).
Then use “piaware-config receiver-type rtlsdr” to switch back to default configuration which is to run dump1090-fa and have it offer data on 30005. But because of the dump1090-fa config change now it will offer data on 30305 and be ignored by piaware. piaware will still look for 30005 and hopefully find airspy offering data there
so sudo systemctl restart piaware and sudo systemctl restart dump1090-fa.
Now your command line for airspy should work.
(all this presumes that changing the receivertype of piaware to relay or other might make it switch off dump1090-fa assuming it doesn’t need it, meaning you can’t connect to it with airspay to give it data which it will then present on the nice local map)
If this explanation is too complicated i can make try and make it simpler by removing the explanations:
piaware-config receiver-type rtlsdr
change the number 30005 in /etc/default/dump1090-fa to 30305 (maybe more than one occurence in the file)
sudo systemctl restart piaware
sudo systemctl restart dump1090-fa
sudo ./airspy_adsb -c 127.0.0.1:30104:BEAST -l 30005:BEAST -g 21 -p -w 4 –d 1 –f1 -x -m12 &
So now i just hope my assumptions are correct and this will work
@SMburn
I tried sudo netstat -an | grep 30104 and nothing was returned when the airspy was being used in all 3 combinations ie.receiver-type rtlsdr, other and relay.
The only one to return any information was rtlsdr (when being used) as follows:
rtlsdr works fine on the Ordroid xu4, but airspy doesn’t - but using a SD image, with alterations as I have done with the add on packages for the Ordroid, works fine with a RPI!!!
@wiedehopf
I tried your suggestions as well to no avail - still the same result
I am at a loss where to try next.
In case it may help, sudo netstat -an | grep 30104 with the airspy/rpi combination returns:
tcp 0 0 0.0.0.0:30104 0.0.0.0:* LISTEN
tcp 0 1029 127.0.0.1:55460 127.0.0.1:30104 ESTABLISHED
tcp 864 0 127.0.0.1:30104 127.0.0.1:55460 ESTABLISHED
tcp6 0 0 :::30104 :::* LISTEN
tcp6 0 0 ::1:30104 ::1:40436 ESTABLISHED
tcp6 0 0 ::1:40436 ::1:30104 ESTABLISHED
Much appreciated for your assistance in trying to solve this.
can you post your /etc/default/dump1090-fa please?
also which program spits out errno 111 and please post that error log.
Just out of curiosity with the airspy use 30004 instead of 30104 in the command line. It should not be a factor but what do i know. (yeah this a dumb idea the error log is more important i think)
Also before starting airspy do: sudo netstat -tulpn | grep 30005
so we can see if some other program is already listening on 30005
if the socket is already used it can’t listen on it.
maybe dump1090 is running instead of dump1090-fa? that’s one of the last things i can think of.
@wiedehopf
Will do when I get back home - VMT for your help
@SoNic67
I’ve tried disabling IPV6, putting piaware in hosts etc to no effect - I feel its got to be something in the OS that’s causing the problem, but no idea what!
Used to program ARM back in the day in machine code, but lost with compiled coding!
Maybe it was “fixed” on Pi3 (maybe not), but I am suspecting it might be something to do with the IPv6 implementation on that specific platform (Armbian 5.59 Odroidxu4 Debian stretch_next4.14.66).
I don’t have IPv6 enabled in router (nor by my ISP).
That is just lighttpd being configured to listen only on IPv6.
Anyway the -c 127.0.0.1:30004 part is not gonna connect via IPv6 because that would be a different address.
But there was some other fault where disabling IPv6 or having IPv6 addresses in the /etc/hosts file actually caused a problem. Don’t remember it specifically though.
@wiedehopf
Don’t have the logs now, but airspy was reporting connected to port 30104 and then disconnected - kept repeating.
Piaware was reporting the errno111.
In desperation, I re-imaged the OS, loaded up dump1090-mutability and got that working on its own!!
Downloaded the piaware addon for dump1090 and all seems to be working!!!
It’s a mystery as to why I can’t get dump1090-fa working as I prefer the look
Still willing to try other things to get dump1090-fa working, but will do work on it in the small hours so my numbers don’t get hit so much!!!
Here is netstat result with working airspy/ordroid set up - I’ve disabled IPV6 at set up, but still used @abcd567 suggestion.
yeah if you still had your config file for dump1090-fa that you used when it wasn’t working that would be great lol
Also that ipv6 is not disabled when a program is listening on it lol. Maybe need to reboot after disabling ipv6?
Hmm i have an idea maybe dump1090 needs to be in net-only mode? Did you set that?
(–net-only in the options)
The only change I made to the piaware config was to change ‘receiver-type’ to other/relay/rtlsdr to see if I could get the add on packages to work, and ‘airspy’ load etc as per the link in my first post - that’s what worked with the RPI.
No other changes made to dump1090-fa as assumed it looked after itself!
I used latest 3.6.3 versions of piaware/dump1090-fa for all tests and now I’m using dump1090-mutability 1.15~dev with piaware 3.6.3.
As I could change the dump1090-mutability settings file I have changed receiver type to ‘none’ and piaware-config to ‘relay’
On setting up the new OS image I set a static ip address for my network (192.168.etc), and disabled IPV6 for APT and system using their config program - maybe it doesn’t do a good job!!!
/etc/hosts file is the default apart from entry for FR24:
Yeah that’s the problem: dump1090-fa settings per default make it listen on 30005 where you want to listen with airpsy and two programs can’t listen on the same port.
Also it’s a good idea to use dump1090-fa in --net-only mode so it doesn’t error out when it doesn’t find the rtl dongle. Also you need to make it NOT listen on 30005 by changing that port.
I’m just wondering which settings are right now working with dump1090-mutability?
Could you post the config file you use?
Sep 21 18:58:22 odroidxu4 piaware[1134]: 282559 msgs recv’d from dump1090-mutab (3140 in last 5m); 282559 msgs sent to FlightAware
Sep 21 19:03:22 odroidxu4 piaware[1134]: 285725 msgs recv’d from dump1090-mutab (3166 in last 5m); 285725 msgs sent to FlightAware
Sep 21 19:07:54 odroidxu4 piaware[1134]: mlat-client(1233): Receiver status: connected
Sep 21 19:07:54 odroidxu4 piaware[1134]: mlat-client(1233): Server status: synchronized with 524 nearby receivers
Sep 21 19:07:54 odroidxu4 piaware[1134]: mlat-client(1233): Receiver: 1707.2 msg/s received 338.2 msg/s processed (20%)
Sep 21 19:07:54 odroidxu4 piaware[1134]: mlat-client(1233): Server: 0.5 kB/s from server 0.0kB/s TCP to server 4.6kB/s UDP to server
Sep 21 19:07:54 odroidxu4 piaware[1134]: mlat-client(1233): Results: 208.1 positions/minute
Sep 21 19:07:54 odroidxu4 piaware[1134]: mlat-client(1233): Aircraft: 27 of 39 Mode S, 79 of 109 ADS-B used
Sep 21 19:08:22 odroidxu4 piaware[1134]: 288946 msgs recv’d from dump1090-mutab (3221 in last 5m); 288946 msgs sent to FlightAware
Sep 21 19:13:22 odroidxu4 piaware[1134]: 292181 msgs recv’d from dump1090-mutab (3235 in last 5m); 292181 msgs sent to FlightAware
You are using port 30005 double right now. Don’t know why it would even work.
For some reason that works with dump1090-mutability and not with dump1090-fa. Not sure why but using 30005 twice as a listen port is WRONG and if you want to use dump1090-fa you need to change that.
In one of my first posts i suggested changing 30005 to 30305 in /etc/default/dump1090-fa but i guess that didn’t reach you
can you do a netstat -tulpn | grep 30005 ?
i’d like to know which program is listening on 30005
Maybe airspy just doesn’t open the port 30005 if it’s already used.
airspy connects to dump1090 sends it the beast data and piaware then connects to dump1090 and gets the data that way.
Is mlat working right now? Not sure if that is even possible with airspy.
Yes, I did try changing 30005 to 30305 in /etc/default/dump1090-fa but unfortunately it didn’t work - port 30005 has always seemed to connect OK - might take a go or two, but connects - its 30104 which has seemed to cause the problems by connecting and being disconnected which just repeats.
Yes, Mlat is working like a charm - Multilateration (MLAT): Supported / Enabled (synchronized with 518 nearby receivers)
[2018-09-21 20:52 BST] mlat-client(1233): Results: 205.3 positions/minute
Also did port 30104 to see if that shows you anything!
There’s no need for airspy_adsb to listen on any port. Don’t use any “-l” command. It just needs to feed to the stock 1090-fa or 1090-mut on port 30104 using the “-c” command.
This! Piaware will handle the MLAT and other chores. Airspy does nothing but feed decoded signals to dump1090.
