On MacOS Sierra SoapySDR generates warning messages about the USB bus when the SDR programs exit -
libusb: warning [darwin_abort_transfers] aborting all transactions on interface 1 pipe 4
libusb: warning [libusb_exit] application left some devices open
After exiting, the Lime Mini will not then start in another session unless you unplug it and plug it back in. With CubicSDR it gives and endless list of -
[ERROR] Rx calibration: MCU error 5 (Loopback signal weak: not connected/insufficient gain?)
starting readLoop()
SDRThread::readStream(): 2. SoapySDR read failed with code: -1
SDRThread::readStream(): 3.1 iqDataOutQueue output queue is full, discard processing of the batch…
SDRThread::readStream(): 2. SoapySDR read failed with code: -1
The software for Lime Mini seems to not close the USB bus correctly and it does not correctly reset Lime Mini when a new session starts.
CubicSDR and SDRConsole (windows 7) do not work correctly with a center frequency below about 30 Mhz. SDRConsole generates frequency spikes all over the place and CubicSDR gives an error message -
[ERROR] SetFrequencySXR(26.5795 MHz) - required VCO frequency is out of range [3800-7714] MHz
The programs that do tune below 30MHZ get CB stations, but strong signal around 13 and 15 MHZ do not come through.
Gnuradio with gr-limesuite can handle the Mini perfectly, opening and closing it repeatedly without needing to unplug. This only works if you exit gently, though (using SIGINT or pushing the red stop button in the grc interface), and not SIGQUIT; If you exit hard, by closing a GUI window directly, this failure does happen.
So, something in the gnuradio interface, which in fact uses the same LimeSuite libraries and calls (apparently) as the python interface, works fine. Someone knows something we don’t.
I have been combing the two code bases line by line, and haven’t found it, but it is clear that the problem is soluble/solved by someone on MacOSX.
OK, I need to update this, since I have a better understanding of the issue, but haven’t really found it yet. It turns out that the red button in grc is a hard exit, and prevents any destructors from running, which is, oddly, fine. The LimeSDR Mini is perfectly usable after this. So, in python, instead of allowing destructors to run in the normal way at exit, you call os._exit(0) instead of deleting the radio (or, specifically, stopping its streams), everything gets left in a perfectly resuable condition. This implies a problem with the destruction process of libusb connections on the MacOSX libusb flavor.
So, two points:
using os._exit(0) is a temporary workaround for SoapySDR/LimeSuite/python which saves a lot of unplugging and replugging of the LimeSDR Mini.
We need to take a hard look at how libusb is being called by LimeSuite, and what provokes the “aborting all transactions on interface 1 pipe 4” message. Apparently, it is fine to just cut off the connection hard (with SIGQUIT or SIGKILL), but not to stop it gently. This shouldn’t be too hard to find.
which indicates that there are devices which do not like whatever ClearPipeStallBothEnds() does, and have irreversible USB interface crashes as a result of it. It is not clear whether this call ever really helps anything. If you modify line 1889 of darwin-usb.c in the os/ directory of libusb, to be something like:
kresult = 0 && (*(cInterface->interface))->ClearPipeStallBothEnds(cInterface->interface, pipeRef);
(or just comment out the line and replace it with kresult=0; ), and rebuild libusb and link SoapyLMS7 to the new library, all is well. I don’t know if this is a definitive patch or not. It probably indicates a bug in the FTDI601 controller with respect to having its pipes cleared, but for now this seems OK. At least I suspect it to be mostly harmless.
The ClearPipeStallBothEnds appears at two places in darwin-usb.c. I put the fix into both places and It appears to have fix the problem. The warning messages still show up, but the lime-mini now works the next time you try to access it.
weird… I don’t get the warnings any more, having removed it in just that one place. I had followed the code through by inserting printf()s to see that it was exactly at the execution of this line that all the messages were emitted, which is why I commented it out. They weren’t coming from the other ClearPipeStallBothEnds() call.
