Latenz der Übertragung messen

Status
Nicht offen für weitere Antworten.
#1
Das ist zwar eher ein Thema für das Winterhalbjahr, aber man kann ja schon mal vorplanen ;)

Die unreife Idee ist:

Mit einem Arduino ein Signal erzeugen und dieses auf ein Gimbalpoti aufschalten. So wird der Kanalwert schlagartig verändert. Dieses Signal und gleichzeitig das Empfänger SBus Signal capturen. Im SBus Capture sieht man, sobald eine Änderung auftritt, sogar ohne das Signal im Detail auswerten zu müssen, so glaube ich das zumindest mal gesehen zu haben bei meinen Messungen. Dann müsste man "zu Fuß" eine ausreichende Zahl von Vorgängen auswerten, um Min, Max und Durchschnitt zu ermitteln.

Schöner wäre eine automatische Auswertung, aber dazu ist mir noch nix eingefallen, ohne dass zusätzliche Latenz ins Spiel kommt.

Crossfire wird ja zur Zeit latenzmäßig massiv gehyped, ohne dass tatsächlich irgendwo Zahlen bekannt sind. Da würde ich gern mal genauer hinsehen.

Oder hat jemand einen sinnvolleren Ansatz?
 

mastersurferde

Erfahrener Benutzer
#2
Nabend Carbonator,

wir haben das schon mal getestet. Allerdings ohne Aruduino, sondern einfach mit einem der Schalter der Taranis - hat den selben Effekt :D
Den Schalter und das Ausgangssignal vom Empfänger dann auf ein Speicheroszi oder einen Logic-Alalyzer und gut.

Zu den Ergebnissen:
SBUS von FrSky hat 16 Kanäle und 100 Herz.
SBUS vom Crossfire hat 12 Kanäle und 150 Herz.

Die erste SBUS Sequenz nach der Schalterbetätigung hat keinesfalls die Schalterbetätigung gezeigt.
Die zweite SBUS Sequenz nach der Schalterbetätigung hat je nach Vorlaufzeit der Schalterbetätigung das Signal übertragen
Die dritte SBUS Sequenz nach der Schalterbetätigung hat das Signal auf jeden Fall übertragen.

Das sowohl bei FrSky wie auch bei Crossfire. Durch die 150 Herz hat das Crossfire also schon mal 6,7ms Vorsprung. Dadurch, dass das Crossfire nur 12 Kanäle überträgt, ist die SBUS Sequenz noch einen Hauch kürzer als bei FrSky. Wegen der Checksummenberechnung muss das Ende der SBUS Sequenz abgewartet werden.

Die Hauptverzögerung findet also innerhalb der Taranis schon statt. Das ist der Softwarebug, von dem man immer mal wieder lesen kann und deswegen sind die FlySky Funken hier klar im Vorteil - bei denen scheint das zu funktionieren (hab ich selber aber nicht nachgemessen).

Gruß
Stefan
 
#3
Moin Stefan,

das ist ja schon mal eine Ansage. Ich dachte auch erst an einen Schalter, was wirklich einfacher ist, aber ich bin nicht sicher, ob die Gimbals und die Schalter mit derselben Priorität abgefragt werden. Eventuell werden die Schalter noch per Software entprellt. Deswegen die Idee, das Potisignal zu manipulieren.

Dass Flysky die geringste Latenz hat, habe ich auch schon gehört. Das soll systembedingt sein. Dort ist nur ein Prozessor für die Kontrollebene und HF-Aufbereitung zuständig. Bei FrSky gibt es zwei Prozessoren im Sender, einen auf dem Mainboard für die Kontrollebene und einen im HF-Modul. Die zusätzliche Latenz kommt durch das zusätzliche Interface. Ein Softwarebug ist das vermutlich nicht.

Beim Einsatz eines Crossfire Moduls hat man aber auch den Nachteil der zwei Prozessoren. Das Crossfire kann nie so schnell sein, wie das Flysky System. Aber schneller wie FrSky. Das OpenTX Interface zu Crossfire läuft z.B. mit 400kB, zumindest bei den 9er Taranis. PXX zu XJT oder R9m mit 115kB, soweit ich weiß.

Aber es kann sein, dass die SBus "Paketierung" am Ende der entscheidende Faktor ist, wie du vermutest. Und dass alles andere kaum eine Rolle spielt.
 

helle

Erfahrener Benutzer
#4
Hy,

bei der X-Lite wurde die Latenz wieder verbessert, halbiert, wie erste Messungen ergeben.

Denke da wird es dann für die XJT und IXJT auch bald updates geben


Anstatt Schalter, die verzögert und gefiltert wird,
einen Anlogwert umschalten /0V, 3,3V) und auf einen Anlaogeingang draufschalten,
per Taktgenerator und oszi damit triggern.
 
Zuletzt bearbeitet:

mastersurferde

Erfahrener Benutzer
#8
Nabend,

Die Ergebnisse von Mike Blandford sind für uns aber nicht wirklich relevant, da er eine Ersky9x verwendet hat. Hierzu wissen wir nicht, ob das Taranis-Protokoll zum XJT das selbe ist, wie bei der ersky und welche systembedingten Verzögerungen relevant sind.

Eigentlich müssten wir erst einmal die Latenz von den Knüppeln bis zum Modulschacht der Taranis messen. Ich denke, dass hier momentan der Löwenanteil der Latenz liegt. Ob dann ein XJT, ein Crossfire oder ein R9 als Funkschnittstelle und Empfänger dranhängt, ist wahrscheinlich momentan zweitrangig. Deswegen glaube ich auch nicht an die Notwendigkeit von Updates für XJT und IXJT.

Der nächste Winter kommt bestimmt....

Gruß
Stefan
 
#9
Eigentlich müssten wir erst einmal die Latenz von den Knüppeln bis zum Modulschacht der Taranis messen. Ich denke, dass hier momentan der Löwenanteil der Latenz liegt.
PXX kann man ja parallel zusätzlich capturen, dann sieht man genau, wo welche Latenz entsteht.

Die Ergebnisse von Mike Blandford sind für uns aber nicht wirklich relevant, da er eine Ersky9x verwendet hat. Hierzu wissen wir nicht, ob das Taranis-Protokoll zum XJT das selbe ist, wie bei der ersky und welche systembedingten Verzögerungen relevant sind.
Es ist dieselbe Hardware, nur nutzt Mike B. sein eigenes Betriebssystem, für das er bei dieser Gelegenheit gleich noch ein bißchen Reklame macht, aber das ist legitim. Hardwarenah machen ihm nur wenige etwas vor, glaube ich. Ob die Synchronisation PXX <-> XJT aber viel bringt? Besser wäre es sicher, User und XJT zu synchronisieren :D.

Der nächste Winter kommt bestimmt....
Die Nachttemperaturen werden diese Woche einstellig ..... :D
 

Norbert

Erfahrener Benutzer
#10
Besser wäre es sicher, User und XJT zu synchronisieren :D.
Da ist viel dran, wenn ich an die Reaktion einzelner auf unvorhergesehene Zwischenfälle erinnere. ;-)~

Nach meiner Erfahrung im RC 1:8 Modellracing, wo man Spitzkehren aus Höchstgeschwindigkeit > 100km/h auf 20cm treffen muss, ist die Konstanz der Latenence wesentlich wichtiger. Auf feste Verzögerungen kann man sich einstellen, auch wechselnde nicht.

Ich war bei RC-Car sehr sensibel - bei RC - Mdellflug - außer bei sehr kleinen unstabilisierten Helis - hatte ich mit 5msec Latenence hin- oder her keine Probleme.

Aber vielleicht übersehe ich da was. Wo wirkt sich die Latenence im FrSky typischen Bereich bei Modellflug aus?

Norbert
 
#11
.... ist die Konstanz der Latenence wesentlich wichtiger. Auf feste Verzögerungen kann man sich einstellen, auf wechselnde nicht.
Sehr guter Einwand! Das haben die Latenzjammerer bis jetzt noch nie thematisiert. Ein weiteres Indiz, dass das nur ein Hype ist.

Ich bin ziemlich sicher, dass man 5ms absolut nie bemerken kann (relativ schon eher), aber nicht 100%. Hochspezialisierte Menschen schaffen gelegentlich unglaubliche Leistungen, da bin ich vorsichtig geworden. Mein Sohn ist bei den Racecoptern aktiv und da kriege ich manches mit, auch zum Thema Latenz. Deswegen und auch um das System besser zu verstehen, will ich Zahlen sehen.

Eine Leistungssteigerung beim Segelfliegen nehme ich aber gerne mit :D :D
 

fa223

Erfahrener Benutzer
#12
...Eine Leistungssteigerung beim Segelfliegen nehme ich aber gerne mit :D :D
Leistungssteigerung beim Segelflug durch die Verringerung der Übertragungs-Latenz?? :p
Bohhhh, ich wusste ja bisher schon, dass ich mich am absolut unterstem Modellflug-Level bewege. :eek:

Früher bei den 35MHz-Anlagen konnte man bei einer "elektronischen" Mischung der Taumelscheibe (im Sender) am Heli schon erkennen, dass diese nicht exakt hochgefahren ist. Da gabs dann ja mal extra Bausteine, die die Mischung im Modell übernommen haben.... aber das ist alles lange Geschichte.
Aktuell würde ich sagen ist nicht mal die Schnittstelle User>XJT das Problem, sondern die Datenverabeitung vor der Schnittstelle.
;)
 
#13
Leistungssteigerung beim Segelflug durch die Verringerung der Übertragungs-Latenz?? :p
Bohhhh, ich wusste ja bisher schon, dass ich mich am absolut unterstem Modellflug-Level bewege. :eek:
Du hast die Ironie erkannt. Aber ich denke, dass wir in den Modellbauforen, dem Elefantenfriedhof der Modellbauer sozusagen, wenn wir schon reflexetechnisch nicht mehr mithalten können, immerhin mit unserer Erfahrung den technischen Background liefern können ;)

Aber ich brauch jetzt mal Support, Bussard wo bist du? GND und Schleifer und PXX habe ich nach außen gelegt. Am Schleifer messe ich

Stick hinten -> 2,46V und 790Ω gegen GND
Stick vorn -> 0,32V und 380Ω gegen GND

Ich würde gerne mit dem Ardu über einen Spannungsteiler, wenn der Stick vorne ist, die Spannung erhöhen. Den Ardu GND würde ich mit Poti GND und die Anzapfung des 1:1 Spannungsteilers (2x1k) mit Schleifer Poti verbinden. Der Potiwiderstand zieht mir dann die 2,5V zwar weiter runter, aber ich sollte einen gut auswertbaren Unterschied sehen. Und egal, welche Verbindung "bricht", meine Taranis wird nicht abrauchen.

Korrekt, oder mache ich einen Denkfehler?
 

Bussard

Erfahrener Benutzer
#14
Aber ich brauch jetzt mal Support, Bussard wo bist du? GND und Schleifer und PXX habe ich nach außen gelegt.
Rabota, Rabota, oder aus Deinem Sprachraum, schaffe, schaffe? ;)

Ich weiß nicht, ob ich helfen kann, ich kenne ja nicht mal die Abkürzung/ Signal PXX.
Welchen Eingangsspannungsbereich möchtest Du denn am Arduino-Eingang erhalten? Vergrößern (spreizen) kann man den Spannungshub nicht durch passive Maßnahmen, dazu braucht man irgendeinen Verstärker. Aber mir fehlt wohl noch der Durchblick, was Du genau an Signalen/ Eingangsgrößen hast und was draus werden soll - siehe PXX.
Klär mich bitte auf.

Gruß Bussard
 
#15
PXX ist das serielle Signal, das das XJT Modul ansteuert. Das will ich zusammen mit dem Empfänger SBus Signal und der Ansteuerung durch den Ardu capturen. Der Ardu liefert alle 100ms high, dann 100ms nix. Mit dem Signal will ich über den Spannungsteiler (bin jetzt gedanklich bei 2x560Ω) das herausgeführte Poti übersteuern. Das Poti bleibt parallel angeschlossen.

Meiner Ur-Taranis darf nix passieren, deswegen brauch ich jemand zum Händchenhalten ;)
 

mastersurferde

Erfahrener Benutzer
#16
ich versteh nur nicht, für was Du da einen Ardu brauchst. Ein Schalter, der über einen Spannungsteiler das Poti überbrückt (ersetzt) ist völlig ausreichend.
Du brauchst eh nach jeder Einzelmessung etwas Zeit, die Signale auszuwerten. Eine Quasi-Dauermessung mit der Taktung 100ms ist völlig sinnfrei bei den zu erwartenden stark unterschiedlichen Latenzzeiten.
 
#17
ich versteh nur nicht, für was Du da einen Ardu brauchst. Ein Schalter, der über einen Spannungsteiler das Poti überbrückt (ersetzt) ist völlig ausreichend.
Du brauchst eh nach jeder Einzelmessung etwas Zeit, die Signale auszuwerten. Eine Quasi-Dauermessung mit der Taktung 100ms ist völlig sinnfrei bei den zu erwartenden stark unterschiedlichen Latenzzeiten.
Ich dachte, ich lass die Messung 60s laufen, hab dann 600 Ereignisse zum Offlineauswerten und sehe durch das unterschiedliche Timing Ardu/Frames dann sogar ganz gut, wo/wann die Information auf den nächsten Frame umspringt. Zumindest in der Theorie.

Wenn von Bussard kein ogottogott mehr kommt, dann probier ich es heute abend so aus.
 
Zuletzt bearbeitet:

Bussard

Erfahrener Benutzer
#19
Der Ardu soll also nur eine "knackige" Potibetätigung simulieren.
Reicht es da nicht, wenn der Potischleifer über einen Angstwiderstand gegen GND geschaltet wird? Du willst die Änderung des Signals doch nur im Ausgangssignal feststellen.

Impulsverfaelschung.jpg

Dazu nur den Schleifer auftrennen und hinter dem Angst-R kurzschließen.
Das Poti hat eventuell 1 oder 2 Widerstände zur Bereichsbegrenzung, kenne die Schaltung nicht und ist auch egal.


Gruß


p.s. Jetzt erst den Link drüber gesehen, bloß gut, daß bei mir meist 500ms reichen :eek:
 
Zuletzt bearbeitet:
#20
Deine Schaltung macht wesentlich weniger Bauchschmerzen wie meine. Ich werde auf diese Lösung umbauen.

Aber jetzt muss das erstmal mit der Fremdspannung laufen - und es läuft :D
Hat mir doch keine Ruhe gelassen. Falls jemand draufschauen will, anbei die Captures von eben. Morgen werde ich das R9M mal dranhängen. Jetzt muss ich erst noch Gartenarbeit simulieren, damit ich was zum Abendessen bekomme ;)

Anhang anzeigen 8_16Kanal_XJT.zip
 
Status
Nicht offen für weitere Antworten.
FPV1

Banggood

Oben Unten