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

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