Link Quality Sensor von Tadango

Status
Nicht offen für weitere Antworten.
Carbonator

Carbonator

Allerhopp ;)
#1
#1
RealTadango/FrSky

Hier mal ein kleiner Baubericht für einen äußerst sinnvollen Sensor im FrSky Bereich. Er misst die Prozentzahl der im SBus Protokoll erfolgreich übertragenen Frames, ist also ein direkter Indikator der Verbindungsqualität. Benötigt werden

- Arduino pro mini oder nano 328 16MHz 5V
- ein SBus Inverter (fertig bei eBay oder handgeschöpft nach Bauplan)
- ein Servokabel für den SBus oder SPort
- ein Einzelkabel für den SBus oder SPort

Entweder man versorgt den Ardu über das SBus oder das SPort Kabel, in meinem Beispiel SPort, für den anderen Anschluss reicht dann ein Einzelkabel. Baut man den Inverter mit einer SMD Transe auf dem Ardu auf, ist es ein ziemliches Gefuddel, aber halt unschlagbar klein.

SPort Signal an Pin3, SBus invertiert an RX, GND an GND und die Spannung an RAW, dann passt das von 5-12V. Doppelklick auf die LinkQualitySensor.ino, Passendes Board und Com-Port einstellen, dann Rechtspfeil -> sollte laufen

Wer sich den Selbstbau nicht antun will, ich verkaufe mein betriebsbereites, eingeschweißtes und handsigniertes ;) Kunstwerk für 20,--€ inkl. Versand.

Vorne.jpg
Hinten.jpg 2N2222.png
 

Anhänge

Zuletzt bearbeitet:
quax2011

quax2011

Erfahrener Benutzer
#2
#2
Hi Carbo, Mal eine Frage: Wo hast du die dünnen Drähte her die du für deine Basteleien verwendest? Ich hab sowas schon gesucht aber nirgends gefunden.

Gruß Jürgen
 
Carbonator

Carbonator

Allerhopp ;)
#3
#3
quax2011 hat gesagt.:
Wo hast du die dünnen Drähte her die du für deine Basteleien verwendest?
Zum Vergrößern anklicken....
Zur Zeit nutze ich ein geschlachtetes Netzwerkkabel, da sind 4 unterschiedlich gefärbte Doppeladern drin. Aus dem PC-Bereich eignen sich aber sowieso viele Strippen, Monitor, Maus, Tastatur u.s.w.

Der abgebildete Sensor funktioniert übrigens nicht. Er meldet immer 100%, das ist zwar beruhigend, aber leider nicht korrekt. Ich vergleiche jetzt mal mit meinem bewährten Sensor aus dem Rangetestcopter.
 
Zuletzt bearbeitet:
markus1234

markus1234

CopterFail
#4
#4
Wo setzt du das ein? Am Sender oder im Modell?
Ich benutze Ähnliches, allerdings als Android App welche die Daten per BT vom Sender bezieht. Das Ergebnis ist alles andere als linear, sobald die ersten defekten s.port Packete kommen, ist schnell Schluss mit Telemetrie...
 
S

strgaltdel

Erfahrener Benutzer
#5
#5
Der Sensor wertet im Modell den Sbus aus und leitet via SPort die Prozent-Zahl richtiger frames per 100 Blöcke an die Telemetrie weiter
Updateintervall also alle 100 frames
95% = 5 verlustierte frames per 100 im letzten "Streampaket"

Wenn die Telemetrieverbindung zum Sender dann allerdings "müll" ist, hast du davon leider auch nix...
 
Carbonator

Carbonator

Allerhopp ;)
#6
#6
Entwarnung, der Sketch oben ist OK, mein kunstvoll drapierter Inverter war schuld.

@markus1234 Der Sender hat "nur" RSSI als Indiz für die Verbindung. Reicht normalerweise auch vollkommen aus.
RSSI = Empfangsstärke = wie "laut" hört der Empfänger den Sender
LQ = Datenqualität = wie gut ist die "Sprachverständlichkeit"

Ohne sonstige Störer beginnt der LQ erst mit der üblichen RSSI Warnung abzufallen, bis dahin hat man konstant >95%.

Wenn z.B. ein Urbayer mich anspricht: RSSI = 102dB, LQ = 10% :)
 
