Most of the time I have lost bytes and quite a few samples per million lost, but it seems that only occurs at the start, and afterwards it runs without any further lost bytes messages…
Are you by chance still on the self-compiled rtl_test?
Self-compiled raspbian, yes, otherwise the Pi4 would not work. Does it come with that or the piaware/dump1090-FA add-ons?
When the testing started, i tried modifying rtl-sdr.
Not sure if you ever installed that.
Easy to check:
apt-cache policy rtl-sdr
This is to replace with default packages:
apt install rtl-sdr=0.6-1+rpt1 librtlsdr0=0.6-1+rpt1 librtlsdr-dev
Looked ok, but I re-installed them anyway. It seems the lost bytes at the start are worse when plugged into the usb3-ports.
Well, I guess the main thing is that after the start it runs without further samples losses.
It indeed is the main thing.
The work-around is probably still very hacky and not perfect.
But if it works, it works!
I won’t be putting my Pi4 up the mast with the Airspy until everything is less hacky and more perfect!
/edit - I see the base Raspbian download was updated on the 10th July. That’s good.
Pretty sure that doesn’t have the fix yet.
No matter, waiting for the dust to settle is a good idea with installations that aren’t easy to access.
The only differences I noted between July 10 and previous issue of Raspbian Buster are following 2 (there may be many more):
(1) This has stopped appearing:
(2) This has started appearing
Now two-fold problems - RPi-4 AND Buster
Problem: RTL Dongle
(2) Debian 10 (Buster) amd64 (released 6th July)
Problem on amd64 PC: Dump978-fa decoder software installation fails
(3) Raspbian Buster (released 10th July)
Problem on RPi: Dump978 decoder software installation fails
(4) Raspbian Buster (released 20th June)
Problem on RPi: Dump1090-mutability decoder software installation fails
rpi-update has the kernel with the USB controller fix now. Usual warnings about it being a test kernel/firmware. If you’re unsure then wait for them to push it as a normal update via apt.
Yeah i was going to try that but it warned about my small boot partition
Gonna have to resize the partitions.
Anyway I’m on a RPi3 so i don’t really need the new kernel.
Is MLAT working…?
Yes it is,
Did you check for lost samples with
rtl_test -s 2400000
Or very comfortably with
sudo bash -c "$(wget -O - https://raw.githubusercontent.com/wiedehopf/adsb-wiki/master/rtl_test.sh)"
I had quite few lost samples at the start, but it was working afterwards.
Lost samples in the first 2 seconds after starting the test are common and not a problem!
Starting 30 second rtl_test, standby!
Found 1 device(s):
0: Realtek, RTL2832U, SN: 00001000
Using device 0: Generic RTL2832U
Detached kernel driver
Found Rafael Micro R820T tuner
Supported gain values (29): 0.0 0.9 1.4 2.7 3.7 7.7 8.7 12.5 14.4 15.7 16.6 19.7 20.7 22.9 25.4 28.0 29.7 32.8 33.8 36.4 37.2 38.6 40.2 42.1 43.4 43.9 44.5 48.0 49.6
[R82XX] PLL not locked!
Sampling at 2400000 S/s.
Info: This tool will continuously read from the device, and report if
samples get lost. If you observe no further output, everything is fine.
Reading samples in async mode…
Allocating 15 zero-copy buffers
Detected Kernel usbfs mmap() bug, falling back to buffers in userspace
lost at least 108 bytes
Signal caught, exiting!
User cancel, exiting…
Samples per million lost (minimum): 0
Reattached kernel driver
More than 2 lost samples per million or other errors probably mean the receiver isn’t working correctly.
Try another power supply before condemning the receiver though!
No undervoltage detected, looking fine!
If the dongle is not directly plugged into the Raspberry Pi, lack of power/voltage could still be an issue.
Even without detected undervoltage a better power supply can often improve reception!
For optimum performance i would recommend the Official Raspberry Pi power supply.
for me running Airspy @20 Mhz gives me 200 m/sec more
Compared to what? 20 vs 12 MHz?