Hi,
In my sylvain/testing branch, there a a few interesting changes:
* Priority support for items in a scheduler bucket
Basically for each sched_item, there is a now a priority field and they are executed in order.
This allows for example to ensure that a scheduled freq change is executed before accesing the L1 parameters, or to make sure that a control channel RX is scheduled before a RACH TX ...
For new items added into the bucket while executing itself (like the abort), those will obviously not be able to obey the priority and will always be executed afterwards.
* Common DSP & TPU Scenario init & end
Previously, each primitive _cmd initialized the TPU (with network/offset) to the timeslot and also ended the tpu & dsp scenario. This scheme doesn't work when you have several primitives that have a TPU window to open and/or a dsp scenario to run. (this happens when doing RACH in the same frame as reading a CCCH/BCCH bursts, or in the case of SDCCH8[4:7]).
Now, each item specifies via some flags if he has a need for TPU and/or DSP. If one item of the bucket needs it, then the common code will handle. : - Aligning the TPU (via offset/network) to the 'base' timeslot (+3 TX offset still has to be added by the primitive) - Restoring base TPU alignement at the end. - Ending both TPU / DSP scenario when everything is done.
* A5 support
Andreas actually made L23 support and added a stub l1ctl_ command itself. Dieter and I actually made the L1 work in // and not surprisingly came up with very similar results given it's mainly: . Load the key in DSP API NDB & set the mode. . Set a fn parameter properly at each frame The rest is handled inside the dsp.
I will now work on merging Dieter's work into the main branch above what I did.
- TOA regulation loop to prevent drifting - TX power control - TCH support
Cheers,
Sylvain Munaut
Sylvain, Dieter, Andreas:
It's great to see the kind of progress you guys are making. Congratulations!
Unfortuately, for both personal and work reasons, I don't really see me being able to contribute significantly to OsmocomBB throguh at least the next two months. I wish it were different, but there are some priorities.
Nonetheless, I will follow your progress and will try to give input as mcuh as I can on this mailinglist.
Sylvain: Feel free to commit your stuff to master once you are confident about it. No need for waiting for me to review every line.
My main objective with regard to the code in master is: * it should be one commit per feature * we should not try to introduce new 'hacks' but rather remove old ones by proper code * Linux kernel coding style must be followed closely
Happy coding, Harald
baseband-devel@lists.osmocom.org