Hey,
I recently stumbled across shellcheck[1] and think we should make it a goal that our shell scripts don't produce errors/warnings with it.
Some of the examples in the GSM tester:
In jenkins-build-common.sh line 76:
cd "$base"
^-- SC2164: Use 'cd ... || exit' or 'cd ... || return' in case cd fails.
In jenkins-build-common.sh line 93:
rm -rf *
^-- SC2035: Use ./*glob* or -- *glob* so names with dashes won't become options.
What do you think? My approach would be:
* Install shellcheck into our build containers
* Run them and provide warnings
* Fix them over time and on new code
* Make CI fail with failures
cheers
holger
[1] https://www.shellcheck.net/
Osmocom New Splits stacks for voice is SOLVED and stable with LimeSDR!
Voice is working actually since back then, my fault is using only C117/118
for test call all the time.
Now I just test using newer phone both Caller and Callee and voice is work
perfectly!
I tested both osmo-trx-lms and osmo-trx legacy.
using osmo-trx legacy 0.20 also have better performance using the
firmware/gateware version I mention here : firmware/gateware version:
LimeSDR-USB_HW_1.3_r3.0.img and LimeSDR-USB_HW_1.4_r2.9.rbf from LimeSuite .
There is trace in wireshark when using old phone as C117/118, the BTS
always freeze and send Measurement Indication all the time when calling is
made and answered, but with newer phone, the Indication is normal.
--
Best Regards,
DUO
Sorry forgot to reply-all and didn't send original mail to ML,
re-sending now.
On 9/14/18 3:25 PM, Pau Espin Pedrol wrote:
> Hi Rafael,
>
> You may want to check at PCU_IF_VERSION in both osmo-pcu.git and
> osmo-pcu.git
>
> It seems that you are running a recent osmo-pcu together with a quite
> old osmo-bts (from at least Feb 28 2018, see osmo-bts.git
> 4046e3b3dd0cffd53d8d0d1f3e1bf9d0dec83ede), and they are not protocol
> compatible.
>
> So you need to either use a newer osmo-bts (preferred I guess) or switch
> to an older osmo-pcu which uses PCU_IF_VERSION 7.
>
> If you are using NuRan original firmware, you either ask them to update
> their stuff or your are pretty much on your own to build new images
> (with non-upstream osmocom versions afaik).
>
> At sysmocom we maintain meta-sysmocom-bsp [1] which together with
> system-images [2] and osmocom's meta-telephny [3] allows to build
> firmware for both sysmobts and litecell 1.5 machines, together with SDKs
> to compile software for them.
>
> I think generated images are not available publicly, but I guess you can
> either attempt building them yourself or perhaps ask sysmocom customer
> support to have access to it.
>
> [1] https://git.sysmocom.de/poky/meta-sysmocom-bsp/
> [2] https://git.sysmocom.de/poky/system-images/
> [3] https://git.osmocom.org/meta-telephony/
>
> Regards,
> Pau
>
--
- Pau Espin Pedrol <pespin(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
And again, forgot to include the list, sorry ;)
On 9/14/18 3:59 PM, Pau Espin Pedrol wrote:
> Hi Rafael,
>
> I'm not sure right now about the details of the binary firmware
> installation and the exact rights you have as customer/user regarding
> it, but I guess you can ask NuRan to provide them, or take them from
> your current LC 1.5 image you are using if they are available there. I
> think the headers are at least provided publicly in gitlab:
> https://gitlab.com/nrw_noa
>
> Regards,
> Pau
--
- Pau Espin Pedrol <pespin(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
Hi all,
I'm trying to test trunk osmo-pcu (using armhf osmo repo) in the NuRan
LC 1.5 in the lab, but I get:
20180914124657820 DLGLOBAL <000e> telnet_interface.c:104 telnet at
127.0.0.2 4240
20180914124657821 DL1IF <0001> osmobts_sock.cpp:248 Opening OsmoPCU L1
interface to OsmoBTS
20180914124657821 DL1IF <0001> osmobts_sock.cpp:308 osmo-bts PCU socket
/tmp/pcu_bts has been connected
20180914124657821 DL1IF <0001> osmobts_sock.cpp:312 Sending version
0.5.1.3-3e9c to BTS.
20180914124657821 DL1IF <0001> pcu_l1_if.cpp:113 Sending 0.5.1.3-3e9c
TXT as PCU_VERSION to BTS
PCU interface version number of BTS (7) is different (9).
Please re-compile!
Any way to make it work without changing BTS software?
Thanks,
Rafael Diniz
Hi Mychaela,
> If Motorola phones running their original firmware [...]
> don't work with Osmocom networks [...] it is a very grave
> problem from the perspective of Freedom [...]
Actually, they do. You can even find some videos on YouTube,
where an original Motorola phone runing FreeCalypso firmware
was tested with Osmocom based network (most likely, CalypsoBTS).
The problem is that the author of this topic is using LimeSDR,
that is still not 100% reliable as a PHY for OsmoTRX, and not
reliable itself, because even a regular firmware update can
brick the board... Moreover, AFAIK the author is not using
any stable clock source, such as GPSDO.
> Sysmocom has two of my FreeCalypso development boards [...]
> The board you've got set up there is the one that did get
> properly calibrated before being sold to Sysmocom.
Maybe I am missing something, but how is this related to
the original topic?
> Do you still have that firmware image in the flash, or have
> you erased it? Where is the RF from that board connected to -
> does it go to a sysmoBTS unit? Would it be possible for someone
> from Sysmocom [...] to test and see if the FCDEV3B can successfully
> connect to Osmocom network using the official FreeCalypso
> firmware on the board, driven via AT commands?
I think you could ask this in context of the mentioned issue.
> If Sysmocom folks are philosophically against doing any
> tests with FreeCalypso firmware [...]
Please don't get me wrong, but I am philosophically against
abusing the mailing list in order to PR your production. This
is not the first time I see some thread mixed with your
advertisements.
There are other commercial companies also using this mailing
list, and let's imagine everybody would constantly PR their
production here? It would just result in a mess. Even
Sysmocom is not abusing that much, at least I don't see
any offers to buy e.g. sysmoBTS when a general question
about some BTS is asked...
With best regards,
Vadim Yanitskiy.
Hi OpenBSC,
My company is working on integrating some BTS (Nokia Flexi ESMB) with Nokia
packet Abis with OsmoBSC.
The Nokia packet Abis seems to be Nokia OML/RSL over SCTP/IUA (RFC 3057).
To get started, we have built a little stub that takes the incoming SCTP/IUA
connection and carries out ASP_UP/ASP_ACTIVE handshake. After this handshake
is complete, we see OML coming in from the BTS.
It seems that this OML is in a form that would be understood by
"bts_nokia_site.c". So now we would like to continue the experiment by
feeding the OML/RSL into a BTS configured in OsmoBSC as type "nokia_site".
Now the questions:
1. Is it possible to configure a BTS of type "nokia_site" to run Abis over a
unix domain socket ?
2. Is there a better way to prototype this integration ?
PS: PCAP trace available on request
Best Regards,
Michael Andersen
Hi All.
posting to the list here rather than going down the line of a ticket as
I'm using the nitb to configure my bts and so this may not be a bug, but
rather a missing back port to legacy. (which may not be appreciated
here, I'm aware!)
Anyway, this is the scenario:
I noticed a lack of audio with latest osmo-bts, and this log message:
<0000> rsl.c:1503 invalid mode/codec instructed by BSC, check BSC
configuration.
I added some logging in osmo-bts to check what was being passed into
this line in rsl.c:
if (bts_supports_cm(lchan->ts->trx->bts, lchan->ts->pchan,
lchan->tch_mode) != 1)
and the values are 0 (zero), GSM_PCHAN_TCH_F_TCH_H_PDCH and
GSM48_CMODE_SPEECH_AMR but bts_supports_cm() only checks against
GSM_PCHAN_TCH_F and GSM_PCHAN_TCH_H
Is it that osmo-bsc is sending the actual current channel mode now,
whereas the osmo-nitb is sending the configured mode, i.e.
TCH_F_TCH_H_PDCH ?? in which case, sorry to bother you, but I will ask:
should we try to keep basic functionality between BTS and nitb for a
little while longer :)
Or are we missing checks for all possible modes in rsl.c:bts_supports_cm()
Related commit: http://git.osmocom.org/osmo-bts/commit/src?id=a4bca1155
Thanks!!
k/
Hi all,
I'm diving into 3GPP standards after all the OsMux discussion. For
example, LCLS, 3GPP TS 44.007 standard was mentioned. Trying to figure
out where to download it, I reached:
http://www.3gpp.org/DynaReport/44-series.htm
But it's not there any 44.007. Any hint?
Thanks,
Rafael Diniz