Becon EVO3 modifiziert

Die Steuerelektronik kommt von flugmodellbau.de in Form des Beacon-EVO3. Dieses Modul erlaubt die direkte Ansteuerung der bekannten Luxeon Emitter LEDs. Das Modul steuert Blitzer und Dauerlichter. Leider werden die Dauerlichter erst nach den Blitzer eingeschalten. Das funktioniert prima für Landescheinwerfer aber nicht für die Positionslichter. Darum habe ich das Modul entsprechend modifiziert.

*** Warnung! ***
Mit der Umsetzung der folgenden Beschreibung verlieren Sie die Gewährleistung des Herstellers.

Die Signale LED1+2 vom Prozessor zum LED Treiber verlaufen auf der Unterseite wie im Bild angezeigt. Die Verbindung muss an geeigneter Stelle unterbrochen werden. Das geht am besten mit einem Dremel und einem kleinen Diamantfräser. Die abgetrennten Leitungen werden anschliessend mit dem Pluspegel des Prozessors!verbunden. Nach einem Funktionstest das Modul neu einschrumpfen, Fertig!

Unilog goes Wireless (reloaded)

‘Drahtlose serielle Datenübertragung auf 2.4GHz’, das war der alte Titel dieses Projektes. In diesem Fall kommen die Daten vom Unilog, einem feinen und kleinen Datenlogger aus dem Hause SM-Modellbau in Deutschland. Und weil dieses Projekt eng an den Unilog angelehnt wird, habe ich den Titel zu seinem Gunsten umbenannt. In einem ersten Schritt werden die Daten auf dem originalen Unilog Display angezeigt. In einem weiteren Projekt kommt dann ein eigenes 2″ Farbdisplay zum Einsatz, das zusätzliche Funktionen hat.

Komponenten
Als Hauptkomponenten kommen der Unilog und das dazu erhältliche Display zum Einsatz. Für die Übertragung der Daten per Funk verwende ich die XBee-Module der Firma MaxStream. Das XBee-Pro Modul unterstützt die maximale in Europa zulässige Sendeleistung von rund 18mW. Die Reichweite wird vom Hersteller mit rund einer Meile angegeben. Wie weit man wirklich kommt wird die Praxis erweisen.

Unilog
Dies ist die Beschreibung auf der Webseite von SM-Modellbau;

Mit dem kleinen leistungsstarken RC-Datenlogger können Spannung, Strom, Leistung, Kapazität, Drehzahl, Temperatur und Höhe in einem Modellflugzeug gemessen, gespeichert und anschliessend bequem mit unserem UniDisplay direkt vor Ort oder nachträglich am PC bzw. Laptop ausgewertet werden.
Unilog-Display
Angaben von SM-Modellbau

Anzeigedisplay für unseren InfoSwitch und UniLog. Alle Messwerte können live angezeigt und Parameter direkt eingestellt werden.
Maxstream Xbee-Pro
Die XBee-Module werden grundsätzlich in der drahtlosen Sensortechnik verwendet, eignen sich aber wegen ihrer Flexibilität ausgezeichnet für diesen Zweck. Technologisch funktioniert es ähnlich einem Netzwerk (ZigBee/IEEE 802.15.4). Mehr über die Möglichkeiten dieses Moduls kann man bei MaxStream erfahren.

Funktionsprinzip
Original wird das Display wird mit einem Kabel mit dem Unilog verbunden. Die Daten werden dann per RS232/TTL gegenseitig übermittelt. Um nun die Daten Wireless übertragen zu können, müssen die Daten aufbereitet und mit den XBee-Modulen übermittelt werden. Das würde theoretisch auch direkt ohne zusätzliche Prozessoren funktionieren, doch bekanntlich steckt der Teufel im Detail.

– Da wäre zum einen die Baudrate, mit der zwischen Unilog und Display kommuniziert wird. Diese ist mit 115200 so hoch , dass bei direkten Senden zum XBee Bitfehler auftreten. Eine Anfrage beim MaxStream-Support hat ergeben, dass das XBee-Modul exakt 111’000 Baud hat. Das ergibt sich aus einem internen Takt von 1 MHz und dem Vorteiler (1 MHz / 9). Darum muss hier ein Prozessor mit USART-Schnittstelle eingesetzt werden.

– Der verwendete Mikroprozessor enthält nur eine USART-Schnittstelle. Um Daten trotzdem an das XBee-Modul senden zu können wird dieser Teil der Kommunikation per Software-RS232 implementiert. Welche Konsequenzen das für die Software bedeutet, erläutere ich im Softwareteil.

