Off-by-one errors in Tx timing

246tnt at gmail.com 246tnt at gmail.com
Sun Apr 25 15:16:48 UTC 2010


> 1) The time between the TDMA interrupt happening and starting to execute
> l1_sync() and actually being able to configure the TPU window and tell the
> DSP what to do was too short for performing the scheduled work in the
> very same TDMA frame.

I think it's never executed in the same TDMA frame.

My understanding is :

- The frame interrupt is triggered (let's call this instant t=0 qbits)
- At this moment the interrupt handler is called and we :
. setup some command for the db in the API DB page. (0 or 1)
. put a scenario in the TPU memory.
. enable the tpu to generate a frame interrupt to the DSP at the _next_  
frame. ( t = 5000 qbits )
. enable tpu_en so the TPU start the execution of the scenario we just put  
in.
- It's only at the next frame (t = 5000) that the DSP will actually read  
what we asked it to do.
. for RX, it will just setup a buffer to receive the data
. for TX, it will do fire/crc/... and send the data to the ABB buffer

So our TPU window _must_ be during that next frame ...

* For RX it always worked for TS=0 because in l1s_rx_win_ctrl we put the  
first command AT(DSP_SETUP_TIME - 100) ... which when you do the modulo  
5000 is somewhere around 4944. So when we start executing the TPU scenario  
in the interrupt handler, that first AT command will force to wait almost  
an entire frame and the rx window will be properly placed in the next frame.

* When I tried to open the RX window at TS=1 by just offsetting the  
commands of l1s_rx_win_ctrl by 625 qbits, that changed the first AT command  
to something around ~ 550, so when we set tpu_en, that time was possibly  
not yet passsed and the RX window was executed 1 TDMA frame early. I could  
work around that by forcing a AT(0) as the first command if the start > 0.  
(but that's a quick hack to test my theory)

* For TX, we need the tpu_enq_at(5000 - 10) all the time because TX is  
always 3 TS after RX, the time of the first AT command was always not yet  
passed before we enabled tpu_en so we executed the TX window 1 timeslot  
early ...

Sylvain
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20100425/7d871f8d/attachment.html>


More information about the baseband-devel mailing list