SB detect error while making a call in osmocomBB

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

Ravi Sharan bhagavathula.ravisharan at
Tue Dec 30 07:31:29 UTC 2014

        I am playing with osmocomBB on Arch Linux, branched off from
jolly/handover. I am running the osmocomBB firmware by chainloading the
layer1 onto Motorola C115(and layer23 on host PC, obviously). Everything
works fine (location update, normal cell selection and re-selection) while
in Idle mode. As soon as the phone enters the dedicated mode (ex: the
moment I make a call or receive an indication about an incoming call), I
notice that the layer1 starts complaining about erroneous detection of
Synchronization Burst (SB) from the neighboring-cells, making the mobile
stick to a single ARFCN throughout the call. As soon as the mobile leaves
dedicated mode, the layer1 stops complaining about SB detect error and
resumes with cell-selection and re-selection normally.
I dug up the layer1/prim_fbsb.c code off the same branch and came to two
conclusions (though I am unable to find out what the actual cause to this
problem is):

   - Either the TPU is programmed to detect information from different
   timeslot using l1s_rx_win_ctrl(). I make this assumption because, while
   the layer1 complains about SB detect error, layer23 complains about bad
   frame with >= 70 bit errors in the frame.
   - Or, l1s_neigh_sb_resp() is receiving the correct frame and ending up
   in a bad CRC check with the received SCH burst header (all 11 times !).

I have tested the osmocomBB firmware with both openBTS network setup and
public, licensed networks and have come to these conclusions, as the errors
were occurring in both the cases. You can find the error logs in here
<> and here
<> (these logs are
based of public networks). Thanks in advance, any help is appreciated.

Ravi Sharan B A G.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the baseband-devel mailing list