You are right there! A bit like on old maps it says “Here be Dragons”
I have just started digging and the script gave an error (and a typo in first line quoted below: numer … should be number)
Counting numer of tests to run. This could take a while.
Will run 80 tests
Running test 1 of 80 : ./sampledir/dump-6-2-21.bin sample-rate=6 sample-format=sc16 gain=21 smoother-window=2 preamble-threshold=0.7 preamble-window=0:0 preamble-strictness=2 msg-window=-7:7 mark-limits-flag=0 fix-flag=0 fix-df-flag=0
Failed to read wisdom file /etc/dump1090-fa/wisdom.local: No such file or directory
Checked the wisdom-local and it looks like a x86 file: one line from it:
Statistics: Fri Jul 16 15:04:04 2021 CEST - Sat Jul 17 10:03:53 2021 CEST
This is from today:
Statistics: Sat Jul 17 10:04:53 2021 CEST - Sat Jul 17 18:18:31 2021 CEST
Jul 17 18:18:31 airspy dump1090-fa[1534]: 3362 unique aircraft tracks
Jul 17 18:18:31 airspy dump1090-fa[1534]: 2981 aircraft tracks where only one message was seen
Jul 17 18:18:31 airspy dump1090-fa[1534]: 2998 aircraft tracks which were not marked reliable
Has anyone else seen this difference when going from a sample-rate of 20 and sample-format u16o12 to a sample-rate of 10 and sample-format sc16?
EDIT:
I also have some dropped samples with this setting. Not huge amounts, but for a period of 6 seconds I dropped samples and had an under-voltage warning at the same time. Never had any under-voltage problems before. The PSU is a separate unit (MeanWell PSU) that feed the Pi with 5.25V via USB-C and can supply up to 7A. It’s just the airspy mini connected to one USB-port, the rest of the ports are free and nothing is connected to the gpio-pins.
On the CPU-graphs there is a small spike at the same time:
Yeah you can do 6 and 10 with the mini. I just happen to always use 12 in examples.
The ADC spits out 12 bit samples where 1 = -2047 and 4095 = +2047. dump1090’s common demod input is 16 bit unsigned representing the absolute value scaled to 65535.
No problem, thats why we test stuff! Thanks for producing the scripts.
I am in the middle of a long stats run to test it all out. It is a very good day here in southern UK, aircraft-wise so I am getting a load of samples to analyse.
Maybe you could consider an option for sample-analyzer “-count-only” so it provides the count but does not do work. I know we can ctrl-c out of the script, but that would be neat. I started a run and the count was 1200, which is fine, but as you have said… the number of iterations just adds up!
Speaking of typos, another one in the README.txt, at the end it should say “files” not “fines”
sample-analyzer doesn't connect to the airspy device
so you can run it any time and any place as long as the
sample fines are available.
I’ll try that the next time I test that setting. Right now I’m a bit curious on why I have dropped packets and an under-voltage warning when running with sc16.
to test which settings work on the Mini, I get the following files created:
The rest give a sample rate not supported error which is expected.
All take about 10 seconds to run when written to a NAS via NFS, except dump-6-4-16.bin which ends after 5 seconds and is half the size of 6-2-16 and 12-4-16.
I notice I am getting a lot of I/O-wait when using the SD card after the first few files in the sequence. Could there be lost samples in the capture data or will the 'Pi just buffer the writes and eventually ‘catch up’? Each job takes 13-25 seconds to complete, as I assume it is waiting for writes to complete.
Don’t worry about the gain setting being low, I am just changing that to give me different file names during testing.
Your SD card might not be fast enough to directly save the samples - they get dropped rather than buffered I think.
You can get around that problem by saving to a ram disk first and then copying to disk after the capture is complete. If you have a pi 4 with 2GB or more this is easier, but you might have enough ram available on a 3 depending on what other stuff you have running.
Adjust the size to suit your available ram:
mkdir /tmp/ramdisk
sudo mount -t tmpfs -o size=700m tmpfs /tmp/ramdisk
then just run the capture command saving to the location /tmp/ramdisk and you can copy the saved file as normal.
Thanks caius,
I don’t see the problem when using the NAS NFS, and since files are large, and the card is 16GB it soon starts to fill up on a long sample run. Memory is not a problem, my Pi4 / 400 are 4GB
It is supposed to be a fast card, but I know not all fast cards are made equal, even if the spec is the same! I only use Samsung or Sandisk cards.
I guess we need to verify if they do get dropped otherwise we may be getting false data even before we start analysing
Using statistics package which helps give a direction and is less ‘subjective’ I have changed settings to test using test samples created during very high traffic levels and good reception conditions.
My conclusion (subjectively / gut feel) is that the Mini is a little down on weak signal reception (longer distances) but is the same or better at less than about 150nm. This is compared with the FA Orange dongle. You can see this on the FA stats page for me (user g7ruh) reference and test systems are there.
In amateur radio we have a saying ‘tune for maximum smoke’! It does not mean overheat hardware (as it can be expensive), as much as change settings until you get distortion or corrupt data and then back off slightly.
I have used Gain=21 to =17 in testing and 21 always gives better results (number of messages / tracks) as this example shows
RECEIVER_GAIN=" --airspy-lna-gain 15 --airspy-mixer-gain 15 --airspy-vga-gain 15"
rather than `RECEIVER_GAIN="--airspy-linearity-gain 21"`
but either way, the settings are at maximum and I cannot increase to the point of overload, to detect the highest usable setting, as per this graph
I know the Airspy behaves differently to the FA Orange dongle so I do not expect very high signal levels (like 0db max) but the median and quartile and weakest still seem a bit lower than I would expect.
@gtj0 is there anything in the code you can change to see if we can get to the point of making things ‘worse’ so we can detect the ‘back off point’? I feel we are nearly there, it is just the distant signals which are not getting through. Of course it could be because the receiver is being desensitised by strong signals and the scope for improving it becomes limited.
Any thoughts? I am just stating a subjective view of my testing (so far) with a bit of data to back it up provided by the excellent stats package.
Unfortunately, ‘worse’ is subjective and implies a comparison over time. One thing you can look at though are your noise, average signal and peak signal numbers as reported directly by dump1090. I’d be interested in seeing them. Also, do you have a preamps and/or a filters in place for both the airspy and the FA orange?
They are fed by the antenna and uptronics LNA (amp and filters) to a 4-way passive splitter with 50 ohm termination on unused ports. So same antenna, LNA and splitter for both.
I have disconnected the reference system to check that there is no back-leakage from that to the airspy test system. When disconnected there is no clear change in results using skyaware web page message rate as a check for both.
Is that the same as using the graphs1090 graphs from both or another source of the data?
I agree worse is very subjective, that is why I was trying to say here is helpful information but very subjective, however, gut-feel is often a good indicator of what is ‘not quite right’,
That matches what I’ve seen too. I compare with an Airspy R2, and there is almost always an advantage for the R2 regarding weaker signals. Often 2-3 aircrafts showing up on the R2 that are not on the mini (running dump1090) and they are always far away, at really low height or behind the large tree shadowing parts of the sky at my location.
I also see the same regarding aircrafts closer to my site and with good signal strength. There are periods during the day (when there are a little more smaller aircrafts flying fairly close (10-100 nm)) when the difference between airspy_adsb and dump1090 is in favor of the latter.
I’ve not yet tried getting samples with a gain of 21. When running airspy_adsb I always get a little worse performance at 21 compared to 17-18. Will make some samples tomorrow when there is a lot more aircrafts present. I’ll try to make with both linearity-gain and individual gain settings.
I think that the difference you see when you set the gain of the different stages compared to using --airspy-linearity-gain 21 is due to this:
As you can see the different stages are lower when using --airspy-linearity-gain 21 than setting them individually. If my memory serves me right, this is how libairspy0 implements the settings.
Took a brave decision and installed 5.0.5 over 5.0 with manual install
followed ins as of 5.0 and put files as they should be
worked untill i rebooted just to make sure it did work
now shown as in pic not working
