Project

General

Profile

Feature #2919

Native LimeSDR support

Added by laforge 9 months ago. Updated 5 months ago.

Status:
Resolved
Priority:
High
Assignee:
Category:
-
Target version:
-
Start date:
02/09/2018
Due date:
% Done:

100%

Spec Reference:

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.

IMG_20180509_145259875.jpg View IMG_20180509_145259875.jpg 1.46 MB pespin, 05/09/2018 02:51 PM
3122

Related issues

Related to OsmoTRX - Support #3316: osmo-trx-uhd fails after OpenBTS starts, LimeSDRClosed2018-06-04

Related to OsmoTRX - Bug #3346: osmo-trx-lms "R_CTL_LPF range limit reached"New2018-06-13

Related to OsmoTRX - Bug #3339: osmo-trx-lms "expect ... got ... diff ff0" error messageNew2018-06-13

Related to OsmoTRX - Bug #3340: osmo-trx-lms doesn't exit nor recover if device is unpluggedResolved2018-06-13

Related to OsmoTRX - Bug #3341: osmo-trx-lms RF Envelope FAIL on LimeSDR, but not on LimeSDR-miniStalled2018-06-13

Related to OsmoTRX - Bug #3342: osmo-trx-lms: low tx output power levelNew2018-06-13

Related to OsmoTRX - Bug #3347: osmo-trx-lms silently ignores rx_spsResolved2018-06-13

History

#1 Updated by laforge 8 months ago

  • Assignee changed from sysmocom to pespin

#2 Updated by pespin 7 months 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?

#3 Updated by pespin 7 months ago

  • Status changed from New to In Progress
  • Priority changed from Low to Normal

#4 Updated by pespin 6 months ago

3122

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.

#5 Updated by laforge 6 months ago

  • Priority changed from Normal to High

#6 Updated by pespin 6 months 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...

#7 Updated by pespin 6 months ago

#8 Updated by laforge 6 months 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)

#9 Updated by pespin 6 months 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

#10 Updated by pespin 6 months 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

#11 Updated by pespin 6 months 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.

#12 Updated by pespin 6 months 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."

#13 Updated by laforge 6 months 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

#14 Updated by pespin 5 months ago

  • Related to Support #3316: osmo-trx-uhd fails after OpenBTS starts, LimeSDR added

#15 Updated by pespin 5 months 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.

#16 Updated by laforge 5 months ago

  • Related to Bug #3346: osmo-trx-lms "R_CTL_LPF range limit reached" added

#17 Updated by laforge 5 months ago

  • Related to Bug #3339: osmo-trx-lms "expect ... got ... diff ff0" error message added

#18 Updated by laforge 5 months ago

  • Related to Bug #3340: osmo-trx-lms doesn't exit nor recover if device is unplugged added

#19 Updated by laforge 5 months ago

  • Related to Bug #3341: osmo-trx-lms RF Envelope FAIL on LimeSDR, but not on LimeSDR-mini added

#20 Updated by laforge 5 months ago

  • Related to Bug #3342: osmo-trx-lms: low tx output power level added

#21 Updated by laforge 5 months ago

  • Related to Bug #3347: osmo-trx-lms silently ignores rx_sps added

#22 Updated by laforge 5 months 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.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)