hello prog, see the comment you made last Jan 2 re the RSSI values.
“That said, I can add another switch in the command line to enable full scale “RSSI” or, better yet, the SNR.”
have you given any more thought to this switch? (this is from a discussion topic titled “planes but not feeding”)
Asking for that was my mistaken interpretation of the code.
You get the full range of values possible for the beast protocol.
The only thing the airspy does differently internally is have better resolution for the RSSI, but it’s not possible to display that better resolution in dump1090.
Correct. We are trying to plug a 16 bit linear scale into 8 bit. The signal strength is limited to 8 bit by removing some LSB’s and MSB’s. Moderate to strong signals will both give 255, and very weak signals will give 1. This is a limitation of the Beast protocol and the way dump1090 interprets the rssi field.
My suggestion was to work around this limitation by using a different “compressed” scale. This would better discriminate weak and strong signals, but it would be just another inaccurate rssi reading. Not sure it will be of much interest to the end users.
It might be better than what we have now - strong signals have all a flatten 0dB.
Better yet I would keep the correspondence linear (bit to bit) but add another switch in the decoder to tell where to “slide” the 8 bit trimming window (how many bits away from MSB).
In this way if I am interested in strong signals, I slide the window to be aligned to MSB and I’ll lose all the weak signals.
And the other way around for people interested in lower signals… slide the MSB lower with 6-8 bits (this is limited by whatever the noise level is in the analog chain and ADC).
I’m afraid the decoder is way more complicated than just the ADC bits (oversamplig, processing gain, different gains from the digital filters, SNR calculation, etc.) Unlike the CPU optimizations, structural changes require a lot of development time and this is one of them. I was discussing with @wiedehopf the idea of including the SNR in the scoring system (and even in the FEC and soft bit decision). The good news is that there is still room for improvement. The bad news is that I don’t have the time right now to get them implemented properly. Too many open projects right now.
PS: In case you didn’t notice yet: I don’t like quick and dirty hacks because I will have to pay for the technical debt they generate, sooner or later.
OK folks, I’ve not been in this thread for some weeks and it’s grown by many hundreds of posts since I was last here!
I’ve just rebuilt my feeder. The aerial has gone up 11ft and I’ve replaced the Pi 3B+ with a Pi4B. I’m still using the Airspy Mini and RTL-SDR LNA.
Live map view here and graphs here.
I did the initial software installation about six weeks ago and I think there have been a lot of changes since then.
Please, is there a TL;DR version of what’s gone before?
What do I need to do to get myself up to current spec?
I’m running gain 14 and the options in my airspy_conf file are:
OPTIONS= -v -f 1
I have my sample rate set to 20. When I look at what’s going into VRS, I’m only getting half the number of MLAT aircraft reported as my loft receiver.
/edit - At 14:30z I’ve run the update command for the airspy stuff and rebooted
There’s been quite a lot of optimisation of the decoder which makes it much more cpu efficient, and improvements to the preamble filtering that means the data you get out should be cleaner.
There is a new option -e which takes an argument from 1 to 20. The higher the number, the more permissive the filter is. The old decoder has an equivalent of -e 5. As you are running on a pi 4, you can increase this to take advantage of the extra cpu power available.
I would suggest starting at a value of 9, which should give a noticeable boost to messages without losing samples. You can gradually increase it to find a maximum level - depending on your local circumstances you may be able to get it up to around 9.7 or so without any loss. More than that is right on the edge in my experience and you can get samples lost, especially overnight.
The other important option added is -w, which is the whitelist score for accepting new planes - the default value is 3. The higher this is, the more messages are required before an aircraft is accepted. Depending in circumstances you might find you still get some bogus decodes at this setting, so a slightly higher one might be required. I’m using 5 and see very few single message tracks now:
Other new options you might want to consider:
-f 2 – this enables error correction of 2 bit errors on location messages. These are likely not quite as reliable, and obj requests that if using it, the -n option is also used so that the messages are sent to the network uncorrected so that software receiving it can decide how to handle it.
If you enable that, you might also need to have --aggressive and --net-verbatim enabled in dump1090, however I’m not sure they are available in the current build of dump1090-fa.
-t sets the number of seconds for the whitelist timeout. The default is 60, which I find is fine - setting it longer means that aircraft that are temporarily out of view have longer before they are required to pass the whitelist filter again.
It looks like you have a very nice range now - some reliable contacts at 240 miles or so.
Edit - I just had a look at your FA stats - that’s quite a huge jump in positions reported!
Thanks, that’s good stuff.
I’ve set options thus:
OPTIONS= -v -f 1 -e 9 -w 5
Let’s see how that goes.
I’d suspect -e 9 might not work without force_turbo=1 in the /boot/config.txt, as the pi sometimes decides to clock down which produces problems in this case.
sudo journalctl -eu airspy_adsb
This will show you lost samples as before.
You can also put this into your ~/.bashrc to make a new command for checking mlat:
alias mlat-sync='sudo journalctl -u piaware.service --no-pager -n1000 | grep -F -e "Server status" -e "clock unstable" -e "not synchronized" -e "Out-of-order" '
As in throttle? I’m keeping an eye on that because as you know, I’ve had undervoltage throwing on the old Pi3B+ for some weeks. I’m using the new PoE hat now which at the moment is doing well. I’ve set the fan to come on at 40°C and off at 35°C and it’s hovering nicely between the two.
Since adding those options, the CPU has gone up from about 52% to just over 70% which is perfectly fine. My mesages/second has gone up by around 300.
My MLAT figure is still much lower than I’d expect. I am getting a few rows of lost samples on boot but nothing after that.
Will add that into the bash profile, thanks.
Maybe you are running another mlat client on the other setup?
Otherwise i’d suspect it’s just different low level coverage.
Or it may just be that the FA mlat algorithm isn’t choosing your station as often.
It’s kinda random which stations are chosen for multilateration and only those get position results.
Maybe. I have no idea and as long as I’m not getting any dropped samples, I guess it doesn’t really matter.
I’ve added the force_turbo and rebooted. I’ll leave it for a while with no further fiddling.
I usually find that despite having by far the most receivers synced, flightaware mlat returns results for the fewest aircraft of the three mlat networks I’m connected to that do return them.
If anyone’s interested, you can see the new aerial arrangement by clicking here.
It’s gone up 11ft and so is now 44ft (13.4m) above the ground.
I’ve installed a Jetvision aerial on the top of the Hexbeam. I’ve used the same box which had my old feeder inside and that box is now mounted a little lower on the mast but of course that doesn’t matter. I’ve got 5.5m of Messi and Paoloni Hyperflex 10 coax going from the new aerial down to the feeder which is probably introducing around 0.7dB loss at 1090 MHz.
Increase that by 0.1 at a time and monitor for a period? What am I checking for lost samples, is that the new command that Wiedehopf has said?
mlat-sync
Nov 24 15:27:54 pi4-tracker piaware[884]: mlat-client(1124): Server status: synchronized with 754 nearby receivers
Nov 24 15:42:54 pi4-tracker piaware[884]: mlat-client(1124): Server status: synchronized with 750 nearby receivers
You could probably put it to something like 9.7 without a problem. If you get lost samples there, then reduce it by 0.1. They will appear in the log like:
Nov 24 14:55:14 raspberrypi airspy_adsb[15057]: /!\ Lost 131072 samples /!\
You are more likely to see lost samples at night when there are few aircraft, as the cpu use actually goes up then.
That new command wiedehopf gave will show you if you are getting any mlat syncing problems.
To see lost samples, just do something like journalctl -u airspy_adsb --no-pager, which gives the log output for just the airspy decoder.
Once you have e set above 9, you are getting into diminishing returns territory, so having it as high as possible isn’t that crucial - you’ll probably get some marginal signals that you didn’t before but don’t expect a big increase.
This is to check the airspy log obviously.
Wow those are spectular results you are getting. I cannot believe the number of planes / msg per second you have. You’ve certainly done something right. I’m sure your location itself plays some role, but it’s clear that you’ve put the right hardware / antenna system to use in the best possible way. Congratulations.
I am still marveling at the 40C temperature on your PI4. I’m baffled. Mine is constantly at 55C and I have a fan on it and its in the house with average temp of 70F.
i also marvel at your 70% ADSB Utilization running -e 9.x . I’m always at about 90%, and I only see about 1/3 the planes and msg/sec that you do.
So I’m curious to ask – are you running the airspy at 12 MHz vs 20 MHz ? You can check your /etc/default/airspy_adsb to see what SAMPLE_RATE is set to. If you’re at 12 MHz, that explains the lower CPU usage. And, if you are looking to eek out some more messages, you can probably go to SAMPLE_RATE 20 with -e 9 -w 3 on yours.
If you are at 12 MHz and switch up to 20 MHz, be prepared for the ADSB CPU Utilization to rise though. It’s certainly worth it to give 20 MHz a test if you aren’t running 20 Mhz.
If you are running 20 MHz already, again I’m baffled at your low temp, low CPU usage on PI4 with that setup.
Mike
Thanks Mike.
I’m sure a lot of it is down to location. I’m in a prime position and I have a really clear view of the sky I pretty much all directions. I’m very close to the CLN beacon which is a major air route into the UK.
Here’s the appropriate part of my config file, screenshotted for your convenience 
Regarding the temperature - Well to start with, it’s only 10°C outside at the moment so that will help. I’m using the Raspberry Pi PoE hat with the fan configured to come on at 40°C and off again at 35°C and that’s keeping the temperature within that range. I don’t really want to switch the fan off to see what it goes up to but I think it’d be a lot higher. I’ve also got the Pi4B mounted on it’s side which I think helps a little as well.
I can’t explain the CPU utilisation though. Since posting in here earlier, I’ve been scrolling back through the thread and I’m also surprised that it’s not higher. Perhaps if I increase -e up in steps, it’ll increase. I’m going to leave it as it is for at least 24 hours though before I even consider making any more changes.
I also don’t know whether it’s worth tweaking the gain. I spent some time when I first switched to the Airspy adjusting it and 14 was definitely the best setting for me then.
Don’t forget it’s outside, which is significantly cooler than inside a house.
Have you ever updated the firmware on your pi 4? The current version is significantly better than the version available when it was first released.
If you haven’t, you can make sure you have the latest version by doing:
sudo apt update
sudo apt install rpi-eeprom
sudo rpi-eeprom-update
this will give you an output like this:
BOOTLOADER: up-to-date
CURRENT: Tue 10 Sep 10:41:50 UTC 2019 (1568112110)
LATEST: Tue 10 Sep 10:41:50 UTC 2019 (1568112110)
VL805: up-to-date
CURRENT: 000137ab
LATEST: 000137ab
If you don’t have the latest version, you can update by doing
sudo rpi-eeprom-update -a
and then rebooting. Subsequent updates should be downloaded automatically and applied on the next reboot.
If your installation of Buster is relatively recent, rpi-eeprom should already be installed, but it was omitted originally.
Also amazing that you don’t require any higher gain. But I’d concur,and I bet Wiedehopf would too, that your gain looks to be tuned just right.
Ok, did not realize you had the device outside. Makes a lot of sense that it is cooler. And, everyone seems to use a different case – and all cases are not created equally.
Still puzzled by the lower ADSB CPU Utilization. Are you running yours overclocked (you would have to have purposefully done that)? I am not. I just run the force_turbo option to keep the CPU from going down, just as you have done.
You know, I forgot that I was running -e 10 now. That would explain my higher CPU usage than yours. I can get away with that (most likely) since I’m not processing as much plane traffic. Given the amount of plane traffic you are processing, you may or may not be able to go up to -e 10 and not lose MLAT sync. Like was mentioned by someone else before, there is a point of diminishing returns. I likely do not need to have mine set at -e 10, but since I can do that and get away with it I’m just trying to eek out every little bit I can with my lesser setup.
In summary, since you are running -e 9 that explains your lower CPU. I had forgot how much @prog and @wiedehopf work had decreased CPU usage in the latest incarnations of airspy_adsb.
Again, great job on your setup!
Mike