search

pothosware / SoapySDR

Vendor and platform neutral SDR support library.
https://github.com/pothosware/SoapySDR/wiki
Boost Software License 1.0
1.13k stars 179 forks source link

Problem with miri driver #359

Closed sypniew closed 1 year ago

sypniew commented 2 years ago

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 commented 2 years ago

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

sypniew commented 2 years ago

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 commented 2 years ago 
$ 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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

Apply this commit to libmirisdr https://github.com/vladisslav2011/libmirisdr-4/commit/d9d7584d28210e3170a47a0a5ba54dd84684cbd3

ericek111 commented 2 years ago

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 commented 2 years ago

@vladisslav2011 Thanks for that commit.

nmaster2042 commented 1 year ago

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

ericek111 commented 1 year ago

SoapyOsmo is outdated, the driver itself does not work (see https://github.com/pothosware/SoapyOsmo/issues/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 commented 1 year ago

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.