SBus2 Telemetriesensoren - wer hat schon was selbst gemacht

onki

User
Hallo,

OxS wird es ja wegen verschiedener Probleme (welcher Honk hat eigentlich den SBUS2 Mist verbrochen?) nicht für den SBus2 geben.
Ein Arduino-Library gibt es aber dafür. Hat jemand damit schon einmal Sensoren selber gebaut und falls ja welche?
Hintergrund ist das mich ein Kumpel darauf angesprochen hat wegen des Durchflussmessers.

Müsste die Rücksetzung der Werte auch im Sensor erfolgen?

Ich hab zwar kein Futaba, würde meinem Kumpel diesbezüglich aber gerne weiter helfen.

Gruß
Onki
 

onki

User
Hi Kalle,

Es gibt ein Statement von Michel, dass es wegen der unendlich dämlöichen Architektus des SBus2 (komische baudrate etc.) keine OxS Implementierung geben wird.
Die Unterschiede sind so signifikant, das es bei einer Implementierung von SBus2 wohl Einschränkungen bei den anderen Protokollen geben würde.
Und das tut er sich (zurecht) nicht an.
https://fpv-community.de/threads/wa...-oxs-Übertragungs-protokoll-für-futaba.83782/

Du warst da selber mit zugange an dem Fred :rolleyes:.

Mir persönlich würde eine Anbindung mit der angesprochenen Library reichen um den Flowmeter auszuwerten und die entnommene Menge zu übertragen und via Taster am Modell zurückzusetzen.
Hab aber halt nix zum testen.


Gruß
Onki
 

onki

User
Hallo,

Nachdem ich mir die Sache mit der Library mal genau angesehen hab ist mein Entschluss klar.
Da mache ich nix. Wer so ein inkompatibels System spezifiziert, hat keinerlei Unterstützung verdient.
Ich werde nun eine Tankanzeige auf Basis eines Arduino und eines kleinen OLED-Displays bauen. Damit kann die entnommene Spritmenge dann irgendwo am Modell direkt angezeigt werden.
Ich denke das ist für Schleppmaschinen, bei denen der Tank nicht einsehbar ist, eine brauchbare Lösung (für Futaba-Piloten). Reset der Menge dann mit einem kleinen Taster am Modell.
PPM Reset ist mir zu knifflig, da ich das alles selbst programmieren muss und die gegebene Lösung schon genug Aufgabe ist.

Ein weiterer Grund warum ich wohl nie auf Futaba zurückgreifen werde. Überteuert, inkompatibel (sogar untereinander) und auch nicht besser als der Rest.

Gruß
Onki
 

OE-0485

User
S - Bus und S - Bus 2 Unterschied

S - Bus und S - Bus 2 Unterschied

Nabend !
- vereinfacht gesagt :
S - Bus ist quasi die Versorgung von beliebig vielen Servos an einer Strippe.
S - Bus 2 sind alle Sensoren, Regler, telemetriefähige Geräte z.B.: Akkuweichen, Durchflußmengenmesser, Unisens E, verschiedene Varios usw.

vg hans
 
Nabend !
- vereinfacht gesagt :
S - Bus ist quasi die Versorgung von beliebig vielen Servos an einer Strippe.
S - Bus 2 sind alle Sensoren, Regler, telemetriefähige Geräte z.B.: Akkuweichen, Durchflußmengenmesser, Unisens E, verschiedene Varios usw.

vg hans

Vielen Dank!

SBUS kenne ich, SBUS2 war mir neu.

Gibt es dazu irgendwie Doku zum Protokoll?

VG
 
Hallo,

das Problem mit der Futaba Telemetrie liegt (wie schon bei SBUS) in dem Invertierten Seriellen Datensignal.

Zum empfangen von SBUS Servodaten wird nur ein Inverter gebraucht. Mit telemetrie muss das Signal aber auch "umgekehrt" invertiert werden.
Außerdem müssen die Telemetriedaten in die entsprechenden Slots "eingefügt" werden. Dadurch sind die Timings relativ wichtig.
All das macht es sehr schwierig Fuataba mit anderen Telemetrieprotokollen zu vereinen.
Entweder man ändert die Hardware, oder man hat einen Mikrocontroller der intern das Signal invertieren kann.


Die Github Arduino Bibliothek ermöglicht es, dass man einen "Anfang" hat um seine eigenen Futaba Sensoren zu bauen.
Harwareseitig braucht man allerdings einen Tri-State Buffer SN74LVC2G240 o.ä.

