SBus2 Telemetriesensoren - wer hat schon was selbst gemacht

Nunja.
Ich würde auch gerne komplett auf Jeti umsteigen. Die habe ein nahezu perfektes Telemetrie Protokoll.
Aber leider extrem teuer, und eigentlich nur 2 Sender im Angebot.


Warum nicht Frsky die haben auch ein gutes Telemetrie Protokoll ob jetzt FRsky oder Jeti vom Protokoll her besser ist kann ich aber nicht sagen.
Der Preis, Qualität , das ganze Zubehör Programm stimmen auf jeden Fall bei Frsky ganz zu schweigen welche Möglichkeiten man mit OpenTX hat.
 
Naja,

ich kenn beide, Jeti und FrSky/openTX. Und ich habe für beide Sensoren programmiert.

ich finde das Telemetrie -Protokoll von Jeti deutlich besser da flexibler.

Die Hardware von Jeti funktioniert zunächst einfach - bei FrSky war es ein Krampf bis der Sender die richtige FW hatte - danach mußte dann bitte auch noch die passende FW für die RX gefunden und eingespielt werden.

Auch kann ich den Vorteil von OpenTX gegenüber Jeti nicht sehen - abgesehen evtl. von dem Konfigurator. Lua ist es jedenfalls nicht.

Mein Fazit - FrSky ist nichts für Leute die erwarten das etwas aus der Box funktioniert aber cool für Bastler da ja man jedes Bit selbst kippen kann.

Gut, FrSky ist deutlich preiwerter.

Gruß

gecko
 
Es ist zwar etwas OT, aber schweigen klappte gerade nicht...;)

Dazu hat jeder seine eigene Meinung, ich kann da deine Meinung nicht teilen, ok, mit den Sensoren kann ich nichts nachteilige zu Jeti sagen, da ich keine besitze und nie besitzen werde.
Für den Frsky Bus habe ich einige Sensoren, Original wie selbstgebaute und kann nur das beste berichten und kenne auch einige Modellflieger die sehr gerne diese Möglichkeiten in Ihrer Anlage hätten, geschweige denn zu dem Preis.

Auch die Jeti Piloten schauen mit große Augen, aber natürlich so das es keiner merkt ;) mit unauffälligem blick etwas neidisch Richtung Frsky.
Flashen kann man wie fast jede Anlage, muss man aber nicht!
Ansonsten ist das nur Faulheit sich bevor man anfängt wild um sich zu Flashen sich mit der Materie und dem Thema auseinanderzusetzen, das ist aber bei anderen dingen auch nicht anders oder konntest du etwa Sensoren Programmieren ohne dich mit dem Thema sehr ausführlich zu beschäftigen ??
Frsky setzt sich zumindest immer mehr durch und nicht nur in den USA.
Wenn du Lua nicht als vorteil siehst naja Ok, deine Meinung (das sehen jedenfalls sehr viel Leute ganz anders und die Skripte werden täglich mehr), auch 32 Frei Programmierbare Mischer sowie 64 Frei Programmierbare Logische Schalter, die Komplette Telemetrie ebenso frei Programmierbar und alles andere eben auch.
Allerdings stößt mir der Begriff "Programmieren" der immer wieder genannt wird auf, bei den ganzen Namhaften Sender Herstellern ist das "Programmieren" doch nur Werte/Zahlen in vorgefertigte Felder einzusetzen und selbst bei Frsky ist das nicht wirklich "Programmieren".
Was auch immer so ein bisschen auffällt sind Modellbauer mit den teuersten und dollsten Sendern und wenn man sie nach dem Xten Landeanflug am Hang fragt warum sie die Klappen nicht setzten... heißt es oft das muss ich noch Programmieren... :confused: habe aber mein Handbuch nicht dabei :D

Genug OT und jeder soll seine Meinung haben
 
