That’s not correct. The signal path in the tuner is mostly analog and has a limited DR per stage. The maximum DR of the R820 (now reamed R860) is about 100 dB when everything is tweaked. In practice, it is more limited than the ADC.
1 Like
Yeah, the datasheet for that was confidential and I have just a leaked (Chinese marked) copy. And that was not the latest R820T2.
Let’s plug some numbers.
NF = 3.5 dB => MDS at 2 MHz = -107.49
IIP3 at max gain = -7.5 dBm => SFDR = 66.6 dB
5 Likes
That type of RF design can become quite complicated, can remember spreadsheets showing each part of the receiver chain, calculating lots of parameters, from combined noise figures, 1dB compression points, IP3 to spurii. That spreadsheet formed the reference of the receiver. I think I spent almost more time generating those spread sheets, than doing the actual hardware design, esp in the beginning of a new radio product.
1 Like
It’s a full time job, indeed. The Rafael Micro tuners are relatively simple (32 x 8bit registers) compared to other RF chips we use in our other products (250 x 24bit registers).
5 Likes
Small thing easily resolved with sudo systemctl restart airspy_adsb after a reboot. Never noticed this in earlier RCs, but happens every time after reboot.
Pi 4 at stock speed, 12 MSPS. options= -v -t 300 -f 1 -w 5 -e 60 -P 5 -b
After reboot, you see the typical post-reboot couple of lost samples. No problem. But over the course of minutes, preamble_filter tends to lock in around 56.2 or 57.2 and stay there, at least for 15 or 20 minutes after reboot until I restart airspy_adsb. There’s no continued lost samples or high CPU to explain it. Everything looks normal. Just not pulling itself back up to match the -e 60 setting until airspy_adsb is manually restarted after reboot.
sudo cat /run/airspy_adsb/stats.json
{ "now": 1633564790.4, "gain": 19.0, "preamble_filter": 57.2, "samplerate": 12,
Simply sudo systemctl restart airspy_adsb and we’re instantly locked back to preamble = 60.
A tiny thing, but probably good for someone else running with a forced -e 60 config to reboot and try reproduce this behavior. Just look at preamble_filter value in sudo cat /run/airspy_adsb/stats.json maybe 5 minutes after reboot.
1 Like
So is it until 15 minutes or until you restart it?
Don’t restart it … doesn’t change?
It’s probably clock stuff … i’ll check.
Edit: Clock stuff is fine and shouldn’t be an issue.
So you’re saying it just stays exactly 57.2 for 5 minutes or longer?
Check this please
while sleep 60; do grep preamble_filter_stats /run/airspy_adsb/stats.json; done
It should output every 60 seconds the relevant stuff for the preamble.
This. Doesn’t change.
Reboot… then
sudo cat /run/airspy_adsb/stats.json - manually every minute or two.
{ "now": 1633584609.7, "gain": 20.7, "preamble_filter": 28.7, "samplerate": 12,
{ "now": 1633584681.6, "gain": 10.9, "preamble_filter": 52.4, "samplerate": 12
{ "now": 1633584921.6, "gain": 10.0, "preamble_filter": 55.3, "samplerate": 12,
{ "now": 1633584741.6, "gain": 10.0, "preamble_filter": 55.3, "samplerate": 12,
{ "now": 1633584801.6, "gain": 10.0, "preamble_filter": 55.3, "samplerate": 12,
{ "now": 1633584921.6, "gain": 10.0, "preamble_filter": 55.3, "samplerate": 12,
while sleep 60; do grep preamble_filter_stats /run/airspy_adsb/stats.json; done
"preamble_filter_stats": { "min": 55, "p5": 55, "q1": 55, "median": 55, "q3": 56, "p95": 56, "max": 56 },
"preamble_filter_stats": { "min": 55, "p5": 55, "q1": 55, "median": 55, "q3": 56, "p95": 56, "max": 56 },
"preamble_filter_stats": { "min": 55, "p5": 55, "q1": 55, "median": 55, "q3": 56, "p95": 56, "max": 56 },
"preamble_filter_stats": { "min": 55, "p5": 55, "q1": 55, "median": 55, "q3": 56, "p95": 56, "max": 56 },
"preamble_filter_stats": { "min": 55, "p5": 55, "q1": 55, "median": 55, "q3": 56, "p95": 56, "max": 56 },
"preamble_filter_stats": { "min": 55, "p5": 55, "q1": 55, "median": 55, "q3": 56, "p95": 56, "max": 56 },
"preamble_filter_stats": { "min": 55, "p5": 55, "q1": 55, "median": 55, "q3": 56, "p95": 56, "max": 56 },
Then sudo systemctl restart airspy_adsb dump1090-fa, wait 30 seconds +/- for json
sudo cat /run/airspy_adsb/stats.json
{ "now": 1633585593.8, "gain": 21.0, "preamble_filter": 60.0, "samplerate": 12,
Yeah no clue what happens.
Tried reproducing, can’t.
1 Like
I just tried restoring the overclock that I had removed 5+ days ago. The glitch was still there upon boot to 1750 MHz. However, when I then removed the overclock and reboot, preamble went to 60! Reboot again to check, went back to 60 again. It was some kinda local thing that repeated over 5 or 6 reboots in a row.
This SD card hasn’t had a fresh format and Raspian OS install in over a year probably. Many projects, it may be time to start fresh.
All seems to be working well here - I’ve got both mine and the MTG set to reboot at midnight tonight just to make sure they start cleanly. I have -C set at 65 and 70 respectively and they’re not dropping any samples. My preamble filter would be continually at the maximum of 60 if it wasn’t for the overnight heatmap generation (and the weekly backup). The MTG receiver only drops a small amount overnight.
Both you and @prog have done a bloody good job. Thank you.
/edited after the overnight reboot, no lost samples (used to be common after a restart)
Me
-- Logs begin at Fri 2021-10-08 00:02:08 BST. --
Oct 08 00:02:09 pi4-tracker systemd[1]: Started Airspy ADS-B receiver.
Oct 08 00:02:09 pi4-tracker airspy_adsb[312]: airspy_adsb v2.2-RC30
Oct 08 00:02:09 pi4-tracker airspy_adsb[312]: Listening for beast clients on port 47787
Oct 08 00:02:09 pi4-tracker airspy_adsb[312]: Acquired Airspy device with serial 26A464DC28751693
Oct 08 00:02:09 pi4-tracker airspy_adsb[312]: Decoding started at 20 MSPS (Gain: auto; CPU target: 65 %)
Oct 08 00:02:10 pi4-tracker airspy_adsb[312]: Push client connected to localhost:30004 (beast)
Oct 08 00:02:10 pi4-tracker airspy_adsb[312]: Push client disconnected from localhost:30004 (beast)
Oct 08 00:02:23 pi4-tracker airspy_adsb[312]: Push client connected to localhost:30004 (beast)
Oct 08 00:02:23 pi4-tracker airspy_adsb[312]: Push client disconnected from localhost:30004 (beast)
Oct 08 00:02:36 pi4-tracker airspy_adsb[312]: Push client connected to localhost:30004 (beast)
MTG
-- Logs begin at Fri 2021-10-08 00:02:05 BST. --
Oct 08 00:02:07 mtg systemd[1]: Started Airspy ADS-B receiver.
Oct 08 00:02:07 mtg airspy_adsb[394]: airspy_adsb v2.2-RC30
Oct 08 00:02:07 mtg airspy_adsb[394]: Listening for beast clients on port 47787
Oct 08 00:02:07 mtg airspy_adsb[394]: Acquired Airspy device with serial 26A464DC287E3993
Oct 08 00:02:07 mtg airspy_adsb[394]: Decoding started at 20 MSPS (Gain: auto; CPU target: 70 %)
Oct 08 00:02:08 mtg airspy_adsb[394]: Push client connected to 127.0.0.1:30004 (beast)
Oct 08 00:02:08 mtg airspy_adsb[394]: Push client disconnected from 127.0.0.1:30004 (beast)
Oct 08 00:02:21 mtg airspy_adsb[394]: Push client connected to 127.0.0.1:30004 (beast)
10 Likes
I will chime in with the rest regarding RC30.
No problems noticed. Good performance and stable operation, preamble varies between 59.7 and 60 when running 24 msps on the R2.
Really good work @prog and @wiedehopf !
3 Likes
Yes to add to the thanks and an update…
Since upgrade to RC29 and then 30… No lost samples for me (I have not rebooted though)
1 Like
I think I know the answer but thought I would ask anyway…following the recent upgrades to airspy-conf, is it possible to decode mode A/C signals, and if so what is required in airspy_adsb options?
Many thanks
4 Likes
What can I say, I went away from ADSB stuff for a few weeks, Real Life got in the way! It happens. I was about a third of the way through the thread (as it is now), installing the RCs and testing: then it has taken me until now to play catch-up!
Did not feel I could give feedback until I got to the end… and every time I came back, the ‘end’ had moved on a ways. Just like walking in the mountains, every time you get to the top of the pass, there is another one in the distance.
Well done does not say enough. Awesome maybe better.
I am running a Mini at samples 12 and gain auto which runs at 21
. All samples 20 does is increase CPU temp, does not appear to make any noticable difference to number of aircraft or position reports. See the data on my FA user ID g7ruh
My location is very quiet RF wise. I am running a Pi4 for my reference system (Orange FA dongle) and a Pi 400 for the Airspy Mini. all fed through Uptronics LNA and a passive 4-way splitter. Unused splitter ports are terminated with 50 ohms
OPTIONS= -v -f 1 -p -w 5 -t 300 -C 85 -P 5
Here is a 48 hr graph showing when I changed from samples 12 to 20 and back to 12
If anyone has suggestions for modifying my settings, please feel free to suggest them, Happy to test and report back.
In the meanwhile, congratulations to @prog and @wiedehopf for the awesome progress.
I see a big increase in position reports, more so at greater than 100nm. Even more at the greater distances when conditions allow (e.g. tropo / ducting).
2 Likes
I have a setup very similar to g7ruh and can confirm a similar observation for 12 vs 20 Mhz on the Airspy Mini with Uptronics LNA and an RPI 4 at standard clock speed with fan.
Sample rate of 12 Mhz, E is flat at 60 and CPU utilization 100%.
Sample rate of 20 Mhz basically doubles CPU utilization to 200%, and raises temp by 5 degrees C. There is no dramatic impact on number of messages or number of planes. I do show that Airspy SNR goes up about 6 db. That may mean that planes or messages are going to increase slightly, but it isn’t enough to see on the graph. If there is an increase it is a few percentage points rather than a big step.
Compared to FlightAware stick, planes and messages are way up, especially in the 150 nmi and up range.
1 Like
I think the benefit of higher sample rates depends on how much traffic there is in your area. If your receiver is somewhere that is both busy and has high message rates due to ground interrogation, then you will get noticeably more messages decoded with 20MHz than with 12MHz. If you live somewhere relatively quiet, or where ground interrogations are more limited, then there will be far fewer conflicting messages, and you will be decoding the majority of messages at the lower sample rate.
If you don’t get any advantage from the higher sample rate, then you might as well save a bit of power and help with hardware longevity and run it at the lower rate.
3 Likes
@caius here is a stat from FA showing my stats today. I am not sure what you count as ‘how much traffic’. Do you think mine is low or average or high, for example? I was thinking I get fairly high traffic here, Top is my FA orange dongle, bottom is the Airspy Mini.
Most days are similar, percentage-wise but on a fine day with high pressure dominating, more positions, percentage-wise from the Airspy Mini. It is much better at 100 nm plus than the orange dongle.
I agree about saving power for little extra positions!
What I will do if I can find a day with high pressure (it is winter season now, so a bit more rare) is change to a higher sample rate and see if there is a noticable improvement at 20Mhz. May take a while to wait for the right day or two. I think you are right, in my case it is my RF quiet location. Lucky me 
Correct me if I’m wrong but aren’t these the average stats for 30 days instead of those for today only?
these seem to be coming from the Nearby Sites section. Reported in that section are flights and positions as Medians calculated over the last 7 days of data.
30 day totals are in a section called 30-Day Site Ranking. I avoid looking at it. But then I am 3000+ spots from the top.