Project

General

Profile

Feature #2919

Native LimeSDR support

Added by laforge 3 months ago. Updated 5 days ago.

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

0%

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 (1.46 MB) pespin, 05/09/2018 02:51 PM

3122

History

#1 Updated by laforge 2 months ago

  • Assignee changed from sysmocom to pespin

#2 Updated by pespin 26 days 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 18 days ago

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

#4 Updated by pespin 13 days 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 5 days ago

  • Priority changed from Normal to High

Also available in: Atom PDF