LimeSDR, GSM with omso

Projects RAN Forum
63

Thanks,

I was able to configure and get the command running

Lime Suite can see the limeSDR, however I get the following error:
Info: SSE3 support compiled in and supported by CPU
Info: SSE4.1 support compiled in and supported by CPU
Sun Jul 29 07:01:27 2018 DLGLOBAL <0002> telnet_interface.c:104 telnet at 127.0.0.1 4237
Sun Jul 29 07:01:27 2018 DLCTRL <0009> control_if.c:887 CTRL at 127.0.0.1 4236
Config Settings
Log Level… 3
Device args…
TRX Base Port… 5700
TRX Address… 127.0.0.1
GSM BTS Address… 127.0.0.1
Channels… 1
Tx Samples-per-Symbol… 4
Rx Samples-per-Symbol… 4
EDGE support… 0
Reference… 0
C0 Filler Table… 1
Multi-Carrier… 0
Tuning offset… 0
RSSI to dBm offset… 0
Swap channels… 0
Tx Antennas… ‘BAND1’
Rx Antennas… ‘LNAW’

Setting SCHED_RR priority(18)
Sun Jul 29 07:01:27 2018 DMAIN <0000> osmo-trx.cpp:379 [tid=140014553808704] Config: Setting SCHED_RR failed

I tried using the configuration file from the osmo-trx git url and the below file as well. both gave the same result.

https://osmocom.org/attachments/3219/limesdr.cfg

Any idea what am I doing wrong ?

64

I’ve not seen this before. Please post details to the appropriate Osmocom mailing list.

65

Will do , but just let me understand one thing

Now LimeSDR with it’s LimeSuite usually connects with the Osmo-trx with SoapySDR, SoapyUHD and UHD.

and this new method doesn’t require SoapySDR, SoapyUHD nor UHD. and the integration is direct from LimeSDR to the Osmo-trx , is that right ?

Also, is there a “recent” guide for using Osmo stack with LimeSDR ?

Thanks for the help

66

Correct.

No. As I said previously, the Osmocom wiki needs updating and any guides will refer to the old approach with Soapy/UHD. Direct LMS API integration is very recent. However, once you have a version of OsmoTRX that uses LMS API directly, everything else should be pretty much the same — with the caveat that the old osmo-nitb is now deprecated in favour of the new decomposed Osmocom architecture detailed here:

So you can follow old guides and take an osmo-nitb approach, but technically this is no longer supported and you should use OsmoBSC and OsmoHLR etc instead. The former should be fine for testing, but if you have problems with osmo-nitb you are now less likely to get support from the Osmocom community.

67

I did ask there,

Said the issue was a permission problem. using it with sudo fixed the issue.

will continue testing it with OpenBTS

1 Like
68

ok, so I tried the osmo-trx-lms and it worked great it’s much better than the UHD and soapy hassle !, however I have a very weird case here.

before I start the osmo and openbts service, I get the following spectrum from my other RTL-SDR

openbts 3
openbts 3.PNG1327×315 15.6 KB

then when I start the osmo-trx then openbts with it’s other services I get this weird signal for a while

openbts 1
openbts 1.PNG1326×328 30.5 KB

then I get an AM signal !! which is a channel that I can hear clearly, and can be seen from the below spectrum

openbts 2
openbts 2.PNG1323×336 23.2 KB

could I have a physical problem with my LimeSDR ?

@cswiger @andrewback

what you guys think ?

Thanks again

EDIT :

ok , looks like einstain was wrong. doing the same thing multiple times can produce different resutls, at least in my case.

I managed to get the GSM network with the same steps. I managed to have a device connect to it, but as soon as it connected I get this error, or if I leave the OpenBTS on for too long I get the same error