– Man kann die XBee-Module auf zwei Arten betreiben, Transparent oder im API-Mode. Jede Betriebsart hat ihre Vorzüge und Schwächen. Im Transparent-Modus werden alle Zeichen die ein Modul empfängt an das andere Modul weitergeleitet und dort wieder ausgegeben. Die Programmierung des Moduls muss mit einer speziellen Sequenz eingeleitet werden. Im API-Modus kommt ein einfaches Protokoll zum Einsatz, in der alle Nutzdaten und Einstellwerte in einen sogenannten Frame verpackt werden. Der Frame enthält zusätzliche Informationen wie zum Beispiel die Zieladresse, Status des Transfers oder die Signalestärke des soeben empfangenen Frames.

Hardware
Das Schema beschränkt sich auf die Verdrahtung der einzelnen Hauptkomponenten. Für Statusanzeigen sind drei LEDs vorgesehen, wo von eine direkt von dem XBee-Modul angesteuert wird. Für eine erleichterte Erstinbetriebnahme ist ein Programmierport vorhanden. Es ist auch möglich, per Bootloader über die Unilog/Display Schnittstelle das Programm hochzuladen.

Die Anschlussleisten des XBee-Moduls haben einen 2mm Raster. Es sollte aber keine grossen Probleme bereiten ensprechende Buchsenleisten zu bekommen. Dadurch lassen sich die Module auch nicht direkt auf einer Lochrasterplatine betreiben. Eine kleine Platine in etwa der gleichen Grösse wie ein XBeePro-Modul beherbergt alle erforderlichen Komponenten.

Die Variante für den Unilog kann einseitig ausgeführt werden. Die Versorgung mit Spannung erfolgt direkt über das Unilog. Die Variante fürs Display ist fast exakt die gleiche wie für den Unilog. Es kommt nur noch ein Spannungsregler hinzu, der die geforderten 3.3V für den Prozessor und das XBee-Modul bereitstellt. Diese Platine ist doppelseitig ausgeführt, weil der Spannungsregler auf der oberen Seite Platz finden musste.

Software
Kommunikation: Aus der hohen Baudrate von 115200 Baud für die Kommunikation mit dem Unilog und dem Display ergeben sich ein paar Schwierigkeiten die es zu umschiffen gilt. Der verwendete Prozessor ATMEL AVR48/88/168 hat nur ein hardwareseitiges USART. Die Verbindung zum XBee-Modul muss darum mit einer Softwarelösung gemacht werden. Es entstehen dadurch aber Probleme im Timing auf die ich hier etwas genauer eingehen möchte.

Zum ersten Verständnis etwas Kopfrechnen:

Baudrate Unilog = 115200
Baudrate XBee = 38400

115200 Baud = ca. 11520 Zeichen/sek. = 0.086ms pro Zeichen
38400 Baud = ca. 3840 Zeichen/sek. = 0.26ms pro Zeichen = 0.026ms pro Bit (Startbit + 8 Datenbit + Stopbit)

Der Unilog sendet die Daten alle am Stück, das heisst, die Bytes im Datenpaket haben keine ‘Luft’ dazwischen. Das Status-Datenpaket hat eine Grösse von 24 Bytes. Das sind rund 2.1 ms Übertragungsdauer. Wenn also der Unilog Daten sendet, wird während 2.1ms alle 0.086ms die entsprechende Interruptroutine zum Abholen des Zeichens aufgerufen. Würde in dieser Zeit mit der XBee kommuniziert, gingen bei der XBee unvermeidlich Zeichen verloren. Es muss also auf eine zeitliche Trennung der Kommunikation geachtet werden.

Timing Unilog: Ein Statusrequest an den Unilog wird in maximal ~3ms beantwortet. Nach Tests am Oszillografen schwankt diese Zeit zwischen quasi 0 und 3 ms. Es deutet darauf hin, dass der Unilog Requests in festen Intervallen abarbeitet.

Timing Display: Bei Anschluss an die Stromversorgung versucht der Prozessor im Display einen Kontakt mit dem Unilog zu erhalten. Ein erster Versuch, Daten direkt über das XBee im transparenten Modus zu senden, ist wegen den zu hohen Latenzzeiten des XBee gescheitert. Das Display erwartet eine Antwort in den oben genannten ~3ms. Wie weit die Antwort hinausgezögert werden kann, habe ich nicht getestet.

Timing XBee: Die Xbee wird im aus praktischen Gründen API-Mode 2 betrieben. Für das Empfangen und senden von Daten ergeben sich darum einige Besonderheiten. Bevor Daten gesendet werden können, muss ein API-Datenframe erstellt werden. Darin ist die Zieladresse, die Checksumme und weitere Informationen enthalten. Nach dem Übermitteln des Frames quitiert die XBee mit einem weiteren Frame, wie die Übermittlung an das Ziel verlaufen ist. Dieses Frame wird nach einigen 10ms gesendet. Daten, die die XBee von aussen erhält, werden sofort in einem Frame an den Prozessor übermittelt. Wenn man sich die Timingangaben der verschiedenen Baudraten vor Augen hält, ergeben sich für die XBee folgende Übertragungszeiten;