markus1234

markus1234

CopterFail
#7
#7
Der Sender hat an seiner s.port Schnittstelle alle s.port Telegramme, das sind alle Telenetriedaten des RX und alle Telemetriedaten der FC und zusätzlich noch die interne Telemetrie des Senders. Vermutlich werden defekte s.port Telegramme im Modell allerdings nicht an den Sender zurück gesendet. Zu s.bus hat man so natürlich keine Information.
Aus deiner Rückfrage entnehme ich dann, dass dein Arduino im Modell eingesetzt ist.
Die Verbindung ist bidirektional, s.bus bildet nur eine Richtung ab, die mit der höheren Sendeleistung.
 
Carbonator

Carbonator

Allerhopp ;)
#8
#8
Ich beschreibe mal aus meiner Sicht (etwas vereinfacht) das D16 Protokoll:

Das Sendemodul schickt alle 9ms ein Datenpaket zum Empfänger, dieses Datenpaket enthält 8 Kanalinformationen und SPort Informationen (von am Sender angeschlossener Telemetrie oder von Software generiert - nur SWR und TxBt werden nicht hochgeschickt).

Der Empfänger dekodiert diese Datenpakete und bildet daraus das SBus-Paket mit bis zu 16 Kanalinformationen (wobei immer nur 8 alle 9ms aktualisiert werden können. Außerdem werden am SPort die SPort Pakete vom Sender ausgegeben. Und an den PWM Anschlüssen die entsprechenden PWM Daten.

Der Empfänger frägt regelmäßig alle SPort IDs ab, wenn ein Sensor seine ID liest, schickt er Daten zurück, wenn vorhanden. Diese Daten werden zusammen mit den internen Daten (RSSI, RxBt) vom Empfänger an den Sender zurückübertragen und vom Senderbetriebssystem ausgewertet. Am Sender SPort stehen alle Daten ebenfalls zur Verfügung. Diese überträgst du mit BT an Android.

FPort lassen wir mal außen vor, der macht nur mit FCs Sinn.

Die Funktion des LQ-Sensor hat @strgaltdel oben schon beschrieben. Er weiß sozusagen, wieviel Prozent der Senderpakete fehlerlos am Empfänger angekommen sind. Dazu wertet er die SBus Frames aus, die synchron mit den "over the air" Frames vom Empfänger gebildet werden und sendet die Prozentzahl über die Telemetrie zurück. Die Telemetrie bricht natürlich irgendwann ab, aber vorher ist die Linkqualität ebenfalls schon deutlich eingebrochen. Ich habe Dutzende Testflüge in den Failsafe gemacht, die das sehr schön zeigen.

Deine App zeigt vermutlich dasselbe auf SPort Seite: Lange alles bestens und an der Reichweitengrenze ist dann relativ schnell Schluss.
 
markus1234

markus1234

CopterFail
#9
#9
Ja, das sehe ich fast genauso. Bei f.port werden die s.bus Inhalte mit in den "s.port" gepackt.

Interessant das man schon Probleme im stärkeren downlink erkennt, während die schwache Telemetrie Verbindung noch steht.
Aber wie du gesagt hast sieht man nur einen kleinen Bereich, also nur bis die Telemetrie abbricht.

Würde man es umgekehrt machen, also die Haufigkeit der Telemetrie Telegramme auswerten , die zum Sender zurück kommen, dann hätte man für diesen Bereich eine Skalierung von 0-100%. Wenn die Telemetrie abbricht ist natürlich genauso Schluss.
 
Carbonator

Carbonator

Allerhopp ;)
#10
#10
markus1234 hat gesagt.:
Interessant das man schon Probleme im stärkeren downlink erkennt, während die schwache Telemetrie Verbindung noch steht.
Zum Vergrößern anklicken....
Man weiß halt genau, wie viele SBus Frames kommen müssen, 111/s. Bei der Telemetrie ist es nicht so klar. Da wird nicht jeder Slot genutzt, weil ja auch eigentlich nicht vorhandene ID's regelmäßig (aber seltener) abgefragt werden. Es ist fast unmöglich, ein einzelnes ausgefallenes Telemetrie-Frame zu erkennen.

