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>
* 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
the l1s signal was an old mechanism between l1test and the layer1
before we introduced the L1CTL protocol. This commit removes all
leftover references to it.
It also disables the l1test app, as it would no longer work without
major modifications (using l1ctl from within the phone).
The idea is that the L1S part can schedule a completion handler which
will then execute in the asynchronous L1A part. This should keep the
FIQ priority L1S extremely short, deferring most of the work into
the L1A part that runs in regular process context.
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>
The new plan for layer1 is to structure the source code not based on
whether it is part of l1s/l1a or other parts, but based on 'primitives'.
All code that relates to transmitting a RACH burst should be in one
file, same for all code related to power management. Those files are
called layer1/prim_*.c
In case a single request from L2 triggers multiple response messages
from L1, we need a way to signal via L1CTL if the response is the
final or some intermediate response.
* introduce a new 'l1ctl_hdr' structure common to all messages
on this interface
* use struct l1ctl_hdr in both the firmware and layer23
* add a new L1CTL_PM_REQ request for performing layer23-initiated
power measurements (firmware does not implement them yet)
* remove linuxlist.h copy and use osmocore
* don't put 'struct gsm_time' into l1ctl packets
* include rx_level and snr for each burst in l1ctl
* properly build libosmocore.a for target
* move gsmtime functions into libosmocore
* move ctype.h to standard location
* print HDLC packets received from L2
* print Tx MAC block as it is written to DSP API RAM
* ensure we don't msgb_free() a message that we've enqueued for l1s
L1 and L2 now pass UI frames like BCCH and CCCH downlink up into
L3, which detects an IMMediate ASSignment command and instructs
the L1 to switch to SDCCH/4.
From this point on, SDCCH/4 and SACCH4/C messages end up in our
L2 LAPDm implementation and are forwarded to L3.
This enables the layer2 to identify on which channel
(BCCH/CCCH/SDCCH/TCH/...) the respective message was received.
* Encode MFrame Task Number + SACCH info in 'p3' parameter
* Generate channel number and link identifier
* Decode channel number in layer2 program
The idea of the third parameter is that it can be specified on a
tdma_schedule_set() level. The multi-frame scheduler can thus use
it to pass some context information into the l1s_{cmd,resp}_*()
functions, such as the MF TASK and whether or not it is SDCCH or
SACCH.
Using the new rach_sched_set_ul and nb_sched_set_ul TDMA scheduler
sets it is possible to transmit RACH bursts as well as sets of four
normal bursts, i.e. everything needed to get a SDCCH established
on a combined CCCH (with SDCCH/4).
Known Limitations:
* Uses constant transmit power (2 dBm)
* Only works on SDCCH/4 so far
* SACCH is received but cannot be transmitted yet
* TSC (traning sequence code) is hard-coded to '7'
This scheduler enables us to schedule repeating events that occur
every multiframe. It e.g. includes definitions for BCCH and CCCH
reading.
The mframe_sched is layered on top of the tdma_sched.
This has the advantage that any caller or other reference does not
need to know the size of the set, which makes it simpler to use the
sched_set as a constant initializer in some other const/static data
structure.
The cause is really not clear. The formual using 2*Pi to convert
from radians to frequency is perfectly correct.
However, measurements with various test equipment (including Racal 6103)
have shown our frequency error estimate is always off by a power of two...
Sylvain Munaut
Harald Welte