Requestframe: Grösse = 10 Bytes = 2.6ms = während 2.6ms alle 0.026ms einen Interrupt für das Senden eines Bits
Responseframe: Grösse = 10 Bytes = 2.6ms = während 2.6ms alle 0.026ms einen Interrupt für das Senden eines Bits
Datenframe: Grösse = 30 Bytes = 7.8ms = während 7.8ms alle 0.026ms einen Interrupt für das Empfangen eines Bits

Damit aber das XBee nicht einfach beginnt Daten zu senden, wird die RTS-Leitung verwendet. Erst wenn ‘die Luft rein ist’ wird die Kommunikation freigegeben und anschliessend auf einen eingegangenen Datenframe geprüft.

Timing des Ganzen: Damit die ganze Kommunikation aneinander vorbei passt, muss man eine geeignete Strategie entwickeln. Das Hauptproblem entsteht, weil der AVR nur einen USART hat. Ein grösserer Prozessor mit zwei USARTS gibt es zwar, jedoch ist sein Preis hoch und die Bauform für einen Selbstbau ungeeignet.

Nachtrag (3.12.2008)
Die Daten zwischen Unilog und Display können auch mittels Bluetooth-Modulen übertragen werden. Eine genauere Beschreibung findet sich hier

Software
MaxStream XBee/XBeePro API-Mode 2 Lib fuer Bascom V1
MaxStream XBee/XBeePro API-Mode 2 Lib fuer Bascom V2

Links
XBEE Modules

Über dieses Thema in Modellbauforen:
UniLog über 2.4GHz DSSS Funkmodul drahtlos auslesen
verkauft eure analogfunken, solange sie noch jemand will
OPEN SOURCE 2.4GHz SS System

Kleiner Schalter mit grosser Ausstrahlung

Dieser elektronische Schalter ist klein und hat ein separates Bedienpanel. Damit bleiben die Wege vom Akku zum Verbraucher kurz, und das Bedienteil kann an geeigneter Stelle im Modell montiert werden. Die Akkuspannung wird mittels zweier LED dauernd signalisiert und dank stromsparendem Mikroprozessor kann der Schalter dauerhaft am Akku verbleiben.

Weniger ist mehr
Ich wollte für meinen kleinen Segler einen Schalter, der mir neben dieser Grundfunktion auch noch Angaben über die momentane Spannungslage des Akkus machen kann. Zuerst sind die Eckdaten, wenn auch nur grob, festzulegen.

Pflicht

  • Betriebsspannung 3.6-7V (Arbeitsbereich von 4-5 Zellen NiCd/Mh)
  • minimaler Strom 3A Dauer / 10A Peak
  • Statusanzeige der Akkuspannung über verschieden farbige LEDs (Grün-Rot)
  • einfache mechanische Herstellung wegen eingeschränkten Fertigungsmöglichkeiten (Einseitige Printplatte)
  • Einsatz vom SMD Technologie
  • Verwendung eines Mikrokontroller
  • als Besonderheit sollen der Taster und die beiden LEDs auf einer separaten Platine montiert sein und mit einem Kabel zur Hauptplatine verbunden werden.

Kür

  • stetiger Verbleib am Akku auch nach dem Flug und bei Lagerung im Hobbykeller
  • Statusanzeige der Akkuspannung während der Lagerung
  • Möglichkeit für den Betrieb mit anderen Akkutypen / Zellenanzahl

Entwicklung
Als Mikrokontroller habe ich mir die Reihe ATTiny von Atmel ausgesucht. Für diese Reihe sind viele professionelle Programme verfügbar, die zuweilen mit limitierten Funktionsumfang auch kostenlos genutzt werden können. Im diesem konkreten Fall ist es der Atmel ATTiny13V. Was dieser uP zum Leben braucht ist schnell beisammen; Spannung zwischen 1.8 und 5.5V und ein bei der vorgesehenen Beschaltung den Pullupwiderstand für den Reset-Pin.

Der ATiny13V besitzt mit der Grösse von 8X8mm einen ausgewachsenen 8-Bit Prozessor, 1kB Flash-ROM für das Programm, 128 Byte RAM für temporäre Programmdaten, 128 Byte EEPROM für Daten die auch nach dem Auschalten erhalten bleiben (ich komme darauf zurück), sowie 5 A/D Wandler. Der Baustein besitzt noch weitere, hier nicht erwähnte Funktionen und dafür braucht er gerade mal acht! externe Anschlüsse (SOIC8).

