DSP TCH task : time to get/put FAACH

Sylvain Munaut 246tnt at gmail.com
Thu Oct 21 18:39:00 UTC 2010


Hi Dieter,
Hi everyone,

(cc'd the list, for the record and if other people are interested in
the inner workings :)


I'm pretty satisfied with the current state of the TCH primitive (as
it is in my testing branch now). But there is still two things I'm
stumbling upon:

 * When to put / read data for FACCH.

   Getting downlink FACCH blocks looks quite logic: just check the
B_BLUD bit on the TCH response of the last burst of the block.

   So with rx_time being the time at which the burst was received
(i.e., one frame before the response is executed)
    - For TCH/F: (rx_time.fn % 13) % 4 == 3
    - For TCH/H: (rx_time.t2 - subchannel) in {6,15,23}

   But for when to load the next FACCH block, it seems weird. From
what I understand of what you did and what the TSM30 does, you need to
load the data on the TCH cmd corresponding to the bursts _before_ the
first burst.

   So with tx_time being the time at which the burst will transmitted
(i.e., one frame after the command is executed = l1s.next_time)
    - For TCH/F (tx_time.fn % 13) % 4 == 3
    - For TCH/H (tx_time.t2 - subchannel) in {6,15,23}  (2 TDMA before
the first burst because on TCH/H, we're executed one once every two
frame)

   Why the need to load it one burst in advance ? (while on the RX
side, which seems more complex to do, data is available directly after
the last burst is received).


 * TCH/H support: AFAIK, I did everything that should be required for
it to work:
  - set fn_report properly for TCH/H
  - set chan_type to TCH_H in dsp_load_tch_parameters
  - Use a different condition for when to put/read FACCH bursts
(according to 05.02)
  - Schedule the TCH task appropriately ...

  But still can't get it to work (testing with the racal). SACCH seems
to work fine (I see the SI messages), but I don't see a single FACCH
message (and eventually the racal says T3107 expired, assignement to
TCH failed).

  Do you see anything else that would be required ?


Cheers,

    Sylvain




More information about the baseband-devel mailing list