Project

General

Profile

Actions

Feature #2919

closed

Native LimeSDR support

Added by laforge about 6 years ago. Updated almost 6 years 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.


Files

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

Related issues

Related to OsmoTRX - Support #3316: osmo-trx-uhd fails after OpenBTS starts, LimeSDRClosed06/04/2018

Actions
Related to OsmoTRX - Bug #3346: osmo-trx-lms: Multi channel support: "R_CTL_LPF range limit reached"Rejectedpespin06/13/2018

Actions
Related to OsmoTRX - Bug #3339: osmo-trx-lms "expect ... got ... diff ff0" error messageResolvedpespin06/13/2018

Actions
Related to OsmoTRX - Bug #3340: osmo-trx-lms doesn't exit nor recover if device is unpluggedResolvedpespin06/13/2018

Actions
Related to OsmoTRX - Bug #3341: osmo-trx-lms RF Envelope FAIL on LimeSDR, but not on LimeSDR-miniStalled06/13/2018

Actions
Related to OsmoTRX - Bug #3342: osmo-trx-lms: low tx output power levelStalledHoernchen06/13/2018

Actions
Related to OsmoTRX - Bug #3347: osmo-trx-lms silently ignores rx_spsResolvedlaforge06/13/2018

Actions
Actions #1

Updated by laforge about 6 years ago

  • Assignee changed from 4368 to pespin
Actions #2

Updated by pespin almost 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?

Actions #3

Updated by pespin almost 6 years ago

  • Status changed from New to In Progress
  • Priority changed from Low to Normal
Actions #4

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.

Actions #5

Updated by laforge almost 6 years ago

  • Priority changed from Normal to High
Actions #6

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...

Actions #7

Updated by pespin almost 6 years ago

Actions #8

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)
Actions #9

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

Actions #10

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

Actions #11

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.

Actions #12

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."

Actions #13

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
Actions #14

Updated by pespin almost 6 years ago

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

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.

Actions #16

Updated by laforge almost 6 years ago

  • Related to Bug #3346: osmo-trx-lms: Multi channel support: "R_CTL_LPF range limit reached" added
Actions #17

Updated by laforge almost 6 years ago

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

Updated by laforge almost 6 years ago

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

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
Actions #20

Updated by laforge almost 6 years ago

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

Updated by laforge almost 6 years ago

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

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.

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)