Maintained software; native decoding/feeding of UAT data rather than going via 1090ES (which is lossy); a dump978 that doesn’t require jumping through hoops with pipelines etc.
All this posting re update versions for airspy ads b to 1.42, wiedehopf does this script update feature update to the latest airspy version??
prog usually puts the new version in the same place. From there my script downloads it.
So yes it does.
Thanks. Had a quick look at the temp graphs on the N2 and XU4 before coming to work, both had increased a couple of degrees, so thought it might have updated the airspy, given the feed back re 1.42. Will dable at a 24 setting when I get home and see what happens :slight_smile. 
There are no automatic updates.
Only updates when you use the script as explained on the airspy-conf github page.
That was noted after I applied your script.
Something might be broke… Just noticing peculiar actions from my N2 and XU4 and your scripts, probably in the last few days. Individually, my N2 constantly out performs the XU4 in detection and signal rates, up until just in the last couple of days after I did an update to both, using your scripts. The other trigger of something up in Denmark is my ADS B signal levels, for both units the peak level, mean level and weakest level have before this issue seems to have arised, been between 0 and -3, very good signal levels. Since testing with gain level, these figures have dropped to between -5 and -12. When doing the gain changes, the restart script is applied after any adjustments. Both normally sit on 21 gain and running at 20 mhz. Dropping to 12 mhz, does not put the signal levels back to the normal range but I noticed after some quick gain changes and putting back to my default 21 the restart, got the signal level heading in the right direction, but not up to my normal levels. Everything is working, but not as good as it was. 
Trying to install airspy;
``
root@odroidn2:~# sudo bash -c “$(wget -O - https://raw.githubusercontent.com/wiedehopf/airspy-conf/master/install.sh)”
–2019-11-01 12:25:00-- https://raw.githubusercontent.com/wiedehopf/airspy-conf/master/install.sh
Resolving raw.githubusercontent.com (raw.githubusercontent.com)… 151.101.28.133
Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|151.101.28.133|:443… connected.
HTTP request sent, awaiting response… 200 OK
Length: 3414 (3.3K) [text/plain]
Saving to: ‘STDOUT’
-
100%[===================>] 3.33K --.-KB/s in 0s
2019-11-01 12:25:01 (31.1 MB/s) - written to stdout [3414/3414]
bash: -c: line 50: syntax error near unexpected token then' bash: -c: line 50: then’
``
The error i believe from github site:
``
49 #package install, install dump1090-fa
50 if ! command dump1090-fa &>/dev/null; then
51 then
52 echo ‘Installing dump1090-fa as it is required:’…
``
Delete the duplicate ‘then’ - (entire line 51) until he has a chance to repair.
EDIT: Here is a bandaid (poor hack!) for you in the meantime:
git clone https://github.com/wiedehopf/airspy-conf.git
cd airspy-conf
sed -i 's/if ! command dump1090-fa \&>\/dev\/null; then/if ! command dump1090-fa \&>\/dev\/null;/' install.sh
sudo bash install.sh
cd
Well done that got it working in the interim thanks
I am not sure there may be more problems with his site, tar 1090 and graphs, all uploaded in the last hour, have issues. The 1090 FA map is working, so 1090 up and running 
I changed airspy-conf and didn’t test right away, anyhow will remove the extra then. (… fixed)
I doubt there’s anything wrong with tar1090/graphs1090.
But by all means in the appropriate thread post what’s the problem.
Or better yet just create your own threads, that’s often helpful to reduce off-topic posts in other threads.
Note this was obviously the correct thread.
Thanks for checking
And now it’s tested already!
Would this bandaid cause problems with dump 1090 etc. What is my option now after this script was applied, re do everything or just airspy over the top… ???
I know i’m not @wiedehopf, but will try to answer best I can since I’m here already and reading.
First and foremost, that hack was to cure a simple syntax typo so the script could continue on it’s decided path the way it was meant. Nothing more, nothing less, so the short answer is no, not a chance. It’s been fixed in the interim as pointed about above.
Secondly, you haven’t described what may be going south with dump1090 and “etc”. I’m sure you’ll get plenty of help after properly describing exactly what’s going on once others can wrap their head around the symptoms.
Other than what you typed above, we have no way of knowing A: what you are trying to accomplish. B: with what C: what you have done from start to finish and finally D: what the symptoms are. Please don’t take this as condescending. We all have certain skill-sets with different things and I can guarantee that nobody was born with an innate ability for this stuff - we’re ALL learning as we go. 
When I started with the Airspy & Pi4, I added ‘force_turbo=1’ to the /boot/config.txt of my Pi4.
I wonder if this is a requisite for best performance or does having one core always at >70% will force the on demand CPU frequency governor to switch automatically to a clock speed of 1.5GHz?
I find that it’s not usually one core at 70%. The process bounces between cores meaning that their usage averages out quite a lot lower than that. The cpu frequency is often at 1.5GHz, but sometimes drops lower. I haven’t found it necessary to have the force turbo option set so far.
Ta for the quick reply, I was planning a slight overclock to 1.7GHz and at that moment force_turbo plays a roll because enabling it together with over_voltage will void the warranty of the Pi by permanently setting a special SoC bit.
There really is no need for overclocking with the Pi4 and the software in question.
You mostly get more bogus messages when you raise -e really far.
The number of extra real messages is very low, diminishing returns.
That’s why the -e was hard coded at 4 before the patch.
Now using 6 might be a few percent advantage over 4, but going much higher likely doesn’t give you much.
I know there’s a point where pushing the e-value even further will no longer yield more valid messages but it’s always fun to look for this point and turning the e-value somewhat down once this has been established. As you mentioned, everyone will notice a slight increase in the number of aircraft reported when increasing the e-value but as it is difficult to quantify the net gain in a dynamic air traffic environment I decided to look outside the (Pi) box.
To do this I compared the daily ‘# of aircraft reported’ of 5 ‘performant’ feeders in my neighbourhood as shown on their stats pages with my own stats and I did this for a week running Airspy at the standard -e 4 and a week at -e 8. To my surprise, the additional gain in the number of aircraft reported with -e 8 compared to those of my fellow feeders was more than I had expected: +8.7%, 9%, 9.1%, 10.4% and 10.3% !
I would conclude that the changes made by Prog are really worth the effort so kudos to Youssef for all the tweaking.
4 Likes
Well that includes some bogus aircraft in the count.
Comparing the number of positions would be a better comparison.
1 Like