Problem with miri driver

[sypniew]

I have receiver with msi2500/msi001 chip-set and I'm trying to use Cubicsdr with Soapy-miri driver. After installing I'm getting following messages:

debian@localhost:~$ SoapySDRUtil --find=miri
######################################################

Soapy SDR -- the SDR abstraction library

######################################################

Found device 0
driver = miri
label = Mirics MSi2500 default (e.g. VTX3D card)
miri = 0

debian@localhost:$
debian@localhost:$ SoapySDRUtil --make=miri
######################################################

Soapy SDR -- the SDR abstraction library

######################################################

Make device miri
Using device #0: Mirics MSi2500 default (e.g. VTX3D card)
usb_claim_interface error -6
Error making device: Failed to open mirisdr device.
debian@localhost:~$

The CubicSDR does not work; the soapy driver is not loaded.
BTW I have copied mirisdr.rules into proper place no change, also Soapy does not work even if I'm root.
The Sopy rtl-sdt driver works perfectly. All software is recent pool from the last version of debian.

I would greatly appreciate any suggestion

[zuckschwerdt]

LibUSB error 6 is "busy", so likely a driver or some other app has claimed the device?

[sypniew]

I appreciate your help, but issue is still there:
I have tried similar SoapySDR driver on the same port & it worked:

joe@localhost:~$ SoapySDRUtil --find=rtlsdr
######################################################

Soapy SDR -- the SDR abstraction library

######################################################

Detached kernel driver
Found Rafael Micro R820T tuner
Reattached kernel driver
Found device 0
available = Yes
driver = rtlsdr
label = Generic RTL2832U OEM :: 00000001
manufacturer = Realtek
product = RTL2838UHIDIR
rtl = 0
serial = 00000001
tuner = Rafael Micro R820T
joe@localhost:~$ SoapySDRUtil --find=rtlsdr
######################################################

Soapy SDR -- the SDR abstraction library

######################################################

Detached kernel driver
Found Rafael Micro R820T tuner
Reattached kernel driver
Found device 0
available = Yes
driver = rtlsdr
label = Generic RTL2832U OEM :: 00000001
manufacturer = Realtek
product = RTL2838UHIDIR
rtl = 0
serial = 00000001
tuner = Rafael Micro R820T

joe@localhost:~$ SoapySDRUtil --make=rtlsdr
######################################################

Soapy SDR -- the SDR abstraction library

######################################################

Make device rtlsdr
Detached kernel driver
Found Rafael Micro R820T tuner
Reattached kernel driver
Detached kernel driver
Found Rafael Micro R820T tuner
driver=RTLSDR
hardware=R820T
origin=https://github.com/pothosware/SoapyRTLSDR
rtl=0
Reattached kernel driver

Also, I've run lsusb -v & lsusb with/without radio attached to see how interface is registered; it looked normal:
(vendor ID is 1df7 & it is OK)
joe@localhost:~$ lsusb
Bus 001 Device 002: ID 8087:8000 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 002 Device 003: ID 0489:e056 Foxconn / Hon Hai
Bus 002 Device 002: ID 1bcf:2c67 Sunplus Innovation Technology Inc. HD WebCam
Bus 002 Device 014: ID 1df7:2500
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

L've run usb-devices; registered OK:

joe@localhost:~$ usb-devices
...
T: Bus=02 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 14 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=ff(vend.) Sub=ff Prot=ff MxPS=64 #Cfgs= 1
P: Vendor=1df7 ProdID=2500 Rev=02.00
C: #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=400mA
I: If#=0x0 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=ff Prot=ff Driver=msi2500
...

I've checked lsmod, if there is colosion; msi modules are registered first:

