Some L1 status updates

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/baseband-devel@lists.osmocom.org/.

Harald Welte laforge at gnumonks.org
Wed Jun 23 17:30:31 UTC 2010


Hi Sylvain,

On Wed, Jun 23, 2010 at 10:29:36AM +0200, Sylvain Munaut wrote:

> The good news, is that hopping and ts[0:4] work just fine and were
> surprisingly easy to implement. 

Thanks a lot for your work and the good news!

> 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).

ok, I will look at it, probably at some point tomorrow.

> 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).

yes, this is one of the shortcuts Dieter and me were willing to take 
to get layer1 going in the beginning.

>  - 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
> overlap.

agreed.  but I haven't looked at the problem hard/long enough to
come up with details for a solution.

>  - 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.

indeed, it probably is very easy to do right now.  And you are the best
candidate to do it, given you did the OpenBSC crypto support.

>    The need for a SIM interface grows quickly :)

well, as inidicated, at the moment we're likely to run layer23 (or at least the
'3' part) on the PC for a long time to come, a PC/SC reader interface
might actually make more sense than remotely driving the sim card reader
in the phone.

> 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.

the proper fix is to either move all the l1s.completion[] assignments to
l1s_init(), as they only need to be set once - or to have a initialization
function for each primitive.  The first option requires making the completion
functions non-static, which I would actually try to avoid.  But having an
init callback function for each primitive that only assigns one pointer is
probably a stupid idea, too.

>  - 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

ok, good (sending patch).  probably best to send an example pcap along with
it.

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




More information about the baseband-devel mailing list