Eigenes PTZ-Pult — Stueckliste

Ein Bedienpult fuer die LZ Camera Bridge: Joystick in der Art des DigitalBird PTZplus, aber mit einem eingebauten Stream Deck und ohne die Schwaechen, die sich an der DigitalBird-Firmware ablesen lassen.

Was dieses Dokument ist: eine Kaufliste mit Begruendung je Posten und die Verdrahtung dazu. Was es nicht ist: ein geprueftes Design. Nichts davon stand bisher auf einem Tisch. Preise sind Richtwerte (netto, Stand 2026-09) und gehoeren vor der Bestellung nachgesehen; bei den Joysticks sind es Familien-Namen und keine Bestellnummern.

1. Der Befund am Vorbild

Gelesen wurde DB-PTZplusESP32-v7.00.ino und DB3_VISCA_Decoder_v6_02.ino aus digitalbird01/DigitalBird-Camera-Slider. Woertlich aus dem Quelltext:

const int panS_PIN = 34;    // Pan Joy      -> analogRead(), ESP32-ADC, 12 bit
const int tiltS_PIN = 32;   // Tilt Joy
const int slidS_PIN = 35;   // Slider joy
const int focusS_PIN = 39;  // Focus joy
const int zoomS_PIN = 36;   // Zoom joy
const int masterA_PIN = 33; // Master pot

Daraus folgen vier Schwaechen, und die vier sind die ganze Begruendung fuer diese Liste:

1. Fuenf getrennte Analogachsen am ESP32-ADC. Der ESP32-ADC ist nichtlinear und rauscht; die Firmware mittelt deshalb in Schleifen (temp_pan += analogRead(panS_PIN)). Gemittelt wird Rauschen, nicht behoben. Bei einer langsamen Live-Fahrt ist genau das der Ruckler.
2. Zoom und Fokus liegen auf eigenen Joysticks, nicht in der Hand, die schwenkt. Jedes echte PTZ-Pult (AW-RP150, PT-JOY) legt Zoom auf den Drehgriff derselben Achse.
3. Funk als Normalfall (ESP-NOW/WLAN zwischen Pult und Kopf). Im Hallen-WLAN ist das der Ausfall, den keiner nachstellen kann.
4. Keine Rueckmeldung am Bedienelement. Das Nextion-Display zeigt, was das Pult glaubt; welche Kamera on air ist, weiss es nicht.

Dazu kommt, was das Pult grundsaetzlich nicht kann: es spricht das DigitalBird-eigene Funkprotokoll und damit nur DigitalBird-Koepfe. Die Bridge spricht 15 Wege (Sony CCU, Canon CCAPI, Lumix, Blackmagic, Z CAM, Panasonic AW, VISCA, JVC, BirdDog, DJI …). Ein Pult, das an der Bridge haengt, faehrt sie alle.

2. Architektur

Die Bridge hat den Eingang dafuer bereits: packages/bridge/src/input/ HidControlSurface.ts nimmt ein beliebiges USB-HID-Pult und bildet Report-Bytes datengetrieben auf RCP-Befehle ab. Das Pult muss also kein eigenes Protokoll erfinden — es muss ein HID-Geraet sein.