Allerdings stößt mir der Begriff "Programmieren" der immer wieder genannt wird auf, bei den ganzen Namhaften Sender Herstellern ist das "Programmieren" doch nur Werte/Zahlen in vorgefertigte Felder einzusetzen und selbst bei Frsky ist das nicht wirklich "Programmieren".
Was auch immer so ein bisschen auffällt sind Modellbauer mit den teuersten und dollsten Sendern und wenn man sie nach dem Xten Landeanflug am Hang fragt warum sie die Klappen nicht setzten... heißt es oft das muss ich noch Programmieren... :confused: habe aber mein Handbuch nicht dabei :D

OT
Gerade in diesem Thread geht es ums proogrammieren in C bzw C++
Und zwar von eigenen Sensoren.

Daher ist es hier egal welche anderen Funtkionen besser oder schlechter sind. Sondern nur wie man mit wenig C Code schnell und einfach eigene Sensoren programmieren kann.

Und das ist bei Jeti am besten, weil das Protokoll extrem flexibel ist und sehr gut dokumentiert und offen gelegt.

OT Ende

Für Futabe mache ich erstmal keine aktualisierung des Git Repos.
Eventuell wird es zukünftig noch Resonanz geben. Dann kann man sicherlich was aktualisieren und helfen.

Solange werde ich meine Futaba Library in meinen Brushlessreglern einsetzen und weiterentwickeln.
 
Du hast mich vermutlich falsch verstanden, oder ich habe mich nicht richtig ausgedrückt.

Das mit dem Programmieren war rein auf die Sender bezogen (Modell erstellen) und nicht auf die Eigenbau Sensoren, hier ist es sehr wohl Programmieren.
 
Neue SBUS2 Telemetrie Version

Neue SBUS2 Telemetrie Version

Ich habe auf Github eine neue Version meiner Library hochgeladen.

- Jetzt können auch Arduino Pro Mini 16MHz verwendet werden
- Und wie bereits angekündigt die vereinfachten SBUS Funktionen mit entsprechenden Beispiel
- Jetzt muss niemand mehr in den Source Codes rumpfuschen -> SBUS_Loop(); entfernt


Inzwischen wurde die Library auch von anderen erfolgreich getestet:cool:


Die nächsten geplanten Weiterentwicklungen sind:
- Arduino Pro Mini 12MHz (braucht wohl niemand außer mir)
- Arduino Pro Mini PB (Wattduino) -> Dieser hat zwei Hardware Serials, die Vorteile sind wohl offensichtlich?!
 
Hier mein Eigenbau Regler mit Futaba Telemetrie

Ein Video wäre vielleicht besser, aber ich denke ihr glaubt mir wenn ich sage die Daten stammen direkt aus dem Regler ;)
 

Anhänge

  • IMG_20190403_1022288_klein.jpg
    IMG_20190403_1022288_klein.jpg
    559,9 KB · Aufrufe: 332
  • IMG_20190404_0754596_klein.jpg
    IMG_20190404_0754596_klein.jpg
    434,3 KB · Aufrufe: 339
  • IMG_20190404_0755447_klein.jpg
    IMG_20190404_0755447_klein.jpg
    382,5 KB · Aufrufe: 359

DKHDKH

User
Hallo Brushlesspower,

Ich habe Ihre Library mit meinem T10J / R3006SB verwendet. Telemetrie funktioniert wirklich gut. Vielen Dank für diese schöne Library.

Nur wenn ich zum Beispiel Kanal 5 mit CH5 = SBUS2_get_servo_data(5) gelesen habe; dann bekomme ich regelmäßig -1 als wert. Was mache ich falsch oder ist diese Funktion nicht vorgesehen?

Vielen Dank im Voraus. Dirk
 
Nur wenn ich zum Beispiel Kanal 5 mit CH5 = SBUS2_get_servo_data(5) gelesen habe; dann bekomme ich regelmäßig -1 als wert. Was mache ich falsch oder ist diese Funktion nicht vorgesehen?

Hallo Dirk,

es freut mich sehr das die SBUS2 Library auch bei dir funktioniert.

der Rückgabewert -1 bedeutet das kein neuer SBUS(2) Frame empfangen wurde.

Ich vermute das deine CH5 = SBUS2_get_servo_data(5) zu schnell erfolgt.
Prüfst du vorher SBUS2_Ready()?


