Some L1 status updates

Sylvain Munaut 246tnt at
Wed Jun 23 08:29:36 UTC 2010


The good news, is that hopping and ts[0:4] work just fine and were
surprisingly easy to implement. The bugs I thought I had were in fact
not related to these and just prior bugs that were never noticed
before. (see my sylvain/testing branch).

Only L1 is changed, so you'll need to tweak l23 (either the mobile app
or layer23 for quick tests) if you want to try them out somehow.

Current limitations:

 - SDCCH8 subchannel 4,5,6,7 won't work.

   For those, we need to TX and RX in the same frame ... which just
isn't possible with the way the primitives work right now. (each
assume to have the full frame for themselve).

 - TS >= 4 may not work

   When using TS>=4 we should also change the interrupt alignment so
that the DSP still has time to do it's job. Switching 'forward' is
easy, but when switching 'back', we need to be conscious that we need
to skip 1 frame at the very least ...

IMHO to solve both those issue, we need a better scheduler/primitives
that possibly have some knowledge of the 'span' (in terms of qbit) of
each operation. Because if we do a TX on TS=5 for instance, there is
no way we can do a RX on TS=0 on the next frame, the tpu window

 - No ciphering.

   That should be trivial to add. Just setup the fn and the kc and set
the flag ... the 'l1s.next_time' contains the godd time of the frame
TX/RX frame during the primitive execution, so that's the FN to use.

   Once that's done, the few bits missing from mobile app could be
added (and from a quick look, not much is missing ... just the l1ctl_*
calls because they don't exists yet) and a full location update with
auth and ciphering could be done.

   The need for a SIM interface grows quickly :)

Some 'gotchas' you might encounter that are not fixed yet:

 - The L1 completion handler crashes.
   In target/firmware/layer1/prim_tx_nb.c ,
l1s.completion[L1_COMPL_TX_NB] is set in l1s_tx_test() but that's
never called. So you need to comment out
l1s_compl_sched(L1_COMPL_TX_NB) in the 'resp' handler temporarly until
a proper fix.

 - Wireshark SDCCH8 subchannel decoding in IMMEDIATE ASSIGNEMENT is
just plain wrong. (source code uses % 0x38 instead of & 0x38), need to
send a patch for this

 - layer23 doesn't currently filter much the IMM.ASS it receives so
you may end up on a channel that's not yours ... beware.


More information about the baseband-devel mailing list