LimeNet micro install failing

I have tried to get my LimeNet micro up and running again. I have installed the latest Raspbian-12 (Bookworm) on the Raspberry Pi CM4s. Following the instructions the OSMOCOM repository has moved and is out of date, but found the new site.
Next I downloaded the LimeSuiteGUI. It starts up but gives me Transfer package failures.
Modules → Programming → automatic - fails.
Running LimeUtil --Update gives Update not supported. Am I doing something wrong?
What should I do to be able to use the board again?

Can you please run LimeQuickTest and post the output.

Hi Andrew,
Thanks for your response.
This is the result of the quick test after a fresh image and install

$ LimeQuickTest
[ TESTING STARTED ]
->Start time: Sun Jan 21 13:19:29 2024
->LimeSuite version: 23.11.0-23.11.0

[ Clock Network Test ]
->REF clock test
Test results: 23655; 42875; 62096 - PASSED
->ADF4002 Test
Result: 10 - PASSED
->VCTCXO test
Results : 5154092 (min); 5154115 (max) - PASSED
->Clock Network Test PASSED

[ FPGA EEPROM Test ]
->Read EEPROM
->Read data: 13 03 09 13 03 09 02
->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
->Testing using internal LMS7002M loopback
->Run Tests (TX_1-> LNA_H):
CH0 (SXR=1800.0MHz, SXT=1802.0MHz): Result:(-17.0 dBFS, 2.00 MHz) - PASSED
->Run Tests (TX_2 → LNA_L):
CH0 (SXR=750.0MHz, SXT=752.0MHz): Result:(-17.6 dBFS, 2.00 MHz) - PASSED
->RF Loopback Test PASSED

=> Board tests PASSED <=

Elapsed time: 3.81 seconds

That looks OK to me.
So maybe I found where I went wrong, I am used to starting LimeSuiteGui and the select Modules → Programming → Automatic.
This produces the error.

Performing LimeQuickTest gives this result:
$ LimeQuickTest
[ TESTING STARTED ]
->Start time: Sun Jan 21 13:23:02 2024
->LimeSuite version: 23.11.0-23.11.0

Cannot claim interface - Resource busy
Failed to open device
libusb: error [submit_bulk_transfer] submiturb failed, errno=16
libusb: error [submit_bulk_transfer] submiturb failed, errno=16
Failed to open. Device is busy.
Error: Unable to connect
Failed to connect

Possibly the FPGA in use is different and not compatible with LimeSuiteGui
After closing LimeSuiteGui I get the result from LimeQuickTest
$ LimeQuickTest
[ TESTING STARTED ]
->Start time: Sun Jan 21 13:37:04 2024
->LimeSuite version: 23.11.0-23.11.0

TransferPacket: Read failed (ret=0)
TransferPacket: Read failed (ret=0)
TransferPacket: Read failed (ret=0)
TransferPacket: Write failed (ret=0)
TransferPacket: Write failed (ret=0)
TransferPacket: Write failed (ret=0)
Board not supported
Failed to connect
libusb: warning [libusb_exit] device 1.5 still referenced
libusb: warning [libusb_exit] device 1.2 still referenced
libusb: warning [libusb_exit] device 1.1 still referenced
libusb: warning [libusb_exit] application left some devices open

After rebooting the device the same result comes up.
Does this make any sense?

Btw to get OSMOCOM installed alter the instruction on the Getting Started page to

sudo apt install extrepo
sudo extrepo enable osmocom-latest

That’s all, only if a Debian distribution like Raspbian is used.

So you run the test and it passes, all looks good.

Then you try to manually update via LimeSuiteGUI and then tests fail? Anyway, you shouldn’t be using LimeSuiteGUI to update. Instead use:

LimeUtil --update

This automates the process and as such is less error prone.

You shouldn’t need to use LimeSuiteGUI nowadays, which now is only really to be used for advanced debugging purposes. LimeQuickTest and LimeUtil automate the common tasks this was once used for.

Sorry, just saw you previously tried this. Can you run LimeQuickTest to verify that everything is as it should be, then run LimeUtil --update and post the full output here.

LimeQuickTest and LimeUtils now both work as expected. I won’t use LimeSuiteGUI anymore.
Only SoapySDR is giving me version (0.7 vs 0.8) problems now when I do an update. I just recompiled it manually but it is not solved.
I am hoping I can install SDRAngel when this is solved, but maybe Raspbian is not suited.

Here is the output:
$ LimeQuickTest
[ TESTING STARTED ]
->Start time: Mon Jan 22 22:01:56 2024
->LimeSuite version: 23.11.0-23.11.0

[ Clock Network Test ]
->REF clock test
Test results: 43848; 63070; 16755 - PASSED
->ADF4002 Test
Result: 10 - PASSED
->VCTCXO test
Results : 5154144 (min); 5154167 (max) - PASSED
->Clock Network Test PASSED

[ FPGA EEPROM Test ]
->Read EEPROM
->Read data: 13 03 09 13 03 09 02
->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
->Testing using internal LMS7002M loopback
->Run Tests (TX_1-> LNA_H):
CH0 (SXR=1800.0MHz, SXT=1802.0MHz): Result:(-19.6 dBFS, 2.00 MHz) - PASSED
->Run Tests (TX_2 → LNA_L):
CH0 (SXR=750.0MHz, SXT=752.0MHz): Result:(-19.2 dBFS, 2.00 MHz) - PASSED
->RF Loopback Test PASSED

=> Board tests PASSED <=

Elapsed time: 3.69 seconds


