My 1st Pi (orangepipc) has Armbian Buster. Dont think apt update/upgrade will help
My 2nd Pi (rpi model 2b) has Piaware SD card image 3.8.0. Not sure apt update/upgrade will help
My 3rd Pi (rpi 4) I got few days ago, burned Buster and installed dump1090-mutability v1.15~dev for test run. It is lying unused in my drawer alongwith unused rtl-sdr tripple filtered lna. I will re-image its microSD card with Buster 2020-02-05.
I know I shouldn’t be concerned but I’m just a bit wary of doing the update on my feeder. If I have any problems, that’s it. It’s off. I can’t get the mast down to do anything about it.
Is it up the mast being powered via PoE? What do you need to do to physically access it? Physical access a reason my mate’s going for a few metres og coax instead – it keeps the Pi accessible in the attic. A tall mast would make that approach more lossy than having the lot up there though.
mine went down some hours ago, but did not come back online on it’s own, even not with the “emergency” script if WiFi is not avaialble any longer. Same after a hard reboot where i tried a simple “sudo reboot”, device stayed unavailable via network
So the update did not solve my problem but made it bigger
Same happened an hour later.
So two issues within a short period made the decision easier to get everything reinstalled. Still on same SD Card (which was new), if it’s not getting better, will use a spare one for testing.
I wonder if you’re seeing this problem, which was found to be a bug in dhcpcd and which has been patched by the dhcpcd maintainer. To check, search syslog for the string ‘SEGV’ and see if you have anything and whether it’s againt dhcpcd.service
FYI - I started with an RPi4B, and the current Buster Desktop (Feb 2020), and only added the rtl-sdr library (sudo apt install rtl-sdr). No lost samples! I did two tests: one with the orange FA Pro Stick and one test with the RTL-SDR v3 receiver. Both did A-OK!
The test below ran for > 2 minutes.
pi@raspberrypi:~ $ rtl_test
Found 1 device(s):
0: Realtek, RTL2838UHIDIR, SN: 00000978
Using device 0: Generic RTL2832U OEM
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 36 bytes
^CSignal caught, exiting!
User cancel, exiting...
Samples per million lost (minimum): 0
Reattached kernel driver
pi@raspberrypi:~ $
To me it looks like the current Buster Desktop build corrected the above issues with LOTS of lost samples. Yay! Life is good!
Good question. I’ve decided to reinstall it yesterday evening. Now after 13 hours it still runs without issues. So my problem could be a different one, but i will monitor it long term.
Before the update the devices went down (lost signal) but rebooted based on my cron script.
After the upgrade it wasn’t coming back any more.
I do not have the old syslog any longer due to reinstall. But currently there is no result by searching for “segv”.
I had a few kernel errors before reinstall too, but not any longer
There is a new revision of the PCB that fixes the USB-C „bug“ and moves a smaller component to a different place, which makes it possible to determine whether the board us the newer version .
