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'
* Tell DSP to properly initialize ABB(TWL3025) registers at first DSP interrupt
* Initialize the entire API RAM to zero on dsp_power_on()
* Tell DSP to initialize the APCRAM to all-zero to preven accidential Tx
* Set number of GUARD bits to 8
* Add function to configure TCH parameters: dsp_load_tch_param()
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.
In commit 9a18ba40d940c9bf173504b941e10f9638032823 (old git), this
was changed to 'fix compiler warnings'.
But %ux is not a valid format specifier at all so that produces
wrong output !
%lx is the correct format AFAICT because uint32_t is typedef'd from
unsigned long in my toolchain (ARM GCC 4.3.3 - newlib 1.17.0). This
doesn't produce any warning here.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Using #define TPU_DEBUG, we can now send the full TPU RAM contents
to the host PC (using a sercomm DLCI) at the time of tpu_enable()
which is very helpful for TPU debugging.
If we perform the downlink calibration too early, the TRF6151 might
not yet provide a stable signal and we'll not be able to receive
anything.
From the desired "BDLENA" time, we subtract all the delays and
latencies to determine the point in time at which the calibration
process should start.
In the sercomm_cons layer, ee used to enqueue a msgb for sending
every time there is an end-of-line. However, if we send a number
of very short lines, we easily run out of msgbs.
Now we check how much msgb backlog there is in the transmit queue,
and decide to skip the end-of-line flushing if needed.
This still doesn't solve all our problems, but its still a useful
mechanism.
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...
Harald Welte
Sylvain Munaut