The power is the Official Raspberry Pi power supply with the USB C connector. I’ll try another power supply to be sure. And I’ll try plugging the receiver/dongle directly into the USB port (there is a pigtail now)
Did not help… 
I tried a different official RPi power supply and no pigtail extension cables and no joy. I rebuilt the RPi4B with a fresh download of Buster (Sep 2019) and no joy. I exchanged the receivers between an orange FA Pro and an RTL-SDR Blog v.3 and no joy. Still lots of samples lost.
Just out of curiosity I downloaded and tried the PiAware SD card image and that worked A-OK (even with extension cables and the first power supply). I’d stay with this but I’d prefer to have Buster Desktop and some other apps on my RPI4B.
Is your build the Buster build with PiAware added? Or the PiAware SD card image?
TL;DR
orange FA Pro Stick:
pi@RPi4B:~ $ sudo systemctl stop piaware dump1090-fa dump978-fa
pi@RPi4B:~ $ rtl_test
Found 1 device(s):
0: Realtek, RTL2832U, SN: 00000978
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 2048000 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
lost at least 830 bytes
lost at least 170 bytes
lost at least 170 bytes
lost at least 20992 bytes
lost at least 3576 bytes
lost at least 298 bytes
lost at least 170 bytes
lost at least 11326 bytes
lost at least 2512 bytes
lost at least 298 bytes
lost at least 170 bytes
lost at least 8430 bytes
lost at least 2044 bytes
lost at least 298 bytes
lost at least 894 bytes
^CSignal caught, exiting!
User cancel, exiting...
Samples per million lost (minimum): 39
Reattached kernel driver
When did you download that image?
The first 2 month there were issues with the drivers, but not for a couple of month now.
I suppose you are also using a monitor? Maybe try a lower resolution?
Try the other HDMI port, just because?
Piaware sdcard image. But the piaware sdcard image is Buster Lite + extra packages, so I’d expect it to behave the same for this sort of thing, assuming you’re up to date.
The Buster Desktop image? I just downloaded it yesterday.
At the moment (during testing) I am not using the monitor. The monitor is off and I am accessing via SSH.
Try removing the HDMI cable when testing for loss.
While the monitor may be off, maybe the RPi is still generating an image.
Just noticing that those images are quite old.
So just for kicks try this:
sudo apt update
sudo apt dist-upgrade
sudo reboot
(i’m pretty sure the image already has the necessary USB driver changes, but it won’t hurt)
Ha! Me too!!
Is there something the “piaware sdcard image = Buster Lite + extra packages” updated?
pi@RPi4B:~ $ uname -a
Linux RPi4B 4.19.93-v7l+ #1290 SMP Fri Jan 10 16:45:11 GMT 2020 armv7l GNU/Linux
pi@RPi4B:~ $ cd /usr/share/vl805fw
pi@RPi4B:/usr/share/vl805fw $ sudo vl805
VL805 FW version: 000137ad
HDMI is unplugged from the RPI4B. All is updated. No joy…
pi@RPi4B:~ $ sudo apt update
Hit:1 http://flightaware.com/adsb/piaware/files/packages buster InRelease
Hit:2 http://archive.raspberrypi.org/debian buster InRelease
Get:3 http://raspbian.raspberrypi.org/raspbian buster InRelease [15.0 kB]
Fetched 15.0 kB in 2s (9,933 B/s)
Reading package lists... Done
Building dependency tree
Reading state information... Done
All packages are up to date.
pi@RPi4B:~ $ sudo apt dist-upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
pi@RPi4B:~ $ sudo reboot
Connection to rpi4b.local closed by remote host.
Connection to rpi4b.local closed.
EDIT:
what did you see that was old?
The images for download on the raspbian page haven’t been updated for a couple of months.
That’s why i was asking.
But the fixes for the USB drivers are probably quite a while back now and included in that image.
You’ve done the update so … it’s up to date and my remark is redundant.
But didn’t want to leave that stone unturned.
You could try a fresh Raspbian Desktop image without the software/changes you made.
Or let me rephrase: Which changes did you make?
I haven’t made any changes yet. Right now it is just Buster Desktop + sudo apt update / dist-upgrade + PiAware. (I’ve rebuilt things many times so I was trying to keep things simple…)
Curious.
This should stop the GUI:
sudo systemctl stop lxdm
Try then.
Would be interesting to know if it’s the configuration of the image or some service that is running which is the problem.
Probably makes no difference, but let’s check which piaware repository you are using:
ls /etc/apt/sources.list.d
didn’t like lxdm
pi@RPi4B:~ $ sudo systemctl stop lxdm
Failed to stop lxdm.service: Unit lxdm.service not loaded.
pi@RPi4B:~ $ ls -al /etc/apt/sources.list.d
total 16
drwxr-xr-x 2 root root 4096 Jan 27 21:30 .
drwxr-xr-x 7 root root 4096 Sep 25 19:31 ..
-rw-r--r-- 1 root root 70 Dec 30 08:13 piaware-buster.list
-rw-r--r-- 1 root root 187 Sep 25 19:11 raspi.list
Yeah i’m not even sure which display manager Raspbian is using.
No clue how to tackle the issue.
It’s really strange as well because you don’t even have the monitor or anything but the receivers plugged in.
If you have a powered USB hub, you can always try if that fixes the issue.
I wouldn’t know why it would … but still.
There is a lightdm…
pi@RPi4B:/etc/init.d $ sudo systemctl status lightdm
● lightdm.service - Light Display Manager
Loaded: loaded (/lib/systemd/system/lightdm.service; indirect; vendor preset: enabled)
Active: failed (Result: exit-code) since Tue 2020-01-28 13:02:33 CST; 47min ago
Docs: man:lightdm(1)
Process: 714 ExecStartPre=/bin/sh -c [ "$(cat /etc/X11/default-display-manager 2>/dev/null)
Process: 716 ExecStart=/usr/sbin/lightdm (code=exited, status=1/FAILURE)
Main PID: 716 (code=exited, status=1/FAILURE)
Jan 28 13:02:33 RPi4B systemd[1]: lightdm.service: Service RestartSec=100ms expired, scheduli
Jan 28 13:02:33 RPi4B systemd[1]: lightdm.service: Scheduled restart job, restart counter is
Jan 28 13:02:33 RPi4B systemd[1]: Stopped Light Display Manager.
Jan 28 13:02:33 RPi4B systemd[1]: lightdm.service: Start request repeated too quickly.
Jan 28 13:02:33 RPi4B systemd[1]: lightdm.service: Failed with result 'exit-code'.
Jan 28 13:02:33 RPi4B systemd[1]: Failed to start Light Display Manager.
Jan 28 13:02:33 RPi4B systemd[1]: lightdm.service: Triggering OnFailure= dependencies.
I do have a powered USB 2.0 hub. I dig that out and give it a try later today.
I doublechecked my Pis and my Pi4/1GB is on slightly older kernel/firmware and is stable. note the mmap / zero-copy complaint
pi@piaware:~ $ uname -a
Linux piaware 4.19.75-v7l+ #1270 SMP Tue Sep 24 18:51:41 BST 2019 armv7l GNU/Linux
pi@piaware:~ $ sudo /usr/share/vl805fw/vl805
VL805 FW version: 000137ab
pi@piaware:~ $ rtl_test -s 2400000
[...]
Reading samples in async mode...
Allocating 15 zero-copy buffers
Detected Kernel usbfs mmap() bug, falling back to buffers in userspace
lost at least 40 bytes
^CSignal caught, exiting!
User cancel, exiting...
Samples per million lost (minimum): 1
Reattached kernel driver
My Pi4/4GB has newer firmware/kernel and is not so stable. note no complaint about mmap / zero-copy
pi@testrig-tx:~ $ uname -a
Linux testrig-tx 4.19.93-v7l+ #1290 SMP Fri Jan 10 16:45:11 GMT 2020 armv7l GNU/Linux
pi@testrig-tx:~ $ sudo /usr/share/vl805fw/vl805
VL805 FW version: 000137ad
pi@testrig-tx:~ $ rtl_test -s 2400000
[...]
Reading samples in async mode...
Allocating 15 zero-copy buffers
lost at least 1116 bytes
lost at least 608 bytes
lost at least 304 bytes
lost at least 432 bytes
lost at least 432 bytes
lost at least 176 bytes
lost at least 304 bytes
lost at least 21536 bytes
lost at least 4384 bytes
lost at least 304 bytes
[...]
It seems a bit unpredictable whether it then stabilizes or not.
So I’d speculate it’s some combination of kernel version + whether librtlsdr decides to use zero-copy or not. It could be that the newer kernel fixes the zero-copy mmap bug, but there’s still some other problem in the zero-copy path.
I tried a USB 2.0 hub and it did not make any difference.
I don’t remember seeing Detected Kernel usbfs mmap() bug, falling back to buffers in userspace. I’ll have to look for that in the Log file.
Just to summarize:
- I rebuilt the RPi4B with a fresh download of Buster Desktop (Sep 2019) + PiAware addon (not the SD card image) and there were lots of lost samples.
- I rebuilt the RPi4B with a the FA PiAware image (the SD card image) and there are no lost samples.
- I then rebuilt the RPi4B with a fresh Buster Lite (Sep 2019) + PiAware addon (not the SD card image) and there were lots of lost samples.
I cannot figure out why my RPi4B build’s are different. I think I’m just going to set this aside for awhile and look for a RPi3B or RPi3B+.
Thanks for everyone’s help! I do appreciate it! 
One other item… I am curious if FA uses apt install rtl-sdr for librtlsdr or if FA does a cmake to create the rtl-sdr / librtlsdr?? I’ve been using apt install rtl-sdr
The piaware sdcard image uses the standard upstream librtlsdr package, we don’t rebuild it.
The USB hardware on the 4B is totally different to what’s on the 3B (and has different drivers etc as a consequence), which is a possible cause.
After a longer time of research and google i might have identified the root cause for the unexpected reboots of my RPi 4B
in several discussions it was discussed that a firmware bug might be the issue as long as the internal WiFi adapter is active and in use.
If something like this can be found in syslog, it’s likely that the RPi is affected by the bug:
brcmf_sdio_hostmail: mailbox indicates firmware halted
There’s a firmware patch developed, but not yet official.
1 Like