Weg 1 über Servo-Ausgangs-Pins des Empfängers scheidet aus, da ich tatsächlich nicht genug davon frei habe... mein Empfänger (Rsat2) hat nämlich überhaupt keine davon
sondern nur einen Summen-Port. Darüber laufen serielle Daten im EX-Bus-Protokoll an den Flight-Controller, der diese parst und daraus die Werte der einzelnen Kanäle extrahiert. Das gleiche müsste ich also auch tun - an den Summenport ran und die Nachrichten ebenfalls parsen. Schade dass die Library das gar nicht kann - ich dachte, die sei bidirektional.
Wahrscheinlich ist es für den Weg vom Sender zum Empfänger tatsächlich am einfachsten, einen Schalter einem Kanal zuzuordnen und dann mit dem Arduino den Wert für diesen Kanal aus dem Datenstrom herauszufischen. Was mir daran nicht so gut gefällt ist, dass eben ein Kanal belegt wird. Eigentlich habe ich ja genügend Kanäle frei, daher sollte ich das vielleicht einfach so machen. Meine Überlegung war halt, dafür "Remote Commands" (Direkteingaben) zu benutzen, die keinen Kanal verschwenden. Ich tappe da etwas im Dunkeln, da ich bisher kein Gerät habe das solche Remote-Commands unterstützt und deswegen gar nicht genau weiß, wie das zu benutzen ist. Die Anleitung sagt dazu jedenfalls:
"Der Sender unterstützt bis zu 16 universelle Befehle für die drahtlos verbundenen und EX Bus fähigen Geräte. Eine Übersicht der möglichen Befehle erhalten Sie nach Druck auf die Taste F4 CMD im Menü Modellauswahl / Geräteübersicht. Die möglichen Befehle werden automatisch von dem jeweiligen Gerät ausgelesen und angezeigt."
Es muss also vom Sender eine Anfrage-Nachricht der Art "Hey Sensor, welche Befehle kennst du?" geben, und daraufhin müsste der Arduino dann antworten: "Ich kann Aufnahme starten, stoppen und Foto machen", so dass der Sender dieses Menü aufbauen kann. Diesen Befehlen kann man auch Schalter zuordnen, aber eben unabhängig von Kanälen. Da ein Schalter auch eher vereinzelte Events liefert und nicht kontinuierliche Werteverläufe wie ein bewegter Knüppel, dachte ich irgendwie, es sei zweckmäßiger solche Direktbefehle zu implementieren (jetzt klar geworden was ich meinte?) Wenn aber keine Library dafür existiert, dann ist es vermutlich deutlich einfacher, das über Kanal-Werte zu machen, denn dann bräuchte ich die Kommunikation vom Sender zum Flight-Controller nur mitzulesen und nicht auch noch zu antworten.
Verständnisfrage: diese Direktbefehle haben nichts mit der Jeti-Box zu tun, richtig? Oder ist das die Jeti-Box-Funktionalität?
Was mir jetzt auch nicht so ganz klar ist: in der Dokumentation zum EX-Bus-Protokoll steht, dass Telemetrie-Daten vom Sender gepollt werden und da ist ein Beispiel für eine "Telemetry request" message. Wie kann denn die Library Telemetrie-Daten zur Verfügung stellen, wenn sie keine Nachrichten vom Sender liest, der die Telemetrie doch anfordern müsste?
Sieht so aus, als sei ein rudimentärer EX-Bus-Parser zwar Aufwand, aber jetzt auch kein Rocket Science (klar, geht ja um Quadrokopter). Ich müsste bei allen Nachrichten den Header und die Länge mitlesen, wenn dann eine Nachricht vom Typ 0x31 (channel values) kommt die zwei Byte des jeweiligen Kanals lesen, und bei allen anderen Nachrichten jeweils solange ignorieren bis die angekündigte Länge durch ist. Sollte auch noch hinzukriegen sein.