if(SBUS2_Ready()){
channel = SBUS2_get_servo_data( 5 ); // Channel = Sbus Value of Channel 5
}
 

DKHDKH

User
Hallo Brushlesspower,
Danke für die Antwort. Ich habe zuerst SBUS2_Ready () geprüft. Ich bekomme noch regelmäßig -1 als wert.
Unter meinem Testprogramm. Vielleicht kannst du das benutzen.

Code:
#include <U8glib.h>          //I2C OLED-Display
#include "SBUS2.h"
#include "SBUS_usart.h"

#define CURRENT_SLOT      3
#define RPM_SLOT          2
#define ERROR_SLOT        6
#define TEMPERATURE_SLOT   1

U8GLIB_SSD1306_128X32 u8g(U8G_I2C_OPT_NONE);

int      i = 0;
int16_t  channel = 0;
uint16_t uart_dropped_frame = false;
bool     transmision_dropt_frame = false;
bool     failsave = false;

void setup() {
  pinMode(2, OUTPUT);           // set pin D2 as Output  
  digitalWrite(2, HIGH);       // set pin D2 High = Inverted UART signal
  SBUS2_Setup();
}//setup()


void loop() {
  if(SBUS2_Ready()){
    channel = SBUS2_get_servo_data( 5 );        // Channel = Sbus Value of Channel 5
   
    if (channel != -1 ){
      SBUS2_get_status(&uart_dropped_frame, &transmision_dropt_frame, &failsave);
      send_alarm_as_temp125(ERROR_SLOT, ((failsave*1000) + (transmision_dropt_frame*100) + uart_dropped_frame));      // Warning with over Temp at Error Slot
      send_temp125(TEMPERATURE_SLOT, (int16_t)i);                                                                     // Temperature [°C]
      send_RPM(RPM_SLOT,(uint16_t)300);                                                                               // RPM -> rounding Error +/- 3 RPM
      send_s1678_current(CURRENT_SLOT,(uint16_t)20,(uint16_t)15000,(uint16_t)1230);                                   // Current 20A, Capacity 15000mAh, Voltage 12.30V
      
      u8g.firstPage();                          //Display Channel 5
      do {
            u8g.setFont(u8g_font_unifont);
            u8g.setPrintPos(0, 10); 
            u8g.print("channel 5:");
            u8g.setPrintPos(0, 30);
            u8g.print(channel);
      } while( u8g.nextPage() );

      i++;                                      //Counter simulates temperature
      if (i==50) 
      {
         i=0;
      }//if
      
    }//if
        delay(100);       // Simulation of User Code, for example measuring Voltage, Temperature, Current, .... -> Maybe causing dropped frames
  }//if  
   
} // End of Loop()
 
Das ist ja echt interessant.

Vorallem weil die Ausgabe über das Display in der if(channel != -1) Bedingung steht.



Ich hab nochmal über den Code geguckt

SBUS2_Ready() prüft nicht frame_ready

die Servo Daten (bzw dessen Rückgabewert) ist aber an frame_ready gebunden.

ich werde das mal als issue in Github einfügen.


wenn der Arduino auf der SBUS(2) Leitung daten empfängt die gleich der Länge eines SBUS Frames entsprechen.....dann wird frame_ready gesetzt
Sobald alle Telemetrie Daten gesendet wurden, bzw die Zeit für Telemetriedaten vergangen ist wird frame_ready zurückgesetzt

nur in dieser Zeit gibt SBUS2_get_servo_data(x) den servowert zurück.

Daher ist die Prüfung auf die -1 dringend erforderlich.


Aber all das machen wir ja. Dein Code ist ja identisch mit meinem Beispiel.
Du hast ja eigentlich nur die Ausgabe über das Display hinzugefügt.

Versuche mal folgendes:

Code:
#include <U8glib.h>          //I2C OLED-Display
#include "SBUS2.h"
#include "SBUS_usart.h"

#define CURRENT_SLOT      3
#define RPM_SLOT          2
#define ERROR_SLOT        6
#define TEMPERATURE_SLOT   1

U8GLIB_SSD1306_128X32 u8g(U8G_I2C_OPT_NONE);

