Hello, 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.
--