SBus2 Telemetriesensoren - wer hat schon was selbst gemacht

DKHDKH

User
Ich habe es gerade ausprobiert und es funktioniert perfekt.
Du hast mir wieder gut geholfen. Jetzt kann ich sehen, welche Strömung während des Segelns fließt.
Wenn ich Ihnen mit etwas helfen kann, lassen Sie es mich wissen.
Nochmals vielen Dank.
 
Wenn ich Ihnen mit etwas helfen kann, lassen Sie es mich wissen.

Ich habe gestern Nacht den Code soweit fertig das man Ihn als neue Version hochladen könnte.

Aber:
Ich habe doch nochmal viel arbeit investiert und gefühlt jede Codezeile geändert.

Das Ergebnis ist ein sehr effizienter Code, relativ leicht zu pflegen und mit allen Funktionen die man (warscheinlich) gerne hätte.
Die Library eigenet sich jetzt auch als eigenständige SBUS Library (ohne Telemetrie)
Oder eben mit Telemetrie (auch mit funktionierenden GPS Sensor)

Das ganze würde ich gern als Version 1.0 hochladen.


Aber es wäre schon wenn es vorher nochmal von jemand anderen getestet wird.
Code lade ich heute noch hoch und kann über das Wochenende getestet werden.

Dann kann ichs nächste Woche als Version 1.0 markieren.
Es wird dann demnächst auch passende Plug&Play Platinen zum aufstecken auf den Arduino Pro Mini geben.
 

DKHDKH

User
Ich habe die neueste Version getestet und alles funktioniert einwandfrei. GPS-Koordinaten werden jetzt gut angezeigt.
Die SBUS-Anzeige funktioniert auch sehr gut.
Vielen Dank.
 
Neue SBUS2 Telemetrie Version

Neue SBUS2 Telemetrie Version

Ich habe die neue Version in Github als Release markiert.

Die neue Version wurde auch auf meinem Eigenbau Motorregler geflasht und lief dort ohne Probleme.
 
hi, danke für die lib.
eine frage: hat es nen grund, dass immer nur die sensoren blockweise via lib-funktion ansprechbar sind? spricht was dagegen das ganze aufzubrechen (um z.b. ein vario ohne gps zu bauen)
was passiert dann eigendlich wenn man die ports durcheinander würfelt (also zuerst höhe dann speed schickt) sollte doch dann nicht richtig funktionieren oder?
entschuldigt die etwas dämlichen fragen, aber ich hatte noch nie behrührungen mit futaba und deren telemetrie und möchte jetzt für einen vereinskollegen einen sensor basteln. (bisher mach ich das nur für mpx, jeti, frsky und standalone mit hc12)
 
Hallo Simon,

es können nur Sensoren verwendet werden, welche im Sender hinterlegt sind.

1. sind das nur Sensoren die von Futaba/Robbe verkauft werden (verkauft wurden)
2. hängt es von der Softwareversion im Sender ab, welche Sensoren bekannt sind
3. muss man wissen wie die Sensoren funktionieren


Bei den Sensoren in meiner Library treffen alle 3 Punkte zu. Diese sind (soweit ich weiß) in allen Futaba Telemetriesendern verfügbar und wurden bereits entschlüsselt.
Beim GPS Sensor z.B. weiß ich aktuell nicht wie die UTC Zeit gesendet wird.

Als Vario kann ich noch den "Vario F1712" und/oder den "Vario F1672" hinzufügen.
Beide Varios sind entschlüsselt. Ich hatte mich aber erstmal auf den GPS Sensor konzentriert, weil dort ja auch ein Vario mit dabei ist.


Fazit:
Du musst die vordefinierten Sensoren verwenden. Änderungen in der SBUS2.cpp bzw SBUS2.h sind nicht empfehlenswert.

Im eigentlichen Sketch kannst du natürlich die Start-Ports der Sensoren "beliebig" ändern.

Port 0 darf nie verwendet werden. Das ist die RX Spannung.

Und Sensoren mit mehreren Ports (GPS, Curr-1678, Varios) müssen in folgende Blöcke passen:

1-7
8-15
16-23
24-31

GPS belegt 8 Ports. Damit sind nur Port 8, 16 und 24 als Startport für GPS geeignet!

Als Hilfe immer den Sender nutzen. Wenn die Sensor Konfiguration im Sender möglich ist, dann funktioniert es auch im Arduino Sketch.
 
vielen dank für die ausführliche antwort! das beantwortet meine fragen.

ja das ist so ne sache, hätte ich zugriff auf einen futaba sender hätte ich es mir anschauen können und nicht fragen müssen, ich fliege aber kein futaba ;)
 
Hallo John,

Es ist schon eine Weile still. Haben Sie dieses großartige Projekt noch weiterentwickelt?


