[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gnuradio-discuss
Subject:    Re: Use /dev/swradioN (v4l2 api) as source
From:       Stefan Oltmanns <stefan-oltmanns () gmx ! net>
Date:       2022-06-14 8:52:17
Message-ID: 43e6fe42-f24a-84ef-1dfa-6fb08f9e8c9e () gmx ! net
[Download RAW message or body]

Franco, as far as I understand this, the libraries like libmirisdr and
librtlsdr do not use the v4l2 kernel driver at all, they use libusb to
connect to the devices and the driver is implemented in user-space.

I looked into the v4l2 documentation and the example fm radio, it's not
exactly easy to implement a device control using ioctl. Also there seem
to be better ways to read the data than just reading the device
(asynchronous DMA techniques with special buffers).
As I couldn't find any GNURadio source block being able to use the v4l2
API, I assume it's not easy to write.

For now I'll stick with SoapyMiri (it seems that libmirisdr is just more
picky what USB connector is used, using another one I could solve the
dropped samples).

Best regards
Stefan


Am 14.06.22 um 04:41 schrieb Franco VENTURI:
> Stefan,
> if I were you I would contact the author of that SoapyMiri driver on GitHub about \
> your problems with it, since to me he seems interested in improving it and he \
> probably would be able to run some tests on his setup to troubleshoot and fix those \
> issues. 
> As per my comment about using the kernel API directly, the word 'directly' was not \
> a good choice; I meant it in the sense of connecting from your userland application \
> 'directly' to the kernel (as opposed via a library or a module like SoapyMiri). \
> This said, if you just want to stream directly from that device /dev/swradioN, I \
> believe it is a character device that streams I/Q samples as 16bit shorts (this is \
> what I remember from long ago; please double check it). In this case I think you \
> should be able to read from it using a GNU Radio file source block with a type of \
> 'complex short' (you shouldn't need a throttle block because the sample rate is \
> decided by your /dev/swradioN device). The limitation of this approach is that it \
> is good only for the streaming part; the control part (like selecting sample rate, \
> frequency, possibly filters, etc) is probably through specialized ioctl() calls to \
> that device (again you may want to double check that), so either you rely on an \
> external application for that or you would have to write an OOT GNU Radio module \
> (or perhaps someone already did, I am not sure). 
> Franco
> 
> 
> > On 06/13/2022 8:47 PM Stefan Oltmanns <stefan-oltmanns@gmx.net> wrote:
> > 
> > 
> > Thank you very much for that information, haven't seen that somebody
> > continued the work on libmirisdr.
> > I was able to get it working with an OsmoSDR Source using
> > soapy=0,driver=soapyMiri
> > 
> > I had to modify the SoapyMiri driver, as OsmoSDR sets the bandwidth to
> > 3/4 of the sample rate, but there are only certain fixed bandwidth
> > values allowed, otherwise SoapyMiri will throw a runtime error (maybe it
> > should find the closest allowed value). For now I hardcoded a bandwidth
> > value and it works, but...
> > 
> > I get a lot of dropped samples, not suitable for practical use. This
> > doesn't happen with the kernel driver.
> > 
> > You said "instead of using the kernel API directly", is there anything
> > that is using the kernel API indirectly? I couldn't find any GNURadio
> > plug-in that is using the SDR kernel API provided by v4l2 at all.
> > 
> > Best regards
> > Stefan
> > 
> > 
> > > gr-osmosdr 0.2.0.0 (0.2.0) gnuradio 3.10.3.0-rc1
> > > built-in source types: file rtl rtl_tcp rfspace soapy redpitaya
> > > [INFO] Opening Mirics MSi2500 default (e.g. VTX3D card) :: 00000001...
> > > failed to open miri usb device 0 with code -3
> > > Traceback (most recent call last):
> > > File "/home/stefan/miri_test.py", line 188, in <module>
> > > main()
> > > File "/home/stefan/miri_test.py", line 166, in main
> > > tb = top_block_cls()
> > > File "/home/stefan/miri_test.py", line 117, in __init__
> > > self.osmosdr_source_0 = osmosdr.source(
> > > RuntimeError: Unable to open LibMiriSDR device.
> > 
> > 
> > 
> > Am 14.06.22 um 00:28 schrieb Franco VENTURI:
> > > Stefan, instead of using the kernel API directly you may want to look into a \
> > > SoapySDR source in GNU Radio, since the SoapySDR block is now a first class \
> > > citizen in GNU Radio 3.9/3.10 
> > > According to this recent discussion in the SoapySDR GitHub repository \
> > > (https://github.com/pothosware/SoapySDR/issues/359) there's a SoapyMiri driver \
> > > (https://github.com/ericek111/SoapyMiri) that might work for you. A comment in \
> > > the same thread \
> > > (https://github.com/pothosware/SoapySDR/issues/359#issuecomment-1150982319) has \
> > > also instructions about integrating his fixes in OsmoSDR, if I understand \
> > > correctly. 
> > > I personally haven't tried this approach so I don't really know if it works or \
> > > not, but I thought you might find this information useful. 
> > > Franco
> > > 
> > > 
> > > 
> > > > On 06/13/2022 3:26 PM Stefan Oltmanns <stefan-oltmanns@gmx.net> wrote:
> > > > 
> > > > 
> > > > Hello,
> > > > 
> > > > is there any way to use devices exposed as /dev/swradioN by the v4l2
> > > > Linux kernel API with GNURadio directly?
> > > > 
> > > > At the moment there are only two in-tree kernel drivers, one for the
> > > > RTL2832U and the other for the Mirics MSi2500. For the RTL2832U
> > > > librtlsdr seems to be the better option, as it offers more features to
> > > > control the device, but libmirisdr seems to unmaintained and not stable
> > > > (at least for me), support has been removed from OsmoSDR years ago.
> > > > I do have such a Dongle and with the kernel driver it seems to work just
> > > > fine.
> > > > 
> > > > I also found an out-of-tree driver for CX2388x-based TV cards, so a V4L2
> > > > source block could be very useful. Is there any specific reason, why
> > > > such a source block doesn't exist yet?
> > > > Or is it just that nobody needed it and therefore no one bothered
> > > > writing one?
> > > > 
> > > > Best regards
> > > > Stefan


[prev in list] [next in list] [prev in thread] [next in thread]