baseband-devel

Download

baseband-devel@lists.osmocom.org

October 2026

1 participants
1 discussions

prim_fbsb.c: where the "magic 23" comes from (and a double subtraction in the FB path)
by Bastien Baranoff 04 Oct '26

04 Oct '26

Hi, prim_fbsb.c has carried this since April 2010 (48dfd41e): /* FIXME: where did this magic 23 come from? */ last_fb->toa -= 23; I think I can answer it. I have been running the Calypso DSP mask ROM (version 3606) on a C54x emulator, lock-stepped with layer1.highram under a QEMU Calypso machine, and disassembled it with binutils' tic54x target. The ROM used is identical, word for word, to the public FreeCalypso dump ( ftp://ftp.freecalypso.org/pub/GSM/Calypso/dsp-rom-3606-dump.txt) nothing below needs the emulator, the static reading is enough. What the ROM does: 1. The receive windows are immediate constants: `stm #191,ar3` at 0xb21d for the SB task, `stm #151,ar3` at 0xb2b1 for the NB task (DMA2_ALGTH = 4 * AR3 bytes). No API word is involved. 2. The SB TOA it reports is the index of the lag it keeps in the training-sequence correlation (correlation starts at sample 39 of the window, 0x84a1; TOA = (AR7 - 0x2be4)/2 at 0x7cbf), i.e. the burst position counted from the start of the window, not a timing error. No constant is added. So with tpu_window.c's formula, burst + 2*margin - tail: 148 + 2*23 - 3 = 191 (L1_SB_MARGIN_Q = 23*4) 148 + 2*3 - 3 = 151 (L1_NB_MARGIN_Q = 3*4) 23 is the only SB margin that reproduces the ROM's window, and `toa -= 23` turns the ROM's position into an offset from an SB at its nominal place. The `+75` qbits in synchronize_tdma() (= 23 - 4.25 bits) then moves the burst to the centre of the 151-sample NB window, which toa.c holds at 16 qbits. The three constants only make sense together, which is probably why the FIXME survived. I checked the chain against two logs from real phones posted to this list (Aegean Chou, 2011-09; nish079858, 2024-10): FB mode 0 TOAs are multiples of 48, mode 1 TOAs are 3 mod 4, the first SB after FB sync lands at 27 +/- 2 (n = 6), and the printed qbits are ((TOA - 46) mod 1250) * 4 on all 12 lines. That last number is the second thing: since cb71b972 (2010-05-20), the mode-1 FB path subtracts 23 twice, once in l1s_fbdet_resp() and once more in fbinfo2cellinfo(). It works (the SB lands near the centre of its window, 27 instead of 4), and the hardware logs show it has been that way all along; I just could not tell whether it is intended. Three questions for whoever remembers: - Was the 23 derived from the DSP's 191-sample window (TI documentation, measurement, TSM30 code), or found empirically? - Is the second `toa -= 23` of the FB path in cb71b972 intentional? - Did "We have to add 75 to get an SB TOA of 4" refer to the residual after the -23? Full write-up, with addresses, the git history and the log analysis, reproducible from the public dump: https://github.com/bbaranoff/c54x_exe/blob/main/proof_toa_23.md If there are no objections I will send a Gerrit change replacing the FIXME with a comment stating the above. Bastien Baranoff

1 0