SBUS-Frame Monitoring über SPort

Norbert · Jan 10, 2017

HAbe jetzt meinen X4R am non-inverted Pin SBus mit dem Arduinio Rx verbunden, sowie D8 mit SPort, sowie Carbonators Script, klappt wunderbar.

Kann eure Werte nur bestätigen. Ab ~ RSSI 55 fällt die % Angabe unter 100%. Habe mir die Werte einfach ansagen lassen und im Range Mode gearbeitet. Dämpfung durch Betonwände im Keller und "justierbar" durch die Stahltüre im Heizungskeller.

Weshalb die RSSI und die LostFrame Werte unter RSSI ~ 32 so unvorhersagbar werden - keine Ahnung. DIe Werte ändern sich sehr deulich, ohne dass die Umgebung sich verändert. Ob das im freien Feld ebenso ist kann ich aufgrund des Wetters nicht testen.

Ich finde es ein sehr gutes Tool, um die Übertragungsstrecke zu testen und zu erkennen, wann die Signalqualität einbricht.

Norbert

Carbonator · Jan 11, 2017

Sigimann hat gesagt.:

Tadango scheint das mit einem gleitenden Durchschnitt zu machen:

Code:

currentpercentage = 100 - (((double)lastLost / (double)frameLossBuffer) * (double)100);

Aber mit aller Vorsicht, ich sehe mich mehr als Praktiker

Sigimann · Jan 13, 2017

So. der Ardiono ist da, angeschlossen, Software installiert, erste Tests gelaufen.

Den Sketch von Tangando hab ich dann auch und kann auch erkennen wie ausgelesen und Verarbeitet wird.
Es wird jeder S.Bus Frame auf Lost ausgewertet. Der Lost-Prozentwert wird immer mit den letzten 100 Frames berechnet.
Ein Lost von 1% bedeutet also 1 Lost Frame bei den letzten 100. Dieses eine Lost Frame bleibt dann für die nächsten 100 Berechnungen aktiv, da ja bei jeder Neuberechnung nur 1 aktuelles Frame dazukommt.
Ich weis nicht mit welcher Taktzeit die S.Bus Frame kommen, ich denke mal mit 18 ms (Messe ich später mal).
Auch die Taktrate der Telemetrie kenn ich nicht. Wenns jemand weis, kann ich mir das Messen sparen.

Gehen wir von einer s.Bus Taktrate von 18 ms aus, dann zeigt ein Lost%Wert die Signaqualität der in den Vergangenen 1,8 sec.
Eine Störung von z.B. 200 ms Dauer führt jedoch sofort zu einem Einbruch von 11%. Die 11 % bleiben dann aber 1,6 Sekunden stehen, also auch bei lückenhafter Telemetrie hat der Einbruch als Einzelereigniss sehr gute Chancen zum Sender durchzukommen. Auch gestreute LostFails werden gut abgebildet und mit "Nachhall" gesendet.

Die Frage, ob bei der Telemetrie viel verloren geht stellt sich nicht, der Verlust von Rücksendeframes hat eine geringe Bedeutung.

Ich denke das ist absolut sauber gelöst, besser geht's wohl nicht.

Sigi

So, Winter, keine Zeit mehr.

Carbonator · Jan 13, 2017

Sigimann hat gesagt.:

SBus Frames kommen alle 9 ms, bei Übertragung von bis zu 8 Kanälen werden diese auch alle 9 ms aktualisiert. Bei mehr als 8 Kanälen wird alle 18 ms aktualisert, weil abwechselnd die unteren und die oberen Kanäle an der Reihe sind.

Die SPort Updaterate hängt von der Anzahl der Sensoren ab, ich hatte 10 Hz geschätzt, wenn nur der Lost Frames Sensor dranhängt. Eine Messung wäre aber interessant.

Sigimann · Jan 14, 2017

Um den skatch von tangando zu verstehen, musste ich mir das SBus Protokoll ansehen.
Das Protokoll ist immer gleich mit allen 16 Kanälen, egal wie der Empfänger gebunden ist.
Es sind immer 25 Byte. 1 Startbyte, 22 Datenbyte (16 Kanäle), ein Flagbyte (6te Bit = Bit5 = Lost Frame), 1 Schlussbyte.

https://developer.mbed.org/users/Digixx/notebook/futaba-s-bus-controlled-by-mbed/