An der Reichweitengrenze stellt der Empfänger immer vor Abbruch des Empfangs das Senden von Telemetriepaketen ein. So riskiert er nicht, bei vielen Frameverlusten und damit fehlender Synchronisation in ein Senderframe hineinzusenden. Die Priorität bleibt so immer gewahrt.
 
Carbonator

Carbonator

Allerhopp ;)
#13
#13
Das ist meine aktuelle Evolutionsstufe zum Einschleifen.
Inverter mit 2N7000 und einem 1/10W 10k Widerstand. Der 2N7000 liegt mit der flachen Seite auf dem Ardu, der linke Anschluss geht an RX zusammen mit dem 10k, der rechte wird in GND gelötet, der mittlere ist SBus Eingang. Der 10k wird dann noch zusammen mit 5V in VCC gelötet. GND und SPort (D3) fehlen noch. Der Sketch muss vor dem Anschluss von RX aufgespielt werden.

Layout2.jpg
 
Carbonator

Carbonator

Allerhopp ;)
#15
#15
Hi,
kann durchaus sein, dass der Code schon 3 Jahre alt ist. Er hat jetzt auf seine SPort Library umgestellt, aber die Funktion ist gleichgeblieben.
 
F

FPV-AH

Neuer Benutzer
#16
#16
Carbonator hat gesagt.:
RealTadango/FrSky

Hier mal ein kleiner Baubericht für einen äußerst sinnvollen Sensor im FrSky Bereich. Er misst die Prozentzahl der im SBus Protokoll erfolgreich übertragenen Frames, ist also ein direkter Indikator der Verbindungsqualität. Benötigt werden
******
******
******
Zum Vergrößern anklicken....
Hallo Carbo,

Danke für Deine hilfreichen Beschreibungen.

Tadango hat auf Github die Struktur umgestellt, daher funktioniert der in Deinem ersten Post angegebene Link nicht mehr.
Hier der aktuelle Link:
RealTadango/FrSky

Ich finde es schade, dass FRSKY Nutzer sich nur durch eine solche Bastellösung die Übertragungsqualität/Lost Frames anzeigen lassen können.
Die Daten liegen im Empfänger vor.
Mein Wunsch wäre es die Daten direkt vom Empfänger als Telemetriewert zu erhalten.

Gruß

Alfons
 
F

FJH

Erfahrener Benutzer
#17
#17
Hallo Alfons,

melde deinen Wunsch doch einfach einmal bei FrSky an, indem du auf RCG einen neuen Thread damit aufmachst => FrSky - RC Groups

Ich könnte mir schon vorstellen, dass andere User sich da deinem Wunsch anschliessen, und FrSky liest dort letztlich mit.
 
F

FPV-AH

Neuer Benutzer
#19
#19
Hallo FJH,

ich bin ein relativ unerfahrener (älterer) FrSky User (Taranis und X10S), der regelmäßig mitliest und sich langsam in das Thema FrSky und OpenTX einarbeitet.
Meine Englischkenntnisse sind auch bescheiden.
Vorschläge im RC Groups Forum sind sicherlich effektiver, wenn sie von einem erfahrenen dort bekannten User kommen.

Graupner HoTT scheint FrSky in dem Punkt Anzeige der Signalqualität voraus zu sein.
Gemäß Bedienungsanleitung wird bei Graupner HoTT in der Telemetrie übertragen:
  • "S-dBm: Pegel in dBm des beim Empfänger eintreffenden Signal des Senders
    Das könnte ähnlich dem FrSky RSSI sein
  • S-STR Signalstärke in % des beim Empfänger eintreffenden Signal des Senders
    Wahrscheinlich auch ähnlich dem FrSky RSSI, nur in %

  • S-QUA (Signalquallität)
    "Dieser Wert stellt eine Art „Bewertung der Brauchbarkeit“ der beim Empfänger eintreffenden Signalpakete des Senders in % dar. Diese, vom Mikroprozessor des Empfängers vorgenommene Bewertung der Qualität der vom Sender eintreffenden Signalpakete in %, wird über den Rückkanal des Empfängers „live“ an den Sender gesendet und im Display entsprechend angezeigt."
Gruß

Alfons
 
Status
Nicht offen für weitere Antworten.
FPV1

Banggood

Oben Unten