I’ve not updated the kernel because I don’t really want to have to do the kludge fix. I think I’m a few versions behind now as I’m still on 4.19.75-v7l+
Is there a way to update the kernel but exclude librtlsdr from the process?
I’ve not updated the kernel because I don’t really want to have to do the kludge fix. I think I’m a few versions behind now as I’m still on 4.19.75-v7l+
Is there a way to update the kernel but exclude librtlsdr from the process?
I recently decided to follow @wiedehopf’s clear instructions: Replace librtlsdr on Raspbian · wiedehopf/adsb-wiki Wiki · GitHub
It’s very easy to implement and works very well for me on my Pi3B.
Cheers,
Andreas / VA2WBT
I’m sure it is but if it’s possible to upgrade the kernel without updating librtlsdr then that has to be a better way of doing it
Then you don’t understand the issue.
Your current version of librtlsdr has the issue when used with the new kernel.
It’s not that much of a kludge … just do it.
Clearly.
I thought that the version of librtlsdr I was currently using was OK but when running an apt update and apt upgrade, it upgraded both the kernel and librtlsdr to versions which don’t work together and reverting back to the previous librtlsdr was the fix.
/edit - ahh heck I’m just going for it. What’s the worse that can happen?
(the worse that can happen is that I have to get the ladders out, release the restraining arm on my mast, lower the mast part way to the ground, go up a pair of rickety old steps, remove the cover from the box, try and get the SD card out so that I can replace it with a backup, then reverse the above procedure).
/edit2 - done.
I had that in mind and it’s as unlikely as with any update to cause total network or pi failure.
The kludge unconditionally deactivates a certain function in librtlsdr (zerocopy).
That function was with the old kernel automatically deactivated by the library (detecting the kernel version or something).
But it works with the new kernel version.
Works is obviously relative as it’s quite slow.
Thanks, it’s all good.
ADS-B CPU usage is up by a tiny amount, maybe a couple of percent but that’s fine, I can live with that.
I did an update/upgrade for the OS, rebooted and you can see here where I did all the work. I compiled the library myself, I didn’t use your pre-compiled version. A final reboot after and job’s a good 'un.
You aren’t even using librtlsdr.
Oh for craps sake
The clue is in the name, isn’t it. “lib RTL SDR”. Sheesh.
I’m still blaming the painkillers. The sooner I get off these damn things the better.
I’ve updated both of my receivers with the method of @wiedehopf a few weeks ago and so far did not identify any issues.
After upgrading to PiAware 4.0, those of us who used your helpful script earlier can, or probably should, revert to the original librtlsdr per your instructions at the bottom of the link above?
Reverting to original librtlsdr for me after 4.0 upgrade made a small ADSB CPU utilization change, I think.
Good hint. Done it a minute ago, htop does not deliver a significant change in CPU usage
I also followed @wiedehopf’s instruction to revert, and noticed no significant change in USB CPU utilization in going from 3.8.1 to 4.0 to 4.0 (reverted librtlsdr).
Cheers,
Andreas / VA2WBT
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.