joe@localhost:~$ lsmod
Module Size Used by
msi001 20480 1
msi2500 36864 0
videobuf2_vmalloc 20480 1 msi2500
videobuf2_memops 20480 1 videobuf2_vmalloc
videobuf2_v4l2 36864 1 msi2500
videobuf2_common 65536 2 videobuf2_v4l2,msi2500
videodev 286720 4 videobuf2_v4l2,msi001,videobuf2_common,msi2500

The difference between rtl-sdr and miri drivers is that rtl-sdr creates several devices: dvb/*, lirc0, media0, swradio0.
Versus miri driver creates only: swradio0.

I appreciate any suggestion what I can check next. Thankyou.

[zuckschwerdt]

$ lsmod
Module Size Used by
msi001 20480 1
msi2500 36864 0
...

That's what I meant ;) There are drivers loaded that claim the device.
If you see any of dvb/*, lirc0, media0, swradio0, ... then you cannot use SDR.
Search for driver detaching, unloading, blocking, blacklisting, or similar.

[sypniew]

Thank you for sticking with me and helping me get miri driver to work.
I thought that msi001/msi2500 drivers are correct since I'm using msi001/msi2500 chipset. Nevertheless, I have blacklisted these drivers & they are not loaded.
The SoapySDRUtil --find=miri still recognizes the radio same as before, but SoapySDRUtil --make=miri is very different than before and it changes most of the time I call:

joe@localhost:~$ SoapySDRUtil --make=miri
######################################################

Soapy SDR -- the SDR abstraction library

######################################################

Make device miri
Using device #0: Mirics MSi2500 default (e.g. VTX3D card)
driver=miri
hardware=miri
_mirisdr_alloc_async_buffers
Lost samples!
02 f1 f7 14 20 92 00 00 f3 d0 25 65 69 e6 02 89
Lost samples!
OOOOOOO ...
... OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOERROR: thread '9SDRThread' has not terminated in time ! (> 3000 ms)

The CubicSDR still is not working & it hung-sup. On terminal (stdout) it is printing "000..."
Conclusion; the communication is there, but it is skipping the samples (?).
BTW I'm using USB3.

[zuckschwerdt]

Not looking good. Perhaps you shouldn't use that "miri" driver and use the more robust SoapySDRPlay driver ("sdrplay").

(It's not USB 3, the lsusb above shows Bus 002 which is a 2.0 root hub. A standard USB 2 cable and/or port is sufficient.)

[sypniew]

Yes, miri driver looks choppy. Unfortunately there is no SoapySDRPlay driver in current debian depository ready to use. I'll try to build it & I hope everything will work fine. I appreciate your help and I let you know (probably tomorrow) how it worked.
Best Sypniew

[zuckschwerdt]

no SoapySDRPlay driver in current debian

https://packages.debian.org/bullseye/soapysdr0.7-module-all
Oh, I never noticed. Probably because sdrplay (not SoapySDRPlay) is closed source :/

[ericek111]

You can use my SoapyMiri driver. :) It works perfectly for me in SDR++ and GNUradio.

But I only have a package for Arch: https://aur.archlinux.org/packages/soapymiri-git

[zuckschwerdt]

The driver name "soapyMiri" is really asking for confusion with "miri" :) Maybe "mirisdr" to match the library name and common scheme in Soapy? Hardly better though.
Could do with a README to explain the relation to Osmo and Play. Looks good overall!

[ericek111]

Yeah, but you know the two hardest problems in computer science. :) AFAIK, there is no other project named "SoapyMiri", so I went with that, even against the naming convention.

There already is a "miri" driver for Soapy, soapy-module-mirisdr from SoapyOsmo, discussed here. It's broken and it's been removed from Osmo 2 years ago, but this hasn't been reflected in the SoapyOsmo module yet.

If you want to use the driver in question, you have to replace miri_source_c.cc in SoapyOsmo with this fixed version and recompile: https://gist.github.com/ericek111/4e59b94ecfc20a182c2bb1c3fab5fa42

[zuckschwerdt]

two hardest problems in computer science

;)

There already is a "miri" driver for Soapy, soapy-module-mirisdr from SoapyOsmo,

And it's not packaging some "mirisdr" but just "miri" (libmiriSupport.so).
So maybe Debian/Ubuntu packagers could name your module "soapy-module-miri" to contain libmirisdrSupport.so. Sounds fair to me ;)

[sypniew]

Thank you for help, however I was not successful to run msi2500/msi001 radio on debian. Beside soapy-module-mirisdr, I have tried mirisdr, ericel111's driver with sdrpp and driver from sdrplay.com; nothing worked. I believe this hardware is not ready for deployment and more established hardware should be used. There is a new soapy-module-mirisdr driver on debian sid, but sid would brake my current system. So I have to wait or use other hardware.
Again, thank you for help.

[sypniew]

Still I'll try to build gr-osmosdr-gqrx with ericek111's driver. Also, I have a question; is msi2500 API opened, or we have to use binary blob from SDRPlay?

[tarhan]

You can use my SoapyMiri driver. :) It works perfectly for me in SDR++ and GNUradio.

But I only have a package for Arch: https://aur.archlinux.org/packages/soapymiri-git

Can you explain how to correctly build flowgraph to not lost samples?
After I've compiled and installed your module. It is working (now gain working on Ubuntu).
But in log window I many following lines :

4259574902 samples lost, 3072, 021c0b8a:00000000
35392142 samples lost, 3072, 000000fc:021c0b8a
41100698 samples lost, 3072, 000000fc:02732696
4252204658 samples lost, 3072, 028c818e:00000000
42762386 samples lost, 3072, 000000fc:028c818e
44639534 samples lost, 3072, 000000fc:02a9262a
48561662 samples lost, 3072, 000000fc:02e4fefa
4242601946 samples lost, 3072, 031f0826:00000000
52365098 samples lost, 3072, 000000fc:031f0826
4242234530 samples lost, 3072, 0324a35e:00000000
52732514 samples lost, 3072, 000000fc:0324a35e
4238027390 samples lost, 3072, 0364d582:00000000
56939654 samples lost, 3072, 000000fc:0364d582
57363014 samples lost, 3072, 000000fc:036b4b42
4236656762 samples lost, 3072, 0379bf86:00000000
58310282 samples lost, 3072, 000000fc:0379bf86
4230281414 samples lost, 3072, 03db073a:00000000
64685630 samples lost, 3072, 000000fc:03db073a
65728910 samples lost, 3072, 000000fc:03eaf28a

My center frequency 1227.6 Mhz and sample rate 5M or 8M.
I'm receiving previous messages very often (5-10 lines each second). So lost samples count is wrong.

[vladisslav2011]

Can you explain how to correctly build flowgraph to not lost samples?

Apply this commit to libmirisdr
vladisslav2011/libmirisdr-4@d9d7584

[ericek111]

I'm maintaining a fork with @vladisslav2011's fixes here: https://github.com/ericek111/libmirisdr-5

Thanks, Vladisslav, I learned a lot from your commits! It also made using RSP1 easier and smoother for me.

[tarhan]

@vladisslav2011 Thanks for that commit.

[nmaster2042]

@ericek111 : about driver name confusion with already existing "miri" driver name from SoapyOsmo driver, what about using "mirisdr" for your driver ?

[ericek111]

SoapyOsmo is outdated, the driver itself does not work (see pothosware/SoapyOsmo#9) and has been removed from gr-osmosdr 2 years ago. My driver is called "soapyMiri", which does not conflict with the SoapyOsmo driver and while I do agree on the confusion part, I think it's SoapyOsmo that should be updated, especially now that there's an alternative.

[nmaster2042]

I agree with you, miri support should be removed from SoapyOsmo.

Other devices in the past have been removed from it when alternative came out

See here: https://github.com/pothosware/SoapyOsmo/blob/master/Changelog.txt

I opened an issue for this.