Wed Aug  1 07:57:39 2018 DMAIN <0000> Transceiver.cpp:376 [tid=140604044097280] chan 0 dumping STALE burst in TRX->USRP interface (0:1327750 vs 3:1327750), retrans=1
Wed Aug  1 07:57:40 2018 DMAIN <0000> Transceiver.cpp:1018 [tid=140604044064512] ClockInterface: sending IND CLOCK 1327797
Wed Aug  1 07:57:40 2018 DMAIN <0000> Transceiver.cpp:376 [tid=140604044097280] chan 0 dumping STALE burst in TRX->USRP interface (0:1327852 vs 3:1327853), retrans=1
Wed Aug  1 07:57:40 2018 DMAIN <0000> Transceiver.cpp:376 [tid=140604044097280] chan 0 dumping STALE burst in TRX->USRP interface (0:1327853 vs 3:1327853), retrans=1
Wed Aug  1 07:57:40 2018 DMAIN <0000> Transceiver.cpp:376 [tid=140604044097280] chan 0 dumping STALE burst in TRX->USRP interface (0:1327903 vs 3:1327904), retrans=1
Wed Aug  1 07:57:40 2018 DMAIN <0000> Transceiver.cpp:376 [tid=140604044097280] chan 0 dumping STALE burst in TRX->USRP interface (0:1327904 vs 3:1327904), retrans=1
Wed Aug  1 07:57:40 2018 DMAIN <0000> Transceiver.cpp:376 [tid=140604044097280] chan 0 dumping STALE burst in TRX->USRP interface (0:1327954 vs 7:1327955), retrans=1
Wed Aug  1 07:57:40 2018 DMAIN <0000> Transceiver.cpp:376 [tid=140604044097280] chan 0 dumping STALE burst in TRX->USRP interface (0:1327955 vs 7:1327955), retrans=1
Wed Aug  1 07:57:41 2018 DMAIN <0000> Transceiver.cpp:376 [tid=140604044097280] chan 0 dumping STALE burst in TRX->USRP interface (0:1328005 vs 3:1328007), retrans=1
Wed Aug  1 07:57:41 2018 DMAIN <0000> Transceiver.cpp:376 [tid=140604044097280] chan 0 dumping STALE burst in TRX->USRP interface (0:1328006 vs 3:1328007), retrans=1
Wed Aug  1 07:57:41 2018 DMAIN <0000> Transceiver.cpp:376 [tid=140604044097280] chan 0 dumping STALE burst in TRX->USRP interface (0:1328007 vs 3:1328007), retrans=1
Wed Aug  1 07:57:41 2018 DMAIN <0000> Transceiver.cpp:1018 [tid=140604044064512] ClockInterface: sending IND CLOCK 1328014
Wed Aug  1 07:57:42 2018 DMAIN <0000> Transceiver.cpp:1018 [tid=140604044064512] ClockInterface: sending IND CLOCK 1328231
Wed Aug  1 07:57:43 2018 DMAIN <0000> Transceiver.cpp:1018 [tid=140604044064512] ClockInterface: sending IND CLOCK 1328447
Wed Aug  1 07:57:44 2018 DMAIN <0000> Transceiver.cpp:1018 [tid=140604044064512] ClockInterface: sending IND CLOCK 1328664
Wed Aug  1 07:57:45 2018 DMAIN <0000> Transceiver.cpp:1018 [tid=140604044064512] ClockInterface: sending IND CLOCK 1328880
Wed Aug  1 07:57:46 2018 DMAIN <0000> Transceiver.cpp:1018 [tid=140604044064512] ClockInterface: sending IND CLOCK 1329097
Wed Aug  1 07:57:46 2018 DMAIN <0000> Transceiver.cpp:376 [tid=140604044097280] chan 0 dumping STALE burst in TRX->USRP interface (0:1329229 vs 3:1329229), retrans=1
Wed Aug  1 07:57:46 2018 DMAIN <0000> LMSDevice.cpp:515 [tid=140604044064512] chan 0 recv buffer of len 2500 expect 5877b48 got 587d6ec (587d6ec) diff=5ba4
Wed Aug  1 07:57:46 2018 DMAIN <0000> LMSDevice.cpp:515 [tid=140604044064512] chan 0 recv buffer of len 2500 expect 587850c got 587e0b0 (587e0b0) diff=5ba4
Wed Aug  1 07:57:46 2018 DMAIN <0000> LMSDevice.cpp:515 [tid=140604044064512] chan 0 recv buffer of len 2500 expect 5878ed0 got 587ea74 (587ea74) diff=5ba4
Wed Aug  1 07:57:46 2018 DMAIN <0000> LMSDevice.cpp:515 [tid=140604044064512] chan 0 recv buffer of len 2500 expect 5879894 got 587f438 (587f438) diff=5ba4
Wed Aug  1 07:57:46 2018 DMAIN <0000> LMSDevice.cpp:515 [tid=140604044064512] chan 0 recv buffer of len 2500 expect 587a258 got 587fdfc (587fdfc) diff=5ba4
Wed Aug  1 07:57:46 2018 DMAIN <0000> LMSDevice.cpp:515 [tid=140604044064512] chan 0 recv buffer of len 2500 expect 587ac1c got 5885f68 (5885f68) diff=b34c
Wed Aug  1 07:57:46 2018 DMAIN <0000> LMSDevice.cpp:515 [tid=140604044064512] chan 0 recv buffer of len 2500 expect 587b5e0 got 588692c (588692c) diff=b34c
Wed Aug  1 07:57:46 2018 DMAIN <0000> LMSDevice.cpp:515 [tid=140604044064512] chan 0 recv buffer of len 2500 expect 587bfa4 got 58872f0 (58872f0) diff=b34c
Wed Aug  1 07:57:46 2018 DMAIN <0000> LMSDevice.cpp:515 [tid=140604044064512] chan 0 recv buffer of len 2500 expect 587c968 got 5887cb4 (5887cb4) diff=b34c
Wed Aug  1 07:57:46 2018 DMAIN <0000> LMSDevice.cpp:515 [tid=140604044064512] chan 0 recv buffer of len 2500 expect 587d32c got 5888678 (5888678) diff=b34c
Wed Aug  1 07:57:46 2018 DMAIN <0000> LMSDevice.cpp:515 [tid=140604044064512] chan 0 recv buffer of len 2500 expect 587dcf0 got 588903c (588903c) diff=b34c
Wed Aug  1 07:57:46 2018 DMAIN <0000> LMSDevice.cpp:515 [tid=140604044064512] chan 0 recv buffer of len 2500 expect 587e6b4 got 5889a00 (5889a00) diff=b34c
Wed Aug  1 07:57:46 2018 DMAIN <0000> LMSDevice.cpp:515 [tid=140604044064512] chan 0 recv buffer of len 2500 expect 587f078 got 588a3c4 (588a3c4) diff=b34c
Wed Aug  1 07:57:46 2018 DMAIN <0000> LMSDevice.cpp:515 [tid=140604044064512] chan 0 recv buffer of len 2500 expect 587fa3c got 588ad88 (588ad88) diff=b34c
Wed Aug  1 07:57:46 2018 DMAIN <0000> LMSDevice.cpp:515 [tid=140604044064512] chan 0 recv buffer of len 2500 expect 5880400 got 588b74c (588b74c) diff=b34c