Ich arbeite gerade an einer Platine für den Arduino Mini Pro. Diese hat dieselben Maße wie der Mini und kann einfach aufgesteckt werden. Auf der Platine befindet sich der Buffer, angebunden an TX und RX vom Arduino. Die Platine soll dann als Arduino - Sbus2 Adapter dienen.
Über Lötbrücken kann man auswählen welche GPIO's man nutzen will für Senden/Empfangen Enable. Warscheinlich wird es zukünftig auch ohne diese 2 GPIO's funktionieren. Dann kann man auch die Library nochmal aufräumen.
 
Zumindest nicht von Michel, das hatte ich schon mit ihm besprochen und bin auch ganz froh das es nicht so sein wird, den die Änderungen würden auch die nicht Futaba Nutzer nachteilig treffen.
Aber es könnte ja sein das jemand anderes den OXS Sketch als Grundlage benutzt, das war mehr mit meiner Frage gemeint ob komplett eigen oder OXS als Grundlage.
 
Leider kenne ich mich bei OxS überhaupt nicht aus. Daher kann ich nicht sagen wie leicht oder schwer die Änderungen sind.

Aber der kritische unterschied:

Soweit ich weiß wird bei OsX ein GPIO für die Telemetrie verwendet, und nicht die Hardware Serielle.
Für die Futaba Telemetrie muss aber die Hardware Serielle benutzt werden.
Das bedeutet gleichzeitig, das alle Sensoren die über die Serielle angeschlossen werden, nicht mehr funktionieren, bzw auf eine Softwareserielle ausweichen müssen.

Und diese Änderungen sind warscheinlich der Hauptgrund warum Futaba nicht in OsX integriert wird. Zumindestens nicht in naher Zukunft.



Derzeit arbeite ich an einem Brushless Regler mit Telemetriefunktionen. Er soll Futaba und Jeti können. (alles andere sollte dann auch funktionieren)
Dann sollte eine Hardware (Schaltplan) existieren womit alle Telemetrieprotkolle funktionieren (Hardwareserielle). Und dann wird auch die Library nochmal aufgräumt. Im Moment sind warscheinlich 40% total nutzlos. Aber es funktioniert halt. Gefühlt bin ich auch der einzige der an einer Arduino <-> Fuataba Telemetrie arbeitet. ich hoffe das es mit der Zeit mehr werden und die Library besser und besser wird.
 
erzähle bitte mehr davon. Strom, Zellenzahl und wird er auch FrSky Telemetrie können?

Die 1. Version des Reglers ist bereits aufgebaut und getestet. Einige Tests müssen aber noch gemacht werden, besonders Volllast.

Der Regler ist speziell für Rennboote gedacht (Wasserkühlung) Die einzelnen Mosfets haben keinen Kühlkörper sondern sind direkt an die Wasserkühlung gelötet. So ergibt sich eine optimale wärmeabfuhr.

Angedacht sind 200A bis 10S. Theoretisch kann er bis 60V betrieben werden, also bis 14S.
Der Mikrocontroller/Firmware ist BlHeli_32 und damit closed source.


Auf der neuen Revision die gerade designed wird (zu 90% fertig) kommen 2 zusätzliche Mikrocontroller dazu (Atmega 328P -> Arduino)
Der 1. Controller wird nur messen (Spannung/Strom/Temperatur/Drehzahl usw) und auf der SD Card Speichern. Ausserdem werden die Daten an den 2.Mikrocontroller gesendet (via i2c oder Softserial). Der 2. Mikrocontroller ist nur für die Telemetrie zuständig.
Ursprüglich sollte alles auf einem Controller laufen, aber es gibt dabei ein paar Probleme. Und die einfachste Lösung war ein 2. Controller (2€ mehr...was solls).

Da ich nur Jeti und Futaba habe, kann ich auch nur diese beiden Protokolle testen. Ich versuche aber auch alle anderen Protokolle einzubauen.
Vorraussetzung ist eine Arduino Lib für den 328P und mit Nutzung der Hardwareserial. Die bestehenden Frsky Librarys nutzen die Softserial. Aber das sollte sich ändern lassen. Ist aber alles eine Frage der Zeit.

IMG_20180911_0812577.jpg
IMG_20180911_0813338.jpg
 
Neuigkeiten

Neuigkeiten

Ich teste derzeit eine neue Futaba Hardware für den Arduino Pro Mini.

Diese besteht nicht mehr aus den Tristate Buffern sondern aus einfachen Invertern.

Ein Inverter für TX und ein Inverter für RX. Damit wird kein GPIO mehr benötigt.



Die Daten habe ich bereits auf meiner T14SG empfangen. Nun will ich die nächsten Tage die Library aufräumen.
Dann werden Schaltplan + Layout und die neue Library auf Github gestellt.
 
Ansicht hell / dunkel umschalten
Oben Unten