A GR block is not intended to be both a source and a sink, though you
could probably force something. Even if you could, gr-osmosdr sits
between GR and HackRF, and also separates source and sink.
You could rework the gr-osmosdr hackrf support to provide a hardware
manager below the source and
I picked up a SDRplay RSP2 recently, and the gr-osmosdr support needed
some work. Here's a rewrite that works with RSP2 and has other
improvements. When the RSP1A comes in, I'll finish support for that. No
plans to pick up a RSP1, but someone can see if this works if
interested. This was tested
Build and install went smoothly for everything, I have PYTHONPATH and
the ld.so.conf stuff setup properly, but for osmosdr, I end up getting:
ImportError: No module named _osmosdr_swig
When I try to import the osmosdr module.
The corresponding .so file is exactly where it is supposed to be.
O
Hi Marcus.
Thank you very match for your responses.
1. I use HackRFs, both with latest firmware. I do not receive any
Error-Messages in Debug Console. But, as I exposed smaller Samplerate in
"Osmocom"-Block or used wav-File with larger Samplerate, streamed "UUU"
and "OOO" Symbols in Console an T
Hi,
I have been trying to get my Pluto to work with WBFM, but I am not
having any luck. I am attaching a grc file that I am pretty sure should
work, but it does not. It just generates sporadic noise. I did the
changes recommended to get the Pluto to work over a wider frequency
range, and the resu
