Sure thing, no problem @prog Here’s a snapshot of my host usage.
thinuser@ThinAware:~$ cpufreq-info
cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpufreq@vger.kernel.org, please.
analyzing CPU 0:
driver: acpi-cpufreq
CPUs which run at the same hardware frequency: 0
CPUs which need to have their frequency coordinated by software: 0
maximum transition latency: 4.0 us.
hardware limits: 800 MHz - 1.50 GHz
available frequency steps: 1.50 GHz, 1.30 GHz, 1.10 GHz, 950 MHz, 800 MHz
available cpufreq governors: userspace, powersave, conservative, ondemand, performance, schedutil
current policy: frequency should be within 800 MHz and 1.50 GHz.
The governor "performance" may decide which speed to use
within this range.
current CPU frequency is 1.50 GHz.
cpufreq stats: 1.50 GHz:24.74%, 1.30 GHz:68.15%, 1.10 GHz:6.03%, 950 MHz:0.64%, 800 MHz:0.45% (5028910)
analyzing CPU 1:
driver: acpi-cpufreq
CPUs which run at the same hardware frequency: 1
CPUs which need to have their frequency coordinated by software: 1
maximum transition latency: 4.0 us.
hardware limits: 800 MHz - 1.50 GHz
available frequency steps: 1.50 GHz, 1.30 GHz, 1.10 GHz, 950 MHz, 800 MHz
available cpufreq governors: userspace, powersave, conservative, ondemand, performance, schedutil
current policy: frequency should be within 800 MHz and 1.50 GHz.
The governor "ondemand" may decide which speed to use
within this range.
current CPU frequency is 1.50 GHz.
cpufreq stats: 1.50 GHz:22.67%, 1.30 GHz:69.11%, 1.10 GHz:6.96%, 950 MHz:0.71%, 800 MHz:0.55% (4761597)
analyzing CPU 2:
driver: acpi-cpufreq
CPUs which run at the same hardware frequency: 2
CPUs which need to have their frequency coordinated by software: 2
maximum transition latency: 4.0 us.
hardware limits: 800 MHz - 1.50 GHz
available frequency steps: 1.50 GHz, 1.30 GHz, 1.10 GHz, 950 MHz, 800 MHz
available cpufreq governors: userspace, powersave, conservative, ondemand, performance, schedutil
current policy: frequency should be within 800 MHz and 1.50 GHz.
The governor "ondemand" may decide which speed to use
within this range.
current CPU frequency is 1.50 GHz.
cpufreq stats: 1.50 GHz:19.86%, 1.30 GHz:70.08%, 1.10 GHz:8.48%, 950 MHz:0.96%, 800 MHz:0.63% (4651695)
analyzing CPU 3:
driver: acpi-cpufreq
CPUs which run at the same hardware frequency: 3
CPUs which need to have their frequency coordinated by software: 3
maximum transition latency: 4.0 us.
hardware limits: 800 MHz - 1.50 GHz
available frequency steps: 1.50 GHz, 1.30 GHz, 1.10 GHz, 950 MHz, 800 MHz
available cpufreq governors: userspace, powersave, conservative, ondemand, performance, schedutil
current policy: frequency should be within 800 MHz and 1.50 GHz.
The governor "ondemand" may decide which speed to use
within this range.
current CPU frequency is 1.50 GHz.
cpufreq stats: 1.50 GHz:18.58%, 1.30 GHz:69.67%, 1.10 GHz:9.79%, 950 MHz:1.23%, 800 MHz:0.74% (4690837)
thinuser@ThinAware:~$ 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
GAIN= 19
#other options, append or remove from the line starting with OPTIONS=
OPTIONS= -v -t 90 -f 1 -w 5 -P 8 -C 90 -E 60 -e 10.0
#-C: CPU target in time percentage: 5 to 95 (adjust preamble filter while running to target CPU load)
# a CPU target of 50 will use around 1 core completely on a multi-core system
#-e: preamble filter sensitivity, values: 1.0 to 60.0 (higher values increase CPU load and can improve detection)
#
#-E <max_preamble_filter> Maximum preamble filter when using CPU target 0..60 (default: 60)
#-P <non_crc_preamble_filter> non-CRC Preamble filter: 1..preamble_filter
# a low setting (8 or less) for -P can help when running higher -e or -C and encountering wrong altitudes or planes showing ground in VRS
# note this will reduce the number of messages without CRC, for example altitude of MLAT aircraft
# at the same time it will reduce CPU usage which can be used to get some more ADS-B position messages
#
#-w <whitelist_threshold> Whitelist threshold: 1..10 (default: 5, lower not recommended due to bogus messages
# threshold is not measured in message number, DF11 are worth 2, DF17 are worth 4 points
# -t <timeout> Aircraft timeout in seconds for the whitelist (default: 60)
#
#-b: enable bias-t (50 mA max according to specification)
#
#-f: error correction bits, 0, 1 or 2: default and recommended is 1 for now.
# (-f 2 is not recommended at the moment when feeding FlightAware and maybe others
# as they have expressed concern about 2 bit error correction)
#
#-v: verbose, will provide messages to system log, read with this command: sudo journalctl -u airspy_adsb
#
#-x: dx mode, introduces bogus messages, improves reception of weak messages (opinion: not worth it)
#-p: bit packing, reduces USB bandwidth.
# please always check the following command for the options used by the current version:
# airspy_adsb -h
# sample rate can be 12 or 20, 20 may not work depending on the system
# when using the Airspy Mini a sample rate of 20 MSPS is not officially supported and an extra heat sink attached to the metal case or active ventilation are recommended
SAMPLE_RATE= 24
# when using a sample rate of 20, check if MLAT is stable!
# If MLAT isn't stable, 12 is the better choice and performance is similar in most cases.
#network settings
NET= -l 47787:beast -c 127.0.0.1:30004:beast
# stats.json
STATS= -S /run/airspy_adsb/stats.json
#don't change:
G=-g
M=-m
#processor affinity, for XU4 you can try 4-7, for the N2 try 2-5
AFFINITY="0-7"
thinuser@ThinAware:~$
htop snapshot:
nmon snapshot:
Looks like I have some linger 978 stuff on this box to clean up.
)I didn’t buy it with the intention of doing ADSB on it, but it is just an example of better hardware in the <$100 price range. Overkill for our hobby? For sure. Higher electricity costs? Absolutely. Something fun to tinker with and keeps my propeller-head turning? No doubt. Some folks wouldn’t spend this, but for me it works… no matter how I end up using it at the end of the day.
Toronto is a great city!
