tdsacnsequencetest.zip (57.5 KB)
I noticed this issue when working with TD2023.12600 and Advatek fw >=3.14.x New advatek fw requires sacn universe sequence index to increment. In TD 2023 the universe packet sequence index is always 0 so all data after the first frame is discarded by the receiver. TD 2025 does increment the index but not in the correct way. However the bug only shows up for dmx out chops with 237 universes and up. Just checked and DMX out POP also has this issue too on 2025.33070.
The DMX Out CHOP’s sACN output increments a single sequence counter per CHOP, advanced once per datagram, rather than one counter per universe. E1.31 §6.2.5 requires the opposite: “Sources shall maintain a sequence for each universe they transmit”, incremented by one for every packet sent on that universe. That wording is identical in E1.31-2016 and E1.31-2018.
Repro
-
Constant CHOP, 48 channels, stretched to 512 samples.
-
Into a DMX Out CHOP: Interface
sACN, FormatPacket Per Channel, Multicast off, Network Address127.0.0.1, Start Universe1, Rate44, Active on. -
Remove the Routing Table parameter so universes are assigned consecutively.
-
Capture UDP 5568 and read the framing-layer sequence byte (offset 111) alongside the universe (offsets 113–114).
Observed — one counter, sliced across universes:
universe 1: 0 48 96 144 192 240 32 80 ...
universe 2: 1 49 97 145 193 241 33 81 ...
universe 3: 2 50 98 146 194 242 34 82 ...
Every universe sees a stride of +48. Over a 20 s capture: 21,217 packets, 48 universes, 100% of per-universe deltas equal +48.
Expected — an independent counter per universe:
universe 1: 0 1 2 3 4 ...
universe 2: 0 1 2 3 4 ...
Why it matters
The stride each universe sees equals the CHOP’s universe count mod 256. The §6.7.2 receiver rule discards a packet when the signed 8-bit delta from the last sequence on that universe is ≤ 0 but greater than −20 — so a shared counter is only tolerated below 237 universes. Measured on 2025.33070, one DMX Out CHOP:
| Universes | Per-universe stride | Receiver discards |
|---|---|---|
| 48 | +48 | 0% |
| 250 | −6 | 100% |
| 256 | 0 | 100% |
At 256 universes the stream is rejected wholesale — the same outcome as 2023.12600, where the byte never incremented at all (100% discarded). Note the counter is per-CHOP, not per-process: two DMX Out CHOPs of 24 universes each give a stride of +24, so splitting the output is a workaround.
2025 is a genuine improvement over 2023 and works fine at typical universe counts, but the counter still isn’t per-universe, so conformance depends on how many universes a single CHOP emits.
I have attached a self-contained repro bundle — generated .toe for both builds, capture/analysis script, and raw per-run JSON for 12 captures.
Separate minor item, same node: the 16-byte CID is not an RFC 4122 UUID as per the sACN spec §5.6. It’s the ASCII of the CID parameter, zero-padded — 546f75636844657369676e6572000000 = "TouchDesigner" + 3 NUL bytes — so every TouchDesigner instance presents the same CID by default, and receivers keying per-source state on CID can’t tell two machines apart.