Looks like I have this BUG
https://osmocom.org/issues/3339

Not sure what to make of it though. it doesn’t say anything about what the issue is,

I guess this is another dead end !

69

Finally got around to playing with a LimeSDR-Mini - getting the 3339 bug however, same thing:

Wed Aug 15 13:13:01 2018 DMAIN <0000> LMSDevice.cpp:515 [tid=139715851286272] chan 0 recv buffer of len 2500 expect 44dd650 got 44f8dc4 (44f8dc4) diff=1b774

Have the mini plugged directly into a USB3 port on a notebook (no cable) with a fan on it to keep cool :slight_smile: The system actually works briefly, phone registers, I can see osmo-pcu packets then goes into the above.

That is in Transceiver52M/device/lms/LMSDevice.cpp line 515 is in LMSDevice::readSamples and this is failing:

if (timestamp != (TIMESTAMP)rx_metadata.timestamp)

There is actually a setting:

rx_metadata.waitForTimestamp = false;

but changing it to ‘true’ does not help. Latest osmo-trx (configure --without-uhd --with-lms) and latest LimeSuite and firmware Library version: v18.06.1-g81fb282e

70

Looks like a case of just getting behind delivering data - I took the ‘if’ conditional out so osmo-trx-lms prints all ‘got’ and ‘expect’ even if they are the same, and collected the timestamps around when it goes from diff=0 to non-zero, and there’s a gap of 10660 instead of 2500, and from then on all packets are from the future and thus out of sync.