$ LimeUtil --update
Connected to [LimeNET-Micro [USB 2.0] 583A100F70B3]
–2024-01-22 22:03:14-- https://downloads.myriadrf.org/project/limesuite/23.11/LimeNET-Micro_lms7_trx_HW_2.1_r1.3.rpd
Resolving downloads.myriadrf.org (downloads.myriadrf.org)… 165.227.233.124, 2a03:b0c0:1:d0::eed:8001
Connecting to downloads.myriadrf.org (downloads.myriadrf.org)|165.227.233.124|:443… connected.
HTTP request sent, awaiting response… 200 OK
Length: 577536 (564K) [application/octet-stream]
Saving to: ‘/home/alle/.local/share/LimeSuite/images/23.11/LimeNET-Micro_lms7_trx_HW_2.1_r1.3.rpd’

/home/alle/.local/share/L 100%[===================================>] 564.00K --.-KB/s in 0.1s

2024-01-22 22:03:14 (5.74 MB/s) - ‘/home/alle/.local/share/LimeSuite/images/23.11/LimeNET-Micro_lms7_trx_HW_2.1_r1.3.rpd’ saved [577536/577536]

Existing gateware is same as update (1.3)

Programming update complete!

$ SoapySDRUtil --info
######################################################

Soapy SDR – the SDR abstraction library

######################################################

Lib Version: v0.8.1-3
API Version: v0.8.0
ABI Version: v0.8
Install root: /usr
Search path: /usr/lib/aarch64-linux-gnu/SoapySDR/modules0.8
Search path: /usr/local/lib/aarch64-linux-gnu/SoapySDR/modules0.8 (missing)
Search path: /usr/local/lib/SoapySDR/modules0.8 (missing)
Module found: /usr/lib/aarch64-linux-gnu/SoapySDR/modules0.8/libHackRFSupport.so (0.3.3)
Module found: /usr/lib/aarch64-linux-gnu/SoapySDR/modules0.8/libLMS7Support.so (22.09.1)
Module found: /usr/lib/aarch64-linux-gnu/SoapySDR/modules0.8/libRedPitaya.so (0.1.1)
Module found: /usr/lib/aarch64-linux-gnu/SoapySDR/modules0.8/libairspySupport.so (0.2.0)
Module found: /usr/lib/aarch64-linux-gnu/SoapySDR/modules0.8/libaudioSupport.so (0.1.1)
Module found: /usr/lib/aarch64-linux-gnu/SoapySDR/modules0.8/libbladeRFSupport.so (0.4.1)
Module found: /usr/lib/aarch64-linux-gnu/SoapySDR/modules0.8/libmiriSupport.so (0.2.5)
Module found: /usr/lib/aarch64-linux-gnu/SoapySDR/modules0.8/libosmosdrSupport.so (0.2.5)
Module found: /usr/lib/aarch64-linux-gnu/SoapySDR/modules0.8/libremoteSupport.so (0.5.2)
Module found: /usr/lib/aarch64-linux-gnu/SoapySDR/modules0.8/librfspaceSupport.so (0.2.5)
Module found: /usr/lib/aarch64-linux-gnu/SoapySDR/modules0.8/librtlsdrSupport.so
dlopen() failed: librtlsdr.so.0: cannot open shared object file: No such file or directory
Module found: /usr/lib/aarch64-linux-gnu/SoapySDR/modules0.8/libuhdSupport.so (0.4.1)
Available factories… airspy, audio, bladerf, hackrf, lime, miri, osmosdr, redpitaya, remote, rfspace, uhd
Available converters…

  • CF32 → [CF32, CS16, CS8, CU16, CU8]
  • CS16 → [CF32, CS16, CS8, CU16, CU8]
  • CS32 → [CS32]
  • CS8 → [CF32, CS16, CS8, CU16, CU8]
  • CU16 → [CF32, CS16, CS8]
  • CU8 → [CF32, CS16, CS8]
  • F32 → [F32, S16, S8, U16, U8]
  • S16 → [F32, S16, S8, U16, U8]
  • S32 → [S32]
  • S8 → [F32, S16, S8, U16, U8]
  • U16 → [F32, S16, S8]
  • U8 → [F32, S16, S8]

Running SDRangel on a Raspberry Pi CM3 might be a bit of a stretch to be honest. However, you could try using SoapyRemote, with SoapySDRServer running on the CM3 and then SDRangel on a remote computer which has more processing power. That way the CM3 would just be responsible for controlling the SDR and streaming samples, with DSP on the remote host.

Andrew,
Thanks for your help.
As you mentioned SDRAngel probably does not work on Raspbian. CubicSDR is working though.
A couple of years ago I purchased this LimeNet Micro because it looks to have some potent features which make it a good choice as a (portable) QO-100 terminal. I have a it now also running with GNSS controlling the clock.
As a matter of fact I have now a CM4s installed which is a bit better then the CM3. Getting the CM4s made me reinvestigate it.This CM4s is very difficult to obtain but have been very lucky obtaining one.

The questions remains if I can set the REF CLOCK OUT to a certain frequency and if so how to do this (use it as a GPS controlled clock for the LNA mixer)"

Anyway thanks for your help.

I did not know about this! I need to get hold of one for my LimeNET Micro :slight_smile:

Ah, nice idea. I’m not sure to be honest. Maybe @ricardas might know.

I ordered a different model that they could not deliver. So they offered me this one.

@ Reichelt Germany
Note: This product is intended for industrial customers only.
For order quantities of 200 pieces or more, please contact raspberry@reichelt.de

Got the whole stack working now thank you. The only thing that I am still struggling with is pyLMS7002Soapy which seems to be only for the mini and the USB.
Did you manage to get a CM4s, I noticed it is on the official site as well.