GPRS on osmo-trx not working

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

Tom Tsou tom at tsou.cc
Wed Jun 29 19:02:56 UTC 2016


On Wed, Jun 29, 2016 at 8:31 AM, Neels Hofmeyr <nhofmeyr at sysmocom.de> wrote:
> It turns out my basic setup of IP addresses was wrong.

OK. That's good to know because I modified the addressed in your
configuration and did not find the same errors.

> When I started up the CN, error messages already appeared *without* any mobile
> device even involved. So I noticed that the main difference to the other BTS
> models is that for TRX, I also run osmo-bts on my host machine.

I see various error messages that occur in different layers at
startup. I can definitely confirm that some of these messages are
caused by initial Tx/Rx chain and device synchronization. Given that
these initialization errors (e.g. early stale bursts, dropped packets)
are harmless as long as they only happen once, I'm OK with ignoring
them for now.

I assume there are other effects and similar concerns that take place
higher up the chain.

> 20160629171522824 DL1C <0006> scheduler_trx.c:1420 GSM clock skew: old fn=463983, new fn=463888
> 20160629171523170 DL1C <0006> scheduler_trx.c:1420 GSM clock skew: old fn=463963, new fn=463888
> 20160629171523817 DL1C <0006> scheduler.c:240 Prim for trx=0 ts=0 at fn=464004 is out of range, or channel already disabled. If this happens in conjunction with PCU, increase 'rts-advance' by 5. (current fn=464010)
>
> Ignoring it for now.

With different log settings I do see the 'rts-advance' messages. I'm
ignoring these for now as well.

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);
                }

  -TT



More information about the OpenBSC mailing list