Date: Sat, 27 Jun 2020 17:36:04 +0200 From: Jan Behrens <jbe-mlist@magnetkern.de> To: Tomasz CEDRO <tomek@cedro.info> Cc: Hans Petter Selasky <hps@selasky.org>, "freebsd-usb@FreeBSD.org" <freebsd-usb@freebsd.org> Subject: Re: USB reset fails when using a LimeSDR Mini on FreeBSD Message-ID: <20200627173604.7f7b7777140e66dbad812fc7@magnetkern.de> In-Reply-To: <CAM8r67DTKdj0%2BhkOegjBj-ywzWFq2CnS2sQed0mibSUeGp6HSQ@mail.gmail.com> References: <20200625121052.e9f7e7cbeb68fad264ec80a9@magnetkern.de> <CAM8r67DFFeFCHMh6mAxw=x2LKYnFGwasOLgceo-EQSMOvMHbeg@mail.gmail.com> <20200625200849.6af81489a80c2f97d4f89ee6@magnetkern.de> <CAM8r67AE1K9AK%2BaL4RCn6_BWajvzKO7K99bYZMdH0mr-HQdyGw@mail.gmail.com> <20200625224522.44d6584465cb6e20d17be320@magnetkern.de> <0ec3e5a3-7f31-d1cd-6862-6066c431aa80@selasky.org> <20200626135151.e5542cf97fad213c4ad661f2@magnetkern.de> <5c0729f9-9e98-52f7-a5cb-6c5dfd2287a3@selasky.org> <20200626172851.872f3a08fa6e632666683230@magnetkern.de> <CAM8r67AF%2BfGiqBr9A0863Za_zR-fG1FxGfNAqEvvafW=wTRmyQ@mail.gmail.com> <20200627144419.f14371695d9b62ea99106c4a@magnetkern.de> <CAM8r67DTKdj0%2BhkOegjBj-ywzWFq2CnS2sQed0mibSUeGp6HSQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 27 Jun 2020 16:12:45 +0200 Tomasz CEDRO <tomek@cedro.info> wrote: > I guess the FreeBSD's LibUSB implementation should be one-to-one > compatible with the GNU LibUSB. I would try to test and compare it > with Linux and MacOS implementation and see the difference: > > 1. If the problem exists on FreeBSD, Linux, MacOS. If so/no then if > there are different error messages / codes. If there are more verbose > codes / messages on systems other than BSD then FreeBSD's > implementation may need an update. However, the difference here seems > to be the USB stack itself. > > 2. If that function blocks normal operations on FreeBSD while without > it everything works fine, then it may be wrapped around ifdef and > simply removed for FreeBSD. > > 3. Make sure this is not a bug in the LimeSDR firmware that makes this > non-standard behaviour. > > 4. According to `man usbconfig` reset will perform "Reset the device. > This forces the USB stack to reenumerate the bus.". If LimeSDR uses > some dynamic USB interfaces configuration and re-organizes itself at > runtime then I would observe how the FreeBSD USB stack reacts to that > changes. Such reset may not be even necessary by hand (or from libusb) > if the OS re-enumerates the bus for you. Maybe on other OS it is > important to call that libusb reset to make sure the bus is > re-enumerated. > > @HPS is the author of the USB stack so he could provide some hints.. > but without actually seeing the device it can be hard to achieve :-) > > > > > When in trouble always try to test at root especially when working with > > > hardware. That may pinpoint the permissions issuses (not only /dev/usb* > > > permissions). > > > > You are right, of course. As "chown user /dev/usb/2.2.*" made a > > difference (and there wasn't any hint about a privilege problem), I > > wrongly assumed that it was not a privilege problem. I'll know better > > next time. > > > > Another question that I still have no clear answer to is: Is it > > semantically correct to use libusb_reset_device() in the Lime Suite > > driver for SoapySDR. The driver runs in the context of user > > applications which likely have no root privileges (for a good reason). > > I also don't know yet why this library call is made in the driver, and > > which purpose it has. See also my most recent post on the myriadrf.org > > discussion forum: > > > > https://discourse.myriadrf.org/t/limesdr-mini-with-freebsd/6230/8 > > > > I wrote: > > > > "I wonder if FreeBSD’s libusb should (and/or could) be fixed to ensure > > libusb_reset_device() can be run as non-root user, or if the Lime Suite > > should be fixed to not call libusb_reset_device() at all because it > > might be an administrative call that should never be used by a user of > > a USB device. I’m not sure what’s right to do. Particularly, I don’t > > know why the Lime Suite developers included that call, and I don’t even > > fully understand (yet) what it does." > > /dev/usb* are userland "access points" to the USB devices. They may be > accessed by the user according to the filesystem permissions. Some > stack level operations on the USB bus/port/hub may only be accessible > to the root user. > > Are you sure this is the problem? When run as root does the program > works fine? If so, there may be a systctl setting for the stack that > may allow user to reset / power-on-off the port (@HPS?)? You may want > to take a look at `sysctl -a | grep usb` to search for such sysctl > option. Maybe also `man usbconfig` and `man usb`. I haven't done a full analysis of the behavior with root privileges (or with a commented out libusb_reset_device call) yet. What I did is the following: 1. Comment out the libusb_reset_device(dev_handle) call in LimeSuite-20.01.0/src/ConnectionFTDI/ConnectionFT601.cpp 2. Compile and install the SoapyLMS7 module of Lime Suite (other parts of Lime Suite will fail to compile, which is a different issue but not required to fix to get the SoapySDR library to work) 3. Use a small C program to setup the LimeSDR Mini and record an I/Q stream to a file. (For those who are not familiar with the term "I/Q-Stream", it's raw sample data recording a radio band around a given center frequency, e.g. 145 MHz plus/minus 1 MHz using complex-valued samples representing in-phase and quadrature components.) I used a walkie talkie to do a test transmission in FM and I could later decode that FM transmission from the I/Q stream (using gqrx with that I/Q file as input). Unfortunately, the gqrx package in FreeBSD doesn't come with Soapy support, so I cannot use gqrx on FreeBSD to access the LimeSDR Mini directly (even with the SoapySDR driver working). Instead, I had to record the I/Q-Stream with my C program and later feed it into gqrx. Improving FreeBSD's packages to support SoapySDR and the Lime Suite is a different issue though, which I'd like to see solved and where I'd also be happy to help. However, I have no experiences in creating packages for FreeBSD yet and the last time I tried, I got pretty confused and failed. Anyway, I can confirm that it was possible to use the LimeSDR Mini with FreeBSD (with my self written C program) as long as that libusb_reset_device() call in the driver is commented out. However, I don't know if this works stable and if there are any other unwanted side effects. Also transmitting an I/Q stream did work (again, using a C program that directly interfaces the SoapySDR library). There are still a lot of error messages regarding "libusb_handle_events_timeout_completed". Not sure what that means. About the reset: No idea if it's even needed or why it's done. I assume only someone with deeper knowledge can answer it (either with knowledge about the LimeSDR driver or about libusb). > > > > > What I don't understand is that the Lime Suite SoapySDR module seems to > > > > work fine on Linux and other operating systems but makes trouble with > > > > FreeBSD. Is it a FreeBSD specific thing that libusb_reset_device() > > > > fails if called as non-root? > > Again, if you are sure that this is the problem, there may be a sysctl > that could set USB stack to allow non-root users to reset / > power-off-on the ports - @HPS can you give a hint please? :-) > > [...] > > > > What particular LimeSDR device do you have? Is it expensive? Can you share > > > a spare one for testing? Can you acquire access to hardware USB sniffer? > > > > The device I have here for testing isn't mine, so it would be difficult > > to mail it. It is the "LimeSDR Mini". I asked on the myriadrf.org Forum > > if the manufacturer could provide a free sample for testing. If that > > doesn't work, I could also ask friends, but eventually I want to get > > one (or two) for myself anyway. > > > > The LimeSDR and LimeSDR Mini seem to have better electrical/radio > > characteristics than other available devices. Compared to the Pluto > > SDR, the LimeSDR (Mini) comes with better frequency stability out of > > the box, i.e. doesn't need to be modded. The LimeSDR also works on > > lower frequency bands while the Pluto SDR does not. For my purposes > > (general experimenting, trying to do ham radio satellite operation, > > operation on different ham radio bands, etc.), the LimeSDR (Mini) seems > > to be an awesome device, which is why I would really like if it was > > supported by FreeBSD. > > I have HackRF-ONE SDR and did not observe such problems.. but also I > did not use it for quite time. > > If LimeSDR vendor could provide three sample devices for HPS, you, and > me, then we may offer a FreeBSD compatibility and testing in return.. > or at least know what the problem is.. cannot tell anything for HPS > though if he will have a free moment for such play :-) Well, I wouldn't say no to a free sample, but at the moment I have a LimeSDR Mini available here for me to use (but it's not mine, so I can't mail it around, and not sure how long I can keep it). So right now I don't really need one for testing things here on my end. But it would be nice if they could provide a free sample for one of you. I do not have access to a hardware USB sniffer (and not sure if I would be capable to operate it properly). In due time, I might be able to get access on a second device or likely buy one myself. They are not that expensive, but certainly more expensive than an RTLSDR. Price is between €150 and €200, like you discovered on Mouser's website linked below. > > Can you please elaborate why this LimeSDR is better than HackRF-One? I > may buy this one for testing if its worth the price :-) I don't know all technical specs for each of them, but when I experimented with the HackRF-One, I had a less clean signal (noise and/or mirror effects). I am not sure if this was due to the HackRF-One or because I operated the device improperly (I was new to ham radio at that stage). According to my information, the HackRF-One comes with USB2, which limits the data rate, and it only has an 8 bit ADC. It also cannot transmit and receive at the same time (half-duplex). The LimeSDR Mini has two antenna connectors and is full-duplex (though I haven't tested that yet). Its resolution is 12 Bit (instead of 8 Bit), so there should be less quantization noise and higher dynamic range. It is a USB 3.0 device, so the maximum data rate should be higher as well. There are some issues with the LimeSDR Mini when you want to transmit or receive on frequencies below 30.72 MHz. I had to set the RF frequency to a value higher than 30.72 MHz and call SoapySDRDevice_setFrequencyComponent(device, SOAPY_SDR_TX, 0, "BB", offset, NULL)) to add a further (negative) offset to reach the 11m and 10m bands. I think if you want to get even further down, you have to increase the bandwidth to reach further down from the center frequency, but I have no experiences with that (yet). > > Mouser seems to have a good price for the bare metal version: > https://pl.mouser.com/ProductDetail/Lime-Microsystems/cs-lime-05?qs=TiOZkKH1s2RNd%252B0xy7toNQ%3D%3D > > Best regards :-) > Tomek > > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info Regards, Jan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20200627173604.7f7b7777140e66dbad812fc7>