Possible fix for problem -- "l1ctl.c:114 FBSB RESP: result=255"

[Bhaskar11]

When I run ccch_scan on a regular network, every once in a while, at random
I find the app stops sniffing with the error:

> <000c> l1ctl.c:291 BURST IND: @(1428545 = 1077/01/35) (-105 dBm, SNR   3,
> SACCH)
> <000c> l1ctl.c:114 FBSB RESP: result=255


At the same time Osmocon gives a message like the following:

> => DSP reports FB in bit that is 1031487569 bits in the future?!?
> Synchronize_TDMA
> LOST 2313!


The problems seems therefore to emerge from some corruption of data in
reception which causes l1ctl.c to dispatch the S_L1CTL_FBSB_ERR signal.

>From this point on ccch_scan ceases to send any further messages to
Wireshark. Tracing the code shows that it is waiting for some input which
never comes. The only way to get things going again is to stop and restart
ccch_scan.

The issue has been briefly raised in two earlier emails from Altaf and
 Joshua with a reply from Sylvain which I have copied below. Although
Sylvain explains the meaning of the error, no solution has been discussed
so far as far as can find.

Studying the code in various apps to see how they handle S_L1CTL_FBSB_ERR,
it seems the only way to get it going is to restart the sync to ARFCN. I do
it by copying code from app_cbch_sniff.c and inserting the following case
option in signal_cb() in app_ccch_scan.c:

case S_L1CTL_FBSB_ERR:
> ms = ((osmobb_fbsb_res *) signal_data)->ms;
> return l1ctl_tx_fbsb_req(ms, ms->test_arfcn,
> L1CTL_FBSB_F_FB01SB, 100, 0, CCCH_MODE_COMBINED,
> dbm2rxlev(-85));


Frankly I do not know what exactly l1ctl_tx_fbsb_req does, but it seems to
work pretty well. Except *very rarely* I find that after processing this
resync, ccch_scan gives repeated data corruptions messages like:

<000c> l1ctl.c:238 Dropping frame with 78 bit errors


repeating endlessly!

Can Holger or Harald who have written ccch_scan please confirm if this is
the correct way to fix the problem or if there is better solution? Can you
please also insert the update in the ccch_scan code in the burst_ind branch
so that others can benefit?

Thanks in advance!

B.

Related earlier emails below:
==========================
From: Altaf <altaf329 <at> gmail.com>
Subject: Re: Osmocom-bb Making a
call<http://news.gmane.org/find-root.php?message_id=%3c1337878154114%2d4013909.post%40n3.nabble.com%3e>
Date: 2012-05-24 16:49:14 GMT (31 weeks, 4 days, 18 hours and 16 minutes
ago)

When I run the Layer23(ccch_scan) application it gives me the following
output on the terminal....

Failed to connect to '/tmp/osmocom_sap'.
Failed during sap_open(), no SIM reader
<000c> l1ctl.c:114 FBSB RESP: result=255

What does it mean.. Can some one help me at this point..

--

*What does FBSB RESP: result=255 mean?*

*Sylvain Munaut* 246tnt at gmail.com
<baseband-devel%40lists.osmocom.org?Subject=Re%3A%20What%20does%20FBSB%20RESP%3A%20result%3D255%20mean%3F&In-Reply-To=%3CCAHL%2Bj08dHmbuRtcwPFeyVVQnpROLCu6n7kZi%3D%3Dat%3DHrbeWtW2A%40mail.gmail.com%3E>
*Thu Apr 26 01:45:42 CEST 2012*

Hi,

>* Running ccch_scan or bcch_scan in the sylvain/burst_ind branch, I keep*>* getting this error:*
bcch_scan doesn't make sense on burst_ind. Only ccch_scan is meant to
do anything useful, all the other apps may do random things becaue
they're not meant for use in burst_ind.

>* <000c> l1ctl.c:114 FBSB RESP: result=255*>**>* I tried checking the code, but I can't quite figure out what's going on.  It*>* looks like 255 is an error code, but I don't know where to go from there.*
It just means failure to sync ...

Most likely the ARFCN you gave doesn't carry a valid C0.

Note that it's only tested on 900/1800. US band support is not tested
and probably not functional especially in burst_ind. Fixing it is left
as an exercise to the reader ...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20130101/281bee27/attachment.html>