Funktionsweise
Über einen Taster soll der Schalter bedient werden. Im eingeschalteten Zustand soll die eine LED (grün) diesen Betriebszustands mit Dauerlicht anzeigen. Die zweite LED (rot) signalisiert die aktuelle Spannungslage des Akkus. Damit während des Fluges und beim Hantieren mit dem Modell keine ungewollten Schaltzustände auftreten, muss der Schalter wie folgt aktiviert und deaktiviert werden;

  • Einschalten: Taste länger als 0.5 sek. im ausgeschalteten Zustand drücken
  • Ausschalten: frühestens nach 3 sek. ohne Tastendruck, den Taster drücken bis die grüne LED schnell zu blinken beginnt (1 Sek.), jetzt den Taster wieder loslassen und die zweite Blinkfrequenz abwarten. Dann nochmals den Taster drücken: AUS.

Hardware / Software
eswitch_pcb / eswitch_source_v7

Licht ins Modell – Drehlicht

Drehlichter werden auf Fahrzeugen und Flugzeugen zur Gefahrensignalisation verwendet. Basierend auf dem Arduino-Board wollte ich ein Drehlicht entwickeln, dass einem Original annähernd nahekommt. Der Hauptunterschied zum Original liegt in der Erzeugung der Rotationsbewegung des Lichtes. Richtige Drehlichter haben eine zentrale Glühbirne um die ein Hohlspiegel rotiert. Beim Modell behilft man sich gerne, in dem man einige LEDs im Kreis anordnet und als eine Art Lauflicht ansteuert.

Bei dem hier vorgestellten Typ handelt es sich um ein Zweistrahldrehlicht, wo der Lichtstrahl auf zwei Seiten entgegengesetzt abgestrahlt wird. Inspiriert durch kommerzielle Produkte wurden folgende Eckdaten festgelegt:

  • 8 LEDs, jeweils zwei rote LEDs parallel/seriell geschalten
  • einfachste Ansteuerung ohne Leistungsstufe (geeignet für kleine Modelle, max. 20-30mA)
  • weicher Übergang durch PWM-Ansteuerung

Das Funktionsprinzip ist einfach. Die LEDs werden zeitlich versetzt linear von 0 auf 100% Helligkeit hochgefahren und in gleicher Weise wieder auf 0% abgesenkt. Während die eine LED seine Helligkeit verringert, steigert die nachfolgende LED die ihre. So entsteht der Eindruck, dass sich das Licht quasi nahtlos weiterbewegt. Einen wesentlichen Anteil am realistischen Eindruck haben Art und Anordnung der LEDs. Acht LEDs stehen im 45 Grad Winkel zueinander. LEDs mit einem Leuchtkegel von mehr als 45 Grad Öffnungswinkel sind dabei besser geeignet als LEDs mit lediglich 20 Grad . Ein schmalerer Leuchtkegel wird in weiterer Entfernung unbeleuchtete Bereiche zurücklassen und somit den Effekt unterbrechen. Am besten sind kleine LEDs mit kugelförmiger Abstrahlcharakteristika. Für PowerLEDs muss aber zwingend noch eine Leistungsstufe vorgeschalten werden. Kühlung unbedingt beachten.

Software
Für die PWM der LEDs wird aktuell ein Timerinterrupt mit 0.5ms Intervall verwendet. Ein Zähler startet mit 0 und wird mit jedem Interrupt um Eins erhöht. Ist der Zähler kleiner als die geforderte LED-Helligkeit (LEDxDutyCycle) wird die LED eingeschalten. Überschreitet der Zähler beim nächsten Interrupt diesen Wert, erlöscht die LED. Erreicht der Zähler das programmierte Maximum (20), wird der Zähler auf Null gesetzt und ein PWM-Zyklus startet von neuem.

timings

Der Plan, die Helligkeit in 1% Schritten zu steuern scheiterte wegen Timingproblemen. Die Programmlänge der Interruptroutine ergibt sich konkret aus der Anzahl separat angesteuerter LEDs und den Plausibilitätschecks. Dauert die Verarbeitung zu lange, unterbricht sie das freilaufende Hauptprogramm immer mehr und führt damit zu Störungen. Da die Interruptroutine auch das Timing des Hauptprogramm steuert, sind zudem Interferrenzen aufgetreten. Als ersten Schritt habe ich die Anzahl der Helligkeitsstufen auf zwanzig reduziert. Das sollte für einen optisch weichen Helligkeitsverlauf noch ausreichen. Im Gegenzug konnte der Intervall der Interruptroutine ebenso um den Faktor fünf verlängert werden, Die Störungen im Hauptprogramm sind damit behoben. Diese Software lässt sich auch sehr gut in reinem Assembler programmieren.

Source: Licht im Modell – Drehlicht

Hardware
Weil die Hardware so einfach ist, habe ich kein Schema hinzugefügt. Es genügen vier normale I/O-Ausgänge eines ATMEL Prozessors. Je I/O Port werden die zwei, sich gegenüberliegenden LEDs angeschlossen. Ob in Serie oder parallel spielt keine grosse Rolle. Meine Ansteuerung arbeitet mit positiver Logik. Alle LEDs werden auf der Kathode zusammengefasst und mit einem 100 Ohm Widerstand gegen Masse geschalten. Ist zwar Quick&Dirty, aber ausreichend fürs Prinzip.

