Re: Off-by-one errors in Tx timing

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