Das Frame muss immer gleich sein, die Taktrate kann unterschiedlich sein, aber 18 ms wären Sinnvoll, wenn das die Zeit für die Funkübertragung von 16 Kanälen ist.

Aktuell suche ich jetzt nach dem Anschluss von Arduino an SBus/SPort, etwas Hilfe verkürzt hier meine Suche.
Sch... Internet, suchst du was, was nichts kostet, wird immer schwerer.

Sigi

Deleted member 51580 · Jan 14, 2017

Carbonator hat gesagt.:

hier die Daten vom S-Port von einen S6R mit und ohne Sensor gemessen.

S-Port ohne angeschlossenen Sensor

S-Port mit einem angeschlossenem GPS Sensor

S-Port S6R mit GPS Sensor puls Messung.JPG

hier noch ein X8R mit GPS Sensor am S-Port.

S-Port X8R mit GPS Sensor puls Messung.JPG

und hier der S-Bus des X8R ohne angeschlossene Geräte.

Carbonator · Jan 14, 2017

Sigimann hat gesagt.:

Ein anderer NPN Transistor sollte auch funktionieren. Links ist der SBus, die rechte Seite geht an den RX PIN vom Arduino. Der Sendepin vom Arduino, bei mir (D) 8, geht an den SPort PIN des Empfängers (- und + vom SPort können freibleiben, oder zur Versorgung des Arduino benutzt werden).

@devil: Muss leider heute arbeiten, hast Du Lust, noch die Zeiten dranzuschreiben? Dann sollte man mal noch mit mehreren Sensoren am SPort testen.

Carbonator hat gesagt.:

Mittlerweile denke ich, dass nur 27 IDs abgefragt werden, weil die Empfängersensoren RSSI und RxBt nicht auf dem externen RX-SPort erscheinen.

Deleted member 51580 · Jan 14, 2017

Carbonator hat gesagt.:

Welche Zeiten möchtest du haben die nicht schon da stehen ?

Mehrere Sensoren kann ich noch mal testen .

Carbonator · Jan 14, 2017

devil hat gesagt.:

Ich finde es zielführend, wenn Messungen interpretiert werden. So muss jeder die Hardcopies laden und sich seine eigenen Gedanken machen, eine Diskussion der Messungen ist dann schwierig.

Was ich zum SBus zu wissen glaube:
Das SBus Signal wird im Empfänger gebildet, es hat mit der TX-RX Kommunikation nichts zu tun. Ein SBus Frame wird immer alle 9ms ausgegeben und beinhaltet 16 Kanalinformationen und den Status (Failsafe und Lostframe) (sowie eine Prüfsumme?). Bis zu 8 Kanälen schafft es OpenTX, alle 9ms neue Daten zu schicken, das heißt, das SBus Frame ist immer aktuell. Bei mehr als 8 Kanälen werden abwechselnd 1-8 und 9-16 im SBus Frame aktualisiert. Man müsste mal schauen, was in den nicht benutzten SBus Kanälen steht, evtl. Servomitte, also 1500us. Vielleicht liest Ralf mit und kann mal mit seinem 16 Kanal Decoder prüfen, wie ein Servo an diesen Kanälen angesteuert wird.

Sigimann · Jan 14, 2017

Carbo, Danke für den Anschlussplan.

Nach der Messung von Devil passt deine Erklärung zum SBus Takt auf 9 ms. Für 16 Kanäle wird ebend Wechselweise in jedem 2. Takt aktuallisiert.
Für die LostFrame Auswertung beträgt die Auswertezeit (und Haltezeit eines Lost) dann 0,9 sec.

Einen Punkt in Tadangos Programm verstehe ich jedoch noch nicht.

Abfrage auf LostFrame in Zeile 87 (Github):

bool framelost = buffer[23] & 0x04;

Hier wird in buffer[23] mit 0x04 das Bit 3 (00000100) abgefragt.
Nach meiner Recherche liegt das LostFlag jedoch auf Bit = 5 (00100000) = Hex20.

Was ist da Falsch?

Github
https://github.com/RealTadango/ssen...ality/LinkQualitySensor/LinkQualitySensor.ino

Sigi

Carbonator · Jan 14, 2017

Sigimann hat gesagt.:

Ich meine, das ist das LSB/MSB, einfach spiegelbildlich.

Das ist noch ganz interessant, wenn mal jemand einen X-XR im D8 Modus bindet:
SBUS on FrSky receivers runs at a fixed 9ms frame rate (which is the whole system's frame rate, also for RF). In D16 mode in each 9ms cycle we have both an uplink (control) transmission and downlink (telemetry) transmission. In D8 mode it's different, you have 3 contiguous 9ms frames for uplink, then the 4th is reserved for telemetry downlink.

Das heißt, jedes 4. Frame geht dann verloren.

Sigimann · Jan 14, 2017

Die Pause nach drei Frames könnte SBus2 Kompatibel sein, der geht bei Futaba ja noch die Telemetrie drüber.
Bei der Messung von Devil war die Pause ja nicht da.

Ich bin noch nicht so weit, kämpfe seit einer Woche mit USB OSI (neu), der will nich.

Sigi

Sigimann · Jan 14, 2017

Carbonator hat gesagt.:

Das erklärt es. Das Byte wird wohl seriell von links in die Variable eingelesen, das erklärt mir jetzt noch vieles andere. Ein Brett vorm Kopf weniger.

Sigi

headwind · Jan 14, 2017

Code:

uint16_t PNP_SBUS::update_packet_stat(uint8_t  sbusstatus){

 uint8_t i, framesok; 

  framesok = 0;

  _sbus_framesOK_stat[_sbus_stat_count] = sbusstatus;
  _sbus_stat_count++;
  if(_sbus_stat_count > 99)
  {
    _sbus_stat_count = 0;
  }
  
  for(i = 0; i < 100; i++)
  {
    if(!_sbus_framesOK_stat[i])      
      {
        framesok++;
      }
  }

  return framesok;
  
}

Köstlich.

mfg hw

Sigimann · Jan 16, 2017

Carbonator hat gesagt.:

Heute kamen dann auch die Transistoren und ich bin da noch unsicher.

VCC geht an Plus Empfänger (SBus)?
GND geht an beide, Arduino und Empfänger

Beim Testaufbau wird der Arduino Uno über Netzteil am 12 V Eingang versorgt.
Im Flieger soll der Arduino dann vom Empfänger versorgt werden, wo geht es dann rein?
auf +V5 ist sicher falsch?

Sigi

Carbonator · Jan 16, 2017

Sigimann hat gesagt.:

Korrekt, SBus oder SPort, die 5V sind identisch.

Sigimann hat gesagt.:

Wenn der Uno in den Flieger passt, und du 5V-Versorgung für den RX hast, dann die 5V auch an den +5V Pin anschließen. Das Einfachste ist dann, da du eh an SBus und SPort musst, an einem auch GND und +5V zu holen, für den Anderen reicht dann das SBus oder SPort Signal, insgesamt also 4 Verbindungen.

Sigimann · Jan 16, 2017

Danke. Mal schauen ob der Uno wirklich im Flieger landet, bis Wetter ist hab ich sicher einen Nano oder Micro in Funktion.
Aber ein guter Rat von dir, dass man ja 5V braucht, und nicht 6,6 V (7V) vom LiFe.
Schiele auch nach dem Teensy. Soll ja Arduino verstehen, kann der dann Arduino Programme unverändert.

Sigi

headwind · Jan 16, 2017

Ich begreife nicht, weshalb ihr euch mit veralteter Hardware, die nicht mal ein TXRX-INV kann und Müll-Software die den SPORT zuknallt beschäftigt. Die wird kaum gute Arbeit leisten - ich habs kurz angeschaut und auf die Schnelle nichts gesehen, das auf eine Auswertung eines RX-pollings hinweisen würde. Mit anderen SPORT-Sensoren wird sie mE nicht zusammenarbeiten. Ich seh da nix, was in irgendeiner Weise mit SPORT-Protokoll zu tun hätte.

Wenn ihr was braucht - vergesst die sinnlose Schnäppchenjagd und kauft brauchbare Hardware für die ich programmiere und sagt vor allem mit etwas Gehalt und Präzision was ihr braucht. Da gibt es etliche Code-Schnippsel, die eure Fragen oder Bedürfnisse mit einiger Wahrscheinlichkeit beantworten würden. Etwas selber machen - dazu brauchts ein wenig verstehen und dann eben selber implementieren.

Pfannenfertige Lösungen - gibts bei mir nicht. Gezielte Fragen beantworte ich gerne und stelle auch Code-Schnippsel rein, die ich gerade habe. Und davon habe ich eine ganze Menge.

Ich habe zuweilen den Eindruck, dass ich hier im komplett falschen Forum bin. Ein wenig von dem Kram muss man schon verstehen, wenn man eigene Lösungen realisieren will - sonst kann ich da reinstellen, was ich will. Wer da keine Ahnung hat, kauft eben das Fertigprodukt. Und wer was davon versteht - der platziert es eben am passenden Ort in seinem eigenen Code.

Macht mal weiter - es hat zuweilen Unterhaltungswert.

Norbert · Jan 16, 2017

Hallo Headwind,

Zitat:" Ich begreife nicht, weshalb ihr euch mit veralteter Hardware" usw usw

Damit hilfst du wirklich niemandem. Ich bin ebenfalls einer dieser Trottel, die sich damit beschäftigt haben, weil ich sonst keine Möglichkeit für mich sehe zu erkennen, ab welchem RSSI die Signalqualität schlechter wird.

Ich bin begeistert, wenn ich ein "Pfannenfertiges" Tool verwenden kann, das mir weiterhilf, auch wenn man einen Inverter dazwischen schalten muss. Damit war die Sache für mich in 30 min fertig "gekocht".

Ich habe zwar früher selbst über Jahre beruflich in Hochsprache programmiert, bin aber nicht bereit noch ein eigenständiges Hobby anzufangen, denn bis man freihändig mit einer Programmiersprache und fremder Hardware arbeiten kann sind wochenlange Arbeit nötig.

Wenn du strukturell etwas beitragen möchtest - gerne - immer willkommen - aber Kommentare wie "köstlich" sind nicht hilfreich.

Es mag ja sein, dass dass eventuell ungeschickt programmiert ist - weiss ich nicht - hilfreich wäre dann ein alternativer Code.

Und daß die Hardware keine Signalinvertierung kann - mag sein. Ich bekomme die Arduinios für etwas über 1€. Wenn ich einen himmle - naja. Und kann man das Signal nicht softwaremäßig drehen? Vielleicht ist der Arduionio dafür zu langsam? Mag sein.

In diesem Sinne

Norbert

PS: Falls dir langweilig ist, steht es dir gerne frei etwas besseres zu programmieren und hier zur Verfügung zu stellen, bevor du 100erte von ironischen Worten hier tippst. Ich kann den Unterhaltungswert für mich nicht erkennen.

Carbonator · Jan 16, 2017

headwind hat gesagt.:

Eigentlich wollte ich auf diesen Post gar nicht eingehen, da du dich jetzt nochmal meldest, frage ich doch mal nach: Der Code ist nicht aus Tadangos Link Quality Script, was soll diese Bemerkung an dieser Stelle?

Ansonsten stimme ich Norbert zu 100% zu. Was nützt mir die neueste Hardware, wenn das Script nicht läuft. Wenn ich überlege, womit die Amis zum Mond geflogen sind, ist so ein Arduino gar nicht so verkehrt, um anspruchsvolle Aufgaben zu erledigen - es kommt halt auf die Software an.

Im Übrigen lebt so ein Forum davon, dass jeder das einbringt, was er kann. Wenn aber hier niemand ist, mit dem du auf deiner Ebene kommunizieren kannst, oder du dich nicht auf die Ebene der Nichtprogrammierer herablassen kannst, gibt es sicherlich geeignetere Foren für dich, um dein Spezialwissen entsprechend gewürdigt zu bekommen.

Nebenbei wäre ich erfreut, wenn mal jemand Tadangos Script, das einwandfrei läuft, erläutern könnte. Ich war auch überrascht, wie "einfach" es ausfällt. Die Zeit, die ich bräuchte, um die Funktionsweise zu verstehen, möchte ich nicht investieren. Aber es soll ja Leute geben, die das lesen und verstehen wie unsereiner die Tageszeitung.

SBUS-Frame Monitoring über SPort

Erfahrener Benutzer

Allerhopp ;)

Erfahrener Benutzer

Allerhopp ;)

Erfahrener Benutzer

Deleted member 51580

Gast

Allerhopp ;)

Deleted member 51580

Gast

Allerhopp ;)

Erfahrener Benutzer

Allerhopp ;)

Erfahrener Benutzer

Erfahrener Benutzer

Benutzer

Erfahrener Benutzer

Allerhopp ;)

Erfahrener Benutzer

Benutzer

Erfahrener Benutzer

Allerhopp ;)