If you love radio like me you always have an rtlsdr on hand. One of my goals was to use it with the FLX1.
On most systems that is as simple as installing the rtl-sdr package or equivalent. Unfortunately there are two bugs that prevent that from working, one in the old 4.19 kernel the FLX1 uses and the second is in the Osmocom rtlsdr source.
The issue with the 4.19 kernel can be found here along with a potential fix. @fakeshell I can confirm it will work based on this current testing. (Previous testing I mistakenly left a version of the repo rtl-sdr package installed which triggered the zero copy buffer) happy to resubmit the pull.
The second issue can be found in the Osmocom driver. Commit 81833a1 from 2019 proclaims to disable zero-copy support by default and yet both the repo version and a fresh compile from source, WITHOUT enabling the zero-copy buffers during compilation *still* results in them being enabled during runtime.
By enabling the kernel fix we would be able to happily use the upstream/or repo versions of the rtl-sdr driver without change or issue.
Without the kernel fix or compiling according to the below, rtl_test or anything else you try to run will be instantly killed (see mailing list):
To make it usable currently:
Fork the Osmocom rtl-sdr github repo and completely remove the Zero-copy buffer section found in src/librtlsdr.cÂ
If you don’t want to do this I have already done so here:
[Permission to view this media is denied]
This ensures we force userland buffers (which are supposed to be the default anyway).
Now when you run rtl_test it will work and not be killed trying to allocate buffers.
HOWEVER, there is another problem (which I may fix shortly) the repo version of librtlsdr0 is “newer” than the compiled version and apt doesn’t know it’s installed. If you try and install say rtl_433 from the repo it will also install librtlsdr0 which has the zero-copy buffer issue.
Â
Don’t actually do the below, see next post for details/workaround
To avoid that you can compile rtl_433 from source or if you are lazy:
1. apt download rtl-433
2. sudo dpkg -i (rtl_433 .deb package)
dpkg will give you warnings, its fine.
3. It is ready to run.
Â
The proof is in the pudding though. Picture of it running and decoded will be posted shortly
If you install something via apt download and sudo dpkg -i you end up with another problem, you break apt as the librtlsdr0 we made and installed isn’t seen by it, and rtl_433 is installed without that dependency. Even if it did work you would have a hell of a time installing radio stuff with more dependencies one by one.
The way around that is a meta-package, a stub that tells apt that rtlsdr0 is installed.
To do this (if you installed rtl_433 via apt download etc, be sure you sudo apt remove it before doing the below):
  sudo apt install equivs
Create a dummy conf:
  equivs-control librtlsdr0.control
Edit it:
  sudo nano librtlsdr0.control
Use the following info, uncommenting pieces as needed:
  Section: libs
  Priority: optional
  Standards-Version: 3.9.2 (Not sure if needed)
  Package: librtlsdr0
  Version: 9.9 (hoping this will keep it far ahead of the repo version, if not I will change it in the actual package fork)
  Provides: librtlsdr0
Save it
  Ctrl – o
 Exit
  Ctrl – x
Build it:
  equivs-build librtlsdr0.control
Install it:
  sudo dpkg -i librtlsdr0_9.9_all.deb
Â
Now you can sudo apt update and sudo apt install rtl_433 or anything else without getting a nonworking librtlsdr0 dependency
Â
@wayne this link and image blocking makes it a real pain to share anything helpful.
This is brilliant! I’d love to have a emergency radio option during the bushfire season here in australia, what rtl-sdr do you recommend? just the one at rtl-sdr(dot)com or ?Â
Honestly it doesn’t matter they are all mostly the same. In my blocked picture I’m using a nooelec nesdr nano 3 simply because it’s small, the tradeoff is that it’s antenna isn’t very good.
I would advise you to get something with TCXO of 1ppm or less. As an rtlsdr heats up the it can cause the crystal to drift. A TCXO prevents most of that and helps if you want to decode P25.
Also keep in mind an rtlsdr is receive only. I haven’t looked into or tested any other sdrs with the FLX1 as of yet (most of my gear is in transit), also I probably won’t use a tx sdr with it anyway. I mostly like radio stuff (TPMS, weather station signals, remotes, keeloq, Sec+ v1/v2) which I can tx with an MCU and radio transceiver and pyserial. Nothing beats a cheap sdr for analysis though.
Which reminds me I need to test pyserial on the FLX1.
Just installed gqrx-sdr from the repo to further test the capability with my patched driver (and see if there were any other dependency issues)
Â
I am happy to say it worked perfectly, although the UI gets cut off in portrait. In landscape you can see it all, and I was able to tune to and listen to a local radiostation with WFM.Â
So working really really well.
I’ll stop posting a ton of stuff here, unless I find something that *doesn’t* work
It appears FuriLabs have held a package related to Qt5, which results in it failing to get all dependencies and build
Â
Dump1090 builds and installs well though, I was tracking some aircraft with it on the interactive map this afternoon.
Â
VoLTE + most of my radio programs makes this thing awesome. Definitely my favorite phone (and I have had a lot including the Cosmo Communicator, and an original Fxtec Pro1). The only thing that could make it better is a hw keyboard addon. Then it would be a phone and a umpc.Â
feel free to open a PR against the kernel. also let me know which qt5 package is held and is causing issues perhaps i can fix it. the only qt5 package we patch is qt5 multimedia which is to allow aal (camera app) and v4l2loopback (everything else) to work at the same time.
Hm interesting. Universal Radio Hacker depends on the following:
python3-psutil
python3-numpy
and python3-pyqt5
(also cython3)
The error I get is python3-pyqt5 Depends: libqt5gui5t64 (> = 5.15) but it is not installable Error: Unable to correct problems, you have held broken packages.
Â
Yet sudo apt-mark showhold doesn’t show anything held. Maybe the package isn’t available for aarch64…Â
Â
Trying to workaround it by installing via pip: sudo pip install pyqt5 hangs on Preparing metadata (pyproject.toml)
feel free to open a PR against the kernel. also let me know which qt5 package is held and is causing issues perhaps i can fix it. the only qt5 package we patch is qt5 multimedia which is to allow aal (camera app) and v4l2loopback (everything else) to work at the same time.