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