9 Sep
2018
9 Sep
'18
8:33 p.m.
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/
10 Sep
10 Sep
2:50 a.m.
On Sun, Sep 09, 2018 at 08:33:44PM +0200, Keith wrote:
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!)
Well, it's rather the other way round: "Our" opinion is that it makes
little
sense to do it, but whoever wants to spend time on osmo-nitb is welcome to do
so! "we" I guess being most of the Osmocom core dev team.
And I appreciate you finding below Chan Mode Modif bug:
<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
At first glance, there should not be a difference between osmo-nitb and
osmo-bsc there.
However, looking more closely, your error message happens during an RSL Mode
Modif. This occurs if the MS already is on an lchan suitable for the voice
call, but just needs a more accurate chan mode. The point being that current
osmo-bsc never reaches that:
a) we almost never assign a TCH/F for immediate assignment even if a phone
asked for it so we usually will not encounter this situation that a phone
already has a TCH/F for early signalling to begin with;
b) the code path that would trigger the mode modif currently doesn't, and
instead we assign a new lchan (
http://git.osmocom.org/osmo-bsc/tree/src/osmo-bsc/assignment_fsm.c?id=981f8…
).
c) Even though current osmo-bsc never invokes Chan Mode Modif, I kind of
expected osmo-bts code to also invoke the same function somewhere for the chan
act case. But it doesn't :P
osmo-nitb, however, doesn't do late assignment, so commonly reaches the Chan
Mode Modif code path.
Either way, even though osmo-bsc doesn't currently use this code path, we still
want it fixed for the future, not only for osmo-nitb.
Solution: bts_supports_cm() should never be fed with dynamic pchan kinds. To
test my patch, I'd need to setup an osmo-nitb ... Keith, can you take over the
test whether this fixes the problem instead?
Placed it on branch neels/dyn_modif in osmo-bts; it's just:
- if (bts_supports_cm(lchan->ts->trx->bts, lchan->ts->pchan,
lchan->tch_mode) != 1) {
+ if (bts_supports_cm(lchan->ts->trx->bts, ts_pchan(lchan->ts),
lchan->tch_mode) != 1) {
If it's any difficulty to build osmo-bts, I do have a compile for sysmoBTS
ready to fire up and could also test myself if you ask me back.
(My initial implementation of dyn TS made using the right pchan value a bit
hard, for hysterical raisins. First there were the TCH/F_PDCH dynamic
timeslots; the implementation I took over from jolly used bit flags to indicate
the current actual channel mode. Then I added TCH/F_TCH/H_PDCH also with
separate state. The better thing to do from the start would have been to keep
the currently used pchan state in the central ts->pchan, and only code that
needs to know about the dynamic nature of TS should need to be aware of them.
So a code refactoring would be good to make it easier to add new code around
checking pchan types -- https://osmocom.org/issues/1902. Such a refactoring has
already happened in osmo-bsc, but that's unrelated to this issue.)
~N
3:36 p.m.
On 10/09/18 02:50, Neels Hofmeyr wrote:
b) the code path that would trigger the mode modif currently doesn't, and
instead we assign a new lchan (
http://git.osmocom.org/osmo-bsc/tree/src/osmo-bsc/assignment_fsm.c?id=981f8…
).
Thanks for explaining that!
c) Even though current osmo-bsc never invokes Chan
Mode Modif, I kind of
expected osmo-bts code to also invoke the same function somewhere for the chan
act case. But it doesn't :P
osmo-nitb, however, doesn't do late assignment, so commonly reaches the Chan
Mode Modif code path.
Either way, even though osmo-bsc doesn't currently use this code path, we still
want it fixed for the future, not only for osmo-nitb.
Solution: bts_supports_cm() should never be fed with dynamic pchan kinds. To
test my patch, I'd need to setup an osmo-nitb ... Keith, can you take over the
test whether this fixes the problem instead?
OK tested, works fine, I have pushed gerrit #10864
Placed it on branch neels/dyn_modif in osmo-bts;
it's just:
- if (bts_supports_cm(lchan->ts->trx->bts, lchan->ts->pchan,
lchan->tch_mode) != 1) {
+ if (bts_supports_cm(lchan->ts->trx->bts, ts_pchan(lchan->ts),
lchan->tch_mode) != 1) {
I pushed before actually looking at your branch,
you'ld probably prefer
a different commit message.
and maybe not include the logging changes.. anyway, please comment on
gerrit.
If it's any difficulty to build osmo-bts, I do have a compile for sysmoBTS
ready to fire up and could also test myself if you ask me back.
No problems, I also have a build machine for sysmoBTS ready, but I am
getting great
value at the moment from the LimeSDR-mini and osmo-trx-lms running on x86!!
So a code refactoring would be good to make it easier to add new code around
checking pchan types -- https://osmocom.org/issues/1902. Such a refactoring has
already happened in osmo-bsc, but that's unrelated to this issue.)
Good to
know, it might help me to spot these things in the future.
~N
k/
11 Sep
11 Sep
12:07 a.m.
On Mon, Sep 10, 2018 at 03:36:43PM +0200, Keith wrote:
OK tested, works fine, I have pushed gerrit #10864
Excellent!
but I am getting great value at the moment from the
LimeSDR-mini and
osmo-trx-lms running on x86!!
Interesting how every other dev is reporting completely different results on
lime. For some it seems to give pure satisfaction, while others seem to be but
puzzled by the sheer uselessness of it?
I also still have that lime mini we got on the OsmoDevCon, still unused. Might
give it a spin then?
~N
5:49 a.m.
New subject: LimeSDR-mini (was Re: confused by osmo-bts rsl.c:bts_supports_cm())
Hi Neels,
On Tue, Sep 11, 2018 at 12:07:23AM +0200, Neels Hofmeyr wrote:
On Mon, Sep 10, 2018 at 03:36:43PM +0200, Keith
wrote:
I think it may be related to
a) the exact LimeSuite version you're using.
b) like any SDR, the stability/calibration of the clock you use. For the mini, this
typically means using an external GPS-DO, which means you need to do a hardware
re-work of moving one resistor, as well as using LimeSuite with patch/commit
9977771c4af14731b5c2b32868b98e29ce7a3ce5
Operating any BTS without a very good clock reference (GPS-DO,
calibrated OCXO) is like playing lottery. You may get lucky some
times, with some phones, but in most cases it will fail one way or
another, in very subtle ways.
At sysmocom, it seems we have bricked all three LimeSDR-mini we have by
doing the usual gateware update using "LimeSuite master" last week or
so. And no error at all was reported during the update. The devices
simply are completely useless afterwards.
but I am getting great value at the moment from
the LimeSDR-mini and
osmo-trx-lms running on x86!!
Interesting how every other dev is reporting completely different results on
lime. For some it seems to give pure satisfaction, while others seem to be but
puzzled by the sheer uselessness of it? I also still have that lime mini we got on the
OsmoDevCon, still unused. Might
give it a spin then?
I also bricked my personal LimeSDR-mini by duing a LimeUtil --update to install
the "latest" gateware (from June 2018!) like the three above-mentioned at
sysmocom.
So whatever you do, I would recommend to be extremely careful with updating the firmware
aka gateware.
--
- 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)
9:27 a.m.
New subject: LimeSDR-mini (was Re: confused by osmo-bts rsl.c:bts_supports_cm())
On 11/09/18 05:49, Harald Welte wrote:
Hi Neels,
On Tue, Sep 11, 2018 at 12:07:23AM +0200, Neels Hofmeyr wrote:
I am using this packaged version:
root@debian-dev:~# apt-cache policy limesuite
limesuite:
Installed: 18.06.0-1
Candidate: 18.06.0-1
Version table:
*** 18.06.0-1 500
500
http://download.opensuse.org/repositories/network:/osmocom:/nightly/Debian_…
./ Packages
The about box on LimeSuiteGui says build date 2018-07-14
On Mon, Sep 10, 2018 at 03:36:43PM +0200, Keith
wrote:
I think it may be related to
a) the exact LimeSuite version you're using. but I am getting great value at the moment from
the LimeSDR-mini and
osmo-trx-lms running on x86!!
Interesting how every other dev is reporting
completely different results on
lime. For some it seems to give pure satisfaction, while others seem to be but
puzzled by the sheer uselessness of it?
b) like any SDR, the stability/calibration of the clock you use. For the mini, this
typically means using an external GPS-DO, which means you need to do a hardware
re-work of moving one resistor, as well as using LimeSuite with patch/commit
9977771c4af14731b5c2b32868b98e29ce7a3ce5
Operating any BTS without a very good clock reference (GPS-DO,
calibrated OCXO) is like playing lottery. You may get lucky some
times, with some phones, but in most cases it will fail one way or
another, in very subtle ways.
I have done no hardware mod. I assume that patch is included in the
packge on the osmocom/opensuse repo.
Oddly enough, ALL of the phones I have are seeing, camping and (mostly)
operating correctly with the LimeSDR-Mini. Even the notoriously cranky
K3 that often will not connect to the Ettus N210 unless the GPS-DO is
locked.
I was also using it to do tests of osmo-pcu on x86 and the Lime seemed
to be working fine.
At sysmocom, it seems we have bricked all three LimeSDR-mini we have by
doing the usual gateware update using "LimeSuite master" last week or
so. And no error at all was reported during the update. The devices
simply are completely useless afterwards.
As far as I'm aware, I haven't updated the gateware. I certainly didn't
do it manually, so unless something was done automatically by part of
LimeSuite, it is as it is when I received it at osmodevcon.
root@debian-dev:~# LimeUtil --find
* [LimeSDR Mini, media=USB 3.0, module=FT601, addr=24607:1027,
serial=1D3A0B0F4756A6]
I don't know what else I can say about it.
I did do some calibration things following tutorials on some webpage in
the LimeSuiteGui at some point, but I really don't know what I'm doing
there, and I believe anyway that none of that is permanent? osmo-trx-lms
does it's own calibration on start up, at least according to log output.
This might be good to know:
root@debian-dev:/etc/osmocom# apt-cache policy osmo-trx-lms
osmo-trx-lms:
Installed: 0.4.0.53.544c
Candidate: 0.4.0.53.544c
Version table:
*** 0.4.0.53.544c 500
500
http://download.opensuse.org/repositories/network:/osmocom:/nightly/Debian_…
./ Packages
> I also still have that lime mini we got on the OsmoDevCon, still unused. Might
> give it a spin then?
Why not? I'd certainly be interested to know how it works for you.
giving it a spin as such, well it should be as simple as installing
osmo-trx-lms and limesuite from the opensuse repo and go!
The only other thing that occurs to me is ambient operating temperature.
The temperature here in this top floor (outside walls exposed to direct
sun all afternoon) I am working in has been far too hot for the last
month, and the Lime has been working fine, although my head has not. I
don't have a thermometer here, but I would guess no less than 35 degrees
C in here, heading for 40s in the afternoon. I stopped working then,
partly because i couldn't even think and partly because even the
sysmoBTS 1002 was getting frighteningly hot. as in too hot to hold.
Previous to that, I did notice that it appeared to be operating fine,
but sometimes "weird" things happened, that "looked" to me like RX
was
failing when stressed. I mean.. it "looked" like bursts were received, a
LUR could be completed for example.. and call setup signalling, but once
you got a call going, the audio would fail. pure guesswork, of course. (
Hence my comments at one time on IRC to not use the Lime for debugging
audio issues on split setup.
It's been cooler last weekend and the Lime is still working although set
to get warm again this week.
Of course, the lime itself gets quite hot even just plugged in but idle,
and extremely hot when running osmo-trx for a few minutes. I tend to try
not to run it too long without a break.
So really, that's probably all worthless info, all the same, maybe give
it two minutes to "warm up"? Of course. maybe somebody who knows more
about the hardware can say if that's nonsense.
I also bricked my personal LimeSDR-mini by duing a
LimeUtil --update to install
the "latest" gateware (from June 2018!) like the three above-mentioned at
sysmocom.
So whatever you do, I would recommend to be extremely careful with updating the firmware
aka gateware.
Good to know! I will avoid it.
I hope I have not jinxed mine now with all this praise.!
k/
12 Sep
12 Sep
1:13 p.m.
On 10/09/18 23:07, Neels Hofmeyr wrote:
On Mon, Sep 10, 2018 at 03:36:43PM +0200, Keith
wrote:
I would note that there has been varying behaviour reported with OsmoTRX
use across Lime Suite (driver) and gateware revisions, which is clearly
frustrating and something we're investigating. This likely explains why
present experiences may vary, but we're working to address this and plan
to use Osmocom CNI as a reference application in release testing.
Cheers,
Andrew
[Wearing my Lime Micro hat, but posting from this account since it's
subscribed]
OK tested, works fine, I have pushed gerrit
#10864
Excellent!
but I am getting great value at the moment from
the LimeSDR-mini and
osmo-trx-lms running on x86!!
Interesting how every other dev is reporting completely different results on
lime. For some it seems to give pure satisfaction, while others seem to be but
puzzled by the sheer uselessness of it? 
1:35 p.m.
As far i can say, the driver that i mention here is the best for
LimeSDR-USB.
Someone never get voice working and dead connection, but after downgrade to
my suggestion, this guys is make it work.
http://discourse.myriadrf.org/t/limesdr-gsm-with-omso/2589/86
So who have the LimeSDR-USB. Try the firmware/gateware version I mention.
firmware/gateware version: LimeSDR-USB_HW_1.3_r3.0.img and
LimeSDR-USB_HW_1.4_r2.9.rbf
from LimeSuite V.17.09.
It should work. I compare to all version and this one is absolutely perfect
with osmo-nitb.
Hope someone can get help.
On Wed, Sep 12, 2018, 18:19 Andrew Back <andrew(a)carrierdetect.com> wrote:
On 10/09/18 23:07, Neels Hofmeyr wrote:
On Mon, Sep 10, 2018 at 03:36:43PM +0200, Keith
wrote:
results on
OK tested, works fine, I have pushed gerrit
#10864
Excellent!
but I am getting great value at the moment from
the LimeSDR-mini and
osmo-trx-lms running on x86!!
Interesting how every other dev is reporting completely different lime. For some it seems to give pure
satisfaction, while others seem to
be but
puzzled by the sheer uselessness of it?
I would note that there has been varying behaviour reported with OsmoTRX
use across Lime Suite (driver) and gateware revisions, which is clearly
frustrating and something we're investigating. This likely explains why
present experiences may vary, but we're working to address this and plan
to use Osmocom CNI as a reference application in release testing.
Cheers,
Andrew
[Wearing my Lime Micro hat, but posting from this account since it's
subscribed]
2062
days inactive
2065
days old
8 comments
5 participants
participants (5)
-
Andrew Back -
Harald Welte -
Keith -
Neels Hofmeyr -
Sandi Suhendro