Open questions for `docs/development`

[floesche]

parity implementation

Currently, we have SUM and XOR as "checksums" / parity checks. It is unlikely that one of them discovers an issue the other type wouldn't.

Suggestion: use XOR for both.

Time series / Mode 1

Do we want to implement a time series (e.g. for AO or patterns)?

Suggestion: we do as a data structure independent of the pattern.

The controller knows?

Should the controller know about the current hardware setup? That would allow acceptance / rejection of "invalid" packages. That could also be used for Arena IDs and Observer IDs.

[mbreiser]

Quick status pass — most of this is resolved by PR #53 (the protocol-restructure rollup + CRC-8/CRC-16 swap that just merged).

1. Parity implementation (SUM and XOR) — resolved.
PR #53 replaced both checksums with CRC-8/AUTOSAR (single algorithm for both the wire-level CIPO confirmation byte and the pattern-file header byte 17), plus added CRC-16/CCITT-FALSE for per-frame integrity in pattern files. So neither sum-mod-256 nor XOR remains — the "use XOR for both" suggestion is now moot in a stronger sense (both upgraded to proper CRC). Universal check values pinned in g6_01 § CRC-8 algorithm and g6_04 § Frame Format.

(Note: a separate "parity bit" — popcount-mod-2 of the 3-byte confirmation slot — still exists in the message header byte; it's not a checksum and wasn't part of this concern.)

2. Time series / Mode 1 — resolved.
g6_03 § "Mode 1 Support via TSI Files" specifies TSI as an independent data structure: 5-byte records [FrameIndex16, DO, AO_lo, AO_hi], stored as tsi<NNNN>_*.tsi on SD, independent of .pat files, indexed via trial-params InitPos fields. Matches the "independent of the pattern" suggestion.

3. Controller knows hardware setup — mostly resolved, one gap.

• Arena ID is in the pattern header (bytes 4–5); controller looks up panel routing via g6_arena_configs.h keyed on that ID (g6_03 § Panel Routing).
• get-controller-info (opcode 0x67) returns version + 8-bit capability bitmap so host can verify controller class (g6_03 § Utility Commands).
• Still open: no explicit "reject pattern if Arena ID doesn't match my compiled-in arena config" rejection policy specified in g6_03. Reasonable controller-side enhancement to add once the G6 controller port is up.
• Observer IDs — not in the current spec. Could you say more about what you had in mind here? Different sense than Arena ID, or controller-identity-of-which-Teensy, or something else?

Proposing to close this issue once you've confirmed the read on items 1+2; the controller-side rejection policy + Observer ID question are worth a separate, narrower issue if/when you've got more detail.

[mbreiser]

Closing — items 1 (parity/SUM/XOR) and 2 (Time series / Mode 1) are resolved by the PR #53 restructure as detailed in the status comment above.

The two genuinely-still-open follow-ups (controller-side Arena ID rejection policy + Observer ID definition) carried over to #55 for tracking @floesche.

Cosmetic doc cleanups from the parallel issue #51 landed in #54.