rffe_compute_gain() is the new name for rffe_set_gain(). I needed to change
this, to solve the name collision with the rffe_set_gain() function, which
actually sets the absolute gain.
rffe_get_gain() will now read the absolute gain which has been computed by
rffe_compute_gain() or set by rffe_set_gain().
This patch changes include paths to get osmocom-bb working with
the current libosmocore tree.
Among all these renames, you can notice several tweaks that I
added on purpose, and that require some explanation, they are:
* hexdump() in osmocon.c and osmoload.c has been renamed to avoid
clashing with hexdump() defined in libosmocore.
* gsmmap now depends on libosmogsm. Actually I had to cleanup
Makefile.am because I was experiencing weird linking problems,
probably due to a bug in the autotools. With the change included
in this patch, I got it compiled and linked here correctly.
This patch has been tested with the phone Motorola C123 and the
following images files:
* firmware/board/compal_e88/hello_world.compalram.bin
* firmware/board/compal_e88/layer1.compalram.bin
Using the osmocon, bcch_scan and mobile tools.
Signed-off-by: Pablo Neira Ayuso <pablo@gnumonks.org>
Otherwise, when it reached AFC_RETRY_COUNT, no new FB0 tasks
were scheduled, and you needed to restart the phone in order to
successfully sync to a cell
Signed-off-by: Steve Markgraf <steve@steve-m.de>
Each item has a priority associated to it. The standard is :
-4 -> Responses processing
-3 -> L1S parameters changes
-2 -> [Reserved for TPU window setup]
-1 -> (anything)
0..7 -> Commands relative to time slot n
(relative to current l1s main timeslot)
8 -> (anything)
9 -> [Reserved for TPU window cleanup]
10 -> (anthing)
Note that with this modification, an item scheduled for the
current frame from within a call back won't have its priority
respected !
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
The interface between l1 and upper layer is called by several
name. IMHO l1ctl is shorted and sounds good so try to unify
using that.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
We introduce the concept of CCCH mode. It can be either
- NONE: receive BCCCH only
- COMBINED: CCCH on a BCCH/CCCH+SDDCH/4
- NON_COMBINED: CCCH on a BCCH/CCCH
There is also a new command to change the mode without having
to do the resync.
Currently, we keep the previous default behavior of requesting
a combined CCCH by default
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
This should remove the 'endless FB0 loop' when the DSP detects a FB
where there really is none, and we drive the AFC DAC to its maximum
without ever getting the frequency offset below our threshold.
So far, we have aborted our FB acquisition if we didn't detect a
Frequency Burst in the first period of 12 TDMA timeslots. However,
this turns out to be giving up a bit too quickly. We now re-try
this three times before giving up, which hopefully gives better
results.
* port 'mobile' application to new l1ctl_tx_fbsb_req()
* make sure we have a proper downlinke header in front of l1ctl_fbsb_resp
* remove duplicate band_arfcn member of struct l1ctl_fbsb_resp
* reset the AFC to its default value when starting new FBSB task
* remove bogus l1s.sb.{synced.count} variables
* allocate msg and send l1ctl_fbsb_resp() only from process context, not FIQ
* properly report SNR and BSIC in fbsb_resp
* introduce arbitrary SNR thresholds for FB0->FB1 and FB1->SB switching
We really want to have those two as distinct operations - and we
want proper state machines in L1 to quickly return if they've
managed to acquire a FB or SB or not. Otherwise scanning will
take ages...
This code now introduces a new l1ctl_fbsb_req that is sent via
L1CTL to ask for a bitmask of FB0/FB1/SB operations. The actual
FB0/FB1 detection now no longer runs for 500 TDMA interrupts
but completes as soon as we either know there is no FCCH,
or that our frequency error is smaller than a caller-specified
threshold.
FB0/FB1 are already working, SB is not yet, sorry.
There was some code meddling with mf_tasks directly. This is
fine if it's just setting/clearing a bit but since we're
gonna need some 'cleverness' into when to activate what to prevent
conflict, it's better to abstract that logic.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>