Hello everyone.
I bought the lime SDR for the sole purpose of playing around with GSM networks. this has proved to be harder than I thought !
anyhow, I’m following this guide
but on an Ubuntu 16.04 ( with the required changes) and everything is good untill I reach the point of compiling the osmo-trx. so I changed the method of installation and installed it through the apt-get. and it was installed successfully.
but running the command gave me the following error
bahaeddin@ubuntu:~$ osmo-trx
osmo-trx: symbol lookup error: osmo-trx: undefined symbol: _ZN3uhd3msg16register_handlerERKPFvNS0_6type_tERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEE
and I have no idea how to troubleshoot this, anyone got a clue where to start ?
//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
Also, where can I learn how to start with the LimeSDR and use it in simple projects for learning purposes. I feel like I’m learning advanced linux more than working on the damn thing ! is there anyway to reduce the curve of this learning curve ?
Thanks and regards
Can you please try execute: “sudo ldconfig”?
That is likely due to libraries built from source confusing the installed package.
Fortunately osmocom source supports ‘make uninstall’
Sounds like you say the compile of osmo-trx failed so you did not get to the point of installing it?
the only string that resembles that I can find in all of the source (including libosmocore) is from osmo-trx itself: osmo-trx/Transceiver52M/UHDDevice.cpp: uhd::msg::register_handler(&uhd_msg_handler);
There is a bit of a wiki here on Osmocom gsm nitb we can keep up to date: https://wiki.myriadrf.org/Osmocom_GSM For one thing the myriadrf version of osmo-trx is no longer needed, the official osmo-trx supports LimeSDR probably better. There is a link in the wiki to it https://osmocom.org/projects/osmotrx/wiki/LimeSDR_Family with step by step.
Osmo GSM is really good, the linux call router (lcr) I had trouble getting to work, gprs basically works if you are patient - it does print a ‘FIXME This should not happen’ regularly so it must be pretty difficult to implement. Their Cisco style mgmt ports are great. I have a published set of config files for gsm/gprs: https://github.com/cswiger/osmocom_cfg1
1 Like
did that !
didn\t change a thing sadly
Thanks for the reply ,
do you suggest that I start from scratch with the supplied links ?
and do I really need to build it from source ? is there a way to install it from package ?
anyhow, will try a new virtual machine and start from scratch tomorrow morning and let you know
thanks again for your reply, it’s good to find some sort of support in this weird SDR world !
I’m not experience with the packages - not sure myself if it supports LimeSDR as built.
I just installed it and had no luck, does not even have the options (-s4 -b4) suggested at the end of their page ( https://osmocom.org/projects/osmotrx/wiki/LimeSDR_Family ):
# /usr/bin/osmo-trx -l DEBUG -s4
linux; GNU C++ version 5.4.0 20160609; Boost_105800; UHD_003.010.003.000-0-gef157678
Config Settings
Log Level............... DEBUG
Device args.............
TRX Base Port........... 5700
TRX Address............. 127.0.0.1
Channels................ 1
Samples-per-Symbol...... 4
External Reference...... Disabled
C0 Filler Table......... Disabled
Diversity............... Disabled
Tuning offset........... 0
RSSI to dBm offset...... 0
Swap channels........... 0
INFO 140616655845184 18:41:05.1 UHDDevice.cpp:716:open: Using discovered UHD device addr=1d50:6108,driver=lime,label=LimeSDR-USB [USB 3.0] 9060B00471F23,media=USB 3.0,module=FX3,name=LimeSDR-USB,serial=0009060B00471F23,type=soapy
-- Make connection: 'LimeSDR-USB [USB 3.0] 9060B00471F23'
-- Reference clock 30.72 MHz
-- Device name: LimeSDR-USB
-- Reference: 3.072e+07 MHz
-- LMS7002M calibration values caching Disable
terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc
Aborted (core dumped)
Whereas the built from source one from the above link works for me:
# osmo-trx -s4 -b4
linux; GNU C++ version 5.4.0 20160609; Boost_105800; UHD_003.010.003.000-0-gef157678
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.............
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............ Disabled
Reference............... Internal
C0 Filler Table......... Disabled
Multi-Carrier........... Disabled
Tuning offset........... 0
RSSI to dBm offset...... 0
Swap channels........... 0
Tx Antennas............. '<default>'
Rx Antennas............. '<default>'
-- Make connection: 'LimeSDR-USB [USB 3.0] 9060B00471F23'
-- Reference clock 30.72 MHz
-- Device name: LimeSDR-USB
-- Reference: 3.072e+07 MHz
-- LMS7002M calibration values caching Disable
-- Filter calibrated. Filter order-4th, filter bandwidth set to 5 MHz.Real pole 1st order filter set to 2.5 MHz. Preemphasis filter not active
-- TX LPF configured
-- RX LPF configured
-- Transceiver active with 1 channel(s)
hello
I did try your solution, and everything compiled well.
however the final result wasn’t as expected.
//////////////////////////////////////////////////////////////////////////////////////////////////////
bahaeddin@ubuntu:~/osmo/osmo-trx$ osmo-trx -s 4 -b 4
linux; GNU C++ version 5.4.0 20160609; Boost_105800; UHD_003.010.003.000-0-unknown
Info: SSE3 support compiled in and supported by CPU
Info: SSE4.1 support compiled in and supported by CPU
<0000> Logger.cpp:53 [tid=140351365162816] Cmd line option ‘s’ is deprecated and will be soon removed. Please use VTY cfg option instead. All cmd line options are already being overriden by VTY options if set.
<0000> Logger.cpp:53 [tid=140351365162816] Cmd line option ‘b’ is deprecated and will be soon removed. Please use VTY cfg option instead. All cmd line options are already being overriden by VTY options if set.
Failed to open config file: ‘osmo-trx.cfg’
////////////////////////////////////////////////////////////////////////////////////////
there is nothing in the documentation about ‘osmo-trx.cfg’, nor could I find it which the find command
any help ?
Wow, they have been busy on it - I just updated the source (git pull) and got a bunch of updates, including the new cfg file. Let me try it and get back to you - this is good news actually.
In short - every osmocom entity has a cfg file - I just put them all in /root/osmocom_cfg1/ or wherever I’m working on a configuration, and cd into that, then run a ‘screen’ terminal - you can also use a bunch of different windows - and run the entity so it finds the cfg file in the local directory, so you don’t need to supply a -c .
My collection of working config with gprs is at https://github.com/cswiger/osmocom_cfg1
and looks like we will be adding an osmo-trx.cfg to it as well 
1 Like
I had to rebuild libosmocore to get the new VTY port define.
Excellent - just use the example cfg file - which has these nice explicit items:
chan 0
tx-path BAND1
rx-path LNAW
with either:
osmo-trx -C <path to>/osmo-trx/doc/examples/osmo-trx-limesdr.cfg
or put it in your local directory and rename or link to: osmo-trx.cfg
Once you get this layer up and running you will be ready for the osmo-nitb and osmo-bts-trx depending on what has changed there. I’ll try the full upgrade tonight. They ARE in the process of breaking the handy nitb network in the box up into separate entities. Every entity will need it’s own cfg file setup so they can find each other.
I’m using a symlink : /root/osmocom_cfg1/osmo-trx.cfg → osmo-trx-limesdr.cfg
root@DellOptiPlex9010:~/osmocom_cfg1# osmo-trx
linux; GNU C++ version 5.4.0 20160609; Boost_105800; UHD_003.010.003.000-0-gef157678
Info: SSE3 support compiled in and supported by CPU
Info: SSE4.1 support compiled in and supported by CPU
Tue Apr 10 11:12:17 2018 DLGLOBAL <0001> telnet_interface.c:104 telnet at 127.0.0.1 4237
Tue Apr 10 11:12:17 2018 DLCTRL <0008> control_if.c:863 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 Core 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'
Tue Apr 10 11:12:18 2018 DMAIN <0000> Logger.cpp:53 [tid=139624975267648] Using discovered UHD device addr=1d50:6108,driver=lime,label=LimeSDR-USB [USB 3.0] 9060B00471F23,media=USB 3.0,module=FX3,name=LimeSDR-USB,serial=0009060B00471F23,type=soapy
-- Make connection: 'LimeSDR-USB [USB 3.0] 9060B00471F23'
-- Reference clock 30.72 MHz
-- Device name: LimeSDR-USB
-- Reference: 3.072e+07 MHz
-- LMS7002M calibration values caching Disable
Tue Apr 10 11:12:19 2018 DMAIN <0000> Logger.cpp:53 [tid=139624975267648] Antennas configured successfully
Tue Apr 10 11:12:19 2018 DMAIN <0000> Logger.cpp:53 [tid=139624975267648] Rates configured for LimeSDR 4 SPS
-- Filter calibrated. Filter order-4th, filter bandwidth set to 5 MHz.Real pole 1st order filter set to 2.5 MHz. Preemphasis filter not active
-- TX LPF configured
-- RX LPF configured
Tue Apr 10 11:12:20 2018 DMAIN <0000> Logger.cpp:53 [tid=139624975267648] Supported Tx gain range [-12; 64]
Tue Apr 10 11:12:20 2018 DMAIN <0000> Logger.cpp:53 [tid=139624975267648] Supported Rx gain range [-12; 61]
Tue Apr 10 11:12:20 2018 DMAIN <0000> Logger.cpp:53 [tid=139624975267648] Default setting Tx gain for channel 0 to 26
Tue Apr 10 11:12:20 2018 DMAIN <0000> Logger.cpp:53 [tid=139624975267648] Default setting Rx gain for channel 0 to 24.5
Tue Apr 10 11:12:20 2018 DMAIN <0000> Logger.cpp:53 [tid=139624975267648]
Single USRP:
Device: FX3
Mboard 0: LimeSDR-USB
RX Channel: 0
RX DSP: 0
RX Dboard: 0
RX Subdev: SoapyRF
RX Channel: 1
RX DSP: 1
RX Dboard: 1
RX Subdev: SoapyRF
TX Channel: 0
TX DSP: 0
TX Dboard: 0
TX Subdev: SoapyRF
TX Channel: 1
TX DSP: 1
TX Dboard: 1
TX Subdev: SoapyRF
-- Transceiver active with 1 channel(s)
Now you can telnet to the port 4237 and manage it Cisco style including writing changes back to the cfg file.
# telnet 0 4237
OsmoTRX> show trx
TRX Config:
Local IP: 127.0.0.1
Remote IP: 127.0.0.1
TRX Base Port: 5700
Device args: (null)
Tx Samples-per-Symbol: 4
Rx Samples-per-Symbol: 4
Test Mode: TSC: 0 (Disabled)
Test Mode: RACH Delay: 0 (Disabled)
C0 Filler Table: Disabled
Clock Reference: internal
Multi-Carrier: Disabled
Tuning offset: 0.000000
RSSI to dBm offset: 0.000000
Swap channels: Disabled
EDGE support: Disabled
Real Time Priority: 0 (Disabled)
Channels: 1
Channel 0:
Rx Path: LNAW
Tx Path: BAND1
Rut rue - I think the latest gateware breaks osmocom GSM - I rebuilt osmo-trx as above and started getting a failure:
Tue Apr 10 15:59:22 2018 DMAIN <0000> Logger.cpp:53 [tid=139904664057600] ClockInterface: sending IND CLOCK 1796274
Tue Apr 10 15:59:23 2018 DMAIN <0000> Logger.cpp:53 [tid=139904664057600] ClockInterface: sending IND CLOCK 1796491
...
Tue Apr 10 16:00:07 2018 DMAIN <0000> Logger.cpp:53 [tid=139904664090368] UHD: Device send timed out
Tue Apr 10 16:00:07 2018 DMAIN <0000> Logger.cpp:53 [tid=139904664090368] UHD: Device send timed out
Revert to an old copy of osmo-trx - same failure. Revert to LimeSuite 17.12 I was using (git checkout fe53178a3c74ce983ca8314c582c0547f723ec20) and update gateware and the above issue goes away. Went back to 18.03 and tested, forgetting to update gateware and it ran ok without that error. Update gateware and it fails.
Process is independant of osmo-trx version.
Install LimeSuite 18.03 (git checkout 7e955d7d7354d259b64991e2399097bfbbe37618) and gateware, rebuild SoapySDR/UHD and get the UHD: Device send timed out
Revert to LimeSuite 17.12 and gateware, rebuild Soapy and the same osmo-trx is running stable.
And just tested git checkout v18.04.0 - update gateware, rebuild Soapy -
same issue:
Tue Apr 10 16:23:55 2018 DMAIN <0000> Logger.cpp:53 [tid=140248190080768] ClockInterface: sending IND CLOCK 1975886
Tue Apr 10 16:23:56 2018 DMAIN <0000> Logger.cpp:53 [tid=140248190080768] ClockInterface: sending IND CLOCK 1976103
…
Tue Apr 10 16:24:28 2018 DMAIN <0000> Logger.cpp:53 [tid=140248190080768] ClockInterface: sending IND CLOCK 1983040
Tue Apr 10 16:24:29 2018 DMAIN <0000> Logger.cpp:53 [tid=140248190080768] ClockInterface: sending IND CLOCK 1983257
Tue Apr 10 16:24:30 2018 DMAIN <0000> Logger.cpp:53 [tid=140248190080768] ClockInterface: sending IND CLOCK 1983474
Tue Apr 10 16:24:30 2018 DMAIN <0000> Logger.cpp:53 [tid=140248024999680] L
Tue Apr 10 16:24:30 2018 DMAIN <0000> Logger.cpp:53 [tid=140248024999680] L
Tue Apr 10 16:24:31 2018 DMAIN <0000> Logger.cpp:53 [tid=140248190080768] ClockInterface: sending IND CLOCK 1983690
Tue Apr 10 16:24:32 2018 DMAIN <0000> Logger.cpp:53 [tid=140248190080768] ClockInterface: sending IND CLOCK 1983907
Tue Apr 10 16:24:33 2018 DMAIN <0000> Logger.cpp:53 [tid=140248190080768] ClockInterface: sending IND CLOCK 1984124
Tue Apr 10 16:24:34 2018 DMAIN <0000> Logger.cpp:53 [tid=140248190080768] ClockInterface: sending IND CLOCK 1984341
Tue Apr 10 16:24:35 2018 DMAIN <0000> Logger.cpp:53 [tid=140248190080768] ClockInterface: sending IND CLOCK 1984558
Tue Apr 10 16:24:36 2018 DMAIN <0000> Logger.cpp:53 [tid=140248190080768] ClockInterface: sending IND CLOCK 1984775
Tue Apr 10 16:24:37 2018 DMAIN <0000> Logger.cpp:53 [tid=140248190080768] ClockInterface: sending IND CLOCK 1984992
Tue Apr 10 16:24:38 2018 DMAIN <0000> Logger.cpp:53 [tid=140248190080768] ClockInterface: sending IND CLOCK 1985209
Tue Apr 10 16:24:39 2018 DMAIN <0000> Logger.cpp:53 [tid=140248190080768] ClockInterface: sending IND CLOCK 1985426
Tue Apr 10 16:24:40 2018 DMAIN <0000> Logger.cpp:53 [tid=140248190113536] UHD: Device send timed out
Tue Apr 10 16:24:40 2018 DMAIN <0000> Logger.cpp:53 [tid=140248190113536] UHD: Device send timed out
Tue Apr 10 16:24:40 2018 DMAIN <0000> Logger.cpp:53 [tid=140248190113536] UHD: Device send timed out
Lime firmware 17.12 definitely seems to work best for me too. Another suggestion as well for Osmo-NITB, I’ve had the best result running the binaries included in this git repo: https://github.com/fairwaves/osmo-combo
Specifically, the ones located in osmo-combo/bin/static-gprs/. You don’t have to use GPRS to start voice call support. Just disable it in the openbsc.cfg file. Keep in mind that to run these binaries you still need the dependencies, but it sounds like you already have those installed.
If it would prove useful, I could create a cellular-configs repo under the Myriad-RF GitHub organisation for keeping current copies of working configs for Osmocom and OAI etc. What do you think?
So this might be that the device name has changed from STREAM to FX3, in a bid to make things a bit more logical.
STREAM is the name of an FPGA development platform that used together with the LMS7002 EVB (RFIC on a big FMC board) provided the prototype for LimeSDR. Now we have multiple LimeSDR variants I think it made sense to identify them each by the host interface used.
OsmoTRX uses the device name to select parameters for things like hardware signal path delay/latency.
Hey guys,
thanks for the replies , however I’m confused, which versions of UHD, SoapySDR, LimeSuit, Osmo should I use.
Just to be clear, I usually use the package manager for UHD, SoapySDR and LimeSuit. but for Osmo, I use the package manager for “osmocom-nitb osmo-bts-trx” through http://download.opensuse.org/repositories/network:/osmocom:/nightly/xUbuntu_17.04/ ./"
and build for osmo-trx.
so I’m new to all this stuff, can someone give me version numbers or something, or maybe some sort of simplified instructions on how to get this thing to work !
Thanks and regards
Unfortunately it’s not simple and I don’t know of any packaged solutions.
I can only report the versions I’m using and they are all built from source, to get the updates from osmocom.
gprs seems less hangy, reading email and slowly loading web pages on an old zte-z990.
Note - the newer osmo-trx prints out helpful messages like ‘clipping detected in RACH or burst’ and had to turn rx-gain way down if in the same room:
osmo-bts-trx:
telnet 0 4241
phy 0
instance 0
osmotrx rx-gain 4
Sounds good - would be better as a community resource as I may not be keeping mine evergreen.
Actually - a really good starting point is get OpenBTS working for the experience before tackling the more involved osmocom stack. They have: a free O’Reilly pdf available from Range Networks that is an easy to read all-in-one tutorial and howto, and they have a working build script for Ubuntu 16.04. That’s the easiest way to get a GSM service up and running on LimeSDR. There is only ONE trick for that from the book - and that is switch the git branch to ‘master’ (for the 16.04 updates) instead of ‘5.0’ with their switchto.sh tool (that could have changed by now also).
http://openbts.org/site/wp-content/uploads/ebook/Getting_Started_with_OpenBTS_Range_Networks.pdf
The nice thing about OpenBTS is it uses the well known Asterisk PBX, so if you have a pstn gateway (I funded one, Diamondcard in 2006 and it still working to this day) you can add the extension and make calls to the outside world, via the LimeSDR and your $11 2g wristwatch.
There is another bug with OpenBTS even in ./switchto.sh master branch due to a change at UHD but we don’t even need to build Transceiver52M, using osmo-trx instead so just do this edit to not even build it, after ./switchto.sh master cd openbts and edit Makefile.am and change:
#if UHD or USRP1 defined, build Transceiver52M as well
if UHD
SUBDIRS = $(_SUBDIRS) \ ← delete the backslash
Transceiver52M ← delete this line
UHD = 1
else
if USRP1
SUBDIRS = $(_SUBDIRS) \ ← delete the backslash
Transceiver52M ← delete this line
USRP1 = 1
else
SUBDIRS = $(_SUBDIRS) \ ← delete the backslash
TransceiverRAD1 ← delete this line
endif
endif
and all of this:
if UHD
$(MAKE) -C ./Transceiver52M install
else
if USRP1
$(MAKE) -C ./Transceiver52M install
else
$(MAKE) -C ./TransceiverRAD1 install
endif
endif
Then ./build.sh B210 runs, installs packages and builds the debs per the book.
1 Like
Yeah, I started on OpenBTS too a few months ago too. The most difficult thing about OpenBTS for me was setting up the configuration with Asterisk, but I finally got a basic system working. I remember the automated dependency and compilation process on Ubuntu 16.04 taking a while, but no problems occurred. Sounds like Bahaeddin is using Ubuntu 17.04 though, so that may create some issues.
hey zodiac-tiger
what was the versions that you installed for openBTS, can I still use the installation guide in the book that cswiger shared ?
if you have any hints or tips and tricks let me know.
Regards
