SB detect error while making a call in osmocomBB
bhagavathula.ravisharan at gmail.com
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
- 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
<https://gist.github.com/NinjaComics/1bce7b581de4f1976753> and here
<https://gist.github.com/NinjaComics/a07699fd283c525de3fa> (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...
More information about the baseband-devel