ledkranz

Natürlich sind im Bascom Programm die entsprechenden I/O Ports Euren Erfordernissen anzupassen. Auch sollte der Timer passend eingestellt werden.

Videos
drehlicht_langsam / drehlicht_schnell

Pilatus Porter von MR-Aerodesign

November 2007. Die Winterzeit hat Einzug gehalten, es ist bereits Nacht wenn man nach der Arbeit nach Hause kommt. Was also liegt näher, als in den Keller hinabzusteigen und ein neues Bauprojekt in Angriff zu nehmen.

 

Das Projekt in diesem Winter heisst PC-6. Zuerst als kleine Variante mit 1200 mm Spannweite. Ein Bausatz der Firma E*STAR MODELS bringt mich nach Jahren der Abstinenz wieder zurück zu Balsastaub und Leimgeruch. Gerade richtig, um mich mit den Eigenheiten eines vom Laser geschnittenen Baukasten vertraut zu machen. Auf RC-Groups gibt es ein Review davon.

Das eigentliche Objekt ist eine PC6 mit doppelter Spannweite, gelasert von Martin Rousseau aus Kanada. Unter dem Label MR-Aerodesign vertreibt er verschiedene Modelle in diversen Grössen. Er hat mir extra einen Baukasten für 2m Spannweite gefertigt. Der Kasten sieht super aus, hat sehr viel Holz und eine tolle Dokumentation auf CD mit vielen Detailaufnahmen von Originalen dieses Flugzeugtyps.

Das Modell ist ein reinrassiger Holzbausatz der lasergeschnittene Bauteile und diverse Platten und Leisten enthält. Die Laserbearbeitung ist gut bis sehr gut und die Teile lassen sich meist sehr leicht aus dem Holz lösen. Ein Papprohr mit dazu passendem 16mm Alurohr als Tragflächenverbinder runden den Inhalt ab. Kleinteile, eine Motorhaube oder das Fahrwerk sind bei dieser Baukastenversion nicht vorhanden. Diese Modellgrösse ist eine Sonderedition und wird wohl nur in unbedeutenden Stückzahlen gefertigt.

Der Baukasten
Im Baukasten enthalten sind mehrere excellente Baupläne. Mit dabei ist ein Teileplan auf dem jedes Teil abgedruckt ist. Damit lassen sich im Reparaturfall leicht die benötigten Ersatzteile herstellen. Eine Mappe mit CAD Baustufenbildern und eine CD mit vielen Bildern einer PC-6 und weiteren Informationen zum Modell runden den Baukasten ab.

Der Bausatz setzt Kenntnisse im Bau und Auslegung von Modellen dieser Grössenklasse voraus. Es sind keine Angaben über die zu verwendenden Klebstoffe oder zum Einbau der Anlenkungen und Elektronik vorhanden. Wenn man einmal mit dem Bauen begonnen hat, kann man fast nicht mehr aufhören. Das gilt besonders für die Bausätze, bei denen man sichtlich weiterkommt und nicht dauernd über ungeklärte Details stolpert. Nun gut, dieser Bausatz ist nicht perfekt. An einigen Stellen passen die Schlitze nicht, und für das Rumpfgerüst wurde auschliesslich Pappelsperrholz verwendet. Trotzdem passt fast alles erstaunlich gut zusammen.

Der Rumpf wirkt bei bei diesem Bausatz extrem massiv und dadurch unnötig schwer. Nach Rückfrage bei MR hat auch er ein zu hohes Gewicht für diesen ersten Bausatz bestätigt. Meine Modifikationen betreffen daher hauptsächlich das Gewicht. Ich habe alle möglichen Sperrholzstücke zusätzlich gelocht und einige Spanten schmaler gesägt. Die Gewichtseinsparung beträgt rund 25%. Für einen bequemen Transport im Kombi wird der Rumpf teilbar ausgeführt. Darum kommt ein zusätzlicher Spanten dazu.

Der Bau des PC-6 ist zügig vorangeschritten. Gerade noch an den Hauptarbeiten am Rumpf, sind jetzt Seiten- und Höhenruder fertiggestellt. Die Flügel sind fast fertig und warten auf die Beplankung. Die Landeklappen und Querruder sind in der Endphase.

Stromversorgung
Zur Stromversorgung kommt ein DPSI-BIC zum Einsatz. Daran angeschlossen werden zwei Eneloop 5-Zellen Akkus. Erste Tests ergaben eine nutzbare Kapazität von rund 3500 mAh. Die PC-6 bekommt eine Beleuchtung. Zwei Positionslichter (rot/grün) an den Flügelenden, zwei Landescheinwerfer, ein ACL und ein Blinklicht auf dem Seitenruder erlauben sicher noch Flüge in der Abenddämmerung.

