OpenBSC

openbsc@lists.osmocom.org

11 participants
4278 discussions

osmo-bts-trx: "No clock from osmo-trx"
by Neels Hofmeyr 17 Jun '17

17 Jun '17

Hi Tom and others, in our testing setup, we have sporadic failures (~2 out of 10 times) with: DOML <0001> bts.c:208 Shutting down BTS 0, Reason No clock from osmo-trx What would be possible reasons for this failure, and how can we go about fixing it? Some more logging around it: 20170614032014399 DRSL <0000> rsl.c:2333 (bts=0,trx=0,ts=0,ss=2) Fwd RLL msg EST_IND from LAPDm to A-bis 20170614032018533 DL1C <0006> scheduler_trx.c:1451 PC clock skew: elapsed uS 4136730 20170614032018533 DOML <0001> bts.c:208 Shutting down BTS 0, Reason No clock from osmo-trx 20170614032018533 DL1C <0006> scheduler.c:240 Exit scheduler for trx=0 20170614032018533 DL1C <0006> scheduler.c:216 Init scheduler for trx=0 20170614032018533 DOML <0001> oml.c:280 OC=RADIO-CARRIER INST=(00,00,ff) AVAIL STATE OK -> Off line [...] Shutdown timer expired (We're using an external 10MHz OCXO timing source) It appears there's four seconds of nothing from osmo-trx? Most curious is that the next run will be completely fine, until some time later we get this same failure. We wait until osmo-trx logs -- Transceiver active with 1 channel(s) and then we "immediately" or up to a second later launch osmo-bts-trx. Would it help to give it more grace time?? Thanks! ~N

4 4

Re: osmo-bts-trx: "No clock from osmo-trx"
by Vadim Yanitskiy 15 Jun '17

15 Jun '17

Neels, > What would be possible reasons for this failure, > and how can we go about fixing it? As I know, this happens when scheduler detects, that system time is changed. For example, it might be caused by NTP time correction. - Do you have NTP enabled? - Have you specified process realtime priority? With best regards, Vadim Yanitskiy.

3 3

osmo-gsm-tester - voice call
by Sudhanthiradasan R 15 Jun '17

15 Jun '17

Hi, Is it possible to perform end-to-end testing like voice calls, sms etc with current osmo-gsm-tester version. I do not see any suites for voice call testing in the suites directory. Thanks Sudhanthiradasan R ::DISCLAIMER:: ---------------------------------------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. ----------------------------------------------------------------------------------------------------------------------------------------------------

3 4

Re: New Defects reported by Coverity Scan for Osmocom
by Neels Hofmeyr 13 Jun '17

13 Jun '17

Max, you fixed the coverity issue in https://gerrit.osmocom.org/2885, but a few lines above that, there is another +1 that seems one +1 too many: if (m_id_len > MAX_BTS_FEATURES/8 + 1) { LOGP(DNM, LOGL_NOTICE, "BTS%u Get Attributes Response: feature vector is truncated to %u bytes\n", bts->nr, MAX_BTS_FEATURES/8); m_id_len = MAX_BTS_FEATURES/8; } I can't claim I understand why this size check is necessary on top of the other one, but certainly "> MAX_BTS_FEATURES/8 + 1" doesn't match setting "m_id_len = MAX_BTS_FEATURES/8". ~N

1 0

Voice audio testing in osmo-gsm-tester
by Harald Welte 12 Jun '17

12 Jun '17

Dear all, osmo-gsm-tester is currently capable of setting up an entire network with one or more BTSs, Modems, NITB, etc. and test signaling + SMS. Voice testing has always been on the wishlist, but further down on the TODO list. One issue here is that a) many modems don't do voice at all (data-only modems for laptops) b) some modems expose voice only as analog audio (difficult to interface, would require custom hardware next to the modem, e.g. using USB soundcard, calibrate the levels, ...) c) some modems expose the voice as PCM bus. Similarly, would require some external codec chip and/or USB soundcard or the like, plus a custom circuit d) some modems expose voice as "GSM codec frames over UART" or other highty proprietary formats e) some modems expose voice as USB audio device. Most convenient, but only found in some Qualcomm LE based devices such as Sierra Wireless or Quectel. Over the weekend I was thinking of yet another method to make this much simpler: Every phone is supposed to include a voice loop-back mode. In this mode, the phone siply loops back all voice frames received in the downlink and sends them back in the uplink. This functionality is mandatory by the spec, and used to test the receiver performance of the phone during development, manufacturing and service. IT is specified in 3GPP TS 44.014 (http://www.etsi.org/deliver/etsi_ts/144000_144099/144014/14.00.00_60/ts_144…) which used to be GSM TS 04.04 (http://www.etsi.org/deliver/etsi_ts/101200_101299/101293/08.06.00_60/ts_101…) before. The idea is that one puts a special "Test SIM" (as specified in TS 51.010-1 Annex 4, where EF.AD first byte == 0x80 is the criteria in this context) into the phone, and then sends some specific commands on Layer3 to activate the loop. So if we can activate that loop-back functionality from the Osmocom stack, we could test if we get back the same voice data that we send in downlink (minus some occasional bit error, but those should be super low given we're operating omso-gsm-tester over coaxial cabling between MS and BTS). Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

