Feature #2919
closedNative LimeSDR support
Added by laforge about 6 years ago. Updated almost 6 years ago.
100%
Description
Currently, LimeSDR is only supported indirectly via UHD -> soapy-uhd -> soapy -> limesuite
It is difficult to debug the stability issues we're seeing in such a complex stack, so it would be great to have a native LimeSuite backend to avoid the complex stack.
This would also have related usability benefits, i.e. users don't need to install a whole bunch of dependencies and make sure they're configured accordingly.
Files
Related issues
Updated by pespin about 6 years ago
Work done so far can be found in osmo-trx branch pespin/lime: https://git.osmocom.org/osmo-trx/log/?h=pespin/lime
Current status:
osmo-trx-lms can be compiled and started. It sends and receives bursts, but there seem to be some clock-related issues.
in osmo-bts-trx, we can see the clock ind calculations showing a permanent drift of error_us=[-77XXX,-80XXXX], indicating that the clock at osmo-trx is going too fast. Output from ettus b200 running with UHD suggests that the limesdr clock is running around 4 times faster than it should.
Here's the sample osmo-bts-trx output when running osmo-trx-lms:
20180426143822498 DL1C <0006> /home/pespin/dev/sysmocom/git/osmo-bts/src/osmo-bts-trx/scheduler_trx.c:1630 TRX Clock Ind: elapsed_us= 207718, elapsed_fn=216, error_us=-789122 20180426143822498 DL1C <0006> /home/pespin/dev/sysmocom/git/osmo-bts/src/osmo-bts-trx/scheduler_trx.c:1643 GSM clock skew: old fn=385760, new fn=385932 20180426143822715 DTRX <000b> /home/pespin/dev/sysmocom/git/osmo-bts/src/osmo-bts-trx/trx_if.c:124 Clock indication: fn=386149 20180426143822715 DL1C <0006> /home/pespin/dev/sysmocom/git/osmo-bts/src/osmo-bts-trx/scheduler_trx.c:1630 TRX Clock Ind: elapsed_us= 217655, elapsed_fn=217, error_us=-783800 20180426143822715 DL1C <0006> /home/pespin/dev/sysmocom/git/osmo-bts/src/osmo-bts-trx/scheduler_trx.c:1643 GSM clock skew: old fn=385979, new fn=386149 20180426143822933 DTRX <000b> /home/pespin/dev/sysmocom/git/osmo-bts/src/osmo-bts-trx/trx_if.c:124 Clock indication: fn=386366 20180426143822933 DL1C <0006> /home/pespin/dev/sysmocom/git/osmo-bts/src/osmo-bts-trx/scheduler_trx.c:1630 TRX Clock Ind: elapsed_us= 217604, elapsed_fn=217, error_us=-783851 20180426143822933 DL1C <0006> /home/pespin/dev/sysmocom/git/osmo-bts/src/osmo-bts-trx/scheduler_trx.c:1643 GSM clock skew: old fn=386196, new fn=386366 20180426143823151 DTRX <000b> /home/pespin/dev/sysmocom/git/osmo-bts/src/osmo-bts-trx/trx_if.c:124 Clock indication: fn=386583 20180426143823151 DL1C <0006> /home/pespin/dev/sysmocom/git/osmo-bts/src/osmo-bts-trx/scheduler_trx.c:1630 TRX Clock Ind: elapsed_us= 218278, elapsed_fn=217, error_us=-783177 20180426143823151 DL1C <0006> /home/pespin/dev/sysmocom/git/osmo-bts/src/osmo-bts-trx/scheduler_trx.c:1643 GSM clock skew: old fn=386413, new fn=386583 20180426143823369 DTRX <000b> /home/pespin/dev/sysmocom/git/osmo-bts/src/osmo-bts-trx/trx_if.c:124 Clock indication: fn=386800 20180426143823369 DL1C <0006> /home/pespin/dev/sysmocom/git/osmo-bts/src/osmo-bts-trx/scheduler_trx.c:1630 TRX Clock Ind: elapsed_us= 217853, elapsed_fn=217, error_us=-783602 20180426143823369 DL1C <0006> /home/pespin/dev/sysmocom/git/osmo-bts/src/osmo-bts-trx/scheduler_trx.c:1643 GSM clock skew: old fn=386630, new fn=386800 20180426143823587 DTRX <000b> /home/pespin/dev/sysmocom/git/osmo-bts/src/osmo-bts-trx/trx_if.c:124 Clock indication: fn=387016 20180426143823587 DL1C <0006> /home/pespin/dev/sysmocom/git/osmo-bts/src/osmo-bts-trx/scheduler_trx.c:1630 TRX Clock Ind: elapsed_us= 218005, elapsed_fn=216, error_us=-778835 20180426143823587 DL1C <0006> /home/pespin/dev/sysmocom/git/osmo-bts/src/osmo-bts-trx/scheduler_trx.c:1643 GSM clock skew: old fn=386847, new fn=387016 20180426143823806 DTRX <000b> /home/pespin/dev/sysmocom/git/osmo-bts/src/osmo-bts-trx/trx_if.c:124 Clock indication: fn=387233
The clock indication is driven by the Receive path in osmo-trx as far as I can tell.
The timestamps received while calling LMS_RecvStream show a bit of strange behaviour as how I udnerstand it. To give an example, at start() time I added a flush_recv function like it's done for UHD, in order to sync the radioInterface class clock with the one from the device. It basically runs 10 times in a loop calling "MS_RecvStream(&m_lms_stream_rx0, &buffer0, len, &rx_metadata, 100);" with len=2500. I then print the received timestamp in hex after each call (no sleep in between), and that's what I get:
20180426144040908 DMAIN <0000> LMSDevice.cpp:326 [tid=140607662315264] Flush: Recv buffer of len 2500 at 0 20180426144040908 DMAIN <0000> LMSDevice.cpp:326 [tid=140607662315264] Flush: Recv buffer of len 2500 at 9c4 20180426144040909 DMAIN <0000> LMSDevice.cpp:326 [tid=140607662315264] Flush: Recv buffer of len 2500 at 1388 20180426144040909 DMAIN <0000> LMSDevice.cpp:326 [tid=140607662315264] Flush: Recv buffer of len 2500 at 4d1c 20180426144040909 DMAIN <0000> LMSDevice.cpp:326 [tid=140607662315264] Flush: Recv buffer of len 2500 at 56e0 20180426144040909 DMAIN <0000> LMSDevice.cpp:326 [tid=140607662315264] Flush: Recv buffer of len 2500 at 60a4 20180426144040910 DMAIN <0000> LMSDevice.cpp:326 [tid=140607662315264] Flush: Recv buffer of len 2500 at 6a68 20180426144040910 DMAIN <0000> LMSDevice.cpp:326 [tid=140607662315264] Flush: Recv buffer of len 2500 at 742c 20180426144040910 DMAIN <0000> LMSDevice.cpp:326 [tid=140607662315264] Flush: Recv buffer of len 2500 at 7df0 20180426144040910 DMAIN <0000> LMSDevice.cpp:326 [tid=140607662315264] Flush: Recv buffer of len 2500 at 87b4 20180426144040911 DMAIN <0000> LMSDevice.cpp:326 [tid=140607662315264] Flush: Recv buffer of len 2500 at 9178 20180426144040911 DMAIN <0000> LMSDevice.cpp:326 [tid=140607662315264] Flush: Recv buffer of len 2500 at 9b3c 20180426144040911 DMAIN <0000> LMSDevice.cpp:336 [tid=140607662315264] Initial timestamp 39740
So it can be seen that the first 2 ties I call the function, when I check it next the timestamp has been increased by the same amount of samples I asked for, ie 0x9c4=dec2500. However, On Forth call, it can be seen that the timestamp has increased for more than that value, 4d1c - 1388 = 14740 samples. Why this value?
Updated by pespin almost 6 years ago
- Status changed from New to In Progress
- Priority changed from Low to Normal
Work in progress in https://git.osmocom.org/osmo-trx/log/?h=laforge/lime
Updated by pespin almost 6 years ago
current status: Using the branch laforge/nightly and latest master LimeSuite, I can see my Network using a phone from time to time during short periods of time.
I attach a photo showing how the current signal looks like. It resembles the one shown with a sysmobts, but the analyzer is unable to detect it correctly as a proper GSM signal.
Updated by pespin almost 6 years ago
After a few days not playing with it and having applied https://github.com/myriadrf/LimeSuite/issues/184, I connected my LimeSDR and I was getting the error again. Updating the value to 5.3 MHz made it work again.
I then tried with a LimeSDR mini since steve|m said that it was working fine, but it's failing at LMS_Init() time:
Fri May 25 17:57:38 2018 DMAIN <0000> LMSDevice.cpp:46 [tid=140694445879168] creating LMS device... Fri May 25 17:57:38 2018 DMAIN <0000> LMSDevice.cpp:88 [tid=140694445879168] Opening LMS device.. Fri May 25 17:57:38 2018 DMAIN <0000> LMSDevice.cpp:94 [tid=140694445879168] Devices found: 1 Fri May 25 17:57:38 2018 DMAIN <0000> LMSDevice.cpp:104 [tid=140694445879168] Device [0]: LimeSDR Mini, media=USB 2.0, module=FT601, addr=24607:1027, serial=1D3548A9613216 Fri May 25 17:57:38 2018 DLMS <0001> LMSDevice.cpp:71 [tid=140694445879168] Claimed Interface Fri May 25 17:57:38 2018 DLMS <0001> LMSDevice.cpp:71 [tid=140694445879168] Estimated reference clock 40.0010 MHz Fri May 25 17:57:38 2018 DLMS <0001> LMSDevice.cpp:71 [tid=140694445879168] Reference clock 40.00 MHz Fri May 25 17:57:38 2018 DMAIN <0000> LMSDevice.cpp:115 [tid=140694445879168] Init LMS device Fri May 25 17:57:38 2018 DLMS <0001> LMSDevice.cpp:71 [tid=140694445879168] INT 121, FRAC 0, DIV_LOCH 1, EN_DIV2_DIVPROG 0 Fri May 25 17:57:38 2018 DLMS <0001> LMSDevice.cpp:71 [tid=140694445879168] VCO 5000.00 MHz, RefClk 40.00 MHz Fri May 25 17:57:38 2018 DLMS <0001> LMSDevice.cpp:71 [tid=140694445879168] ICT_VCO: 180 Fri May 25 17:57:38 2018 DLMS <0001> LMSDevice.cpp:71 [tid=140694445879168] csw=64 cmphl=0 Fri May 25 17:57:38 2018 DLMS <0001> LMSDevice.cpp:71 [tid=140694445879168] csw=96 cmphl=0 Fri May 25 17:57:38 2018 DLMS <0001> LMSDevice.cpp:71 [tid=140694445879168] csw=112 cmphl=0 Fri May 25 17:57:38 2018 DLMS <0001> LMSDevice.cpp:71 [tid=140694445879168] csw=120 cmphl=0 Fri May 25 17:57:38 2018 DLMS <0001> LMSDevice.cpp:71 [tid=140694445879168] csw=124 cmphl=0 Fri May 25 17:57:38 2018 DLMS <0001> LMSDevice.cpp:71 [tid=140694445879168] csw=126 cmphl=0 Fri May 25 17:57:38 2018 DLMS <0001> LMSDevice.cpp:71 [tid=140694445879168] csw=127 cmphl=0 Fri May 25 17:57:38 2018 DLMS <0001> LMSDevice.cpp:71 [tid=140694445879168] Failed to lock Fri May 25 17:57:38 2018 DLMS <0001> LMSDevice.cpp:71 [tid=140694445879168] csw=192 cmphl=0 Fri May 25 17:57:38 2018 DLMS <0001> LMSDevice.cpp:71 [tid=140694445879168] csw=224 cmphl=2 Fri May 25 17:57:38 2018 DLMS <0001> LMSDevice.cpp:71 [tid=140694445879168] csw=240 cmphl=3 Fri May 25 17:57:38 2018 DLMS <0001> LMSDevice.cpp:71 [tid=140694445879168] csw=232 cmphl=3 Fri May 25 17:57:38 2018 DLMS <0001> LMSDevice.cpp:71 [tid=140694445879168] csw=228 cmphl=2 Fri May 25 17:57:38 2018 DLMS <0001> LMSDevice.cpp:71 [tid=140694445879168] csw=230 cmphl=3 Fri May 25 17:57:38 2018 DLMS <0001> LMSDevice.cpp:71 [tid=140694445879168] csw=229 cmphl=2 Fri May 25 17:57:38 2018 DLMS <0001> LMSDevice.cpp:71 [tid=140694445879168] CSW: lowest=223, highest=229, selected=226 Fri May 25 17:57:38 2018 DLMS <0001> LMSDevice.cpp:71 [tid=140694445879168] cmphl=2 Fri May 25 17:57:38 2018 DLMS <0001> LMSDevice.cpp:71 [tid=140694445879168] VCOL : csw=226 tune ok Fri May 25 17:57:38 2018 DLMS <0001> LMSDevice.cpp:71 [tid=140694445879168] ICT_VCO: 180 Fri May 25 17:57:38 2018 DLMS <0001> LMSDevice.cpp:71 [tid=140694445879168] TuneVCO(SXT) - VCO too high Fri May 25 17:57:38 2018 DLMS <0001> LMSDevice.cpp:71 [tid=140694445879168] VCOM : csw=0 tune fail Fri May 25 17:57:38 2018 DLMS <0001> LMSDevice.cpp:71 [tid=140694445879168] ICT_VCO: 180 Fri May 25 17:57:38 2018 DLMS <0001> LMSDevice.cpp:71 [tid=140694445879168] TuneVCO(SXT) - VCO too high Fri May 25 17:57:38 2018 DLMS <0001> LMSDevice.cpp:71 [tid=140694445879168] VCOH : csw=0 tune fail Fri May 25 17:57:38 2018 DLMS <0001> LMSDevice.cpp:71 [tid=140694445879168] Selected: VCOL Fri May 25 17:57:38 2018 DLMS <0001> LMSDevice.cpp:71 [tid=140694445879168] INT 116, FRAC 0, DIV_LOCH 1, EN_DIV2_DIVPROG 0 Fri May 25 17:57:38 2018 DLMS <0001> LMSDevice.cpp:71 [tid=140694445879168] VCO 4800.00 MHz, RefClk 40.00 MHz Fri May 25 17:57:38 2018 DLMS <0001> LMSDevice.cpp:71 [tid=140694445879168] ICT_VCO: 180 Fri May 25 17:57:38 2018 DLMS <0001> LMSDevice.cpp:71 [tid=140694445879168] csw=64 cmphl=0 Fri May 25 17:57:38 2018 DLMS <0001> LMSDevice.cpp:71 [tid=140694445879168] csw=96 cmphl=0 Fri May 25 17:57:38 2018 DLMS <0001> LMSDevice.cpp:71 [tid=140694445879168] csw=112 cmphl=0 Fri May 25 17:57:38 2018 DLMS <0001> LMSDevice.cpp:71 [tid=140694445879168] csw=120 cmphl=0 Fri May 25 17:57:38 2018 DLMS <0001> LMSDevice.cpp:71 [tid=140694445879168] csw=124 cmphl=0 Fri May 25 17:57:38 2018 DLMS <0001> LMSDevice.cpp:71 [tid=140694445879168] csw=126 cmphl=0 Fri May 25 17:57:38 2018 DLMS <0001> LMSDevice.cpp:71 [tid=140694445879168] csw=127 cmphl=0 Fri May 25 17:57:38 2018 DLMS <0001> LMSDevice.cpp:71 [tid=140694445879168] Failed to lock Fri May 25 17:57:38 2018 DLMS <0001> LMSDevice.cpp:71 [tid=140694445879168] csw=192 cmphl=0 Fri May 25 17:57:38 2018 DLMS <0001> LMSDevice.cpp:71 [tid=140694445879168] csw=224 cmphl=3 Fri May 25 17:57:38 2018 DLMS <0001> LMSDevice.cpp:71 [tid=140694445879168] csw=208 cmphl=3 Fri May 25 17:57:38 2018 DLMS <0001> LMSDevice.cpp:71 [tid=140694445879168] csw=200 cmphl=2 Fri May 25 17:57:38 2018 DLMS <0001> LMSDevice.cpp:71 [tid=140694445879168] csw=204 cmphl=3 Fri May 25 17:57:38 2018 DLMS <0001> LMSDevice.cpp:71 [tid=140694445879168] csw=202 cmphl=2 Fri May 25 17:57:38 2018 DLMS <0001> LMSDevice.cpp:71 [tid=140694445879168] csw=203 cmphl=2 Fri May 25 17:57:38 2018 DLMS <0001> LMSDevice.cpp:71 [tid=140694445879168] CSW: lowest=199, highest=203, selected=201 Fri May 25 17:57:38 2018 DLMS <0001> LMSDevice.cpp:71 [tid=140694445879168] cmphl=2 Fri May 25 17:57:38 2018 DLMS <0001> LMSDevice.cpp:71 [tid=140694445879168] VCOL : csw=201 tune ok Fri May 25 17:57:38 2018 DLMS <0001> LMSDevice.cpp:71 [tid=140694445879168] ICT_VCO: 180 Fri May 25 17:57:38 2018 DLMS <0001> LMSDevice.cpp:71 [tid=140694445879168] TuneVCO(SXR) - VCO too high Fri May 25 17:57:38 2018 DLMS <0001> LMSDevice.cpp:71 [tid=140694445879168] VCOM : csw=0 tune fail Fri May 25 17:57:38 2018 DLMS <0001> LMSDevice.cpp:71 [tid=140694445879168] ICT_VCO: 180 Fri May 25 17:57:38 2018 DLMS <0001> LMSDevice.cpp:71 [tid=140694445879168] TuneVCO(SXR) - VCO too high Fri May 25 17:57:38 2018 DLMS <0001> LMSDevice.cpp:71 [tid=140694445879168] VCOH : csw=0 tune fail Fri May 25 17:57:38 2018 DLMS <0001> LMSDevice.cpp:71 [tid=140694445879168] Selected: VCOL Fri May 25 17:57:38 2018 DLMS <0001> LMSDevice.cpp:71 [tid=140694445879168] INT 57, FRAC 385875, DIV_OUTCH_CGEN 18 Fri May 25 17:57:38 2018 DLMS <0001> LMSDevice.cpp:71 [tid=140694445879168] VCO 2334.72 MHz, RefClk 40.00 MHz Fri May 25 17:57:38 2018 DLMS <0001> LMSDevice.cpp:71 [tid=140694445879168] csw 157; interval [154, 161] Fri May 25 17:57:38 2018 DLMS <0001> LMSDevice.cpp:71 [tid=140694445879168] INT 57, FRAC 385875, DIV_OUTCH_CGEN 18 Fri May 25 17:57:38 2018 DLMS <0001> LMSDevice.cpp:71 [tid=140694445879168] VCO 2334.72 MHz, RefClk 40.00 MHz Fri May 25 17:57:38 2018 DLMS <0001> LMSDevice.cpp:71 [tid=140694445879168] csw 157; interval [154, 161] Fri May 25 17:57:38 2018 DLMS <0001> LMSDevice.cpp:71 [tid=140694445879168] M=160, N=4, Fvco=614.400 MHz Fri May 25 17:57:42 2018 DLMS <0001> LMSDevice.cpp:71 [tid=140694445879168] SetPllFrequency: timeout, busy bit is still 1 Fri May 25 17:57:42 2018 DLMS <0001> LMSDevice.cpp:71 [tid=140694445879168] M=160, N=4, Fvco=614.400 MHz Fri May 25 17:57:42 2018 DMAIN <0000> LMSDevice.cpp:117 [tid=140694445879168] LMS_Init() failed Fri May 25 17:57:42 2018 DMAIN <0000> osmo-trx.cpp:446 [tid=140694445879168] Failed to create radio device Shutting down transceiver...
Updated by pespin almost 6 years ago
I added a new bug report in https://github.com/myriadrf/LimeSuite/issues/193
Updated by laforge almost 6 years ago
18:06 < pespin_> steve|m, LimeSDR mini is not working properly with latest osmo-trx-lms from
laforge/lime. It doesn't initialize properly. did you do any ad-hoc modification?
https://osmocom.org/issues/2919#note-6
21:31 < steve|m> pespin: no, I didn't make any modifications
21:31 < steve|m> and only TX was working correctly afair
21:32 <@LaF0rge> steve|m: I guess it might bould down to LimeSuite versions. I think pespin was tracking
LimeSuite master rather closely, which appears to be a bad idea.
21:34 < steve|m> my limesuite HEAD is 52d6129 (Remove LMS settings override on stream start)
Updated by pespin almost 6 years ago
I tried steve|m's same LimeSuite version and I'm still seeing the same issue.
We may have different firmware/hw versions? I posted mine in here: https://github.com/myriadrf/LimeSuite/issues/193#issuecomment-392562710
Updated by pespin almost 6 years ago
I tested with my LimeSDR mini at home and it can be initialized fine. I saw it fail twice in a row after the first successful a attempt with the same type of error.
This time, the LimeSDR Mini is of hardware version v1.1, while the one in the office was v1.0.
Using LimeSuiteGUI to connect to the device also shows a newer GW:
INFO: Connected Control port: LimeSDR-Mini FW:5 HW:0 Protocol:1 GW:1.24 Ref Clk: 40.00 MHz
TX looks better with LimeSDR Mini than with the regular LimeSDR, my mobile phone can see the BTS all the time.
RX is not working yet. However, when I order my mobile phone to register to the BTS, I see osmo-trx detecting the action with several of these messages, so it seems we are on the correct path:
Mon May 28 21:08:15 2018 DMAIN <0000> Transceiver.cpp:631 [tid=140024391735040] Clipping detected on received RACH or Normal Burst
Updated by pespin almost 6 years ago
The issue I'm seeing with the LimeSDR Mini v1.1 is actually an LMS_Open() issue. it seems to be time-related, as in trying to open the device to quickly after using it. Waiting a few more seconds seems to fix it.
Updated by pespin almost 6 years ago
I got an answer providing a how-to upgrade old versions of limeSDR: https://github.com/myriadrf/LimeSuite/issues/193#issuecomment-392666338, which involves buying a 9 Euro clone of the Altera usb programmer and, as far as I can tell, some Windows flasher program.
I also got this answer: "LimeSDR-Mini v1.0 is not supported. Pre-production boards are v1.1, just gateware version is older than 24."
Updated by laforge almost 6 years ago
Some quick updates, from what I understood:
- it seems the LimeSDR-mini sysmocom has received are v1.0 hardware, which apparently is no longer supported by current gateware/LimeSuite (see https://github.com/myriadrf/LimeSuite/issues/193#issuecomment-392689250)
- it seems that LimeSuite API tends to break frequently with the most frequent issue: Asking for ever-more-wide minimum LPF frequency, )see https://github.com/myriadrf/LimeSuite/issues/184) - even via UHD, not just when using LimeSuite directly
- LimeSDR-mini hardware v1.1 seems to have result in good Tx GSM waveform
- LimeSDR (classic/USB) seems to produce worse signal than LimeSDR mini v1.1 for yet-to-be-determined reasons
Updated by pespin almost 6 years ago
- Related to Support #3316: osmo-trx-uhd fails after OpenBTS starts, LimeSDR added
Updated by pespin almost 6 years ago
After latest changes in LimeSuite (using master), GW and osmo-trx (branch laforge/lime2), a phone can detect the network and the network detects the phone correctly and LU can be done.
Only tested so far with LimeSDR mini.
Updated by laforge almost 6 years ago
- Related to Bug #3346: osmo-trx-lms: Multi channel support: "R_CTL_LPF range limit reached" added
Updated by laforge almost 6 years ago
- Related to Bug #3339: osmo-trx-lms "expect ... got ... diff ff0" error message added
Updated by laforge almost 6 years ago
- Related to Bug #3340: osmo-trx-lms doesn't exit nor recover if device is unplugged added
Updated by laforge almost 6 years ago
- Related to Bug #3341: osmo-trx-lms RF Envelope FAIL on LimeSDR, but not on LimeSDR-mini added
Updated by laforge almost 6 years ago
- Related to Bug #3342: osmo-trx-lms: low tx output power level added
Updated by laforge almost 6 years ago
- Related to Bug #3347: osmo-trx-lms silently ignores rx_sps added
Updated by laforge almost 6 years ago
- Status changed from In Progress to Resolved
- % Done changed from 0 to 100
initial osmo-trx-lms support has been merged to master. However, plenty of known issues (and probably more unknown issues) remain, see the list of related issues here.
