Updating Osmo-TRX from MyriadRF to main branch but problems occur

I’ve been trying make sure I’m using the most up to date version of osmo-trx but, I just can’t seem to get a working install. I was using the MyriadRF/Osmo-TRX fork and that worked fine with both OpenBTS and OsmoNITB. However, my understanding is that the LimeSDR functionality has since been merged into the main OsmoTRX branch and so there is no longer a need for the MyriadRF fork. I assumed some potential improvements has been made as well. I’ve installed the most current LimeSuite from git and the most current OsmoTRX from git with no apparent errors. However, I experience one of two outcomes when I try to use the osmo-trx -e -a “driver=lime,device=0” with OsmoNITB.

It gets stuck at this step and the indicator lights on the lime remain green, despite claiming the TRX is active…

sudo osmo-trx -e -a "driver=lime,device=0"
linux; GNU C++ version 5.4.0 20160609; Boost_105800; UHD_003.010.002.000-3-g122bfae1

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......... Disabled
   Multi-Carrier........... Disabled
   Tuning offset........... 0
   RSSI to dBm offset...... 0
   Swap channels........... 0

-- Make connection: 'LimeSDR-USB [USB 3.0] 9062000C42715'
-- Reference clock 30.720 MHz
-- Device name: LimeSDR-USB
-- Reference: 30.72 MHz
-- Init LMS7002M(0)
-- Ver=7, Rev=1, Mask=1
-- LMS7002M calibration values caching Disable
-- Transceiver active with 1 channel(s)

or

I run the same command with a continual cylcing of the TRX with lots of continual error messages like…

ERR 139886685017856 09:36:02.7 UHDDevice.cpp:1095:readSamples: Sample buffer: Requested timestamp is not valid
ERR 139886685017856 09:36:02.7 UHDDevice.cpp:1095:readSamples: Sample buffer: Requested timestamp is not valid
ERR 139886685017856 09:36:02.7 UHDDevice.cpp:1096:readSamples: timestamp = 2103920, length = 262144, time_start = 5832905, time_end = 5833040, data_start = 183641, data_end = 183776
ERR 139886685017856 09:36:02.7 UHDDevice.cpp:1096:readSamples: timestamp = 2103920, length = 262144, time_start = 5832905, time_end = 5833040, data_start = 183641, data_end = 183776
ALERT 139886685017856 09:36:02.7 radioInterface.cpp:374:pullBuffer: Receive error 0
ALERT 139886685017856 09:36:02.7 radioInterface.cpp:374:pullBuffer: Receive error 0
ERR 139886685017856 09:36:02.7 UHDDevice.cpp:1095:readSamples: Sample buffer: Requested timestamp is not valid
ERR 139886685017856 09:36:02.7 UHDDevice.cpp:1095:readSamples: Sample buffer: Requested timestamp is not valid
ERR 139886685017856 09:36:02.7 UHDDevice.cpp:1096:readSamples: timestamp = 2103920, length = 262144, time_start = 5832905, time_end = 5833040, data_start = 183641, data_end = 183776
ERR 139886685017856 09:36:02.7 UHDDevice.cpp:1096:readSamples: timestamp = 2103920, length = 262144, time_start = 5832905, time_end = 5833040, data_start = 183641, data_end = 183776
ALERT 139886685017856 09:36:02.7 radioInterface.cpp:374:pullBuffer: Receive error 0
ALERT 139886685017856 09:36:02.7 radioInterface.cpp:374:pullBuffer: Receive error 0
ERR 139886685017856 09:36:02.7 UHDDevice.cpp:1095:readSamples: Sample buffer: Requested timestamp is not valid

There may be something I’ve overlooked in the install. Maybe I have to recompile uhd, soapysdr, soapysdr-uhd?

Any help is appreciated, Thanks.

Ben

Hi,

as far as I know everything in MyriadRF/Osmo-TRX fork was merged back to upstream, so you should be using latest upstream master [1] instead of the fork.

Regarding your issues:

  • On the first one, as it stalls immediately after the “Transceiver active with 1 channel(s)”, it usually means osmo-trx and osmo-bts-trx didn’t start yet to talk and so osmo-bts-trx didn’t tell osmo-trx to start transmitting. You should be able to know more by looking at osmo-bts-trx logs, and also by using wireshark to see the UDP stream(s) between osmo-bts-trx and osmo-trx. The CTRL protocol is plain text on top of UDP, and you can find some documentation in osmo-trx.git (see README file).
  • Second issue: Not sure what’s the problem, I have been experiencing lots of clock related issues myself, still working on it to see if I can improve the situation, but I’d say it’s some issues in the lower-level layers under osmo-trx (soapy or limesuite) or maybe some clock accuracy limitations of limesdr, as I don’t experience right now this kind of issues when testing with non soapySDR but plain UHD device.

Feel free to report or ask for questions regarding osmo-* in Osmocom’s mailing list [2], as you have more chance of it being seen by osmocom developers/users. You can also join IRC channel #osmocom in freenode.

[1] https://git.osmocom.org/osmo-trx
[2] https://lists.osmocom.org/mailman/listinfo

I forgot to say, you may also want to look at the LimeSDR page in osmocom’s wiki for related information. Feel free to improve it (you will need write permissions, ask for them in IRC channel).
https://osmocom.org/projects/osmotrx/wiki/LimeSDR_Family

Also worth noticing, OsmoNITB binary has been deprecated and you should be using new split components instead (osmo-msc, osmo-mgw, osmo-hlr, osmo-bsc, etc.) as no new development is happening in osmo-nitb (openbsc.git).