LimeSDR - self_test.ini strange behavior

I have a LimeSDR-USB installed on a Rasberry Pi 4 running under Raspbian 10 (Buster). Loading the self_test.ini in the LimeGUI everything works as expected. I have another LimeSDR-USB installed on a Raspberry PI 3 B+ also running Raspbian 10 (Buster). Loading the self_test.ini throws a failed to load file error with the helpful log entry : ERROR Read(64 Bytes) failed. The example.ini file loads successfully and displays as expected in the FFT viewer.

Any clues as to this behavior ? Please advise.

Might be that Raspberry PI3 does not supply enough power

The self_test.ini is 16.9 KB and the example.ini file is 16.5 KB.
Thus the assertion is that using USB power results in file load failure due to file size, specifically in this case somewhere above 16.5 KB file size ?

BTW any suggestions for source of 6-12V power supply with J20 Barrel connector ?

File size does not matter, what matters is what settings are being written to the chip, channel enables, frequencies, gains, depending on that the board can draw different amount of power.

A: Considering that the files being loaded are sample values for loopback testing wouldn’t the power level settings be low since power needed to drive the signal be minimal ?

B: Examination of the files reveals that the header and footer exactly are exactly the same in both instances. The other entries are (I assume) hex values indicating memory and/or register address with hex values denoting the memory and/or register content.

C: None of the documentation provides any identification of any specific purpose of any of the memory/registers. Is there any documentation that indicates any specific address mapping ?

D: I am trying to understand why two exactly same LimeSDR-USB devices operate differently on a Pi 3b+ versus Pi 4. More specifically why two observably similar files load with no problem on a Pi 4 but one loads ok and the other doesn’t on the Pi 3B+.


Pi 3B+ is USB 2.0

Pi 4 is USB 3.0.

LimeSDR USB is a USB 3.0 device and USB 2.0 provides just a little over half the power of USB 3.0, hence this behaviour is not at all surprising.