Hi.
I've noticed check for device type around
Transceiver52M/UHDDevice.cpp:772 - seems like USRP B200 is not supported
for multitrx configurations:
sudo chrt 20 ./Transceiver52M/osmo-trx -c 2
sudo chrt 15 ./src/osmo-bts-trx/osmo-bts-trx -c
~/.config/osmocom/osmo-bts-trx.cfg -i 192.168.122.1 -t 2
Where does this limitation comes from? Is it just smth which is not
implemented (yet) or it's impossible to implement due to X and Y?
--
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
On Jun 15, 2016 10:38 PM, "Tom Tsou" <tom(a)tsou.cc> wrote:
>
> On Wed, Jun 15, 2016 at 10:08 AM, Max <msuraev(a)sysmocom.de> wrote:
> > I've tried it with manually sending POWERON - the issue with CHAN RQD is
> > gone but the phone still does not work. I'll look into OML/RSL/whatever
> > is preventing it from working.
>
> Make sure that the static variable 'settsc_enabled' is set.
>
> diff --git a/src/osmo-bts-trx/trx_if.c b/src/osmo-bts-trx/trx_if.c
> index a4c16dc..8c9a839 100644
> --- a/src/osmo-bts-trx/trx_if.c
> +++ b/src/osmo-bts-trx/trx_if.c
> @@ -47,7 +47,7 @@
> //#define TOA_RSSI_DEBUG
>
> int transceiver_available = 0;
> -int settsc_enabled = 0;
> +int settsc_enabled = 1;
> int setbsic_enabled = 0;
Could you explain why is that required?
I don't remember the code exactly, but IIRC this is equivalent to setting
or removing 'tsc' line in the config file.
Please excuse typos. Written with a touchscreen keyboard.
--
Regards,
Alexander Chemeris
CEO Fairwaves, Inc.
https://fairwaves.co
Hi Harald,
On Wed, Apr 6, 2016 at 12:59 AM, Harald Welte <laforge(a)gnumonks.org> wrote:
> Can you or somebody else interested in getting this resolved provide a
> full bug report, including
> * debug log output on OsmoNITB side for for the rsl and nm
> * debug log output on OsmoBTS side for oml / transceiver interface or
> anything else related
> * pcap file of A-bis traffic between OsmoBTS and OsmoNITB, as well as
> the control commands between osmo-bts-trx and osmo-trx
Attached are the logs for master branches of OpenBSC, OsmoBTS, and
OsmoTRX leading up to the following RACH access behavior.
<0004> abis_rsl.c:1423 BTS 0 CHAN RQD: no resources for SDCCH 0x2
Hopefully, somebody more familiar than myself with A-bis and related
L1/L2 dependencies can provide some insight on why the above is
happening or where to start debugging. I'll be happy to test any
subsequent changes or look into specific parts of the A-bis code.
-TT
I am a bit ambiguous on our use of comments in gerrit.
We do discuss at least some fairly interesting things in the comments on
patches waiting for approval in gerrit.
When these discussions are attempted on openbsc@ or osmocom-net-gprs@, you
tend to block off and redirect the discussion back to the gerrit comments
infrastructure.
However, we have moved the gerrit mails to a separate and very noisy
mailing list, and these potentially interesting discussions are moved
essentially out of the public focus.
Also, if we in future would like to investigate discussion on some topic,
we need to search both the main ML and the gerrit ML.
IMHO it would make sense to copy the human originated comments to our
"human" mailing lists, so that the automatic jenkins and gerrit
notifications remain on the noisy ML while we see all discussions here.
Is that easy to achieve (filter on originator of comment),
and would you guys agree?
~Neels
--
- Neels Hofmeyr <nhofmeyr(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
* Geschäftsführer / Managing Directors: Harald Welte
Hi.
So far release process for new versions of osmocom components was rather
quiet (unless I'm looking at the wrong place). This is different from
many other open source projects some of which do announcements in ML,
some use blogposts etc. Is there any interest/value in the release
announcements for osmocom projects? Or maybe partially (applications but
not libraries for example)? Or only major but not minor? Or not at all?
To me personally the value is twofold: a) we generate some news which
might be good thing to attract attention of potential contributors (if
we won't overdo it :) and b) it makes it clear when some feature is
"officially shipped" so we have to start paying attention to things like
backward compatibility.
Of course writing such announcements is boring regardless of a medium so
if we follow this road we should automate the process as much as possible.
What do you guys think?
--
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
Today I've taken another close look at branches and gerrit, and have written
down my conclusions here:
http://osmocom.org/projects/cellular-infrastructure/wiki/Gerrit#Submitting-…
In summary:
* Branch re-submission needs the workaround of tweaking the first commit.
It would be nice to fix gerrit to not need this, but for the time being the
effort of cosmetically changing the first commit log is acceptable.
* It *is* possible to have private branches in the gerrit repos and still be
able to submit them to master, with the proper project config.
I have thus switched all our gerrit projects' configs to rebase-if-necessary
with the flags as described on the wiki page.
(Except for osmo-pcap, where we still disallow content merges.)
I will now go back to pushing my "private" developments to the public
repository (gerrit) under the neels/ or sysmocom/ namespaces.
~Neels
--
- Neels Hofmeyr <nhofmeyr(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
* Geschäftsführer / Managing Directors: Harald Welte
I'm testing things related to our gerrit bug report, if it's not working
for you right now it may be because I'm restarting gerrit to test with/out
our fix.
I'll repost when I'm done.
~Neels
--
- Neels Hofmeyr <nhofmeyr(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
* Geschäftsführer / Managing Directors: Harald Welte
Hi.
Repository over git.osmocom.org/osmo-trx is not (yet?) converted to
gerrit. Can I get commit access so I can push (not to master of course)
some branches for review/testing if necessary?
--
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
> Date: Fri, 27 May 2016 18:02:28 +0200
> From: Pierre Baudry <pierre.baudry(a)diateam.net>
> I noticed that since several weeks that osmo-pcu did not work as good as
> previously.
Yes we have also seen similar failures for GPRS calls in the osmo-pcu. Our setup uses NuRAN hardware with osmo-bts-sysmo
> The latest "good" revision I am aware of is commit
> d87e1d6ab747423d3668c74d16201a5d967accf0 (2015/12/14)
This is a useful information for us that the above mentioned commit works for GPRS.
> Can somebody confirm or reproduce this attitude ?
The PCU log that we have during failure matches with the one you have reported.
We have tried a workaround for this GPRS call failure by forcing two-phase-access in osmo-pcu.cfg.
Based on our analysis done till now it seems One phase access of GPRS is broken.
> I will try to provide more logs and a pcap capture as soon as I get
> hands back on the hardware.
It will be quite useful to narrow down the issue, so please share the relevant logs collected
Regards
Saurabh