Hallo, seit Mai 2019 hat sich nichts an der Library verändert.
Es gab immer mal wieder ein paar Nachfragen/Probleme, aber diese lagen immer auf User Seite.

Ich wollte irgendwann mal verschiedene Übergabewerte für GPS einbauen...je nach dem ob man dezimal grad oder grad minuten usw hat.
Ich wollte auch mal ein Wiki schreiben.
Ich wollte meinen Eigenbauregler mit SBUS Telemetrie weiter testen.

Aber bisher habe ich dazu keine Zeit gefunden.
Und da die Library stabil zu laufen scheint, gibt es auch keinen Druck für eine Weiterentwicklung.
 

DKHDKH

User
Wenn Sie mit Ihrem Projekt ein bisschen weiter sind, lassen Sie es uns erneut wissen.
Ich bin sehr zufrieden mit der aktuellen Library.
 
Wenn Sie mit Ihrem Projekt ein bisschen weiter sind, lassen Sie es uns erneut wissen.

In den letzten Tagen gab es ein paar Fehlermeldungen.
Sobald diese geklärt bzw. abgearbeitet sind wird es eine neue Version geben.
die neue Version bleibt aber kompatibel mit alten Projekten.

Falls es also Wünsche und Anregungen gibt, wäre jetzt der richtige Moment

aktuelle Fehler:
- GPS Koordinaten funktionieren nicht für Süd/West (in DE sind wir Nord/Ost -> Daher ist der Fehler noch nicht aufgefallen)

