Hi guys,
I think some of us would like to move to redmine and start using public tickets more frequently. So in case we move there are some topics to be discussed and I would like to start with a couple of them right now.
Tickets:
Redmine has a global linear sequence of ticket numbers. If we move from many tracs to a single redmine we can either:
* not import tickets
* only import from one project
* deal with changing ticket numbers
In terms of installations the GMR trac is broken in regard to tickets, there are some for SDR that are probably not being fixed anytime soon, baseband might be relevant and OpenBSC is unlikely to be relevant. I don't think we have ever used ticket reference in OpenBSC commit messages so in terms of OpenBSC having changing ticket numbers would not be a big deal. E.g. we could add a custom field with the old trac number?
Wiki:
We have external references that should be redirected to the new place. Is there any way besides maintaining a list in the apache2/nginx configuration and making redirects as we find broken references? Can we proactively manage this? Is anybody willing to come up with a script and nginx configuration for doing this?
kind regards
holger
Hi Tom and List,
we're currently introducing some code that will make more use of
measurement related information associated with the PH-RACH.req and
PH-DATA.ind coming from the PHY up into L2.
The first part is to introduce a reasonable BER limit fo 17% for RACH
ghost elimination, but I have more plans for unifying the measurement
processing/generation accross all supported BTS models.
For osmo-bts-{sysmo,lc15,octphy} it is clear to me how to get the
related information on RSSI, BER and LinkQuality for each of the RACH
and DATA indications from the PHY.
However, how can I get the related information from osmo-bts-trx?
osmo-bts-trx seems to lack any BER reporting toward the common part,
which among other things is the reason why link/rate adaption in the PCU
can not work with it.
Could you sched some light on this?
--
- 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)
On Tue, Jun 28, 2016 at 10:05:28AM +0200, Harald Welte wrote:
> [translated from german]
> is it certain that we switch a channel to PDCH only when
> gprs mode != none?
A TS can be GSM_PCHAN_TCH_F_PDCH; those are the only ones for which we
send a PDCH ACT message.
We send a PDCH ACT message
- during init (CHANNEL OML's state changed to enabled -> send PDCH ACT),
- and upon channel release ack when pchan == GSM_PCHAN_TCH_F_PDCH.
So the question is, when we receive a channel release ack, could that be
the PDCH release and we switch PDCH right back on by accident? No, because
we only receive a chan rel ack when the *TCH/F* is being released.
That is because the PDCH release is initiated "internally" from the PDCH
DEACT, and thus this condition in common/rsl.c rsl_tx_rf_rel_ack() catches
on, which existed before dyn PDCH:
if (lchan->rel_act_kind != LCHAN_REL_ACT_RSL) {
LOGP(DRSL, LOGL_NOTICE, "%s not sending REL ACK\n",
gsm_lchan_name(lchan));
return 0;
}
In rsl_rx_rf_chan_rel() the rel_act_kind is set to LCHAN_REL_ACT_RSL, but
not in the rsl_rx_dyn_pdch().
This is analogous to the ip.access way -- the ip.access nanobts replies to
a PDCH DEACT with a PDCH DEACT ACK and doesn't send a separate channel
release ack.
Maybe we could set rel_act_kind to some new LCHAN_REL_ACT_IPAC_DYN_PDCH
for clarity? (But we shouldn't actually send a release ack, to stay
compatible.)
Even though it works as-is, we should indeed add another flag check:
- We do check the flags that no ACT/DEACT is already pending;
- And we do send a PDCH DEACT only if ts->flags & TS_F_PDCH_ACTIVE;
- But we would send a PDCH ACT despite ts->flags & TS_F_PDCH_ACTIVE.
This should never happen, but it would make sense to ensure that.
~Neels
Hi all
I am installing OpenBSC.I just following
http://openbsc.osmocom.org/trac/wiki/Building_OpenBSC
(I am just Building libosmocore, Building libosmo-abis, Building
libosmo-netif, Building OpenBSC and install library.)
But when I tried to run OpenBSC,I encounter with this error(problem).
user12@ubuntu:~$ cd '/home/user12/openbsc/openbsc/src/osmo-nitb'
user12@ubuntu:~/openbsc/openbsc/src/osmo-nitb$ sudo ./osmo-nitb
<0005> bsc_init.c:492 Failed to parse the config file: 'openbsc.cfg'
Or how do I run the software(OpenBSC)!
Or do I have to install something missing?
Note: My Linux is version ubuntu 12.04 .
Please help me.
thank you.
Hi all,
Would somebody who is familiar with the relevant part of the GSM spec be
able to comment?
I'm wondering if there's any issue in GSM running a dual TRX BTS with
two ARFCNs on opposite ends of the band?
For example, in GSM850, this would mean the downlinks could be on 869.2
and 893.8 Mhz so the phone could have to tune across a wider range
between the SDCCH and TCH for example.
Thanks!
On Jun 29, 2016 10:04 PM, "Tom Tsou" <tom(a)tsou.cc> wrote:
>
> On Wed, Jun 29, 2016 at 8:31 AM, Neels Hofmeyr <nhofmeyr(a)sysmocom.de>
wrote:
> Another non-startup error message I found is bad PDTCH and PTCCH and
> blocks under ideal RF signal conditions. It appears that you have seen
> this behavior as well.
>
> DL1C <0006> scheduler_trx.c:835 Received bad data frame at fn=372020
> (12/104) for PTCCH
> DL1C <0006> scheduler_trx.c:918 Received bad PDTCH block ending at
> fn=310516 (76/104) for PDTCH
>
> The cause of these errors with excellent signal is the following piece
> of code where zero-filled buffers are passed to the decoder. I have no
> idea why this is done. Removing the code prevents the bad PDTCH/PTCCH
> blocks with no loss of GPRS functionality.
>
> diff --git a/src/common/scheduler.c b/src/common/scheduler.c
> @@ -1598,10 +1598,6 @@ int trx_sched_ul_burst()
>
> func(l1t, tn, fn, chan, bid, bits, rssi, toa);
> } else if (chan != TRXC_RACH && !l1cs->ho_rach_detect) {
> - sbit_t spare[148];
> -
> - memset(spare, 0, 148);
> - func(l1t, tn, fn, chan, bid, spare, -128, 0);
> }
Each L2 frame consists of several L1 bursts, so you need to accumulate them
all before you can pass them to Viterbi for decoding.
If I remember this part of the code correctly, this zeroing is required to
make this work when there are lost bursts. E.g. if you need 4 bursts, but
you only received bursts 0, 1 and 2 you should let the device know that
your missing burst 3. If you don't do that, decoder won't run at all and to
will miss what could be a decodable frame.
By disabling this code you essentially start decoding only perfect frames,
which are obviously decoded fine in perfect conditions. I.e. this only
makes the actual problem, whatever it is.
Please excuse typos. Written with a touchscreen keyboard.
--
Regards,
Alexander Chemeris
CEO Fairwaves, Inc.
https://fairwaves.co
I notice that apparently osmo-bts-trx is the only caller of the trx_sched_*
API, yet it is implemented in common/scheduler.c and compiled to
libl1sched.a. Is osmo-bts-trx really the only caller?
Also in osmo-bts-trx, the "trx" to me means SDR, like B200.
But any BTS has one or more TRXs. So why isn't it osmo-bts-sdr?
That's why I thought: maybe trx_sched_ is for all BTS models?
Thanks for any clarification / confirmation :)
~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.
I've got following problem while trying to make osmotrx work in multitrx
setting on USRP B210:
sudo chrt 20 ./Transceiver52M/osmo-trx -c 2
sudo chrt 15 ./src/osmo-bts-trx/osmo-bts-trx -t 2 -c
~/.config/osmocom/osmo-bts-mtrx.cfg -d DRTP:DCC:DRSL:DOML:DL1C:DTRX
The bts quits from trx_if.c after checking "if (tcm->critical) {...".
The command sequence seems to be the same for both phy0.0 and phy0.1
However 0.0 one accepts SETTSC command and 0.1 rejects it:
trx_if.c:380 transceiver (phy0.1) rejected TRX command with response:
'RSP SETTSC 1 7'
So far I fail to see where this difference comes from.
Full log:
<0001> oml.c:1249 Initializing OML attribute definitions
<000b> trx_if.c:560 Open transceiver for phy0.0
<000b> trx_if.c:222 Adding new control 'CMD POWEROFF'
<000b> trx_if.c:169 Sending control 'CMD POWEROFF' to phy0.0
<000b> trx_if.c:560 Open transceiver for phy0.1
<000b> trx_if.c:348 Response message: 'RSP POWEROFF 0'
<0001> oml.c:547 Ignoring T200[0] (150 ms) as sent by BSC due to
suspected LAPDm bug!
<0001> oml.c:547 Ignoring T200[1] (180 ms) as sent by BSC due to
suspected LAPDm bug!
<0001> oml.c:547 Ignoring T200[2] (180 ms) as sent by BSC due to
suspected LAPDm bug!
<0001> oml.c:547 Ignoring T200[3] (1680 ms) as sent by BSC due to
suspected LAPDm bug!
<0001> oml.c:547 Ignoring T200[4] (520 ms) as sent by BSC due to
suspected LAPDm bug!
<0001> oml.c:547 Ignoring T200[5] (165 ms) as sent by BSC due to
suspected LAPDm bug!
<0001> oml.c:547 Ignoring T200[6] (1680 ms) as sent by BSC due to
suspected LAPDm bug!
<000b> trx_if.c:222 Adding new control 'CMD POWEROFF'
<000b> trx_if.c:169 Sending control 'CMD POWEROFF' to phy0.0
<000b> trx_if.c:348 Response message: 'RSP POWEROFF 0'
<0001> oml.c:884 ADM state already was Unlocked
<000b> trx_if.c:222 Adding new control 'CMD RXTUNE 1783400'
<000b> trx_if.c:169 Sending control 'CMD RXTUNE 1783400' to phy0.0
<000b> trx_if.c:222 Adding new control 'CMD TXTUNE 1878400'
<000b> trx_if.c:222 Adding new control 'CMD SETTSC 7'
<000b> trx_if.c:222 Adding new control 'CMD POWERON'
<000b> trx_if.c:222 Adding new control 'CMD SETRXGAIN 1'
<000b> trx_if.c:222 Adding new control 'CMD SETPOWER 0'
<000b> trx_if.c:222 Adding new control 'CMD SETSLOT 0 4'
<0005> paging.c:545 Paging: BS_AG_BLKS_RES = 0 != 1 not fully supported
<000b> trx_if.c:348 Response message: 'RSP RXTUNE 0 1783400'
<000b> trx_if.c:169 Sending control 'CMD TXTUNE 1878400' to phy0.0
<000b> trx_if.c:348 Response message: 'RSP TXTUNE 0 1878400'
<000b> trx_if.c:169 Sending control 'CMD SETTSC 7' to phy0.0
<000b> trx_if.c:348 Response message: 'RSP SETTSC 0 7'
<000b> trx_if.c:169 Sending control 'CMD POWERON' to phy0.0
<0005> paging.c:545 Paging: BS_AG_BLKS_RES = 0 != 1 not fully supported
<000b> trx_if.c:222 Adding new control 'CMD SETSLOT 1 7'
<000b> trx_if.c:222 Adding new control 'CMD SETSLOT 2 13'
<000b> trx_if.c:222 Adding new control 'CMD SETSLOT 3 13'
<000b> trx_if.c:222 Adding new control 'CMD SETSLOT 4 13'
<000b> trx_if.c:348 Response message: 'RSP POWERON 0'
<000b> trx_if.c:169 Sending control 'CMD SETRXGAIN 1' to phy0.0
<000b> trx_if.c:348 Response message: 'RSP SETRXGAIN 0 1'
<000b> trx_if.c:169 Sending control 'CMD SETPOWER 0' to phy0.0
<000b> trx_if.c:348 Response message: 'RSP SETPOWER 0 0'
<000b> trx_if.c:169 Sending control 'CMD SETSLOT 0 4' to phy0.0
<000b> trx_if.c:348 Response message: 'RSP SETSLOT 0 0 4'
<000b> trx_if.c:169 Sending control 'CMD SETSLOT 1 7' to phy0.0
<000b> trx_if.c:348 Response message: 'RSP SETSLOT 0 1 7'
<000b> trx_if.c:169 Sending control 'CMD SETSLOT 2 13' to phy0.0
<000b> trx_if.c:348 Response message: 'RSP SETSLOT 0 2 13'
<000b> trx_if.c:169 Sending control 'CMD SETSLOT 3 13' to phy0.0
<000b> trx_if.c:348 Response message: 'RSP SETSLOT 0 3 13'
<000b> trx_if.c:169 Sending control 'CMD SETSLOT 4 13' to phy0.0
<000b> trx_if.c:348 Response message: 'RSP SETSLOT 0 4 13'
<000b> trx_if.c:222 Adding new control 'CMD SETSLOT 5 13'
<000b> trx_if.c:169 Sending control 'CMD SETSLOT 5 13' to phy0.0
<000b> trx_if.c:348 Response message: 'RSP SETSLOT 0 5 13'
<000b> trx_if.c:222 Adding new control 'CMD SETSLOT 6 13'
<000b> trx_if.c:169 Sending control 'CMD SETSLOT 6 13' to phy0.0
<000b> trx_if.c:348 Response message: 'RSP SETSLOT 0 6 13'
<000b> trx_if.c:222 Adding new control 'CMD SETSLOT 7 13'
<000b> trx_if.c:169 Sending control 'CMD SETSLOT 7 13' to phy0.0
<000b> trx_if.c:348 Response message: 'RSP SETSLOT 0 7 13'
<0001> oml.c:884 ADM state already was Unlocked
<000b> trx_if.c:222 Adding new control 'CMD RXTUNE 1783800'
<000b> trx_if.c:169 Sending control 'CMD RXTUNE 1783800' to phy0.1
<000b> trx_if.c:222 Adding new control 'CMD TXTUNE 1878800'
<000b> trx_if.c:222 Adding new control 'CMD SETTSC 7'
<000b> trx_if.c:222 Adding new control 'CMD SETSLOT 0 7'
<000b> trx_if.c:348 Response message: 'RSP RXTUNE 0 1783800'
<000b> trx_if.c:169 Sending control 'CMD TXTUNE 1878800' to phy0.1
<000b> trx_if.c:348 Response message: 'RSP TXTUNE 0 1878800'
<000b> trx_if.c:169 Sending control 'CMD SETTSC 7' to phy0.1
<000b> trx_if.c:348 Response message: 'RSP SETTSC 1 7'
<000b> trx_if.c:380 transceiver (phy0.1) rejected TRX command with
response: 'RSP SETTSC 1 7'
<0001> bts.c:203 Shutting down BTS 0, Reason TRX-CTRL-MSG: CRITICAL
<000b> trx_if.c:222 Adding new control 'CMD POWEROFF'
<000b> trx_if.c:169 Sending control 'CMD POWEROFF' to phy0.0
<000b> trx_if.c:348 Response message: 'RSP POWEROFF 0'
<0001> oml.c:547 Ignoring T200[0] (150 ms) as sent by BSC due to
suspected LAPDm bug!
<0001> oml.c:547 Ignoring T200[1] (180 ms) as sent by BSC due to
suspected LAPDm bug!
<0001> oml.c:547 Ignoring T200[2] (180 ms) as sent by BSC due to
suspected LAPDm bug!
<0001> oml.c:547 Ignoring T200[3] (1680 ms) as sent by BSC due to
suspected LAPDm bug!
<0001> oml.c:547 Ignoring T200[4] (520 ms) as sent by BSC due to
suspected LAPDm bug!
<0001> oml.c:547 Ignoring T200[5] (165 ms) as sent by BSC due to
suspected LAPDm bug!
<0001> oml.c:547 Ignoring T200[6] (1680 ms) as sent by BSC due to
suspected LAPDm bug!
<0001> oml.c:884 ADM state already was Unlocked
<000b> trx_if.c:222 Adding new control 'CMD POWERON'
<000b> trx_if.c:169 Sending control 'CMD POWERON' to phy0.0
<000b> trx_if.c:222 Adding new control 'CMD SETRXGAIN 1'
<000b> trx_if.c:222 Adding new control 'CMD SETPOWER 0'
<000b> trx_if.c:222 Adding new control 'CMD SETSLOT 0 4'
<000b> trx_if.c:222 Adding new control 'CMD SETSLOT 1 7'
<000b> trx_if.c:222 Adding new control 'CMD SETSLOT 2 13'
<000b> trx_if.c:222 Adding new control 'CMD SETSLOT 3 13'
<000b> trx_if.c:222 Adding new control 'CMD SETSLOT 4 13'
<000b> trx_if.c:222 Adding new control 'CMD SETSLOT 5 13'
<000b> trx_if.c:222 Adding new control 'CMD SETSLOT 6 13'
<000b> trx_if.c:222 Adding new control 'CMD SETSLOT 7 13'
<0001> oml.c:884 ADM state already was Unlocked
<0001> oml.c:884 ADM state already was Unlocked
<0001> oml.c:884 ADM state already was Unlocked
<0001> oml.c:884 ADM state already was Unlocked
<000b> trx_if.c:348 Response message: 'RSP POWERON 0'
<000b> trx_if.c:169 Sending control 'CMD SETRXGAIN 1' to phy0.0
<000b> trx_if.c:348 Response message: 'RSP SETRXGAIN 0 1'
<000b> trx_if.c:169 Sending control 'CMD SETPOWER 0' to phy0.0
<000b> trx_if.c:348 Response message: 'RSP SETPOWER 0 0'
<000b> trx_if.c:169 Sending control 'CMD SETSLOT 0 4' to phy0.0
<000b> trx_if.c:348 Response message: 'RSP SETSLOT 0 0 4'
<000b> trx_if.c:169 Sending control 'CMD SETSLOT 1 7' to phy0.0
<000b> trx_if.c:348 Response message: 'RSP SETSLOT 0 1 7'
<000b> trx_if.c:169 Sending control 'CMD SETSLOT 2 13' to phy0.0
<000b> trx_if.c:348 Response message: 'RSP SETSLOT 0 2 13'
<000b> trx_if.c:169 Sending control 'CMD SETSLOT 3 13' to phy0.0
<000b> trx_if.c:348 Response message: 'RSP SETSLOT 0 3 13'
<000b> trx_if.c:169 Sending control 'CMD SETSLOT 4 13' to phy0.0
<000b> trx_if.c:348 Response message: 'RSP SETSLOT 0 4 13'
<000b> trx_if.c:169 Sending control 'CMD SETSLOT 5 13' to phy0.0
<000b> trx_if.c:348 Response message: 'RSP SETSLOT 0 5 13'
<000b> trx_if.c:169 Sending control 'CMD SETSLOT 6 13' to phy0.0
<000b> trx_if.c:348 Response message: 'RSP SETSLOT 0 6 13'
<000b> trx_if.c:169 Sending control 'CMD SETSLOT 7 13' to phy0.0
<000b> trx_if.c:348 Response message: 'RSP SETSLOT 0 7 13'
<0001> oml.c:884 ADM state already was Unlocked
<0001> oml.c:884 ADM state already was Unlocked
<0001> oml.c:884 ADM state already was Unlocked
<0001> oml.c:884 ADM state already was Unlocked
<000b> trx_if.c:222 Adding new control 'CMD SETSLOT 0 7'
<000b> trx_if.c:222 Adding new control 'CMD SETSLOT 1 1'
<000b> trx_if.c:222 Adding new control 'CMD SETSLOT 2 1'
<000b> trx_if.c:222 Adding new control 'CMD SETSLOT 3 1'
<000b> trx_if.c:222 Adding new control 'CMD SETSLOT 4 1'
<000b> trx_if.c:222 Adding new control 'CMD SETSLOT 5 1'
<000b> trx_if.c:222 Adding new control 'CMD SETSLOT 6 1'
<000b> trx_if.c:222 Adding new control 'CMD SETSLOT 7 1'
<0001> oml.c:884 ADM state already was Unlocked
<0001> oml.c:884 ADM state already was Unlocked
<0001> oml.c:884 ADM state already was Unlocked
<0001> oml.c:884 ADM state already was Unlocked
<0001> oml.c:884 ADM state already was Unlocked
<0001> oml.c:884 ADM state already was Unlocked
<0001> oml.c:884 ADM state already was Unlocked
<0001> oml.c:884 ADM state already was Unlocked
<000b> trx_if.c:138 Clock indication: fn=999376
<000b> trx_if.c:470 TX burst tn=0 fn=999396 pwr=0
<000b> trx_if.c:470 TX burst tn=1 fn=999396 pwr=0
<000b> trx_if.c:470 TX burst tn=2 fn=999396 pwr=0
...
--
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