int      i = 0;
int16_t  channel = 0;
[B]int16_t  channel5 = 0;[/B]
uint16_t uart_dropped_frame = false;
bool     transmision_dropt_frame = false;
bool     failsave = false;

void setup() {
  pinMode(2, OUTPUT);           // set pin D2 as Output  
  digitalWrite(2, HIGH);       // set pin D2 High = Inverted UART signal
  SBUS2_Setup();
}//setup()


void loop() {
  if(SBUS2_Ready()){
    channel = SBUS2_get_servo_data( 5 );        // Channel = Sbus Value of Channel 5
   
    if (channel != -1 ){
      [B]channel5 = channel;[/B]
      SBUS2_get_status(&uart_dropped_frame, &transmision_dropt_frame, &failsave);
      send_alarm_as_temp125(ERROR_SLOT, ((failsave*1000) + (transmision_dropt_frame*100) + uart_dropped_frame));      // Warning with over Temp at Error Slot
      send_temp125(TEMPERATURE_SLOT, (int16_t)i);                                                                     // Temperature [°C]
      send_RPM(RPM_SLOT,(uint16_t)300);                                                                               // RPM -> rounding Error +/- 3 RPM
      send_s1678_current(CURRENT_SLOT,(uint16_t)20,(uint16_t)15000,(uint16_t)1230);                                   // Current 20A, Capacity 15000mAh, Voltage 12.30V
      
    }//if

  }//if  
[B]  u8g.firstPage();                          //Display Channel 5
  do {
      u8g.setFont(u8g_font_unifont);
      u8g.setPrintPos(0, 10); 
      u8g.print("channel 5:");
      u8g.setPrintPos(0, 30);
      u8g.print(channel5);
  } while( u8g.nextPage() );
  i++;                                      //Counter simulates temperature
  if (i==50) 
  {
     i=0;[/B]
  }//if 
} // End of Loop()


Ich hab den Display Code in die Loop gepackt.
Eventuell gibt es irgendwo ein Timing Problem.
 

DKHDKH

User
Ich glaube auch, dass es sich um ein Timing-Problem handelt.
Jetzt sehe ich auch, dass mein Zähler, der die Temperatur simuliert, Schritte überspringt. Das bedeutet also, dass -1 noch regelmäßig zurückgegeben wird. Trotzdem wieder eine gute Anzeige.
 
ich habe die Library mal überarbeitet.
jetzt gibt es auch bald einen GPS Sensor :cool:

Leider kriege ich aber grad die Telemetrie nicht zum laufen :cry:
Selbst das aktuelle Github Repo läuft nicht.

Kann sein das es an meinem R7003 liegt. Habe sonst nur mit dem R7008 getestet.
 
Ich habe jetzt mal den R7008SB verwendet -> Alles Gut:cool:

Erkenntnis No. 1 : Der R7003 ist wohl (warm auch immer nicht kompatibel)
Kann an meinem R7003 liegen, kann an den Einstellungen liegen, oder sonst was. Das muss ich mal später ausprobieren.

Das -1 Problem konnte ich bei mir ebenfalls sehen.
Wenn ich das Delay(100) auskommentiere ist das Problem nicht mehr vorhanden.

Das Delay(100) sollte nur zur Simulation dienen. An dieser Stelle soll der eigentliche User Code stehen.
- Analog read's
- I2C Zeug
- oder wie bei Dirk die Display Ansteuerung (wäre mal interessant zu wissen wie lange das dauert)
- User Code + Delay ist ganz schlecht

Erkenntnis No. 2 : es sollte irgendwo mal ein Buffer eingebaut werden, wo die SBUS Werte hinterlegt und dauerhaft verfügbar sind


Bei dem Test des GPS Sensors bin ich noch auf weitere Fehler gestoßen.

Erkenntnis No. 3 : Sensor Port 8 bis 31 funktionieren nicht
Es geht nur Sensor Port 1 bis 7 (Port 0 wird von der Empfängerspannung belegt)

Erkenntnis No. 4 : Es gibt ein Timing Problem wenn zb. nur Port 2 und Port 6 verwendet werden
Es sollten also keine Port's ausgelassen werden.


