D.I.Y. - Wireless Alarm and Telemetry with two XBee
Alarme wireless zum Piloten bringen.. Das ist im Augenblick in JLog2 implementiert:
Wer diese Telemetrie hat, hat auch Alarme am Sender. Allerdings gibt es derzeitig Trauer, und damit auch für Alarme “unten”, mit FASST, und mit Spektrum und Hitec im gegenwärtigen Status, mit etlichen Systemen mehr, die ich gerade gar nicht im Detail kenne. Thema ist also für den interessierten Leser: Wie mache ich es wireless trotz der Handicaps meines R/C-Systems? Nun, viele Wege führen nach Rom, manche auch nur in die Sackgasse. Hier soll nicht auf 433MHz geklingelt werden, hier machen wir es “professionell” auf 2,4GHz mit DSSS, sprich, mit Digi’s (ehemals Maxstream) XBee. Immerhin basiert auch XPS/IFS auf diesen OEM-Moduln. 
So könnte es aussehen, wenn man nur die beiden Alarmleitungen des Logger “runter bringen” will:
Das Ganze passiert ohne zusätzlich implementierte Funktion im Logger per sog. “Line Passing”. Die beiden XBees bekommen jeweils ein Profil, was bewirkt, dass der Status digitaler Eingänge des Air-Moduls auf digitale Ausgänge des Base-Moduls 1:1 übertragen wird
Man hängt nun einen Alarmgeber an den Ausgang eines Base-Moduls, im einfachsten Fall direkt oder via eine Treiberstufe (1 Transistor) einen Piezo Buzzer. Der würde nun einen Dauerton geben im Alarmfalle. Um den Eigenbau einer Intervallschaltung zu ersparen, beabsichtige ich, zukünftig die Alarmleitungen des Loggers wahlweise (JLC) zu takten, bei Alarm im Intervall, oder es wird ein Morsezeichen je Alarmtyp gegeben, also ‘a la JETI. Durch das Morsezeichen entsteht der Vorteil, dass die Alarmtypen auch akustisch unterscheidbar sind, meiner Meinung nach besser als mit unterschiedlichen Tonhöhen. - Wegen des verwendeten “Line Passing” müssen die XBees vom Typ “802.15.4″ bzw. “Serie 1″ sein!
Es ließe sich nun erweitern zu einer vollständigen Telemetrie, also mit Display der Momentandaten und alarmierender Daten. Leider schließt sich dabei das Verwenden einer JETIbox (und damit bereits implementierter Display-Funktion) aus, das hat zwei Gründe: Erstens ist das ein 1-Wire-Protokoll. Man müsste das erst mit zusätzlicher Hardware vor dem Air-Modul in Zweidraht umwandeln, bevor es seriell übertragen wird, dann hinter dem Base-Modul wieder zu Eindraht machen, um es in die JETIbox einspeisen zu können. Der zweite Grund ist schwerwiegender: Das Terminalprotokoll von JETI basiert auf 9 Datenbits pro Zeichen, die serielle Schnittstelle der XBees unterstützt aber nur 8 Datenbits. Man könnte nun versuchen, das serielle JETIprotokoll auch per “Line Passing” zu übertragen. Ich habe das nicht probiert, es könnte u.U. hinsichtlich des Timing kritisch werden.
Daher setze ich auf ein anderes Terminal, eines, was mit 8 Datenbits pro Zeichen arbeitet. Das ist hier das Unidisplay von SM-Modellbau, es bringt uns den zusätzlichen Vorteil vierfacher Display-Kapazität, verglichen mit bisherigen JETIboxen, 8 x 16 Zeichen. Das Display ist viel kleiner und leichter als eine JETIbox, allerdings sind die Zeichen auch kleiner. Eine Display-Beleuchtung gibt es nicht, aber das hat die “klassische” JETIbox auch nicht.
my favored –>
<–
Obige Lösung ist meine präferierte, es ist die, die ich auch für mich selbst sehe, ich bin Spektrum-User, – dessen Telemetrie ist im Augenblick ungeeignet für einen Multisensor wie JLog.
Bevor nun noch ein paar Worte zu XBee kommen, – die Dinger werden nicht gerade unmissverständlich vermarktet, – hier noch andere mögliche Varianten für JLog-eigene Telemetrie, die ich teilweise testete, dann aber zugunsten obiger Variante verwarf:
Die binären Datenpakete des JIVE kommen als 8 Datenbits pro Zeichen. Nichts ist also einfacher, als das Kabel zwischen JIVE und JLog durch die Luft zu verlängern. Habe ich gemacht, funktioniert. Allerdings beeinflusst es das Log im Falle schlechter Verbindung, – und das Log hat einfach Priorität. Außerdem muss man dabei eine Sache vergessen: JLog-eigene Sensoren, der Logger ist ja “unten”.
Rein technisch am besten, weil am flexibelsten, wäre es, eben auf beiden Seiten einen Microcontroller zu haben, den wir benutzen können (in der Hand haben), also sinnvollerweise einen JLog oben und einen unten, Firmware und JLC dafür aufgebohrt. Der JLog oben loggt, damit ist maximale Sicherheit für das Log gegeben. Er sendet dann als Livestream das Binärprotokoll des JIVE, ergänzt um Daten der JLog-eigenen Sensoren. Die Alarme bildet der Logger am Boden und gibt sie über seine Alarmleitungen an einen geeigneten Alarmgeber. Er kann zusätzlich auch loggen, muss es aber nicht (ohne SD, die Firmware muss diese Betriebsweise dann unterstützen). Als Display kommt somit auch eine JETIbox in Frage, oder eben zukünftig alternativ das Unidisplay. Hier wären auch XBees der Serie 2 verwendbar (XBee Pro ZB), weil “Line Passing” nicht gebraucht wird. – Ja, Leute, ich bin mir leider ziemlich sicher, dass Ihr das nicht mögen würdet, des Geldes wegen..;)
Inzwischen sieht es so aus:
Nun zu den XBees:
Seitens der Strahlungsleistung (Output mal Antennengewinn) in Frage kommen nur die XBee Pro. Man muss eigentlich;) beachten, dass nach den Bestimmungen in Europa und DE, also seitens der ETSI, es nicht gestattet ist, so ein XBee Pro mit dem maximal möglichen Output von 63mW zu betreiben (mit Boost Mode, sonst 50mW). Ein XBee Pro der Serie 1 (802.15.4) kann (muss) per Setup (Profil) auf ca. 10mW Output reduziert werden. Ein XBee Pro der Serie 2 (ZB) unterstützt das nicht, stattdessen gibt es hier die “International Variant”, die die Ausgangsleistung fest auf ca. 10mW reduziert. Witzigerweise findet sich diese Variante in Deutschen Shops gar nicht;), da gibt’s nur XBee (ohne “Pro”) mit 1 bzw. 2mW und XBee Pro “volle Pulle”.
Braucht man “Line Passing”, kommt z.Z. nur Serie 1 (802.15.4) in Frage!!! Die Serie 2, als “ZNET” oder “ZB” oder “DigiMesh 2.4″ gehandelt, kann kein “Line Passing”! Um diese (Serie 2) benutzen zu können, müsste der JLog vor dem Air-Modul das unterstützen, sog. “Remote AT Commands” via den XBee in der Luft an das Base-Modul senden, um dort die digitalen Ausgänge zu setzen. Das Air-Modul kann ruhig im sog. “AT-Mode” betrieben werden, das Base-Modul muss dazu aber im “API-Mode” sein. Ich schlage aber vor, wir nehmen generell nur XBee Pro 802.15.4, Serie 1.
Die Bezeichnung “Serie n”, von Digi ursprünglich eingeführt und nun wieder zurückgenommen, war irreführend, denn sie suggerierte, dass Serie 2 der verbesserte Nachfolger von Serie 1 ist. Das ist aber nicht der Fall! Ein XBee Pro 802.15.4 (ehemals Serie 1) ist die “alte” Version mit einem Protokollstack nach IEEE 802.15.4. Ein XBee Pro ZB oder ZNET (älter) oder DigiMesh ist ehemals Serie 2. Beide Generationen können nicht miteinander kommunizieren! Die neue Serie unterstützt auch vermaschte Netzwerke (Mesh), die alte nur Punkt-zu-Punkt und Stern, aber das reicht uns ja, wir wollen P2P, mehr nicht.
Generell: Für “Long Range” Anwendungen schließt sich die Variante mit der Chip-Antenne eigentlich aus. Beim XBee Pro 802.15.4, dem “Objekt der Begierde”, bekommen wir hierfür einen Lambda/4 Vertikalstrahler, fest mit der Platine des XBee verbunden. (Das entspricht, nebenbei bemerkt, XPS/IFS.) Bei Serie 2, die wir besser bleiben lassen, gibt es neben dieser Antenne auch eine Variante mit Koaxbuchse, RPSMA, Reverse SMA, da passt eine “Gummiwurscht” (i.Allg. ein Dipol) drauf, wie sie die meisten WLAN Access Points für 2,4GHz oder Dualband und JETI benutzen. – Die Version mit Hirose U.FL Koaxverbinder auf der Platine scheint es nicht oder kaum mehr zu geben. Abgesehen davon, dass man einen passenden Koaxstecker, der ein Weibchen ist, brauchte, um die Antenne anzuschließen, ist das die platzsparende Version ohne feste Antenne. – Hier gibt es ein paar Informationen mehr zu den XBee-Antennen.
Es gibt also einen Pferdefuß! Nicht ohne Grund hat XPS/IFS, ebenso wie all die vielen anderen DSSS-R/C-Systeme, das Frequenzhopsen implementiert, also XPS/IFS auf der applikativen Seite des XBee. Man hätte ja auch die Ausgangsleistung reduzieren können für Europa, Japan etc. Hat man aber nicht! Warum wohl?;) – Okay.., die Europäischen Spektrum-User und ihre Modelle haben es auch überlebt (meine auch), allerdings hatte Spektrum nicht soo weit den Output reduziert, man berief sich auf die Zweikanalnutzung des Bandes, was XBee nicht macht. Nun, ETSI und BNA mussten wohl alle Hühneraugen zudrücken, – Spektrum hat sich mit DSMX (hopsasa) nun aus dem Schneider gebracht.
In diesem Selektor http://www.digi.com/xbee/selector.jsp kann man sich schlau machen, so sähe unsere Selektion nach der Reichweite aus
und das bliebe dann übrig für Serie 1, 802.15.4 mit “Line Passing”:
