Frage zum FrSky Sensor Hub Protokoll

[Rangarid]

Hallo,

nachdem ich mir seit gestern Abend den Kopf zerbrochen habe warum mein Parser bei einem der drei Frames nicht funktioniert, die andern zwei Frames aber kein Problem sind habe ich das ganze mal durch nen Serialportmonitor laufen lassen und bin dabei zu folgender Erkenntnis gekommen:

Frame 1, welcher laut Protokoll 49Bytes haben soll, kommt nur auf 29bytes
Frame 2, soll 53bytes haben, bekomm ich auch raus
Frame 3, soll 17 bytes haben, bekomm ich auch raus

Ein Frame vom Typ 1 sieht bei mir so aus:
5e 24 f0 ff <--Acc-x
5e 25 f0 ff <--Acc-y
5e 26 f0 ff <--Acc-z
5e 10 70 0 <--vario alt before "."
5e 21 4b 0 <--vario alt after "."
5e 2 ef ff <--Temp1
5e 5 e9 ff <--Temp2
5e <--Tail
Man sieht also, dass laut Protokoll noch die Daten für RPM, Voltage, Current und Amp Sensor fehlen. Dementsprechend reduzieren sich die Bytes um 20.

Wenn ich also davon ausgehe, dass ich nur 29Bytes für Frame 1 benutze klappt mein parsen nun auch anständig.

Jetzt meine Frage:
Ist das bei euch auch so, dass Frame 1 nicht auf die im Protokoll angegebenen Werte kommt? Oder woran könnte das liegen? Da bisher meines Wissens noch kein Stromsensor für den Hub da ist und auch kein Current Sensor könnte es sich hierbei um eine vorsorglich eingeplante Erweiterung handeln, die aber noch nich implementiert ist? Wär jedenfalls mal interessant zu wissen, warum bei jedem Protokoll was man irgendwo bekommt irgendwelche Fehler drin sind...(Garmin lässt grüßen...).

 

[somebuddy]

Die neueste Hub Firmware ?

 

[der-Frickler]

Evtl werden Sensoren die nicht angeschlossen sind auch nicht übertragen - was ja Sinn macht.

Bau den Parser einfach anders auf dann ist es scheiß egal in welchem Frame du gerade bist und ob ein Datensatz kommt oder nicht. Einfach jeden Datensatz als einzelnes Paket ansehen das mit 5e anfängt, dann folgt die ID dann 2 Bytes Daten.

int FrskyHubData[38] ;  // All 38 words
int state=0;

void processHubByte(byte b) {
  if ( state == 0 ){ // Waiting for 0x5E
    if ( b == 0x5E ) {
      state = 1 ;                  
    }               
  } 
  else { // In a packet
    if ( b == 0x5E ) { // 
      state = 1 ;                  
    } 
    else {
      if ( b == 0x5D ) {
        hubStuffFlag = 1 ;  // Byte stuffing active
      } 
      else {
        if ( hubStuffFlag ) {
          hubStuffFlag = 0 ;
          b ^= 0x60 ;  // Unstuff
        }
        if ( state == 1 ) {
          hubId = b ;
          state = 2 ;
        } 
        else if ( state == 2 ) {
          hubLowByte     = b ;
          state = 3 ;
        } 
        else {
          if ( hubId < 38 ) {
            FrskyHubData[hubId] = ( b << 8 ) + hubLowByte ;
          }       
          state = 0 ;

          if (hubId == 0x02) // temp1 (after height)
            newHeight = true;
        }
      }
    }                
  }

So hast du alle IDs später an der entsprechenden Stelle im Array stehen.

 

[Rangarid]

Naja ist halt seltsam, wenn ich andere Sensoren nicht dran hab kommt der Frame trotzdem als ganzes an...Laut FrSky sollen nicht angeschlossene Sensoren nicht angezeigt werden, aber wenn ich die nicht anschließe wird der Teil mit Nullen aufgefüllt...

 

[der-Frickler]

Weist doch wie das mit dokumentieren ist, das macht man als Entwickler wenn überhaupt ungenügend und auch nur wenns wirklich sein muss.
Is halt auch nicht perfekt das FrSky System, alleine die Sache mit den rs232 Pegeln - WARUM? wahrscheinlich weil der 1. Entwickler nur n seriellen Port am PC hatte... Sei froh das die überhaupt was rausgeben. Ich würde nich auf das ganze Frame gehen, das wird sicher mit der nächsten Version und neuen Sensoren wieder geändert.

 

[Rangarid]

Joah ich hol jetzt auch nur die einzelnen 5E Frames raus. War nicht viel Änderung in meinem Parser.

Andere Frage. Jetzt hab ich mein Vario dran aber mit den Werten bin ich höchst unzufrieden:

Vario: fff8 ffb7
Vario: fff6 fffa
Vario: fff7 ffb7
Vario: fff7 ffc7
Vario: fff6 ffc8
Vario: fff7 ffa6
Vario: fff6 ffe9
Vario: fff7 ffc7
Vario: fff6 ffb7
Vario: fff6 fffa
Vario: fff8 ffb7
Vario: fff8 ffd8

Der vordere Hexwert ist das vor dem "." der hintere nach dem ".", wie man sieht springen die ganz schön, dabei hab ich den Sensor garnicht bewegt...Wenn ich das ganze durch meinen Filter laufen lasse sieht die Ausgabe so aus (diesmal nicht in HEX):

Vario: 9.021648612120872m
Vario: 8.935345013106321m
Vario: 8.741491439792933m
Vario: 8.485957991764923m
Vario: 8.22495321882986m
Vario: 8.051986139326324m
Vario: 7.995966815800397m
Vario: 8.001090070079258m
Vario: 7.994717430334395m
Vario: 7.938184943864757m

Der Sensor wurde wieder nicht bewegt. Aber die Werte werden halt durch die Sprünge verfälscht...Naja mal kucken ob man da noch was machen kann. Habe noch einen andern Filter gesehen, vielleicht probier ich den einfach mal aus.

 

[der-Frickler]

Mein Filter macht ein moving-average über 5 werte nimmer dann immer die diff von alt und aktuellem Wert und "runded" dann noch auf 1/4 Nachkommastelle = 0,25m, damit war auf dem Schreibtisch ruhe im vario, es reagierte aber am boden und decke. Draußen am Platz wars wieder ein gefiebse.

 

[Rangarid]

Ich lass es demnächst mal im Mini Skywalker im Park mitfliegen und logge mal die Höhe, dann sieht man ja ungefähr wie genau das Vario letztendlich ist bzw wie hoch die Werte ohne Filter um den eigentlichen Wert herumschwirren. Ich mach dann mal n Bild mit Exel.

 

[somebuddy]

Habe den Hub gerade nicht zur Hand.. wie sieht denn die Verbindung zwischen Sensor und Hub aus ?Analoges Signal !? Vielleicht den Sensor notfalls durch bessere "Hardware" ersetzen ?

 

[Rangarid]

Hab mir mal ne Grafik zu den Werten die ich rauskriege gemacht (siehe Anhang)

Die gefilterten Werte schwanken nichtmehr allzustark, schwanken aber doch noch so +-1 maximum. Habe hier jetzt nichts gerundet bei den Originaldaten, sondern die daten so in meinen Filter gemacht, wie sie rauskommen...

Irgendwie ist mir das noch zu krass...woher kommen denn die Schwankungen da?

 

[der-Frickler]

nun ja, sind halt nur kleine Druckschwankungen die direkt n Meter unterschied machen, dann noch Messungenauigkeit des Sensors etc..
Evtl den Sensor mit was Schaumstoff einpacken gegen Windeinflüsse etc..

Sensor ist der normale Bosch baro via i2c, evtl mal in den code vom multiwii schauen, da soll das höhe halten mit dem sensor in der letzten Version deutlich verbessert worden sein.