SBUS-Frame Monitoring über SPort

Hi Carbo

ein Dankeschön an den Tester. Ein Feedback, das Hand und Fuss hat. Ich hab mal zu Testzwecken einen Zähler eingefügt. der alle 500ms raufzählt und das in der Taranis ausgelesen. Tatsächlich - so liess sich Deine Beobachtung nachvollziehen. Dasselbe, wenn die Daten &vario eingefüttert werden. Ich werde mir das in den nächsten 1-2 Wochen mal genauer anschauen - bin noch an der MPU9250 und MS5611 dran, und das möchte ich wenn ich gerade "drin" bin vorher auf 90% bringen.

mfg hw

[video=youtube_share;lbnMM-GxQBs]https://youtu.be/lbnMM-GxQBs[/video]

Ich hab mal testweise das RPM-Feld benutzt und da war die Übertragung fast regelmäßig.

Dann habe ich mal im Rangetest die Grenze der sicheren Übertragung ermittelt (man kann im Rangetestmodus übrigens mit Page auf die Telemetrieseite wechseln-wusste ich nicht). Interessanterweise war diese dort, wo ich sie auch beim Fliegen und bei der Analyse der RSSI Logs vermutet habe: bei 40 dB RSSI beginnen die Frameverluste. Bei 36 dB RSSI wird kein gültiges Frame mehr übertragen.
Der Test ist sicher in vielen Punkten fragwürdig, aber die gute Übereinstimmung mit meinen Erfahrungen zeigt, dass die FrSky Standardwerte für RSSI-Warnungen nicht so verkehrt sind.

Hier gibt es einen neuen Sketch für den Arduino pro mini/nano zur Messung der Lost Frames, ebenfalls in %. Superschnelles Update mit geschätzt 10 Hz. Leider wird ein Inverter für den SBus benötigt, da er am UART erwartet wird. Aber so ein Teil ist ja schnell zusammengelötet. Mein Test war indoor im Rangetest-Modus. Flugtest folgt, wenn das Wetter einigermaßen passt, bin gespannt!

Hallo,

hochinteressante Sache und erschreckend. Ab RSSI ~38 deutliche Einbrüche der Signalqualität, dh auswertbare Frames?

Das entspricht ja dem, was ich von FrSky in Zusammenhang mit RX8R gefordert habe - Signalqualität als Telemetriewert und darüber hinaus Umschaltung des Receivers zum Empfänger mit besserem Signal.


Original GitHub Readme zum LinkQuality:

"Link Qualoty Sensor

This sensor provides a link quality from S.Bus data.
Folder LinkQualitySensor contains an Arduino sketch for an Arduino Mini. RX port is connected to the S.Bus port of a FrSky receiver through an inverter. RB3 is connected to the S.Port of the X-Series receiver.
The sensor with id 0x5100 will show the link quality in %. This is not the RSSI but the actual quality of the received data."

Verstehe ich das richtig, über RX Port des Arduinio mit Inverter am X-Receiver SBus Anschluss und den RB3 des Arduinio am X-Receiver SPort. Dann noch +/- Stromversorgung das wars? Klar - Arduinio programmieren???

Was genau muss ich aufspielen? Das hackt es bei mir???

Vielen Dank für die Hilfe

Norbert

https://github.com/RealTadango/ssensors/tree/master/LinkQuality/LinkQualitySensor

Sketch mit Arduino Software kompilieren ( beide Dateien aus dem Verzeichnis...), dann auf Arduino hochladen...

Ralf

VielenDank,
werde ich nachher probieren.
Norbert

Das Thema sollte man differenziert angehen. Es liegen noch sehr wenige Logs mit Lost Frames vor.

Selbst wenn nur ab und zu ein Frame "durchkommt" bleibt das Modell steuerbar. Ich würde mir erst bei mehr als 50% Frameloss Sorgen machen. Aber ich finde es wichtig, die Grenzen auszuloten. Vermutlich gibt es einen recht soliden Zusammenhang zwischen RSSI und Lostframes. In HF-verseuchten Gebieten könnte es aber abweichende Ergebnisse geben. Da wären Tests bei viel Betrieb auf dem Modellfluggelände interessant.

Den Sketch von Tadango musste ich in der SPort.ino ein bißchen ändern. Hier ist der compilierfähige Sketch mit SPort auf D8, es kann aber jeder Digitalpin verwendet werden (im Sketch eintragen).

Anhang anzeigen LQ2.zip

Wichtig: Es müssen zwei Tabs mit LQ2 und SPort.ino zu sehen sein. Ein Doppelklick auf LQ2 startet bei mir die IDE und öffnet beide Tabs.

Hier nochmal ein Log mit einem vernünftigen Sender (X9E ) und einem X8R in 1100 m Entfernung. Man sieht, dass bei ordentlicher Installation noch eine Menge Sicherheitsreserve beim RSSI da ist.

@ Bernd

Was hast du denn noch geändert?
Die Datei die ich gestern vom Github geladen hab ist identisch mit deiner, hat bei mir auch ohne Probleme ( für Arduini Nano) direkt kompiliert...
Ralf

Ich hab noch mal nachgesehen: Nix, du hast Recht, das war mein eigener copy/paste Mist , der den Fehler verursacht hat, peinlich.

Geflashed ist der Arduinio mal.
Werde einen X4r als Empfänger verwenden, da es da den non-invertierten SBus gibt.
Eine Frage noch: Ich habe den Arduionio mini - also den ohne USB.
Da gibt es 2 RX-Pins .

An der Stirnfläche DTR - TX - RX - VCC usw, wo ich den Programmer anschliese

und seitlich von rechts nach links TX - RX - RST - GND usw

Sind die beiden RX Pins identisch oder muss ich den seitlichen nehmen?

Danke

Norbert

Sind identisch, ich nehm aber den seitlichen, damit ich den Programmer nach wie vor einfach einstecken kann.

OK -alles klar - Danke

Da ich keine Eisbrecher hab um bei diesem Wetter doch zu fahren mal ein schneller Schreibischtest:
Im Bastelzimmer Rangetest eingeschaltet, dann 2 Etagen Treppe Runter, unten 2x Antenne komplett Abgeschirnt ( = Failsafe). Dann wieder ab nach oben...

Failsafe Ende kann man sehr gut erkennen, das sind die Peaks bis 0.

Ralf

@ Bernd, damit hat sich für mich das Umstricken von Headwinds Sketch erledigt...

Sehe ich genauso. Ich war überrascht, wie übersichtlich der Sketch ist - ohne dass ich behaupten will, ich verstehe mehr als 15% davon. Kann es sein, dass die SPort.ino auch die Kommunikation über SPort kann und nicht nur die Telemetrie?

Die waagrechten Linien können auch bedeuten, dass die Telemetrie ausgefallen ist und nicht unbedingt, dass der Uplink die ganze Zeit ausgefallen war. Mach doch nochmal den Test im Rangetest-Modus, du kommst bestimmt noch unter RSSI 36. Der Rangetest hat den Vorteil, dass die Telemetrie solange funktioniert, bis der Uplink ausfällt - und du nicht so weit laufen musst

Der Test war im Rangetest-Modus (bis 20:26:15...)

Eigentlich gehe ich auch davon aus dass nur die Telemetrie ausgefallen war.
Mein Sohn hat jedenfalls behauptet die angeschlossenen Servos sind in Endlage = Failsafeposition gefahren, muss den Test also demnächt mit vertauschten Rollen mal wiederholen. ( Morgen ist aber Schule, der liegt jetzt schon im Bett...)

Ralf

Gestern hatte ich nochmal einen Test im Rangetestmodus gemacht, bei dem X4R scheint bei 36 dB die Grenze zu sein, bis zu der die Mehrzahl der Frames durchkommt. Aber scheinbar bis 16 dB herab findet eine Übertragung statt. Wobei der RSSI in dem Bereich nicht mehr vorhersagbar ist, er verändert sich irgendwie chaotisch.



Ein ähnliches Bild gab es auch schon bei meinem XSR Test, wo ich ein Dreieckssignal dekodiert und über den SPort zurückgeschickt hatte:



Auch beim XSR beginnt das RSSI Chaos bei 36 dB. Oder positiv ausgedrückt, bis hinab zu 36 dB haben wir eine sehr sichere Übertragung. Das entspricht bei vernünftigem Einbau (und Sender ) mehreren Kilometern Reichweite.

Perfekte Zusammenfassung zum Thema RSSI

Gestern entdeckt.

Ich würde ja gerne Mitreden, nur fehlt mir etwas der Plan dank kein Arduino zum probieren.

Frage: Was sollte ich kaufen, um mich mit Arduino anzufreunden.

Noch ne Frage zum Thema hier, weis jemand wie die Prozente des LostFail berechnet werden.

Sigi

Am besten holst du den Arduino nano, der hat eine USB-Schnittstelle onboard und ist klein genug, um ihn ins Modell zu packen. Und als Zweitverwendung kannst du ihn zum STK-Stick Ersatz umfunktionieren.

Hier sind die Grundlagen ganz schön zusammengefasst.

Im Prinzip ist das Ganze einfacher wie ein Firmwareupdate eines FrSky-Empfängers.

Vielen Dank das passt 100pro

Sigi