Bisher konnten Sensordaten nur via den X-Bus (I²C) an einem TM1000 gesendet werden. Der TM1000 gewinnt auch Daten von eigenen Sensoren, – Voltage, RPM, Temperature.
Die neue Empfängerserie ARnnnnT, z.B. AR9030T, hat den TM1000 sozusagen integriert, der Empfänger als Baugruppe hat selbst ein X-Bus Interface, und er hat auch eigene Sensorschnittstellen, wie sie der TM1000 hat.
Auf dem X-Bus kann ein Gerät keine Servokanaldaten empfangen. Solche gehen “over the air” zu PWM Ports des Empfängers. Der X-Bus ist also sozusagen one-way, nur für Sensordaten, die zum Sender in adressierte Displays geschickt werden.
Adressierung: Unmittelbar nach dem Powerup scannt TM1000 oder ARnnnnT den X-Bus, fragt jede mögliche Adresse (3-125) ab. Wer zu diesem Zeitpunkt antwortet, wird danach reihum mit anderen geantwortet habenden Adressen abgefragt, um die Daten zu übernehmen. Adressen von Sensoren, die TM1000 oder ARnnnnT selbst darstellt, werden nicht gefragt (126, 127). Man kann also als Gerät auf dem X-Bus nicht Vbatt/RPM/Temp im Display “Telemetry” befüllen. Das kann nur TM1000/ARnnnnT selbst mit Daten von seinen eigenen Sensorschnittstellen. (Vorsicht übrigens mit der Masseleitung bei solchen Schnittstellen! Deren Anschließen ist bestens geeignet, sich eine Ground Loop zu bauen, also einen Spannungsoffset auf die Signalmasse zu ziehen.)
Nun gibt es ein weiteres Protokoll neben X-Bus: SRXL
Bisher (Feb 2017) gibt es nur einen Empfänger, der es spricht: SPM4649T. Der nennt sich “Quad Race Serial Receiver”, vermutlich, weil er so klein und leicht ist. Klein ist er, weil er nur ein Interface hat, SRXL, was ein angeschlossener Flight Controller (oder “FBL”) verstehen können muss, – ein Single Line oder Summensignal. Das Gehäuse ist eigentlich keines im herkömmlichen Sinne, – noch mal Platz/Gewicht gespart. Satelliten-Empfänger sind nicht anschließbar. Der 4649T hat aber zwei Antennen, macht Diversity. Nachteilig in größeren Modellen könnte höchsten sein, das sich die Fußpunkte beider Antennen am selben Ort befinden (am 4649T). Man kann die Antennen nicht räumlich verteilen im Modell, man kann sie aber so ausrichten, dass zwei Polarisationsebenen abgedeckt sind. Der 4649T hat auch einen 2-Draht-Anschluß “Laps/Vbatt”, offenbar alternativ für Spannungsmessung oder Impulszählung. Das Manual sag reinweg gar nichts darüber. Bei mir wollte es partout nicht funktionieren. Die momentan verfügbaren 4649T haben ein Hardwareproblem: Die Betriebsspannung ist spezifiziert als 4-8,4V, es heißt aber, dass man den Empfänger mit >7,4V killt.
Die Spezifikation sagt, der Sender müsse 11ms Frame Rate verwenden. (der Rx ließ sich aber auch mit 22ms binden) 4649T unterstützt 11ms 2048 DMSX oder DSM2. Es wird explizit darauf hingewiesen, dass DSM2 aber mit 11ms Frame Rate zu senden ist. “2048″ ist die Resolution der Servokanaldaten, 2048 Schritte. Das sendet der 4649T, und nur 2048.
SRXL ist ein bidirektionales asynchron-serielles Protokoll (1-Wire). Es ist noch nicht fertig. Die Specs kultivieren noch etwas Konfusion mit Missinformation, Papier und Praxis unterscheiden sich.
Busmaster ist der Empfänger (4649T). Er sendet Servokanaldaten. Nach jedem sog. “Phase-0 Paket” kann ein Gerät Sensordaten senden, also nach jedem zweiten Kanaldatenpaket. Das Protokoll, die Media Arbitration dadurch, ist nicht geeignet, um SRXL als Bus betreiben zu können, jedenfalls nicht ohne zu erwartende Probleme. SRXL ist im Wesentlichen ein 2-Device Protokoll.
Daten, gesendet vom 4649T: Das ist momentan ganz simpel das bekannte “Remote Receiver” Protokoll, was ein “Sat” sendet. (Ich sähe auch keinen Effekt darin, es in der Weiterentwicklung von SRXL “einzukleiden”.) Neu/anders ist nur die Gegenrichtung, und natürlich das involvierte Problem für momentan existierende “SAT Implementierungen” in FBL, dass etwas anders ist, wenn man es benutzt: Bidirektionalität auf dem Medium und des Protokolls, Notwendigkeit des erkennenden Trennens der Kanaldaten von Sensordaten.
In der Rückrichtung packt man komplette X-Bus Pakete in einen SRXL Frame. Im Unterschied zum X-Bus wird man nicht gescannt, man kann theoretisch jederzeit einsteigen und seine adressierten Daten senden. In der Praxis sieht es aber nicht ganz so aus.. Das durfte ich bereits mit dem X-Bus feststellen, da ich Sensoren, die S32 auf dem X-Bus darstellt (momentan bis zu 6) setup-abhängig benutzen oder nicht benutzen wollte. Das geht nur zum Teil. Schuld scheint die Firmware der Sender zu sein. Bestimmte Kombinationen oder das spätere “Aussterben” bestimmter Sensoren quittiert sie mit unlogischem Verhalten, wodurch eigentlich nicht beteiligte Displays in Mitleidenschaft gezogen werden. — So auch mit SRXL, sogar extremer. Die empfangenen Daten sehen ja für den Sender wie solche vom X-Bus aus, vom TM1000 oder ARnnnnT. Jedenfalls würde es wieder langer Forschung bedürfen, bis man weiß, welchen Sensor man evtl. “aussterben” lassen darf, ohne, dass der Sender darauf komisch reagiert. Deshalb sendet S32 auf SRXL immer alle 6 Sensoren (Displays), die er potentiell verwendet. Er sendet auch dann Speed, wenn sich kein Speed Sensor im Setup befindet (auf X-Bus kann er sich als Speed Sensor abschalten), dasselbe bezüglich der zwei Displays für Daten von CVS16.
Neu ist: Man MUSS zwei weitere Sensordatenpakete vor seinen eigentlichen senden, “QOS” und “RPM”. In QOS tut S32 seine Betriebsspannung. Der 4649T scheint selbst seine Betriebsspannung nicht zu senden. “RPM” sind die lokalen Sensoren an einem TM1000 oder ARnnnnT, Voltage/RPM/Temp, die der 4649T nur teilweise hat, wenn sie denn funktionieren würden.. Hier, im Gegensatz zum X-Bus, kann man diese Werte für das Übersichts-Display “Telemetry” überschreiben, und S32 tut das auch: ”Voltage”==Ubat, “RPM”==rpmMotor, “Temp”==tFET:
Minimal darstellbare RPM ist 900. Null kann man nicht ausgeben. Man kann es aber als “—–” erscheinen lassen. Das tun wir, “—–”, bis die Drehzahl 900 übersteigt. Auch ein Grund, rpmMotor zu nehmen und nicht rpmRotor. Das Ratio für rpmRotor ist im Sender anwendbar. “Temp”: Wenn der Sender mal kurz Null sah, was sich beim Startup des Ganzen eigentlich gar nicht vermeiden lässt, dann sehen wir “-17″ als minimale Temperatur. Das sind F (Fahrenheit), daher.
Insgesamt gesehen, eine gute Sache: Herzlich kleiner Full Range Empfänger, jede Menge Telemetrie.
Leider bleibt da noch was: Ich wollte doch fernsteuern. Wie bekomme ich die Kanaldaten in mein FBL, vor allem, wenn da S32 mein FBL evtl. verwirrende Daten auf die Leitung sendet? Dann noch: Ich habe gehört, dass mein FBL den 4649T momentan nicht verstehen kann wegen …
Auch dafür gibt es eine Lösung:
S32 verwendet die Aussendungen des 4649T (Kanaldaten) nicht nur zur Synchronisation mit dem Busmaster, er liest sie auch vollständig und zeichnet sie auf im Log, – so, wie er es auch mit Daten auf JETI EXbus und Futaba S.Bus2 tut. Der Anwender hat nun auch die Option, seinen S32 als “Serial Remote Receiver” erscheinen zu lassen, was das FBL momentan vermutlich viel prickelnder findet:
Falls sich das vorhandene FBL auf eine bestimmte “System ID” in den Paketen eines “Sat” (Remote Receiver) eingeschossen haben sollte, dann kann man in S32′s Setup wählen, als welcher Sat er sich ausgibt. Nur ein’s wird momentan nicht unterstützt, 1024 Auflösung.
“22MS 2048 DSMS” sind nicht wirklich 22ms, sondern auch 11ms, – es sei denn, man bindet den 4649T vorschriftswidrig mit 22ms. S32 folgt einfach der Kadenz des Empfängers.
So sieht das dann aus:
Sensor Data Rate:
Zunächst muss man zur Kenntnis nehmen: Diese “22ms” bzw. “11ms” sind nicht die tatsächliche Datenrate, sondern einfach nur der zeitliche Abstand zwischen zwei Datenpaketen. Da es zweier Kanaldaten-Pakete bedarf (daher Phase 0 und 1), sind es also eigentlich 44 bzw. 22ms. Genau mit dieser Kadenz, nämlich nach jedem Phase-0-Paket, darf ein Sensor auf SRXL Daten senden, – je Aussendung für einen “Sensor” == Display-Adresse. Zum Senden von zweien, ursprünglich nicht gewollten, ist man gezwungen, – “QOS” und “RPM/Volt/Temp”, was eigentlich empfängerinterne Daten sein sollen.
S32 verwendet 6 Displays. Das macht dann in Summe 8, ergo braucht es 8*22ms=176ms, um einmal alle Displays zu updaten. Das hört sich viel an, ist aber eher sehr schnell im Vergleich zu anderen Systemen. HoTT, z.B., kennt eh nur 5 Sensortypen (Displays), und es braucht 5*200ms=1000ms, um sie alle einmal zu updaten.
Verfügbarkeit ab Version: S32 app 1.35, S32Terminal 2.1.1.32
Wenn ein FBL das Remote Receiver Protokoll in SRXL versteht, gleichzeitig aber auch bereits in der Lage ist, Kanaldaten von Sensordaten zu unterscheiden, – dann kann man das FBL auch parallel zu S32 mit dem SRXL Port des Empfängers verbinden. — Was zu Problemen führen könnte, ist, wenn das FBL auch selbst Sensordaten senden will. Wie gesagt, SRXL ist eigentlich ein 2-Device Protokoll. Eines ist natürlich, wie auch auf echten Bussen (z.B. HoTT, S.Bus2), zu beachten: Je Display-Adresse darf nur ein Device senden. — Leider ist die Media Arbitration im Protokoll (kein Tun des Busmasters, im Protokoll nur “Idle Line”) nur schlecht geeignet, mehrere Sender von Sensordaten miteinander zu koordinieren. Falls das Senden seitens eines FBL wirklich sinnvoll sein sollte, könnte S32 zukünftig hierfür der “Durchlauferhitzer” sein, somit für Koordination sorgen.
Single Line Protokoll (Summensignal), Konfusion möglich
SRXL.org, wo sich Walter Meyer von Freakware engagiert, beschreibt einen Protokollrahmen, der es ermöglicht, den Vendor einer Aussendung zu erkennen, die enthaltenen Daten damit richtig interpretieren zu können. Jeder Vendor, wie Multiplex, Freakware (Beast), JR (X-Bus B), Graupner (HoTT SUMD), Horizon (SPEKTRUM) hat eine ID, oder mehrere, wenn es mehrere Datenformat-Varianten geben sollte. (SRXL ist die digitale Alternative zum bekannten Summensignal PPM.)
Das Protokoll ist unidirektional (one-way), nur Kanaldaten übertragend. SPEKTRUM allerdings, bisher nicht SRXL verwendend, sondern sein eigenes “Remote Receiver” (aka “Sat” Protokoll), erfand jetzt sein “Bidirectional SRXL”. Der erste Empfänger, der es spricht, ist der SPM4649T. Jedoch ist das nicht nur ein aufgebohrtes SRXL, es ist gleichzeitig KEIN SRXL momentan: Kanaldaten werden nach wie vor im Remote Receiver (Sat) Protokoll gesendet, nicht als SRXL! Man sagt, man hätte SRXL auch für diese Richtung im “Bidirectional SRXL” auf dem Radar, ein Updater für den 4649T würde kommen.
Da kann man nur hoffen, dass dieses SRXL für den eigentlichen Zweck, Kanaldaten, dann auch wirklich SRXL-konform sein wird.. Es gibt bereits auch SPEKTRUM Empfänger, die reines SRXL (one-way) sprechen, allerdings nicht konform, mit der Checksumme (CRC16) machte man Fehler. Der SRXL-Anteil im “Bidirectional SRXL” des 4649T ist jedenfalls auch nicht SRXL-konform bezüglich der Checksumme: CRC nur über den Payload (Kanaldaten), die beiden Bytes des CRC16 in der verkehrten Reihenfolge mit Bezug zu SRXL.org.
Nun sollte klarer sein, warum ein Gerät den 4649T als “Sat” lesen können sollte. Fraglich bzgl. dieses Gerätes ist dann nur jeweils, ob es damit klar kommen wird, wenn in der Gegenrichtung Sensoren in SRXL senden. Schließlich kann so ein Gerät ja nicht ursprünglich darauf vorbereitet gewesen sein. Es könnte also passieren, dass Sensordaten als Kanaldaten interpretiert werden! Das ist der Grund, weshalb ein S32 im Setup für Telemetrie “SPEKTRUM SRXL” optional anbietet, auf einem anderen Port als Remote Receiver (“Sat”) die enthaltenen Kanaldaten wieder auszusenden.
SRXL.org ist wahrscheinlich der einzige Standard, der sich je in RC entwickelte, ein zartes Pflänzchen. Selbst auf der anderen Seite des Teiches nahm man in zur Kenntnis. Man benutzte ihn. Ich sage absichtlich “benutzte”, weil man ihn nicht respektierte. Nun habe ich angefragt bei Horizon wegen “Bidirectional SRXL”, was dann auch das eigentliche SRXL enthalten soll, Rx–>FBL. Ich bat darum, sich doch bitte an den Standard zu halten bezüglich CRC: “PLEASE put the CRC(s – both directions) SRXL.org conform.” Die Antwort: “The CRC will not change order or content.”
Die minimale Verzögerung Knüppel zu FBL beträgt 22ms in einem 11ms System, weil Kanaldaten in zwei Paketen gesendet werden. S32 empfing Remote Receiver Daten (Sat) erst, dann sendete er sie durch einen anderen Port wieder aus, – frei von “SRXL bidirectional”. Das addierte etwas Extra-Latenz von etwa 1,4ms.
Nun (seit app 1.39) sendet S32 puren Remote Receiver parallel zum Empfang dieser Daten. Die extra Verzögerung reduziert sich dadurch auf 95 Mikrosekunden:
