Hello all,
When running a simple loopback test at 1250 MHz, the board has frequent dropouts and total failures on USB2 and has constant dropouts when powered over USB3.
The most likely cause for this seems to be USB power issues, but I am not yet able to test this. I will provide an update once I’ve verified that this is the issue.
USB3:
USB2:
Both tests are at the same center frequency - 3370 MHz. The GRC file is just a basic loopback test with a sample rate of around 20-40 MHz.
Is anyone else having this issue?
The LimeUtil version is here:
Version information:
Library version: v19.01.0-myriadrf1~xenial
Build timestamp: 2019-02-08
Interface version: v2019.1.0
Binary interface: 19.01-1
and this is just basic GNURadio Companion 3.7.10 on Ubuntu 16.04. I never see dropouts like this with my USRP.
Here are the automatic test results on USB3.
LimeQuickTest
[ TESTING STARTED ]
->Start time: Sun May 5 20:52:27 2019
->Device: LimeSDR Mini, media=USB 3.0, module=FT601, addr=xxxxx:xxxx, serial=xxxxxxxxxxxxxxxxxxxxxxx
Serial Number: 1D4xxxxxxxxxxxxxxxxx
[ Clock Network Test ]
->REF clock test
Test results: 35921; 49118; 62315 - PASSED
->VCTCXO test
Results : 6711064 (min); 6711222 (max) - PASSED
->Clock Network Test PASSED
[ FPGA EEPROM Test ]
->Read EEPROM
->Read data: xx xx xx xx xx xx xx
->FPGA EEPROM Test PASSED
[ LMS7002M Test ]
->Perform Registers Test
->External Reset line test
Reg 0x20: Write value 0xFFFD, Read value 0xFFFD
Reg 0x20: value after reset 0x0FFFF
->LMS7002M Test PASSED
[ RF Loopback Test ]
->Configure LMS
->Run Tests (TX_2 -> LNA_W):
CH0 (SXR=1000.0MHz, SXT=1005.0MHz): Result:(-14.0 dBFS, 5.00 MHz) - PASSED
->Run Tests (TX_1 -> LNA_H):
CH0 (SXR=2100.0MHz, SXT=2105.0MHz): Result:(-15.6 dBFS, 5.00 MHz) - PASSED
->RF Loopback Test PASSED
=> Board tests PASSED <=
Elapsed time: 2.43 seconds
"Calibrate All" option in LimeSuiteGUI
[20:51:02] INFO: Connected Control port: LimeSDR-Mini FW:6 HW:2 Protocol:1 GW:1.29 Ref Clk: 40.00 MHz
[20:51:07] ERROR: Tx Calibration: MCU error 4 (SXT tune failed)
This only occurs above 15-18 Msps, so I’m going to put this down as a front-end and ADC brownout problem. Will test with a 2A power supply to see if the issue persists.
@andrewback
I think this is going to need an RMA. I’ve tested this board with almost every configurable option and cannot resolve the intermittent tx/rx failures.
When I measured its current draw with an external 5V supply, the Mini only draws a maximum of 600 mA while transmitting (well within the USB3 spec). The current limit allowed for this testing was 2A and the voltage never went below 5.001 V. Nevertheless, any sample rate above 10 MHz (or 10 Msps) suffered from these dropouts.
The current draw over USB2 exceeds 500 mA, which explains the total brownouts on that bus. It does not explain the failures on USB3.
Incidentally - I’ve spoken to a few people who backed the crowdfunding campaign and have the same issue and more. Is there an avenue for them to RMA their LimeSDR Minis?
@Zack, could you take a look please and advise whether there is anything else to try or we should arrange an RMA.
I think the problem may be that you are just trying to use to high sample rate.
Have you tried it with other applications or other PC?
On USB2 maximum throughput is ~40MB/s and in case of loopback it is divided between TX and RX. gr-limesdr uses 4 bytes per sample, so the maximum sample rate you can achieve is ~5MSps(best case).
When connected via USB3 and both TX and RX are used, the maximum throughput of LimeSDR-Mini is up to 110-120 MB/s per direction. In my experience, it can also vary somewhat depending on USB controller and OS but I have never seen it higher than 120 MB/s. So calculating based purely on USB throughput the maximum sample rate could be ~27-30Msps. However, to avoid sample drops, low latency also has to be ensured, so PC hardware specs, OS, system load, process priorities, etc… come into play. Higher sample rate requires lower latency as buffers are filled faster. It may be that in your situation at higher sample rates, low latency is not ensured and samples are not sent or read from LimeSDR-Mini in time and are dropped.
Thanks for the clarification, @IgnasJ!
I do not think that is the problem. I’ve tested on multiple computers (on USB3) and have seen this issue when the USB3 bus is carrying as little as 20-25 Mbit/s in both directions. Obviously, it also occurs when sending/receiving higher sample rates, with the bus utilization around 110-120 Mbit/s (according to usbtop), substantially lower than the 120 MB/s you quoted. Ordinarily, I’d expect the LimeSuite or gr-limesdr to send “OOOO” or “UUUU” to indicate USB overflow or underflow, as the UHD package does, but I haven’t seen that.
It’s incredibly inconsistent; over a test period of 20 seconds, at a sample rate as low as 20 MHz, it will have a few seconds with 2-3 small dropouts and then the rest of the time will be 90% dropped.
