Technisches Sendekonzept¶
Normales Tally-Paket¶
Das aktuelle normale Live-Paket ist 9 Byte lang. Es wird unverändert über BLE Coded PHY, WiFi UDP und MQTT transportiert. MQTT verpackt den Binärinhalt nicht in JSON; der Payload des MQTT-Topics ist dasselbe 9-Byte-Paket.
| Byte | Feld | Bedeutung |
|---|---|---|
| 0 | Marker | 0xA2. Kennung für ein gültiges CameraTally-16-Paket. |
| 1..4 | Matrix32 | 32 Bit Tally-Zustände: 16 Tallys mit je 2 Bit. |
| 5 | Control | Bits 0..1 Source, Bits 2..3 Cue Type, Bits 4..7 Cue Target Low. |
| 6 | Cue Target High | Bit 0 ist das fünfte Zielbit für T1..T16. Die übrigen Bits sind reserviert. |
| 7..8 | Payload16 | System-ID, Cue Sequence und Cue Value. |
32-Bit-Tally-Matrix¶
Die Matrix enthält nur die Live-Zustände der 16 Tally-Kanäle. Jeder Kanal belegt genau zwei Bits. Wert 0 bedeutet OFF, Wert 1 bedeutet PRV/Preview grün, Wert 2 bedeutet PGM/Program rot. Wert 3 ist reserviert.
| Tally | Bits | Wert 0 | Wert 1 | Wert 2 | Wert 3 |
|---|---|---|---|---|---|
| T1 | 0..1 | 0 = OFF | 1 = PRV | 2 = PGM | 3 = reserviert |
| T2 | 2..3 | 0 = OFF | 1 = PRV | 2 = PGM | 3 = reserviert |
| T3 | 4..5 | 0 = OFF | 1 = PRV | 2 = PGM | 3 = reserviert |
| T4 | 6..7 | 0 = OFF | 1 = PRV | 2 = PGM | 3 = reserviert |
| T5 | 8..9 | 0 = OFF | 1 = PRV | 2 = PGM | 3 = reserviert |
| T6 | 10..11 | 0 = OFF | 1 = PRV | 2 = PGM | 3 = reserviert |
| T7 | 12..13 | 0 = OFF | 1 = PRV | 2 = PGM | 3 = reserviert |
| T8 | 14..15 | 0 = OFF | 1 = PRV | 2 = PGM | 3 = reserviert |
| T9 | 16..17 | 0 = OFF | 1 = PRV | 2 = PGM | 3 = reserviert |
| T10 | 18..19 | 0 = OFF | 1 = PRV | 2 = PGM | 3 = reserviert |
| T11 | 20..21 | 0 = OFF | 1 = PRV | 2 = PGM | 3 = reserviert |
| T12 | 22..23 | 0 = OFF | 1 = PRV | 2 = PGM | 3 = reserviert |
| T13 | 24..25 | 0 = OFF | 1 = PRV | 2 = PGM | 3 = reserviert |
| T14 | 26..27 | 0 = OFF | 1 = PRV | 2 = PGM | 3 = reserviert |
| T15 | 28..29 | 0 = OFF | 1 = PRV | 2 = PGM | 3 = reserviert |
| T16 | 30..31 | 0 = OFF | 1 = PRV | 2 = PGM | 3 = reserviert |
Source, Cue und Payload¶
| Bits / Feld | Werte | Bedeutung |
|---|---|---|
| Byte 5 Bits 0..1 | 0 API, 1 Digital, 2 vMix, 3 ATEM | Quelle des aktuellen Tally-Zustands. Besonders nützlich für Supervisor und Diagnose. |
| Byte 5 Bits 2..3 | 0 Off, 1 Minute, 2 Countdown, 3 Text | Typ eines optionalen Moderator-Cues. |
| Byte 5 Bits 4..7 + Byte 6 Bit 0 | 0 = alle, 1..16 = T1..T16 | Ziel des Cue-Befehls. Nur passende RX zeigen den Cue an. |
| Payload Bits 15..12 | 1..15 | System-ID. Trennt mehrere Systeme im gleichen Raum oder Netz. |
| Payload Bits 11..8 | 0..15 | Cue Sequence. Verhindert, dass derselbe Cue mehrfach als neu gewertet wird. |
| Payload Bits 7..0 | 0..255 | Cue Value. Bedeutung abhängig vom Cue Type. |
| Cue Type | Cue Value | Beispiel / Hinweis |
|---|---|---|
| Off | 0 | Kein aktiver Cue. Sonderfall: Bei Program-Ende kann Cue Type Off mit Ziel T1..T16 und Wert 1..255 eine externe Stoppzeit in Sekunden übertragen. |
| Minute | 1..60 | Hinweis wie 1 Minute, 5 Minuten oder 10 Minuten. |
| Countdown | 1..255 Sekunden | Countdown, z.B. 10 Sekunden. |
| Text | 1..4 | 1 STOP, 2 END SPEECH, 3 CONTINUE, 4 lokaler Custom Text. |
\ MQTT ====
Topic, MQTT verwendet ein Topic pro System-ID:
cameratally/system/\<id>/matrix
Beispiel für System-ID 1: cameratally/system/1/matrix. Der TX publiziert den 9-Byte-Binärpayload auf dieses Topic. Browser-Monitor und MQTT-fähige RX abonnieren dasselbe Topic und filtern zusätzlich über die System-ID im Paket.
Timing¶
Der TX sendet Zustandsänderungen sofort. Zusätzlich gibt es einen Heartbeat, damit Empfänger erkennen, ob der Link noch lebt. Ohne Änderung wird ungefähr einmal pro Sekunde ein aktueller Zustand gesendet. BLE Coded PHY läuft mit kurzem Advertising-Intervall; im aktuellen TX ist 20 ms eingestellt, während der Matrix-Heartbeat und erzwungene Updates die effektive Paketfolge bestimmen.
Im Langzeittest lagen die gemessenen Verarbeitungszeiten stabil im unkritischen Bereich. WiFi UDP lag typischerweise bei wenigen 10 us, BLE nach längerer Laufzeit bei einigen 100-800 us. MQTT hängt zusätzlich von WLAN, Internet und Broker ab; für Tally-Zustände ist es als Zusatz- oder Fernstrecke sinnvoll, während BLE lokal der robuste Grundkanal bleibt.
Mehrere Systeme nebeneinander¶
Mehrere CameraTally-Systeme können parallel laufen, wenn jedes System eine eigene System-ID von 1 bis 15 verwendet. RX, Supervisor und Web-Monitor werten nur Pakete mit der passenden System-ID aus. Der UDP-Port darf gleichbleiben, weil die Trennung im Paket selbst erfolgt. Auch MQTT nutzt die System-ID im Topic.
| System | System-ID | Topic / Verhalten |
|---|---|---|
| System A | 1 | cameratally/system/1/matrix; RX mit ID 1 akzeptieren diese Pakete. |
| System B | 2 | cameratally/system/2/matrix; RX mit ID 1 ignorieren diese Pakete. |