All diese Erkenntniss führen dazu, dass das Update der Library noch etwas dauern wird.
Außerdem muss ich die ganzen Fehler mal bei Github eintragen.
 
Neue SBUS2 Telemetrie Version [beta]

Neue SBUS2 Telemetrie Version [beta]

Hallo Dirk,

ich habe auf Github mal eine neue Version hochgeladen.

Bitte mal übers Wochenende ausprobieren.

- das -1 Problem tritt nicht mehr auf (prüfung auf SBUS2_ready() und -1 sind unnötig)
- das Delay in der Loop() kann beliebig groß sein ohne Fehler zu verursachen
- die gesamten Timings wurden überarbeitet
- die Sensor ID stimmen jetzt
- und ein GPS Demo Sensor wurde hinzugefügt (feste Position auf Berlin Fernsehturm)


Achtung: Es sind sehr viele auskommentierte Zeilen. D10 und D13 werden noch getoggelt und die SoftwareSerial ist noch drin.
Sollte aber alles kein Problem sein.

Gruß John
 

DKHDKH

User
Hallo John,

Ich werde dich nicht bis zum Wochenende warten lassen. Ich habe es getestet. Ich hoffe, ich schreibe alles gut auf Deutsch. Ansonsten solltest du mir keine Vorwürfe machen.

- Ich habe einen Zähler hinzugefügt, um die Geschwindigkeit der Telemetrie zu testen. Die delay() kann auf 500 ms zurückgesetzt werden. Im Allgemeinen simuliert dies ein normales Programm.
- Vielleicht habe ich den Sender noch nicht richtig eingestellt, aber ich sehe alle gesendeten Werte gut außer Altitude (0m), latitude und longitude.
- Ich bekomme keine -1 Werte mehr. Alles ok.
- Ich habe channel 5 gelesen. Dies ist mit meinem Zifferblatt (VR) am Sender verbunden. Die Werte reichen von 208 bis 2032. Beim Aufdrehen werden die Werte jedoch nicht allmählich erhöht. Zum Beispiel: 208 311 423 360 525 678 601 und so weiter. Gelegentlich also auch einen niedrigeren Wert beim Aufdrehen. Ich nehme es leicht. Gilt auch für das Ablehnen.

Hoffentlich profitieren Sie von meinem Test. Und Vielen dank für die Arbeit.


send_f1675_gps(GPS_SLOT, (uint16_t)50, (int16_t)100, (int16_t) 200, latitude, longitude); // Speed = 50km/h, Altitude = 1000m, Vario = 200m/s

Ich habe Altitude 100 statt 1000 gemacht. Jetzt sehe ich -900m auf dem Sender.
Mit 1100 sehe ich 100 meter auf dem Sender.
 
Die SBUS(2) Frames kommen werden alle 15 ms empfangen (bzw telemetrie gesendet)

d.h.
alle 15ms sollte ein aktueller Servo Wert zur verfügung stehen.

Bisher habe ich wenig bis gar keine Zeit in die Servo Kanalauswertung investiert. Dies werde ich mal nachholen und testen. Erst wenn ich das getestet habe gibt eine neue Version auf Github.

Mal sehen wann ich dazu komme:rolleyes:


Zum GPS Sensor:

Höhe und Entfernung werden erst im Sender berechnet. Das heißt, der erste Höhenwert ist der Startwert und damit immer 0m. Erst wenn sich die Höhenwerte ändern wird die Änderung im Sender angezeigt.
Deswegen wird 100m angezeigt wenn die Höhe von 1000m auf 1100m geändert wird.

Genauso ist es mit den Koordinaten (Longitude/Latitude). Die ersten Koordinaten sind der Startpunkt. Erst wenn sich dieser Ändert wirde eine Distanz angezeigt.
Bei der T14SG lässt sich die absolute Koordinate bei der Distanz anzeigen, wenn man direkt den "DistanzWert/Distanzfeld" öffnet.

