Finally... FB/SB Layer1 changes working/merged

historical

Hi all!

I've merged a number of layer1 related changes that I've been working on
for quite some time.

The major difference is: there is no L1CTL_NEW_CCCH_REQ anymore, it has been
replaced by L1CTL_FBSB_REQ.  When issuing FBSB_REQ, you can specify what
tasks you want the layer1 to perform (any bitmask of FB0, FB1, SB).

Also, if the acquisition fails completely, you will get a L1CTL_FBSB_RESP
with result=0xff.  This means there is now proper error reporting.

Let's say you want a relatively quick indication if the ARFCN specified
could at all be a BCCH, then issuing FBSB_REQ only with FB0 should return
even more quickly.  You will definitely get a response after some 15 TDMA
frames if there was a frequency burst or not.

Furthermore, I have changed some details of the FB/SB acquisition process:

Rather than waiting for a fixed amount (500) TDMA frames before switching from
FB0->FB1 or FB1->SB, the switch is now done based on thesholds for frequency
delta and SNR.  The frequency thresholds can actually be specified by L1CTL,
the SNR thresholds are hardcoded.

One problem with fast scanning was that by erroneous FB0 reports, we tuned our
VCO so far off the desired frequency that it never synced to any cell at all
anymore.  I have reduced that problem by simply resetting the AFC-DAC to
its default value every time we start a FBSB acquisition.

Andreas:  I think it would make sense to use the S_L1CTL_FBSB_RESP and
S_L1CTL_FBSB_ERR signals in 'mobile', especially if you receive an _ERR,
you can immediately switch to the next ARFCN without wasting further time.

My next API change will be to introduce a separate command, i.e. FBSB_REQ
will no longer start the multiframe task for BCCH NORMAL/EXTENDED, but the
application will have to explicitly request that.  However, I don't think I'll
find much time throughout the next 10 days or so.. .sorry :/

Regards,
	Harald

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)