4 8

Re: vty talloc report
by Vadim Yanitskiy 11 Jun '17

11 Jun '17

Hi Neels, > If you submitted a patch for it I would probably +vote it. Not yet. > I guess it would actually be a whole bunch of patches, > a common part in libosmocore and using it in each osmo* program? Probably, it would be a whole bunch of patches for osmo* programs only. I was wondering about modifying libosmovty to enable a new VTY command in all projects, like Harald did in osmo-fsm implementation. But in case of FSM, all state machines are being registered before use, so libosmovty "knows" about them. What is impossible in case of talloc contexts right now. Of course, we can write a new function and register every root talloc context using it. What about that? Regarding to the commands to add, I think show ctx all - Show list of all registered talloc contexts. show ctx NAME - Find specified context and call talloc_report_full. With best regards, Vadim Yanitskiy. 2017-06-01 4:34 GMT+07:00 Neels Hofmeyr <nhofmeyr(a)sysmocom.de>: > re "what do you guys think about having a special VTY command to get a > talloc report?" > > If you submitted a patch for it I would probably +vote it. I guess it would > actually be a whole bunch of patches, a common part in libosmocore and > using it > in each osmo* program? > > ~N > >

2 2

Proposal: Usage of stow in jenkins build scripts
by Alexander Huemer 11 Jun '17

11 Jun '17

Hi, The osmocom software that I do not install via apt but build myself gets installed in $HOME/usr and I do things like: export PATH="${PATH}:${HOME}/usr/bin" export LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:${HOME}/usr/lib" export PKG_CONFIG_PATH=$HOME/usr/lib/pkgconfig MANPATH="${MANPATH}:${HOME}/usr/man" Therefore I don't have to install to a destination outside my home directory which in turn means I can avoid some sudo calls. But that actually does not matter so much, you can mentally substitute $HOME with '/' and append '/local' in the following if you want. I don't install to $HOME/usr directly but use stow for 'managing' the installations, so an installation goes like this: $ mkdir -p $HOME/src/telco/osmo/libosmo-abis $ cd $HOME/src/telco/osmo/libosmo-abis $ git clone git://git.osmocom.org/libosmo-abis $ autoreconf -i $ ./configure --prefix=$HOME/usr/stow/libosmo-abis $ make $ make install $ STOW_DIR=$HOME/usr/stow stow libosmo-abis This has two advantages: * Good visibility of what is installed by a package. $ tree $HOME/usr/stow/libosmocore * Possibility of uninstalling a package even if the Makefile is not present. For me those two advantages outweigh the small additional effort of using stow. Because of that workflow I sometimes run into situations in which make runs fail because either header files are not found during compilation or libraries are not found during linking. The reason is that autotools variables pointing to pkgconfig supplied directories point to a destination under the prefix path with which configure was called. If a dependency was not mentioned in a Makefile.am the required files are not found because the other dependencies are in other directories. For a system on which the osmocom-own dependency libs are installed in distinct directories, current openbsc master HEAD requires the attached patch for a build to succeed. I admit that in most situations the dependencies are installed in the same directory so this does not matter, but it is still a small bug. Therefore I propose to modify the jenkins build scripts so that they use distinct, stow managed directories for the dependencies. That should help to detect oversights, although admittedly developers would have to adapt their workflows to use stow as well in their daily hacking. Otherwise an oversight would be detected by jenkings and not locally which in turn would require additional cleanup commits which is not so nice. What is your gut feeling? Does the increased correctness of Makefiles.am contents justify the (IMO rather small) additional effort of using stow? Kind regards, -Alex