Das ist von Futaba so vorgegeben.
Eine mögliche Hilfe wäre es die ersten 5-6 Telemetrieframes mit 0m zu senden und erst dan den eigentlichen Höhenwert.
Ist aber an sich quatsch. Man möchte ja die relative Höhe/Distanz wissen. Nicht die absolute.


An alle T18MZ oder FX32 Nutzer (Bzw. alle bei denen Der Sender die Telemetriedaten auf SD Karte loggt):

Bei GPS Sensor werden 8 Werte auf SD Karte geloggt, aber nur 4 Werte (T14SG) im Sender Live angeziegt.
Daher würde mich mal ein Logfile vom meinem GPS Sensor interessieren, ob dabei alles passt.
Besonders die UTC Zeit wird nur im Logfile gespeichert.
Und ich habe aktuell keinen Schimmer ob die Zeit richtig sende.
 
Ich habe channel 5 gelesen. Dies ist mit meinem Zifferblatt (VR) am Sender verbunden. Die Werte reichen von 208 bis 2032. Beim Aufdrehen werden die Werte jedoch nicht allmählich erhöht. Zum Beispiel: 208 311 423 360 525 678 601 und so weiter. Gelegentlich also auch einen niedrigeren Wert beim Aufdrehen. Ich nehme es leicht. Gilt auch für das Ablehnen.

Bisher habe ich wenig bis gar keine Zeit in die Servo Kanalauswertung investiert. Dies werde ich mal nachholen und testen. Erst wenn ich das getestet habe gibt eine neue Version auf Github.

Also ich habe jetzt ein paar tests durchgeführt.

Soweit sieht das aber alles gut aus. Die Werte die per SBUS(2) übertragen werden passen mit den Servo Werten überein.

Es sollten keine Delay() funktionen in der Loop() benutzt werden.
Auch die Softserial sollte nur benutzt werden wenn unbedingt nötig.


Der GPS Sensor funktioniert auch noch nicht richtig. Die angezeigte Koordinate in der T14SG passt nicht mit der aus dem Sketch überein.

N 52° 31' 14.9988" = 52520833(Dezimal) wird angezeigt als N 53° 44.5121

E 13° 24' 33.9480" = 13409430(Dezimal) wird angezeigt als E 13° 19.6608


Daher wird es erstmal bei der Beta Version in Github bleiben.
 

DKHDKH

User
Ich habe noch eine Frage. Wie kann ich den Strom mit 1 Ziffer hinter dem Komma am Sender anzeigen? Zum Beispiel 2.6 A.
Mit Spannung kann ich 1230 senden für 12,30V, aber nicht mit dem Strom.
 
Ich habe noch eine Frage. Wie kann ich den Strom mit 1 Ziffer hinter dem Komma am Sender anzeigen? Zum Beispiel 2.6 A.
Mit Spannung kann ich 1230 senden für 12,30V, aber nicht mit dem Strom.

Ja, das geht. Müsste sogar mit 2 Stellen nach dem komma gehen.

in der SBUS2.cpp folgende Zeilen suchen:

Code:
void send_s1678_current(uint8_t port, uint16_t current, uint16_t capacity, uint16_t voltage)
{
   uint16_t value = 0;
   uint32_t local = 0;
   uint8_t bytes[SBUS2_TEL_DATA_SIZE] = {0x03, 0x40, 0x00 };
 
   
   // CURRENT
   local = ((uint32_t)current) [B]* 100[/B] ;
   value = (uint16_t)local;   
   if ( value > 0x3FFF )
   {
      // max current is 163.83
      value = 0x3FFF;
   }

Die * 100 entfernen (für 2 Nachkommastellen) und der funktion 2000 für 20,00A übergeben.
oder die * 100 durch *10 ersetzen und der funktion 200 für 20,0A übergeben.


ich werds mal bei Github als Issue für die neue Version eintragen.
Wird dann gleich mit eingepflegt.


Den GPS Sensor habe ich inzwischen auch hinbekommen.
Außerdem hab ich was gefunden um die Servo Kanäle aus dem SBUS Frame effizienter zu berechnen.

Brauche noch ein paar Tage zum testen und aufräumen.
 
Ansicht hell / dunkel umschalten
Oben Unten