Off-by-one errors in Tx timing

historical

Hi all,

as this has been a quite weird bug so far, and Sylvain now seems to have
run into some related problems when trying to make a SDCCH8 on TS1 work,
I'll elaborate a bit more on it.

Before commit 0e9d250407f589cff312adc6c9e2c83f6af37de5, what happened was as
follows:

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.

2) As a result, the actions that we thought were performed in the same TDMA
   were actually performed one TDMA later.  Somehow we must have had another
   off-by-one error and thus the two errors compensated themselves in most
   cases, particularly for Rx

3) When trying to send, we hand a MAC BLOCK of 23 bytes to the DSP, after
   which the DSP has to do the FEC, Fire CRC, burst spreading, etc -
   before being able to generate the bits for the furst burst.  Those
   bits then get sent over the TSP to the ABB (into its burst buffer),
   from where they are sent based on TPU signals.

   So what happened is that the data of the first burst was not in the
   burst buffer yet, and the TPU signals triggered sending the last burst
   of the previous MAC block, rather than the first burst of the current.

This is why Dieter added the 
>       tpu_enq_at(5000 - 10); /* TPU_CLOCK_RANGE - EPSILON_SYNC */
to l1s_tx_win_ctrl(), thereby delaying the TPU signal generation by one
TDMA frame.  At that time, the DSP has by long finished writing the new burst
bits in to the ABB burst buffer, and we can transmit the correct burst data.

I personally believe it would be better to simply move the TDMA interrupt a bit
more ahead.  Rather than occurring immediately before TS0, we could set SYNCHRO
in a way that it occurs at a defined point in time still quite a bit into TS7.

In this case we hopefully have enough time for the DSP to be able to transmit
in TS0, making the timing sequence easier to understand.

Hope that helps to explain...
-- 
- 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)