Das Stream Deck ist ein zweites USB-Geraet und wird nicht von der Bridge getrieben, sondern von Bitfocus Companion, fuer das in diesem Repo bereits ein Modul liegt (packages/companion-module-lz-camera-bridge). Damit sind Tastenbeschriftung, Tally-Rueckmeldung und Preset-Layout Konfiguration statt Firmware.

   [Hall-Joystick 3 Achsen]---[ADS1115 16 bit]--I2C--+
   [Encoder Fokus/Zoom]------------------------------+--[Pico 2]==USB-HID==+
   [Taster, Fader]-----------------------------------+                     |
                                                                           v
   [Stream Deck XL]======================================USB=========>[Pi 5]
   [7" DSI-Touch] <--- Web-RCP http://localhost:3700 -------------------|
                                                                        |
                                            Gigabit-Ethernet (Kabel) ---+
                                                                        v
                                   DB3-Kopf (VISCA/UDP 1259), ATEM, andere Kameras

Variante A (empfohlen): Rechner im Pult. Pi 5 im Gehaeuse, laeuft Bridge + Companion. Ein Netzwerkkabel raus, sonst nichts. Das Pult ist ein Geraet.

Variante B: Pult am Laptop. Nur Pico + Stream Deck im Gehaeuse, beide per USB an den Rechner, auf dem die Desktop-App ohnehin laeuft. Spart rund 200 EUR und den halben Aufbau — kostet aber, dass ohne diesen Laptop nichts geht.

3. Stueckliste Variante A

3.1 Rechner und Bedienflaeche

Statt Pos. 5 denkbar: Stream Deck + (Plus) mit 8 Tasten und 4 Drehgebern (~230 EUR). Die Drehgeber koennen Fokus/Iris/Weissabgleich uebernehmen und sparen die Encoder aus 3.3 — dafuer fehlen die Preset-Tasten. Beides zusammen ist die Vollausbau-Variante und kostet ~480 EUR.

3.2 Joystick — die eine Entscheidung, die das Pult ausmacht

Drei Klassen. Der Unterschied ist nicht die Genauigkeit auf dem Papier, sondern ob das Ding nach zwei Jahren Tourbetrieb in der Mitte noch Ruhe gibt.

Empfehlung: Hall, 3 Achsen, Drehgriff. Der Preisunterschied ist einmalig, das Zittern eines Potis begleitet einen bei jeder Probe.

3.2.1 Der Gamepad-Weg — und warum er trotzdem der erste Schritt ist

Ein Spiele-Controller ist ein USB-HID-Geraet mit zwei Analogsticks und zwei Analogtriggern. Er faellt damit in denselben HidControlSurface-Adapter wie alles andere in diesem Dokument. Der Unterschied zwischen den beiden Lagern ist aber nicht kosmetisch:

Praktisch heisst das: ein DualSense am Kabel ist der kuerzeste Weg zu einem fahrenden Kopf. Kosten 0 EUR, wenn einer da ist, sonst rund 70.

Was ein Gamepad kann, und das ist mehr, als man erwartet:

• Linker Stick Pan/Tilt, die analogen Trigger L2/R2 auf Zoom ein und aus — das ist naeher an einem PTZ-Pult als DigitalBirds zweiter Joystick.
• Die Achsen liefern 8 bit, also 256 Stufen. Fuer einen VISCA-Kopf ist das nicht die Grenze: das Protokoll kennt fuer Pan nur 24 Geschwindigkeiten (0x01…0x18), fuer Tilt 20. Das Argument „16 bit" aus 3.3 gilt fuer die Paint-Werte und fuer direkt angesteuerte Schrittmotoren, nicht fuer VISCA-Fahrbefehle. Wer hier etwas anderes behauptet, verkauft Aufloesung, die auf dem Draht gar nicht ankommt.
• Rund ein Dutzend Tasten fuer Presets, bis das Stream Deck da ist.

Warum es trotzdem nicht das Endergebnis ist, und diese drei Gruende sind koerperlich und nicht elektrisch:

1. Der Weg ist zu kurz. Ein Gamepad-Stick hat rund 8 mm Auslenkung, ein PTZ-Joystick gut das Dreifache. Die langsame Fahrt lebt vom Weg, nicht von der Zahl der Stufen.
2. Die Feder ist falsch. Ein Gamepad zentriert schnell und hart, weil es fuer Zielen gebaut ist. Einen Schwenk ueber acht Sekunden haelt man damit nicht ruhig.
3. Stick-Drift. Die Sticks sind Potis und das bekannte Verschleissteil der Bauart. Es gibt Hall-Ersatzmodule (GuliKit u. ae., ~25 EUR das Paar), die genau das beheben — ein billiger Test, ob Hall den Unterschied macht, den dieses Dokument behauptet.

Empfohlene Reihenfolge: Gamepad zuerst. Erst wenn Pan/Tilt/Zoom damit sauber fahren, ist die Frage nach dem 400-EUR-Joystick ueberhaupt zu beantworten — und dann beantwortet sie die Hand und nicht das Datenblatt. Der Adapter dafuer steht (Abschnitt 6); was am Geraet noch zu bestaetigen ist, steht in 6.3.

Eines dabei im Blick behalten: Companion sieht ein Gamepad nicht. Es treibt Stream Decks und Satellite-Flaechen, kein HID-Gamepad. Der Controller haengt also am Bridge-Eingang, das Stream Deck an Companion. Zwei Wege, mit Absicht.

3.3 Achsen-Erfassung und Bedienelemente

3.4 Gehaeuse, Netz, Kleinteile

3.5 Summe

Zum Vergleich: ein Panasonic AW-RP60 liegt bei rund 3.000 EUR und spricht nur Panasonic; ein PTZOptics PT-JOY bei rund 500 EUR und spricht nur VISCA.

4. Variante B (Pult am Laptop)

Entfallen: Pos. 1–4, 6, 21. Bleibt: Stream Deck, Pico, ADS1115, Joystick, Bedienelemente, Gehaeuse. Summe ca. 700–900 EUR im empfohlenen Ausbau. Companion und Bridge laufen dann auf dem Rechner, der ohnehin dasteht.

Der Preis dafuer ist nicht das Geld: ein Pult, das ohne einen bestimmten Laptop nichts tut, ist im Aufbau das erste, was fehlt.

5. Verdrahtung in Stichworten

• Joystick → ADS1115 #1, Kanaele A0–A2 (Pan, Tilt, Zoom-Twist), A3 = Master-Speed-Poti. Versorgung 5 V, Signal ratiometrisch.
• ADS1115 #2: A0 = Iris-Fader, A1–A3 frei (zweiter Fader, Pedal, T-Bar).
• Beide ADS1115 → I2C des Pico (Adressen 0x48/0x49 ueber ADDR-Pin), ueber den Pegelwandler.
• Encoder + Taster → GPIO des Pico, Fokus-Encoder auf die PIO-Einheit (RP2350 zaehlt Quadratur damit ohne CPU-Last).
• Pico → Pi per USB, meldet einen HID-Report fester Form: Byte 0 Report-ID, Bytes 1–16 acht Achsen zu je 2 Byte little-endian, Bytes 17–18 Tasten-Bitfeld. Diese Form ist mit Absicht so gewaehlt: sie passt 1:1 auf HidBinding { offset, bytes: 2 } in der Bridge.
• Stream Deck → Pi per USB, Companion greift direkt darauf zu.
• Display → DSI, Chromium im Kiosk auf http://localhost:3700.

6. Der Stand in der Software

6.1 Erledigt

Die drei Luecken, die hier als offen standen, sind zu. Alle drei lagen in HidControlSurface.ts, und alle drei sind mit Tests belegt (test/gamepadBindungen.test.ts):

1. Zweiseitige Achsen. Eine Bindung mit centre gibt -span … +span aus statt 0 … span. group buendelt zwei Achsen in EINEN Befehl — ptz bekommt pan und tilt zusammen, statt als zwei Fahrten, von denen die zweite die erste aufhebt.
2. Totband. deadband gibt die Ruhelage zurueck, step haelt das Zittern eines gehaltenen Sticks von der Leitung fern. Die Ruhelage selbst geht immer durch, sobald die Achse sie ERREICHT: ein verschluckter Stopp liesse den Kopf weiterfahren. Sie geht aber nicht bei jedem Report erneut durch, sonst schickte ein Pult, das niemand anfasst, einen Stopp je Report.
3. Tasten im Bitfeld. bit waehlt die Taste im Byte, und der Merker haengt jetzt an der Bindung statt am Byte-Offset. Vier Symboltasten in einem Byte loeschen sich nicht mehr gegenseitig aus.

Dazu kam eine vierte Sache, die erst der Test zeigte: zwei Bindungen auf demselben Befehl kaempfen gegeneinander. Die beiden Trigger fahren denselben Zoom in entgegengesetzte Richtungen; als eigene Befehle schickte der eine Fahrt und der andere im selben Report den Stopp, und wer gewann, entschied die Reihenfolge in der Tabelle. Mit sum addieren sie sich zu einem Wert — und beide gedrueckt heisst jetzt Stillstand statt Zufall.

6.2 Die Belegung, die beim Einstecken greift

standardBindungen() waehlt nach Vendor/Product-ID. Ein DualSense oder DualShock 4 bekommt die Fahr-Belegung, alles Uebrige die bisherige Paint-Belegung. Das ist keine Bequemlichkeit, sondern die Sperre aus Anhang A: die alte Vorgabe legte Achse 1 und 2 auf setIris und setMasterGain, und das sind bei VISCA 9-Byte-Pakete, deren Bytes 6/7 der DB3-Decoder als Pan/Tilt-Richtung liest. Ein Stick auf setIris haette den Kopf losfahren lassen — unkontrolliert, und ohne dass am Pult etwas danach ausgesehen haette.

6.3 Was weiterhin von Hand zu pruefen ist

Die Byte-Offsets sind nicht am Geraet nachgemessen. Sie sind das dokumentierte USB-Format; ueber Bluetooth liegt derselbe Controller anders, und ob node-hid die Report-ID mitliefert, haengt an der Plattform. Deshalb gibt es debug: die Bruecke schickt dann jeden Report als Hex ({ type: 'hidReport', hex }), und die Offsets sind in einer Minute ausgezaehlt. Lieber eine Tabelle, die man pruefen kann, als eine, die man glauben muss.

node-hid ist eine optionale Abhaengigkeit und ein natives Modul. Fehlt es, sagt die Bruecke es im Klartext, statt still nichts zu tun.

7. Vor dem Bestellen zu klaeren

• Genaue Bestellnummer des Hall-Joysticks: Achszahl, Federrate, ob der Drehgriff rastet, Steckerbelegung.
• Aussenmasse und Einbautiefe des Stream Deck XL am eigenen Geraet.
• Ob Aktivkuehler, NVMe-HAT und PoE-HAT zusammen auf den Pi 5 passen.
• Ob Companion und Bridge auf einem Pi 5 nebeneinander genug Luft haben — vor dem Gehaeusebau einmal auf einem nackten Pi messen.
• Die Byte-Offsets des Gamepads aus 3.2.1, falls der Weg ueber die Erprobung geht: einmal mit hidraw ausmessen, je Modell und je Anschlussart.

Anhang A: Was der DB3-Kopf von unserem ViscaClient versteht

Gelesen wurde DB3/DB3_VISCA_Decoder_v6_02.ino gegen packages/bridge/src/cameras/ViscaClient.ts. Der Decoder laeuft auf einem WT32-ETH01 (PoE), lauscht UDP 1259 auf rohem VISCA ohne Sony-Kopf und gibt per UART 115200 an den Kopf weiter. Das ist genau der Vorgabe-Zweig des ViscaClient (port = 1259, Sony-Kopf erst ab 52381).

Weiteres: die IP des Decoders steht statisch im Sketch (192.168.x oder 10.x, kein DHCP), pro Kopf ein Decoder-Board, und alle Teile des DigitalBird-Systems muessen dieselbe Hauptversion tragen (heute 7.x). Der Decoder beantwortet Pan/Tilt- und Zoom-Abfragen — unser ViscaClient fragt nichts ab.

Lizenz des DigitalBird-Repos: BSD-3-Clause (Colin Henderson).