image
image

71

Using the same software and configuration with the (non-mini) LimeSDR hardware - one that works for weeks with the UHD/Soapy driver setup - also gets the difference between the ‘expected’ timestamp and the ‘got’ timestamp error, using the latest osmo-trx-lms and LimeSuite.

Thu Aug 16 20:45:57 2018 DMAIN <0000> LMSDevice.cpp:516 [tid=139767917520640] chan 0 recv buffer of len 2500 expect 965346c got 9688c5c (9688c5c) diff=357f0
Thu Aug 16 20:45:57 2018 DMAIN <0000> LMSDevice.cpp:516 [tid=139767917520640] chan 0 recv buffer of len 2500 expect 9653e30 got 9689620 (9689620) diff=357f0
Thu Aug 16 20:45:57 2018 DMAIN <0000> LMSDevice.cpp:516 [tid=139767917520640] chan 0 recv buffer of len 2500 expect 96547f4 got 9689fe4 (9689fe4) diff=357f0
73

So going back to UHD/Soapy is the only option ?

I’ll try next week. is there any troubleshooting that you want me to test as well ?

74

I am just a consumer - the http://osmocom.org/issues/3339 ticket was updated to ‘urgent’ and there was some recent work on it:

commit 5cc8858d8f167b521e412883bb477e73f88280cb
Author: Harald Welte <laforge@gnumonks.org>
Date:   Fri Aug 17 19:55:38 2018 +0200

    logging: Introduce new "DDEV" category for device-specific code
    
    The DMAIN category got too overloaded.  Let's have the code in
    Transceive52M/device/* use the new DDEV category.

I tried a horrible hack (no idea what I’m doing) to re-sync the timestamp but then the buffers are out of sync and the phone still stops working. Also tested LimeSuite 17.12 with a non-mini and osmo-trx-lms but still get the timestamp issue.

75

Thanks for the reply

so I went back to UHD since this is not working at the moment, using the same old setup, I got the following output

baha@ubuntu:~$ osmo-trx -e -f -a ‘driver=lime,device=0’
opening configuration table from path :memory:
Info: SSE3 support compiled in and supported by CPU
Info: SSE4.1 support compiled in and supported by CPU
Config Settings
   Log Level............... NOTICE
   Device args............. ‘driver=lime,device=0’
   TRX Base Port........... 5700
   TRX Address............. 127.0.0.1
   GSM Core Address.........127.0.0.1
   Channels................ 1
   Tx Samples-per-Symbol... 4
   Rx Samples-per-Symbol... 4
   EDGE support............ Enabled
   Reference............... Internal
   C0 Filler Table......... Dummy bursts
   Multi-Carrier........... Disabled
   Tuning offset........... 0
   RSSI to dBm offset...... 0
   Swap channels........... 0

[INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800; UHD_3.11.0.1-16-g34fc6362
[INFO] [UHDSoapyDevice] Make connection: 'USB 3.0 (LimeSDR-USB)'
Estimated reference clock 30.7197 MHz
Selected reference clock 30.720 MHz
[INFO] [UHDSoapyDevice] Device name: LimeSDR-USB
[INFO] [UHDSoapyDevice] Reference: 30.72 MHz
[INFO] [UHDSoapyDevice] Init LMS7002M(0)
LMS7002M values cache at /home/baha/.limesuite/LMS7002M_cache_values.db
[INFO] [UHDSoapyDevice] Ver=7, Rev=1, Mask=1
[INFO] [UHDSoapyDevice] LMS7002M calibration values caching Enable
[INFO] [UHDSoapyDevice] SoapyLMS7::setFrequency(Rx, 0, BB, 0 MHz)
[INFO] [UHDSoapyDevice] SoapyLMS7::setFrequency(Tx, 0, BB, 0 MHz)
[INFO] [UHDSoapyDevice] SoapyLMS7::setAntenna(Rx, 0, LNAL)
[INFO] [UHDSoapyDevice] SoapyLMS7::setAntenna(Tx, 0, BAND1)
[INFO] [UHDSoapyDevice] SoapyLMS7::setGain(Rx, 0, PGA, 0 dB)
[INFO] [UHDSoapyDevice] SoapyLMS7::setGain(Rx, 0, LNA, 0 dB)
[INFO] [UHDSoapyDevice] SoapyLMS7::setGain(Rx, 0, TIA, 0 dB)
[INFO] [UHDSoapyDevice] SoapyLMS7::setGain(Tx, 0, PAD, -50 dB)
[INFO] [UHDSoapyDevice] SoapyLMS7::setSampleRate(Rx, 0, 10 MHz), CGEN=80 MHz, ADC=20 MHz, decim=2
ConnectionSTREAM::ConfigureFPGA_PLL(tx=20MHz, rx=10MHz)
[INFO] [UHDSoapyDevice] SoapyLMS7::setSampleRate(Tx, 0, 10 MHz), CGEN=80 MHz, DAC=20 MHz, interp=2
ConnectionSTREAM::ConfigureFPGA_PLL(tx=10MHz, rx=10MHz)
[INFO] [UHDSoapyDevice] SoapyLMS7::setBandwidth(Rx, 0, 30 MHz)
[INFO] [UHDSoapyDevice] Rx Filter calibrated from cache
[INFO] [UHDSoapyDevice] SoapyLMS7::setBandwidth(Tx, 0, 30 MHz)
[INFO] [UHDSoapyDevice] Tx Filter calibrated from cache
[INFO] [UHDSoapyDevice] SoapyLMS7::setFrequency(Rx, 1, BB, 0 MHz)
[INFO] [UHDSoapyDevice] SoapyLMS7::setFrequency(Tx, 1, BB, 0 MHz)
[INFO] [UHDSoapyDevice] SoapyLMS7::setAntenna(Rx, 1, LNAL)
[INFO] [UHDSoapyDevice] SoapyLMS7::setAntenna(Tx, 1, BAND1)
[INFO] [UHDSoapyDevice] SoapyLMS7::setGain(Rx, 1, PGA, 0 dB)
[INFO] [UHDSoapyDevice] SoapyLMS7::setGain(Rx, 1, LNA, 0 dB)
[INFO] [UHDSoapyDevice] SoapyLMS7::setGain(Rx, 1, TIA, 0 dB)
[INFO] [UHDSoapyDevice] SoapyLMS7::setGain(Tx, 1, PAD, -50 dB)
[INFO] [UHDSoapyDevice] SoapyLMS7::setSampleRate(Rx, 1, 10 MHz), CGEN=80 MHz, ADC=20 MHz, decim=2
ConnectionSTREAM::ConfigureFPGA_PLL(tx=20MHz, rx=10MHz)
[INFO] [UHDSoapyDevice] SoapyLMS7::setSampleRate(Tx, 1, 10 MHz), CGEN=80 MHz, DAC=20 MHz, interp=2
ConnectionSTREAM::ConfigureFPGA_PLL(tx=10MHz, rx=10MHz)
[INFO] [UHDSoapyDevice] SoapyLMS7::setBandwidth(Rx, 1, 30 MHz)
[INFO] [UHDSoapyDevice] Rx Filter calibrated from cache
[INFO] [UHDSoapyDevice] SoapyLMS7::setBandwidth(Tx, 1, 30 MHz)
[INFO] [UHDSoapyDevice] Tx Filter calibrated from cache
[INFO] [UHDSoapyDevice] SoapyLMS7::setSampleRate(Tx, 0, 1.08333 MHz), CGEN=8.66667 MHz, DAC=2.16667 MHz, interp=2
ConnectionSTREAM::ConfigureFPGA_PLL(tx=1.08333MHz, rx=1.08333MHz)
[INFO] [UHDSoapyDevice] SoapyLMS7::setSampleRate(Tx, 1, 1.08333 MHz), CGEN=8.66667 MHz, DAC=2.16667 MHz, interp=2
ConnectionSTREAM::ConfigureFPGA_PLL(tx=1.08333MHz, rx=1.08333MHz)
[INFO] [UHDSoapyDevice] SoapyLMS7::setSampleRate(Rx, 0, 1.08333 MHz), CGEN=8.66667 MHz, ADC=2.16667 MHz, decim=2
ConnectionSTREAM::ConfigureFPGA_PLL(tx=1.08333MHz, rx=1.08333MHz)
[INFO] [UHDSoapyDevice] SoapyLMS7::setSampleRate(Rx, 1, 1.08333 MHz), CGEN=8.66667 MHz, ADC=2.16667 MHz, decim=2
ConnectionSTREAM::ConfigureFPGA_PLL(tx=1.08333MHz, rx=1.08333MHz)
[INFO] [UHDSoapyDevice] SoapyLMS7::setBandwidth(Tx, 0, 5 MHz)
[INFO] [UHDSoapyDevice] Tx Filter calibrated from cache
[INFO] [UHDSoapyDevice] SoapyLMS7::setBandwidth(Rx, 0, 5 MHz)
[INFO] [UHDSoapyDevice] Rx Filter calibrated from cache
[INFO] [UHDSoapyDevice] SoapyLMS7::setGain(Tx, 0, PAD, -26 dB)
[INFO] [UHDSoapyDevice] SoapyLMS7::setGain(Rx, 0, LNA, 24.5 dB)
[INFO] [UHDSoapyDevice] SoapyLMS7::setGain(Rx, 0, TIA, 0 dB)
[INFO] [UHDSoapyDevice] SoapyLMS7::setGain(Rx, 0, PGA, 0 dB)
-- Transceiver active with 1 channel(s)
WARNING 140662157780736 22:28:53.1 Transceiver.cpp:820:driveControl: bogus command READFACTORY on control interface.
[INFO] [UHDSoapyDevice] SoapyLMS7::setFrequency(Rx, 0, RF, 900.2 MHz)
SetFrequency using cache values vco:2, csw:158
[WARNING] [UHDSoapyDevice] GetDC_IQ_Interp(900.2 MHz, ch=0, tx=0): no matches between [899.2, 901.2] MHz
[INFO] [UHDSoapyDevice] SoapyLMS7::setFrequency(Rx, 0, BB, -4.88281e-06 MHz)
[INFO] [UHDSoapyDevice] SoapyLMS7::setFrequency(Tx, 0, RF, 945.2 MHz)
SetFrequency using cache values vco:2, csw:215
[WARNING] [UHDSoapyDevice] GetDC_IQ_Interp(945.2 MHz, ch=0, tx=1): no matches between [944.2, 946.2] MHz
[INFO] [UHDSoapyDevice] SoapyLMS7::setFrequency(Tx, 0, BB, 4.88281e-06 MHz)
NOTICE 140662157780736 22:28:53.1 Transceiver.cpp:791:driveControl: Changing TSC from 0 to 2
[INFO] [UHDSoapyDevice] SoapyLMS7::setGain(Rx, 0, LNA, 10 dB)
[INFO] [UHDSoapyDevice] SoapyLMS7::setGain(Rx, 0, TIA, 0 dB)
[INFO] [UHDSoapyDevice] SoapyLMS7::setGain(Rx, 0, PGA, 0 dB)
NOTICE 140662157780736 22:28:53.1 Transceiver.cpp:244:start: Starting the transceiver
[WARNING] [UHD] Unable to set the thread priority. Performance may be negatively affected.
Please see the general application notes in the manual for instructions.
EnvironmentError: OSError: error in pthread_setschedparam
[WARNING] [UHD] Unable to set the thread priority. Performance may be negatively affected.
Please see the general application notes in the manual for instructions.
EnvironmentError: OSError: error in pthread_setschedparam
[WARNING] [UHD] Unable to set the thread priority. Performance may be negatively affected.
Please see the general application notes in the manual for instructions.
EnvironmentError: OSError: error in pthread_setschedparam
[WARNING] [UHD] Unable to set the thread priority. Performance may be negatively affected.
Please see the general application notes in the manual for instructions.
EnvironmentError: OSError: error in pthread_setschedparam
[INFO] [UHDSoapyDevice] SoapyLMS7::setGain(Tx, 0, PAD, -10 dB)
[WARNING] [UHD] Unable to set the thread priority. Performance may be negatively affected.
Please see the general application notes in the manual for instructions.
EnvironmentError: OSError: error in pthread_setschedparam
NOTICE 140662157747968 22:28:53.3 Transceiver.cpp:382:pushRadioVector: dumping STALE burst in TRX->USRP interface
NOTICE 140662157747968 22:28:53.3 Transceiver.cpp:382:pushRadioVector: dumping STALE burst in TRX->USRP interface
NOTICE 140662157747968 22:28:53.3 Transceiver.cpp:382:pushRadioVector: dumping STALE burst in TRX->USRP interface
NOTICE 140662157747968 22:28:53.3 Transceiver.cpp:382:pushRadioVector: dumping STALE burst in TRX->USRP interface
NOTICE 140662157747968 22:28:53.3 Transceiver.cpp:382:pushRadioVector: dumping STALE burst in TRX->USRP interface
NOTICE 140662157747968 22:28:53.3 Transceiver.cpp:382:pushRadioVector: dumping STALE burst in TRX->USRP interface
NOTICE 140662157747968 22:28:53.3 Transceiver.cpp:382:pushRadioVector: dumping STALE burst in TRX->USRP interface
NOTICE 140662157747968 22:28:53.3 Transceiver.cpp:382:pushRadioVector: dumping STALE burst in TRX->USRP interface
NOTICE 140662157747968 22:28:53.3 Transceiver.cpp:382:pushRadioVector: dumping STALE burst in TRX->USRP interface
NOTICE 140662157747968 22:28:53.3 Transceiver.cpp:382:pushRadioVector: dumping STALE burst in TRX->USRP interface
NOTICE 140662157747968 22:28:53.3 Transceiver.cpp:382:pushRadioVector: dumping STALE burst in TRX->USRP interface
NOTICE 140662157747968 22:28:53.3 Transceiver.cpp:382:pushRadioVector: dumping STALE burst in TRX->USRP interface
NOTICE 140662157747968 22:28:53.3 Transceiver.cpp:382:pushRadioVector: dumping STALE burst in TRX->USRP interface
NOTICE 140662157747968 22:28:53.3 Transceiver.cpp:382:pushRadioVector: dumping STALE burst in TRX->USRP interface
NOTICE 140662157747968 22:28:53.3 Transceiver.cpp:382:pushRadioVector: dumping STALE burst in TRX->USRP interface

I’ve searched for this error, they say make sure that sipauthserve is running, which is running in my case

I can see that the message is coming from line 372 in the file osmo-trx/Transceiver52M/Transceiver.cpp, but I cannot troubleshoot such issue because I don’t know how the script works

  for (size_t i = 0; i < mChans; i ++) {
state = &mStates[i];

while ((burst = mTxPriorityQueues[i].getStaleBurst(nowTime))) {
  LOG(NOTICE) << "chan " << i << " dumping STALE burst in TRX->USRP interface ("
              << burst->getTime() <<" vs " << nowTime << "), retrans=" << state->mRetrans;
  if (state->mRetrans)
    updateFillerTable(i, burst);
  delete burst;
}

TN = nowTime.TN();
modFN = nowTime.FN() % state->fillerModulus[TN];

bursts[i] = state->fillerTable[modFN][TN];
zeros[i] = state->chanType[TN] == NONE;

if ((burst = mTxPriorityQueues[i].getCurrentBurst(nowTime))) {
  bursts[i] = burst->getVector();

  if (state->mRetrans) {
    updateFillerTable(i, burst);
  } else {
    burst->setVector(NULL);
    filler[i] = false;
  }

  delete burst;
  } 
}

can anyone help ?

76

That is just a harmless NOTICE - I fired up the OpenBTS container and have a watch and a Blu phone camped on it and get the same thing:

NOTICE 140002343315200 22:57:27.4 Transceiver.cpp:382:pushRadioVector: dumping STALE burst in TRX->USRP interface
NOTICE 140002343315200 22:57:27.4 Transceiver.cpp:382:pushRadioVector: dumping STALE burst in TRX->USRP interface
NOTICE 140002343315200 22:57:27.4 Transceiver.cpp:382:pushRadioVector: dumping STALE burst in TRX->USRP interface
NOTICE 140002343315200 22:57:27.4 Transceiver.cpp:382:pushRadioVector: dumping STALE burst in TRX->USRP interface
NOTICE 140002343315200 22:57:27.4 Transceiver.cpp:382:pushRadioVector: dumping STALE burst in TRX->USRP interface
77

@cswiger, do you have a complete Base station setup (using OSMO stack or any other including configuration? I am currently stuck with the error below using OSMO stack and osmo-trx-lms with limesdr mini

Mon Aug 20 07:11:17 2018 DDEV <0001> LMSDevice.cpp:515 [tid=139690793129728] chan 0 recv buffer of len 2500 expect aad3b08 got ac659d0 (ac659d0) diff=191ec8
Mon Aug 20 07:11:17 2018 DDEV <0001> LMSDevice.cpp:515 [tid=139690793129728] chan 0 recv buffer of len 2500 expect aad44cc got ac66394 (ac66394) diff=191ec8
Mon Aug 20 07:11:17 2018 DDEV <0001> LMSDevice.cpp:515 [tid=139690793129728] chan 0 recv buffer of len 2500 expect aad4e90 got ac66d58 (ac66d58) diff=191ec8
Mon Aug 20 07:11:17 2018 DDEV <0001> LMSDevice.cpp:515 [tid=139690793129728] chan 0 recv buffer of len 2500 expect aad5854 got ac6771c (ac6771c) diff=191ec8

Thank you

78

this is odd, my phone can’t see the network , I’ll try again

79

chuck has these dockers

https://hub.docker.com/u/cswiger/

as for the issue you are having, it’s a bug https://osmocom.org/issues/3339

80

Thanks, will try it .

81

Testing with all LimeSDR-USB firmware,I found the firmware/gateware version: LimeSDR-USB_HW_1.3_r3.0.img and LimeSDR-USB_HW_1.4_r2.9.rbf from LimeSuite V.17.09.0 seems the most stable and having the best performance than any other releases or latest firmware when using with openbsc/osmo-nitb. Hope Myriad people will check this version and why the latest firmware is not good as this version for osmocom stacks also openbts. Using osmo-trx-lms also perform better when downgrade to this firmware.

Thanks.

2 Likes
82

does it keep going more than 10 minues ?

I get the error that I and cswiger talked about above

83

Yes, its very stable 24 hours.