https://projects.osmocom.org/https://projects.osmocom.org/favicon.ico?16647414092018-03-17T23:46:09ZOpen Source Mobile CommunicationsOsmoTRX - Feature #2919: Native LimeSDR supporthttps://projects.osmocom.org/issues/2919?journal_id=83262018-03-17T23:46:09Zlaforge
<ul><li><strong>Assignee</strong> changed from <i>4368</i> to <i>pespin</i></li></ul> OsmoTRX - Feature #2919: Native LimeSDR supporthttps://projects.osmocom.org/issues/2919?journal_id=90392018-04-26T13:58:32Zpespin
<ul></ul><p>Work done so far can be found in osmo-trx branch pespin/lime: <a class="external" href="https://git.osmocom.org/osmo-trx/log/?h=pespin/lime">https://git.osmocom.org/osmo-trx/log/?h=pespin/lime</a></p>
<p>Current status:<br />osmo-trx-lms can be compiled and started. It sends and receives bursts, but there seem to be some clock-related issues.</p>
<p>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.</p>
<p>Here's the sample osmo-bts-trx output when running osmo-trx-lms:<br /><pre>
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
</pre></p>
<p>The clock indication is driven by the Receive path in osmo-trx as far as I can tell.</p>
<p>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_rx<sup><a href="#fn0">0</a></sup>, &buffer<sup><a href="#fn0">0</a></sup>, 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:<br /><pre>
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
</pre></p>
<p>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?</p> OsmoTRX - Feature #2919: Native LimeSDR supporthttps://projects.osmocom.org/issues/2919?journal_id=91402018-05-04T12:12:47Zpespin
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>In Progress</i></li><li><strong>Priority</strong> changed from <i>Low</i> to <i>Normal</i></li></ul><p>Work in progress in <a class="external" href="https://git.osmocom.org/osmo-trx/log/?h=laforge/lime">https://git.osmocom.org/osmo-trx/log/?h=laforge/lime</a></p> OsmoTRX - Feature #2919: Native LimeSDR supporthttps://projects.osmocom.org/issues/2919?journal_id=92592018-05-09T14:53:28Zpespin
<ul><li><strong>File</strong> <a href="/attachments/3122">IMG_20180509_145259875.jpg</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/3122/IMG_20180509_145259875.jpg">IMG_20180509_145259875.jpg</a> added</li></ul><p>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.</p>
<p>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.</p> OsmoTRX - Feature #2919: Native LimeSDR supporthttps://projects.osmocom.org/issues/2919?journal_id=93722018-05-17T11:42:15Zlaforge
<ul><li><strong>Priority</strong> changed from <i>Normal</i> to <i>High</i></li></ul> OsmoTRX - Feature #2919: Native LimeSDR supporthttps://projects.osmocom.org/issues/2919?journal_id=95012018-05-25T16:05:25Zpespin
<ul></ul><p>After a few days not playing with it and having applied <a class="external" href="https://github.com/myriadrf/LimeSuite/issues/184">https://github.com/myriadrf/LimeSuite/issues/184</a>, I connected my LimeSDR and I was getting the error again. Updating the value to 5.3 MHz made it work again.</p>
<p>I then tried with a LimeSDR mini since steve|m said that it was working fine, but it's failing at LMS_Init() time:<br /><pre>
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...
</pre></p> OsmoTRX - Feature #2919: Native LimeSDR supporthttps://projects.osmocom.org/issues/2919?journal_id=95032018-05-25T16:58:27Zpespin
<ul></ul><p>I added a new bug report in <a class="external" href="https://github.com/myriadrf/LimeSuite/issues/193">https://github.com/myriadrf/LimeSuite/issues/193</a></p> OsmoTRX - Feature #2919: Native LimeSDR supporthttps://projects.osmocom.org/issues/2919?journal_id=95122018-05-25T19:35:52Zlaforge
<ul></ul><pre>
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)
</pre> OsmoTRX - Feature #2919: Native LimeSDR supporthttps://projects.osmocom.org/issues/2919?journal_id=95602018-05-28T16:42:46Zpespin
<ul></ul><p>I tried steve|m's same LimeSuite version and I'm still seeing the same issue.</p>
<p>We may have different firmware/hw versions? I posted mine in here: <a class="external" href="https://github.com/myriadrf/LimeSuite/issues/193#issuecomment-392562710">https://github.com/myriadrf/LimeSuite/issues/193#issuecomment-392562710</a></p> OsmoTRX - Feature #2919: Native LimeSDR supporthttps://projects.osmocom.org/issues/2919?journal_id=95612018-05-28T19:17:18Zpespin
<ul></ul><p>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.</p>
<p>This time, the LimeSDR Mini is of hardware version v1.1, while the one in the office was v1.0.<br />Using LimeSuiteGUI to connect to the device also shows a newer GW:<br /><pre>
INFO: Connected Control port: LimeSDR-Mini FW:5 HW:0 Protocol:1 GW:1.24 Ref Clk: 40.00 MHz
</pre></p>
<p>TX looks better with LimeSDR Mini than with the regular LimeSDR, my mobile phone can see the BTS all the time.</p>
<p>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:<br /><pre>
Mon May 28 21:08:15 2018 DMAIN <0000> Transceiver.cpp:631 [tid=140024391735040] Clipping detected on received RACH or Normal Burst
</pre></p> OsmoTRX - Feature #2919: Native LimeSDR supporthttps://projects.osmocom.org/issues/2919?journal_id=95622018-05-28T19:19:37Zpespin
<ul></ul><p>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.</p> OsmoTRX - Feature #2919: Native LimeSDR supporthttps://projects.osmocom.org/issues/2919?journal_id=95662018-05-29T09:45:13Zpespin
<ul></ul><p>I got an answer providing a how-to upgrade old versions of limeSDR: <a class="external" href="https://github.com/myriadrf/LimeSuite/issues/193#issuecomment-392666338">https://github.com/myriadrf/LimeSuite/issues/193#issuecomment-392666338</a>, which involves buying a 9 Euro clone of the Altera usb programmer and, as far as I can tell, some Windows flasher program.</p>
<p>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."</p> OsmoTRX - Feature #2919: Native LimeSDR supporthttps://projects.osmocom.org/issues/2919?journal_id=95982018-05-29T22:21:03Zlaforge
<ul></ul><p>Some quick updates, from what I understood:</p>
<ul>
<li>it seems the LimeSDR-mini sysmocom has received are v1.0 hardware, which apparently is no longer supported by current gateware/LimeSuite (see <a class="external" href="https://github.com/myriadrf/LimeSuite/issues/193#issuecomment-392689250">https://github.com/myriadrf/LimeSuite/issues/193#issuecomment-392689250</a>)</li>
<li>it seems that LimeSuite API tends to break frequently with the most frequent issue: Asking for ever-more-wide minimum LPF frequency, )see <a class="external" href="https://github.com/myriadrf/LimeSuite/issues/184">https://github.com/myriadrf/LimeSuite/issues/184</a>) - even via UHD, not just when using LimeSuite directly</li>
<li>LimeSDR-mini hardware v1.1 seems to have result in good Tx GSM waveform</li>
<li>LimeSDR (classic/USB) seems to produce worse signal than LimeSDR mini v1.1 for yet-to-be-determined reasons</li>
</ul> OsmoTRX - Feature #2919: Native LimeSDR supporthttps://projects.osmocom.org/issues/2919?journal_id=98672018-06-12T16:30:42Zpespin
<ul><li><strong>Related to</strong> <i><a class="issue tracker-3 status-5 priority-2 priority-default closed" href="/issues/3316">Support #3316</a>: osmo-trx-uhd fails after OpenBTS starts, LimeSDR</i> added</li></ul> OsmoTRX - Feature #2919: Native LimeSDR supporthttps://projects.osmocom.org/issues/2919?journal_id=98762018-06-12T18:27:51Zpespin
<ul></ul><p>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.</p>
<p>Only tested so far with LimeSDR mini.</p> OsmoTRX - Feature #2919: Native LimeSDR supporthttps://projects.osmocom.org/issues/2919?journal_id=98982018-06-14T07:02:21Zlaforge
<ul><li><strong>Related to</strong> <i><a class="issue tracker-1 status-6 priority-2 priority-default closed" href="/issues/3346">Bug #3346</a>: osmo-trx-lms: Multi channel support: "R_CTL_LPF range limit reached"</i> added</li></ul> OsmoTRX - Feature #2919: Native LimeSDR supporthttps://projects.osmocom.org/issues/2919?journal_id=99002018-06-14T07:02:29Zlaforge
<ul><li><strong>Related to</strong> <i><a class="issue tracker-1 status-3 priority-4 priority-high2 closed" href="/issues/3339">Bug #3339</a>: osmo-trx-lms "expect ... got ... diff ff0" error message</i> added</li></ul> OsmoTRX - Feature #2919: Native LimeSDR supporthttps://projects.osmocom.org/issues/2919?journal_id=99022018-06-14T07:02:38Zlaforge
<ul><li><strong>Related to</strong> <i><a class="issue tracker-1 status-3 priority-3 priority-high3 closed" href="/issues/3340">Bug #3340</a>: osmo-trx-lms doesn't exit nor recover if device is unplugged</i> added</li></ul> OsmoTRX - Feature #2919: Native LimeSDR supporthttps://projects.osmocom.org/issues/2919?journal_id=99042018-06-14T07:02:43Zlaforge
<ul><li><strong>Related to</strong> <i><a class="issue tracker-1 status-7 priority-3 priority-high3" href="/issues/3341">Bug #3341</a>: osmo-trx-lms RF Envelope FAIL on LimeSDR, but not on LimeSDR-mini</i> added</li></ul> OsmoTRX - Feature #2919: Native LimeSDR supporthttps://projects.osmocom.org/issues/2919?journal_id=99062018-06-14T07:02:49Zlaforge
<ul><li><strong>Related to</strong> <i><a class="issue tracker-1 status-7 priority-2 priority-default" href="/issues/3342">Bug #3342</a>: osmo-trx-lms: low tx output power level</i> added</li></ul> OsmoTRX - Feature #2919: Native LimeSDR supporthttps://projects.osmocom.org/issues/2919?journal_id=99082018-06-14T07:03:08Zlaforge
<ul><li><strong>Related to</strong> <i><a class="issue tracker-1 status-3 priority-2 priority-default closed" href="/issues/3347">Bug #3347</a>: osmo-trx-lms silently ignores rx_sps</i> added</li></ul> OsmoTRX - Feature #2919: Native LimeSDR supporthttps://projects.osmocom.org/issues/2919?journal_id=99102018-06-14T07:04:03Zlaforge
<ul><li><strong>Status</strong> changed from <i>In Progress</i> to <i>Resolved</i></li><li><strong>% Done</strong> changed from <i>0</i> to <i>100</i></li></ul><p>initial <code>osmo-trx-lms</code> support has been merged to master. However, plenty of known issues (and probably more unknown issues) remain, see the list of related issues here.</p>