Ok next time, i don’t reboot ;+))
A different question concerning the Airspy decoders: Is there a way to list them in the global stats? This could help a lot with the testing we are doing. Thanks!
1 Like
Bad luck, the system still has a strange behavior :
I have checked and my Pi4 is not freezed, i have access on SSH, all service are runing and the Airspy daemon too ! But however, it no longer returns any info on the web pages !
Maybe a crash of the USB key, but it’s been a lot lately :+((
What USB key?
Anyway this all looks like random data corruption.
The Airspy-Mini USB.
I’d recommend starting with a fresh sd-card (as in from the store. somehow i get the impression this may be data corruption with the CPU plotting wrong also occuring).
When the airspy crashes, have you checked that it’s not dump1090 that’s crashing?
As in those two logs are interesting if you get no more data:
sudo journalctl -u airspy_adsb --no-pager
sudo journalctl -u dump1090-fa --no-pager
I would doubt that. I’m not sure piaware reports any such thing back to home base as far as what type of receiver is being used. I’m sure they absolutely could do that, but I doubt it’s being done. I’ve never seen anyplace where one could sort out receivers based upon the type of SDR in use.
Mike
piaware does collect the process name of whatever’s listening on 30005, but that’s mostly for debugging and propagating it up to the stats pages would be pretty painful
I think most people are using wiedehopf’s airspy script, which means that dump1090 is listening on 30005 anyway - the airspy decoder listens on a different port and makes an outgoing connection to dump1090 on 30004.
Airspy-Mini crash again !
root@ads-b:~# journalctl -u airspy_adsb --no-pager
-- Logs begin at Thu 2019-10-24 18:23:01 CEST, end at Thu 2019-10-24 20:22:50 CEST. --
oct. 24 18:23:04 ads-b systemd[1]: Started Airspy ADS-B receiver.
oct. 24 18:23:04 ads-b airspy_adsb[351]: Listening for beast clients on port 29999
oct. 24 18:23:04 ads-b airspy_adsb[351]: Listening for asavr clients on port 47806
oct. 24 18:23:04 ads-b airspy_adsb[351]: Acquired Airspy device with serial 26A464DC28381C93
oct. 24 18:23:04 ads-b airspy_adsb[351]: Decoding started at 20 MSPS
oct. 24 18:23:04 ads-b airspy_adsb[351]: /!\ Lost 294912 samples /!\
oct. 24 18:23:04 ads-b airspy_adsb[351]: /!\ Lost 98304 samples /!\
oct. 24 18:23:04 ads-b airspy_adsb[351]: /!\ Lost 393216 samples /!\
oct. 24 18:23:04 ads-b airspy_adsb[351]: /!\ Lost 294912 samples /!\
oct. 24 18:23:16 ads-b airspy_adsb[351]: Push client connected to localhost:30004 (beast)
oct. 24 20:00:51 ads-b airspy_adsb[351]: Decoding stopped
oct. 24 20:00:51 ads-b airspy_adsb[351]: Push client disconnected from localhost:30004 (beast)
root@ads-b:~#
root@ads-b:~# journalctl -u dump1090-fa --no-pager
-- Logs begin at Thu 2019-10-24 18:23:01 CEST, end at Thu 2019-10-24 20:23:46 CEST. --
oct. 24 18:23:04 ads-b systemd[1]: Started dump1090 ADS-B receiver (FlightAware customization).
oct. 24 18:23:05 ads-b dump1090-fa[466]: Thu Oct 24 18:23:05 2019 CEST dump1090-fa 3.7.2 starting up.
oct. 24 18:23:05 ads-b dump1090-fa[466]: Net-only mode, no SDR device or file open.
root@ads-b:~#
Each time the same info in the log : Decoding stopped !
Yeah so the problem is definitely with the Airspy somehow.
But no clue what’s going on.
It’s unfortunate that the program isn’t just exiting.
Which version are you running?
Maybe try 12 MHz?
If the bias-t is active and you’re using the uputronics with it’s own power, try with the bias-t disabled.
It could be that your device just has a defect, i don’t know.
Which settings are you running? (/etc/default/airspy_adsb)
If you want a work-around for the meantime:
sudo crontab -e
# should open a document in nano, paste the following line at the end:
* * * * * /bin/bash /root/.airkill.sh
sudo nano /root/.airkill.sh
# should open an empty document, paste the following:
#!/bin/bash
if journalctl -u airspy_adsb -b -0 -n3 | grep 'Decoding stopped'
then
pkill -9 airspy_adsb
fi
With the problem, do you have to reboot to fix it?
In this case instead of the pkill you need a reboot in the script.
But let’s try like this first.
This is only a temporary work-around, something is definitely not working right.
Thanks wiedehopf for your help !
I’m using the Airspy-mini with the 20Mhz setting, this is my conf :
root@ads-b:~# cat /etc/default/airspy_adsb
#gain is 0 to 21, each step of gain is equivalent to about 3dB, so reduce in increments of 1 if 21 is too high
# For Uptronics LNA -> 19 / for RTL-SDR LNA -> 15
GAIN=19
#other options
OPTIONS= -v -f 1 -p
#sample rate can be 12 or 20, 20 may not work depending on the system
SAMPLE_RATE=20
#don't change:
G=-g
M=-m
#network settings
NET= -l 29999:beast -l 47806:asavr -c localhost:30004:beast
root@ads-b:~#
The Uptronics is powered by a separated Bias-T, (not the internal USB).
Thanks for your script !
I see that when the message Decoding stopped appear, your script kill the airspy process, but is it normal do not have a line to relaunch it ?
It’s automatically restarted by the systemd service.
I’ve tested, so yes i’m sure.
Remove the -p please.
It’s not needed and causes extra strain on the Airspy.
It should work with -p, but it’s generally more stable without it in my experience.
(If you run 24 MHz with the R2, you have to use -p but that’s another story)
Thanks !
What the use of the -p in the conf file ?
I have removed it, but i’m using this conf from 2 months ago, and the probleme start only from 15 days.
I have modified your script to keep a trace if the Airspy stop working again :
#!/bin/bash
if [ ! -f "/tmp/result-airkill.txt" ];
then touch /tmp/result-airkill.txt
fi
if journalctl -u airspy_adsb -b -0 -n3 | grep 'Decoding stopped'
then
pkill -9 airspy_adsb
date >> /tmp/result-airkill.txt
fi
You’ll see it being killed in the syslog (sudo journalctl -eu airspy_adsb)
Oct 24 20:44:36 pi systemd[1]: airspy_adsb.service: Main process exited, code=killed, status=9/KILL
Oct 24 20:44:36 pi systemd[1]: airspy_adsb.service: Failed with result 'signal'.
Oct 24 20:44:36 pi systemd[1]: airspy_adsb.service: Service RestartSec=100ms expired, scheduling restart.
Oct 24 20:44:36 pi systemd[1]: airspy_adsb.service: Scheduled restart job, restart counter is at 1.
Oct 24 20:44:36 pi systemd[1]: Stopped Airspy ADS-B receiver.
Oct 24 20:44:36 pi systemd[1]: Started Airspy ADS-B receiver.
1 Like
That’s a possibility. Mine works fine with your add-on software over Buster.
Works even with that -p enabled 
Someone knows what is the purpose of this command (-p) ?
Bit packing was just recently discussed, not sure if this thread or the RPi4 thread.
Oh and:
airspy_adsb --help
1 Like
Thanks, i find the information ;+)