SBUS-Frame Monitoring über SPort

Status
Nicht offen für weitere Antworten.
H

headwind

Benutzer
#21
#21
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
 
Carbonator

Carbonator

Allerhopp ;)
#22
#22
[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.
 
Carbonator

Carbonator

Allerhopp ;)
#23
#23
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!

LQ_Rangetest.png
 
Norbert

Norbert

Erfahrener Benutzer
#24
#24
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
 
Carbonator

Carbonator

Allerhopp ;)
#27
#27
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 :D) und einem X8R in 1100 m Entfernung. Man sieht, dass bei ordentlicher Installation noch eine Menge Sicherheitsreserve beim RSSI da ist.

RSSI1100m.png
 
r41065

r41065

:)
#28
#28
@ 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
 
Norbert

Norbert

Erfahrener Benutzer
#30
#30
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
 
r41065

r41065

:)
#33
#33
08-01-2017.JPG
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...
 
Carbonator

Carbonator

Allerhopp ;)
#34
#34
r41065 hat gesagt.:
@ Bernd, damit hat sich für mich das Umstricken von Headwinds Sketch erledigt...
Zum Vergrößern anklicken....
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 :)
 
r41065

r41065

:)
#35
#35
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
 
Carbonator

Carbonator

Allerhopp ;)
#36
#36
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.

X4R_LQ.png

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

Whiskershort.png

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 :D) mehreren Kilometern Reichweite.
 
Zuletzt bearbeitet:
Sigimann

Sigimann

Erfahrener Benutzer
#38
#38
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
 
Carbonator

Carbonator

Allerhopp ;)
#39
#39
Status
Nicht offen für weitere Antworten.
FPV1

Banggood

Oben Unten