Project

General

Profile

Actions

Bug #4829

open

OsmocomBB Rx bit errors in dedicated mode

Added by laforge over 3 years ago. Updated about 3 years ago.

Status:
Stalled
Priority:
High
Assignee:
Category:
-
Target version:
-
Start date:
10/24/2020
Due date:
% Done:

40%

Resolution:
Spec Reference:

Description

I'm observing quite a number of bit errors when receiving in dedicated mode.

Those bit errors are not present while in receive-only mode (CCCH/BCCH camping.

The bit errors can be observed on SDCCH/4, SDCCH/8 and TCH/F (didn't try TCH/H).

I've tried to roll back to old OsmocomBB firmware versions as old as 2012 (using old gnuarm-4.0.x toolchain) - the problem even exists in those old versions, so it doesn't look like a regression.

I've tested with perfect RF signals (coaxial connection via attenuators) to exclude any real-world impact.

I've tested both with sysmoBTS 1002 as well as with a commercial cellular network.

I've tested with C118, C121, C123 and C140.

In all situations, the problem persists and looks like this:

Camping with good signal level 0 BER / fire_crc = 2

<000c> l1ctl.c:237 BCCH on TS0 (0301/13/02) -56 dBm 0/0: 59 06 1a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff e5 04 00 
<000c> l1ctl.c:237 PCH/AGCH on TS0 (0301/17/06) -56 dBm 0/0: 03 03 01 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 
<000c> l1ctl.c:237 PCH/AGCH on TS0 (0301/23/12) -56 dBm 0/0: 15 06 21 00 01 f0 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 
<000c> l1ctl.c:237 PCH/AGCH on TS0 (0301/01/16) -56 dBm 0/0: 2d 06 3f 03 41 e3 67 00 68 8f 00 00 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 

Once switched to dedicated channel:

<000c> l1ctl.c:237 SDCCH/8(0) on TS1 (0301/10/00) -56 dBm 0/0: 03 03 01 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 
<000c> l1ctl.c:237 SDCCH/8(0) on TS1 (0301/16/32) -56 dBm 66/2: a3 4b 33 0a 38 66 2a a4 57 cc 2e db 60 f7 e2 7e 9e cd ac d8 ee dc bd 
<000c> l1ctl.c:300 Dropping frame with 66 bit errors
<000c> l1ctl.c:237 SDCCH/8(0) on TS1 (0301/09/00) -56 dBm 74/2: a3 35 0f 0a b8 79 13 2a 6b 5e c2 da 60 f7 e2 7e 9e cd ac d8 ee dc fd 
<000c> l1ctl.c:300 Dropping frame with 74 bit errors
<000c> l1ctl.c:237 SDCCH/8(0) on TS1 (0301/08/00) -56 dBm 82/2: a3 35 0f 14 f1 f7 17 aa 57 cc 2e 12 67 f7 e2 7e 9e cd ac d8 7e 29 85 
<000c> l1ctl.c:300 Dropping frame with 82 bit errors
<000c> l1ctl.c:237 SDCCH/8(0) on TS1 (0301/14/32) -56 dBm 77/2: a3 4b 33 0a 38 66 2a a4 57 cc 2e 92 44 f8 e2 7e 9e cd ac d8 fe 85 2f 
<000c> l1ctl.c:300 Dropping frame with 77 bit errors
<000c> l1ctl.c:237 SDCCH/8(0) on TS1 (0301/07/00) -56 dBm 74/2: a3 4b 33 0a 38 66 2a 24 6b 5e c2 da 60 f7 e2 7e 9e cd ac d8 fe 85 2f 
<000c> l1ctl.c:300 Dropping frame with 74 bit errors

so as we can see, he very first block is still received well, all other blocks have massive bit errors (typically in he 70..95 erroneous bit range)

Playing with the source code I could narrow it down to whether or not we are enabling the PA in the rffe_mode() function by means of tspact | PA_ENABLE

If I enable the PA only for RACH / access burst, but not for any normal bursts, the SDCCH bit errors are not reported anymore.

I've played a lot with l1s_tx_win_ctrl in terms of ordering, etc. but the problem persists.

It cannot be a general scheduling problem, as the TX window duration is not affected by whether or not we enable the PA. There are just as many TPU instructions etc. even without that one bit.


Files

sky77324.pdf View sky77324.pdf 3.75 MB PA data sheet laforge, 10/25/2020 08:28 AM
Sch_C118_A2_C_L3_1.0.pdf View Sch_C118_A2_C_L3_1.0.pdf 583 KB C118 schematics laforge, 10/25/2020 08:29 AM
SF_C118_A3_C_L3_1.2.pdf View SF_C118_A3_C_L3_1.2.pdf 593 KB C118 component placement (position of resistors) laforge, 10/25/2020 08:29 AM

Related issues

Related to OsmoBSC - Bug #4832: osmo-bsc hard-releases lchan if no MSC is foundStalledneels10/25/2020

Actions
Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)