Im Dauerbetrieb müssen die Luxeon LEDs gekühlt werden. Ich habe sie auf rund 17mm lange Aluröhrchen mit 7mm Durchmesser geklebt. Zwei kleine Platinenstreifen führen die Anschlüsse nach hinten. Ein Stück Schrumpfschlauch isoliert gegen Kurzschlüsse.

Die Steuerelektronik von flugmodellbau.de habe ich speziell angepasst. Die Idee dabei ist, dass bereits beim Einstecken der Antriebsakkus die Positionlichter in den Flügeln leuchten. Das ist eine perfekte Kontrolle ob der Antrieb eingeschalten ist. Das Blinklicht auf dem Seitenruder wird zusammen mit der Empfängerversorgung aktiviert. Sobald am Sender der Motor per Schaltfunktion scharf gestellt wird, beginnt das ACL zu blitzen. Die Landescheinwerfer werden über eine Flugphase aktiviert.

Die Landeklappen der PC-6
Im Plan von MR-Aerodesign sind die Landeklappen mit Vorflügel gezeichnet. Dass es diese wirklich gibt, ist in der Scale-Dokumentation auf der mitgelieferten CD ersichtlich. Doch lohnt sich der Aufwand wirklich? Da ich nicht Scale baue, wohl eher nicht. Jetzt füllt ein Balsablock den ‘nicht benötigten’ Zwischenraum.

Zur Kontrolle ob das Profil stimmt, habe ich mir aus Resten einer Acrylglasplatte eine Schablone gefertigt, die den Profilverlauf vom Plans kopiert. Die untere ‘Gabel’ bestimmt die Position der Drehachse der Landeklappen.

Steckverbindung Flügel – Rumpf
Die elektrische Verbindung vom Flügel zum Rumpf ist bei jedem Modell eine Herausforderung. Die Vielzahl der im Handel erhältlichen Steckersysteme und die verschiedenen Anforderungen bezogen auf das betreffende Modell erschweren die Entscheidung für ein bestimmtes System manchmal. Ich habe für mich drei Systeme gefunden, die alle Bereiche abdecken können. Da wäre zum einen der klassische Servostecker. Gut für Ströme bis 2A Dauer erledigt dieses System die Versorgung von Slowflyern und kleineren Modellen mit 1-2 Servos pro Stecker. In der nächst höheren Kategorie verwende ich die bekannten grünen Multiplex Stecker / Buchsen. Damit lassen sich ohne Probleme 4 Servos pro Flügel inkl. Versorgung verbinden. Wenn es mehr Verbinungen braucht, verwende ich das System von XYZ.Natürlich sind diese Stecker und Buchsen nicht für den Modellflug konzipiert worden, lassen sich aber flexibel anpassen und bestücken. Das System besteht im wesentlichen aus Stecker und Buchsenkontakten mit den dazugehörigen verschiedenen mehrpoligen Gehäusen. Die Kontake gibt es passend für diverse Kabelquerschnitte. Gemäss Hersteller werden die Kontakte gecrimpt, für uns Modellbauer reicht auch löten, was mit den Kontakten wirklich sehr gut gelingt. Das System trägt die Bezeichnung Qikmate und stammt vom Hersteller Souriau. Die Gehäuse müssen für den Einbau in einen einfachen rechteckigen Ausschnitt etwas modifiziert werden.

Wer das Modell in der ursprünglichen Grösse vom 3.2m bestellt, bekommt eine passende GFK-Haube mitgeliefert. Bei meiner Grösse ist das leider wegen der Sonderanfertigung noch nicht der Fall. Die urprüngliche Idee, mit dem Bau einer Form für die GFK-Haube den Einstieg in die Laminier- und Harztechnik einzusteigen, habe ich nach dem Studium der Orininalfotos auf der CD verworfen. Die Haube hat eigentlich keine geschwungenen Fläche, alles lässt sich mit einfachen Kegeln und Flächen bequem in Holz nachbauen. Ein sehr nützliche Hilfe sind die im Plan enthaltenen Spanten für die Nase. Übertragen auf Papier, bekommt man schnell eine Vorstellung wie sowas in Holz aussehen wird. Die Spanten habe ich mit Ausschnitten versehen und mit Kiefernleisten verbunden, sowie zusätzlich diagonal mit Kohlestäben abgestützt. Das Ganze wurde anschliessend mit 2mm Balsa verkleidet.

 

Jeti Duplex Telemetrie

Funktionsprinzip
Jeti Duplex Empfänger besitzen die Möglichkeit, Daten an dessen Sendemodul zurück zu senden. Angezeigt werden diese Daten auf der Jeti-Box, die ein zweizeiliges LCD à 16 Zeichen und 4 Tasten besitzt. Die Jeti-Box fungiert dabei als reines Anzeigemodul mit Tasten. Anzeigedaten und Funktionsumfang werden von den angeschlossenen Modulen bereit gestellt. Eine geniale Idee. So bleibt man flexibel für die Zukunft. Gerade deswegen lässt es sich für eigene Anwendungen nutzen.

Meine Recherge im Internet ergab, dass Anfang 2009 erste Nachbauten von Box und Sensoren gemacht wurden. Im Laufe der Zeit wurden immer weitere Details des Datenprotokoll veröffentlicht.

Wie bereits erwähnt ist die Jeti-Box eine simple Anzeige mit 4 Tasten. Wird sie an ein Jeti-Modul angeschlossen (Sendermodul, Empfänger, Sensor), so zeigt es dessen aktuelle ‘Bildschirmseite’ an. Die Tasten dienen zur Menusteuerung als auch zum Ändern von Parametern. In den folgenden Erklärungen gehe ich davon aus, dass ausreichende Kenntnisse für die Bedienung der Jeti-Produkte vorhanden ist.

Um jedes Modul erreichen zu können, werden die Telemetriedaten ‘durchgereicht’.

Jeti-Box <- TX <-Empfänger <- Sensor(en /mit Expander)

In der obersten Menuebene finden sich die drei Standardmodule Tx, Rx, Mx

Wählt man zum Beispiel Rx aus, leitet das Sendemodul die Daten vom Empfänger direkt an die Box weiter. Beim Sensor Mx werden dessen Daten über den Empfänger und Sendemodul zur Box weitergeleitet.

Protokoll
Die Übertragung erfolgt seriell auf TTL Pegel (negative Logik). Jedes Byte enthält 13 Bit. Damit ergibt sich ein Datenformat in der Form 9O1 ( 1 Startbit, 9 Datenbit, 1 Parity (odd), 1 Stopbit). Das scheint zunächst etwas ungewöhnlich zu sein, hat aber Vorteile. Mehr dazu später.

Ein Box-Datenframe besteht aus 34 Bytes. Das erste und das letzte Byte sind Steuerdaten. Die anderen 32 Bytes sind Anzeigedaten, die dann auf dem 2×16 Zeichen Display angezeigt werden. Werden auf der Box eine oder mehrere Tasten gedrückt, übermittelt die Box diese rund 5ms nach Ende des Frames. Das sendende Modul empfängt diese und reagiert entsprechend. Es passt den ‘Bildschirm’ an und sendet neue Daten zur Box. Jedes Modul sendet dauerhaft seinen ‘Bildschirm’, ausser es muss den Bildschirm eines nachgeschaltenen Modules weiterleiten.

Zur Beachtung: Weil die Daten mit neun statt den üblichen 8 Bits übertragen werden, wird das neunte Bit nachfolgend mit 0 oder 1 im HEX-Wert angezeigt (0x0FE, 0x184)

Ein Frame beginnt mit dem Zeichen 0x0FE, danach folgen 32 Byte Anzeigedaten bei welchen das neunte Bit 1 ist (0x1XX). Letztes Byte ist 0x0FF

Der Sendeinterval beträgt ca. 20ms. Die Box sendet ca. 5ms nach dem Frame ein Byte mit dem Status der Tasten. Der korrekte Wert ergibt sich aus dem Bitmuster in den oberen 4 Bits.

0x0F0 / 11110000 = keine Taste (alle Eingänge high). Jede gedrückte Taste setzt sein Bit auf 0. Damit lassen sich auch mehrere gleichzeitig gedrückte Tasten übermitteln.

Bit 4 = Rechts (right)
Bit 5 = Hoch (up)
Bit 6 = Runter (down)
Bit 7 = Links (left)

Eine Besonderheit ist noch zu erwähnen. Die Sensoren kommunizieren bidirektional über  die RC-Impuls) Leitung. Um die beiden getrennten TX und RX Leitungen der Mikroprozessoren an den Sensor schalten, muss der TX-Kanal mit einer Diode entkoppelt  werden: RX –|>|– TX

Sonderfall Alarmierungen
Bei Sensoren lassen sich Alarmierungen einrichten. Gemäss Konvention werden diese über die Box direkt im Sensor  programmiert und gespeichert. Tritt ein Alarm auf, werden die Alarmdaten direkt vor dem Displayframe gesendet.

Unterspannung: 0x07E, 0x192, 0x123, 0x155 (0x055 -> ‘U’ für Spannung)
Strom zu hoch: 0x07E, 0x192, 0x123, 0x149 (0x049 -> ‘I’ für Strom)
Kapazität überschritten: 0x07E, 0x192, 0x123, 0x143 (0x043 -> ‘C’ für Spannung)

Byte 0x07E scheint der Alarmheader zu sein. Die Bedeutung der beiden weiteren Bytes sind nicht geklärt. Weil die Jeti-Box keinen Piepser hat, werden Alarmmeldungen vom Sendemodul abgewickelt. Das bedeutet, dass bei Alarmframes die Anzeige temporär vom Sendemodul übernommen wird und dieses auch seinen Piepser aktiviert. Alarmdaten werden nicht zur Box weitergeleitet.

Wie es scheint, verzögern Jeti-Sensoren die Alarmierung um einige Sekunden.

Veröffentlicht unter Jeti

Futaba S-BUS : Servos programmieren

Vor dem Einbau muss jedem Servo eine ID zugewiesen werden. Das kann man mit dem kleinen SBC-1 machen, oder komfortabler, weil mehr Parameter verfügbar, mit dem USB-Adapter CIU-2.

Gemessen habe ich es mit dem SBC-1, in einem Empfängergehäuse integriertes Modul, sendet periodisch Frames mit 17 Bytes aus. Das Servo antwortet unmittelbar darauf mit einem gleich langen Frame.

Das SBC-1 sendet für eine Überprüfung des Servos folgende Daten:
F9 07 03 79 F9 00 00 00 00 00 00 00 00 01 00 07 7C

Das Servo antwortet mit:
A0 07 03 79 F9 0C 0C 0F 15 64 64 00 00 00 01 08 77

Bei beiden Frames repräsentiert Byte 2 die ID des Servos, das letzte Byte ist eine Checksumme.

Soll das Servo eine neue ID bekommen sendet das SBC-1 folgendes Frame:
F9 00 03 79 F9 00 00 00 00 00 00 00 00 01 00 4D 3D

Wieder steht Byte 2 für die (diesmal neue) ID, das zweitletzte Byte hat den Wert 4D. Das Servo sendet dabei keine Daten zurück.

Servoparameter:

Dataframe = 17 Byte;

Byte1 = Startframe (0xF9) 
Byte2 = Channel (00-0F,10,11) Ch1-16 / Digi 1&2 
Byte3 = ? 
Byte4 = ? 
Byte5 = ? 
Byte6 = Death range (02-FF) 0.03-3.98 degrees 
Byte7 = Start force (00-52) 0-1000us 
Byte8 = Dampening (00-32) 0-50ms 
Byte9 = Keeping force (00-27) 0-50 degrees/sec. 
Byte10 = Servo range right (00-FA) 50-175% 
Byte11 = Servo range left (00-FA) 50-175% 
Byte12 = Middle position (88-FF/00/01-78) 0.25 degrees/digit 
Byte13 = Servo speed (00-78) 12 - 0.1sec/45 degrees 
Byte14 = ? 
Byte15 = ? 
Byte16 = ? 
Byte17 = Checksum 

Veröffentlicht unter S-Bus

Futaba S-BUS Protokoll

Anfangs 2010 hat Futaba ein neues Bussystem für den Anschluss von Servos an den Empfänger vorgestellt. Über einen einzigen Empfängerausgang werden alle daran angeschlossenen S-Bus fähigen Servos mit Daten gesteuert. Welches Servo zu welchem Kanal gehört wird am Servo über den Programmer SBC-1 oder CIU-2 eingestellt.

Protokollstruktur

Das Protokoll ist 25 Byte lang und wird alle 14ms (analog) oder 7ms (highspeed) gesendet.
Ein Byte = 1 Startbit + 8 Databit + 1 Paritybit + 2 Stopbit (8E2), Baudrate = 100’000 bit/s
Es wird zuerst das höchste Bit gesendet. Die Logik ist intertiert (Pegel High = 1)

Nachtrag – 20.03.2012: Die Datenrate kann auch 9600 bit/s betragen. Dazu sind andere Timings anzupassen. Begründung: das USB-Interface CIU-2 arbeitet mit 9600 bits/s. Damit sind einfachere Controller auch in der Lage S-Bus Daten zu senden, wenn auch einiges gemächlicher.


[Startbyte] [Data1] [Data2] .... [Data22][Flags][Endbyte] 

Startbyte    = 11110000b (0xF0) 
Data 1-22    = [ch1, 11bit][ch2, 11bit] .... [ch16, 11bit] (ch# = 0 bis 2047) 
               Kanal 1 benutzt 8 Bits von Data1 und 3 Bits von Data2 
               Kanal 2 benutzt restliche 5 Bits von Data2 und 6 Bits von Data3 usw.

Flags        = Bit7 = ch17 = Schaltkanal (0x80) 
               Bit6 = ch18 = Schaltkanal (0x40) 
               Bit5 = Frame lost, entspricht roter LED am Empfänger (0x20) 
               Bit4 = Failsafe aktiviert (0x10) 
               Bit3 = unbekannt 
               Bit2 = unbekannt 
               Bit1 = unbekannt 
               Bit0 = unbekannt 

Endbyte      = 00000000b

SBUS Datenframe (Kanal 1 im Logger)

 

S-Bus Servoimpulse Ch1-6 starten zur gleichen Zeit

Impulsintervall 7ms

Veröffentlicht unter S-Bus