Neue Features:
- GPS Sensor soll mehrere Möglichkeiten bieten GPS Koordinaten zu übergeben (Dezimal oder Grad-Minuten oder Grad-Minuten-Sekunden)
- Sensoren (bzw dessen Funktionsnamen an die Namen der original Sensoren anlehenen damit es weniger Verwirrungen gibt
 

DKHDKH

User
Vielen Dank für das Update. Ich benutze noch kein GPS und habe den Fehler auch nicht bemerkt.
Ich schaue, ob ich den Höhensensor steuern kann (Altitude: SBS-01A). Wenn es mir gelingt, werde ich Sie wissen lassen.
 
Hallo,

ich bin ein Modellbau wiedereinsteiger (nach 20 Jahren ohne) und habe demnach die letzten 2 Jahrzehnte Fernsteuerungs-inovation verpasst.
Zuerst überfordert von den neuen Begriffen, jetzt richtig begeistert was man alles machen kann.

Insbesondere als Informatiker und Bastler mit RPi und Arduino Hintergrund bin ich erfreut, das es schon Projekte gibt die die neuen digitalen Elemente adaptieren können.

Ich war auf der Suche nach Informationen zu S-BUS/Telemetrie und Arduino und bin quasi sofort auf diesen Thread gestoßen.

Ich habe eine Fuataba T16SZ mit R7008SB, die ich gerne um eigene Sensorik/Telemetrie erweitern möchte.

Da ich Modellrennboote mit Verbrennungsmotor fahre und den Eindruck habe, das es hierfür fast nichts zu kaufen gibt will ich einiges selber entwickeln.

Wenn ich den Thread richtig verstanden habe läuft die Software zur Zeit nur unter Arduino Pro Mini 8/16 MHz welchen ich dann auch nutzen werden.
Ich würde den Arduino gerne mit auch der Empfänger-Batterie (5 Zellen X 1,2V) speisen, kann der das ab oder müssen das genau 5V sein?

Ich habe irgendwo gelesen, das man die Sensoren dem Sender irgendwie bekannt geben muss.
Erkennt der das nicht automatisch wenn ein Empfänger plötzlich die entsprechenden Werte übermittelt?

Ich werde zuerst mit einem GPS-Modul anfangen, würde aber auch gerne eine Drehzahlmessung realisieren.
Das ganze wenn es geht ohne Magneten, das könnte sonst bei > 25.000 U/min evtl. kritisch werden.
Die käuflichen Teile benötigen anscheinend immer irgendwas mit Propellern was wir in unserem Bereich nicht haben.
Hat jemand Erfahrung was man dafür verwenden könnte?
 

onki

User
Hallo,

also zumindest zum Arduino ProMini kann ich dir ein paar Dinge sagen.

Es gibt einen 3v3 Typ und einen 5V Typ. Das sind aber nur die internen Betriebsspannungen, die über einen integrierten Längfsregler bereitgestellt werden.
Mit einem 5 Zeller NiCd kommen beide problemlos zurecht.
Es gibt ein paar Komponenten (einige GPS-Module), die definitiv 5V Betriebsspannung benötigen, was dann für die 5V Version spricht.

Gruß
Onki
 

kalle123

User
SBUS2-Protokoll

SBUS2-Protokoll

Hallo zusammen,

basierend auf den Soucen in dem GIT Reposiory von "brushlesspower" habe ich versucht zu verstehen wie das Protokoll denn nun eigentlich genau ist.
Folgende Annahmen habe ich per reverse engineering heraus gefunden und bitte die "Wissenden" um Überprüfung.

Code:
SBUS2-Telemetrie Protokoll
===========================


1. Allgemeiner Informationen

1.1 Generelle Abläufe
1.1.1 Init und Startup Sequenz

Zum Startup sendet die Telemetrie ein Byte (0xAA), der Empfänger muss darauf hin mit einem Byte(0x55) antworten.

Telemetrie/Sensor						Empfänger
-----------------------------------------------------
                  0xAA
           ------------------->
                  0x55
	       <---------------------


1.1.2 Daten Transfer

SBUS2-Telemetriedaten werden nicht Asynchron gesendet, sonder nur nach einer Aufforderung durch den Empfänger.
Der Empfänger wir ein SBUS2-Datenpaket senden in dem Server Steuerungsinformationen enthalten sind und auch im letzen Byte 
die Nummer des Frames, der im Anschluss zu senden ist.

Telemetrie/Sensor						Empfänger
-----------------------------------------------------
           SBUS2-Datenpaket + Request Frame
           <-------------------------------
             Requested Frame (1 Frame =  8 Slots = 24 Byte)     
	       -------------------------------->


1.2 Protokoll Nachrichtenaufbau

1.2.1 Frames und Slots
Ein Frame besteht auf 24 Bytes. 

1.2.1.1 vom Empfänger
Wenn der Frame vom Empfänger gesendet wurde, enthält der Frame Servo Steuerinformationen und zusätzlich im letzen Byte 
die Information ob es ein Valider SBUS2-Frame ist oder ein normaler SBUS-Frame.
Bei einem SBUS2-Frame enthält das letzte Byte im High-Nibble die Information welcher Frame von der Telemetrie übertragen werden soll.

If (lastbyte & 0x0f) == 0x04   -> SBUS2 Frame	
	requestFrame = lastbyte & 0x30 
If (lastbyte & 0x0f) == 0x00   -> nur Servo Daten

else -> irgendein anderer Frame

Startbyte = 0x0F gefolgt von Servo-Datenaten

Servo Daten
--------------
16 Analog Channel
2 Digital Channel (1 Byte)
11 Bits pro Analog Channel

16 (Analog Channel) X 11 Bit = 176 Bit = 22 Byte
22 Byte  + 1 Byte (Digital) + 1 Byte (lastbyte) = 24 Byte

Timeout
-------------
Vermutung: Ein Frame muss innerhalb von 200 ms komplett empfangen worden sein, sonst entsteht ein Frame-Error


1.2.1.2 von der Telemetrie

Die Daten von der Telemetrie sind auch in Frames organisiert, wobei ein Frame aus 8 Slots besteht.
Insgesammt gibt es 32 Slots die in 4 Frames zu 8 Slots organisiert sind.
Es werden immer ganze Frames gesendet, die auf einer 8ter Grenze beginnen.

Frame 1 : Slot 0-7
Frame 2 : Slot 8-15
Frame 3 : Slot 16-23
Frame 4 : Slot 24-32

Jeder Slot besteht aus 3 Byte (SLOT-ID, DATA1, DATA2)
Somit haben wir für einen Frame 8 (Slots) X 3 Byte = 24 Byte Daten für einen Frame

Es wird immer nur der Frame gesendet, welcher vom Empfänger angefordert wurde.

Delays
----------
Zwischen dem Empfang eines Frames und dem senden der Telemetrie Daten ist ein minimum Dealy von 0,5 ms einzuhalten.
Jeder Slot wird mit einem Delay von 1 ms zwischen den Slots übertragen.

Das ganze ist nur aus dem Source Code per reverse Engineering ermittelt worden.
Ich vermute das die Delays jedoch nur minimal delays sind, die nicht unterschritten werden dürfen, aber überschritten werden können ohne negative einflüsse.
 
Es gibt Neuigkeiten.

Dank der Initiative von DeadOldMan gibt es jetzt auf meinem Tisch einen Futaba Telemetriesensor auf basis des ESP32.

Vorteil:
- Kein Inverter nötig (Signal wird intern invertiert)
- man kann ganz tolle Sachen mit Wifi und Bluetooth machen
- DualCore
- und der ESP32 ist sehr verbreitet unter Arduino Nutzern.

Wie bereits beim 328P laufen alle wichtigen Routinen als Interrupt und sind daher frei von Delay's; Task's und anderen blockierenden Quark.

In den kommenden Tagen werde ich Version 1.0 für den 328P hochladen und ein Repo anlegen für den ESP32 (version 0)
 
Ansicht hell / dunkel umschalten
Oben Unten