Hi - I am using a couple of LimeSDR Mini 2.4’s with a program incorporating LimeSuiteNG under MacOS for a NMR application.
I have things working quite well in general, however I am getting occasional messages “No samples or timeout” on reads; this does not happen a lot, but if a long run is occurring (like a couple of hours where I have 1000’s of reads), I will see these at random. I assume these are coming from the API itself as I have no messages of that sort in my program.
When these occur I see no signal (only noise) for a variable amount of time, after which everything seems fine. I am assuming that, due to the error message given, this is related to the Rx function and not what I am transmitting - it would be difficult or impossible to verify this is correct by looking at a scope for the entire run. I am using the default timeout for the StreamRx function.
I understand a lot of information would be needed to fully diagnose this, but I am wondering, in general, is this likely to be a usb issue? Are there any other ideas as to what could cause this? Is it recommended to try a timeout value other than what is set by default?
Correct, it is an error log message from StreamRx(), indicating that there was no data available in the specified timeout period.
If those error messages were encountered, then it’s up to the host software how to deal with it. If no samples were returned, does the host handle it appropriately, or does it keep going with the undefined data buffer (which most likely would appear as random noise).
The default timeout is 1 second, which is plenty, unless the expected read data amount requires more to be produced. It’s most likely a bug in the LimeSuiteNG with the “libusb” implementation, if the CPU load gets to 100% there seems to be a possibility that the USB processing gets messed up.
Thank you for getting back to me - I didn’t realize the default timeout is 1 second and indeed that is very long. I am handling the situation where no samples are delivered by copying only the number of samples delivered into a separate buffer, so I am not accessing an undefined buffer that was sent to the function.
If this is resulting from a 1 second timeout I can see how that would have a serious effect on how the program works and I will need to look into and account for that - the effect of a 1 second delay in the middle of a run like that is probably why the effect seems to continue on for awhile.
I also think power supply and temperature issues are always good to suggest. In this case I am reading the chip temperature of each device at the start and end of the run and they are almost identical at each end. The power supply and cables are definitely worth looking into.