2 5

osmo-trx rach question
by Max 09 Jun '17

09 Jun '17

Hi. I'm troubleshooting peculiar use case with packet access and osmo-bts-trx. There are 2 options for ME to acknowledge reception of control packet to PCU according to 3GPP TS 44.060 § 11.2.2: 1) Packet Control Acknowledgement message 2) 4 identical access bursts The latter can be both 8-bit RACH and 11-bit RACH (not supported by osmo-bts-trx yet). The choice of response format is defined by OpenBSC in SI: 1) is default, 2) can be activated with "gprs control-ack-type-rach" option. The problem is that I don't understand how 2) will be handled by OsmoTRX? Shall I expect 4 consecutive RACH messages via rx_rach_fn() in scheduler_trx.c in osmo-bts-trx? Shall it be some other message/function? Will it be ignored/dropped altogether by OsmoTRX? -- Max Suraev <msuraev(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte

2 1

osmo-trx: GSM signal generator
by Tom Tsou 08 Jun '17

08 Jun '17

Hi All, I wrote a GSM signal generator application based on osmo-trx. The new osmo-siggen allows random GSM or EDGE burst generation without using special configurations of osmo-trx or the socket control interface. Frame trigger output through GPIO is also available. I use the application for testing modulation parameters and other PHY level testing. Hopefully it's useful to other developers beyond myself. $ ./osmo-siggen -h Options: -h, --help This text -a, --args UHD device args -l --log Logging level ('err', 'warn', 'notice', 'info', 'debug') -b, --burst Burst type ('normal', 'access', 'freq', 'sync', 'edge') -r, --ref Frequency reference ('internal', 'external', 'gps') -f, --freq Tx RF frequency -g, --gain Tx RF gain -s, --sps Tx samples-per-symbol (only 4 supported) -m, --mod GSMK modulator type ('laurent4', 'laurent2', 'laurent1', 'nco') -p, --ampl Tx amplitude (0.0 - 1.0) -o, --offset Baseband frequency offset -t, --tsc Normal and EDGE burst training sequence (0-7) -S, --swap Swap channels Currently osmo-siggen is located in the below branch. I've tested solely with B210. C++14 availability is also required for now. git://git.osmocom.org/osmo-trx ttsou/siggen -TT

1 0

osmo-trx: Generating frame sync output on GPIO?
by Harald Welte 08 Jun '17

08 Jun '17

Hi all, I was wondering if it is possible to generate a TDMA frame sync output on a GPIO line of a USRP device (and/or any other SDR supported by osmo-trx). This way it would be much easier to do e.g. BER testing by using a pure waveform/pattern generator for the "MS side". Such devices (Like an E4433B) can only generate the uplink bursts with pseudo-random sequence, but they don't have any receiver, so they're not able to receive the downlink from the BTS in order to lock on the TDMA frame and transmit the uplink in sync to that. There are of course specialized devices (CMU-300, ...) or hardware options that add such receivers for synchronization on the signal generators, equipment side, but why go there if there would be an easy way to generate some kind of a frame sync output. I would appreciate to know even if there's a way to introduce such "synchronous GPIO toggles" or the like in the command stream to UHD devices. If that existed, it should be rather simple to insert those whenever a new burst for TS0 is sent. A rather computationally (and bandwidth) expensive other option might be to use the second RF output to generate such a signal, but I was hoping not having to abuse the 2nd channel for that ;) Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

2 1

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC