On Sun, Sep 09, 2018 at 08:33:44PM +0200, Keith wrote: 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: 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

On Mon, Sep 10, 2018 at 03:36:43PM +0200, Keith wrote: Excellent! 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

On 11/09/18 05:49, Harald Welte 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 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. 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 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. Good to know! I will avoid it. I hope I have not jinxed mine now with all this praise.! k/

On 10/09/18 23:07, Neels Hofmeyr 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]