Latenz der Übertragung messen

[Leo1962]

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

wahrscheinlich nur im Kopf der Theoretiker sonst brauchen wir noch Beschleuniger für die Finger damit sei die zeit auch schaffen. Und unser verflixt lange Reaktionszeit müssen wer dann auch noch irgend wie in den Bericht der Latenz zeit in den griff bekommen.

Hmmm Fazit: Bevor die Frsky Verbessert werden muss müssen wir die Piloten operativ optimiert an die Steuerung anpassen damit sei das auch schaffen mit der Geschwindigkeit .
Fieleicht hilft es dann Modelle Steuern direkt über das Hirn. Interessant daran du erckenst dann jeden Modepiloten an den Daten steck Buchsen am Schädel.

 

[Carbonator]

Alles richtig, aber in diesem Thread geht es um das Messen der Latenz.

Ich hatte gehofft, dass man den Frames ansieht, dass sich der inhalt geändert hat, aber nada. Ich wiederhole die Messung, aber diesmal wechseln alle 8 bzw. 16 Kanäle von -100 auf +100 - das sollte man sehen.

 

[Carbonator]

So, einen Schritt weiter. Ich logge jetzt ganz oldfashioned noch einen PWM Kanal mit, das gaht ja mit dem G-RX8 auch im 9ms Highspeed-mode. Trotz Schalten aller 8 bzw. 16 Kanäle kann ich immer noch kein Muster in den Captures von PXX und SBus erkennen. Hat da jemand noch eine Idee?

 

[Bussard]

Das eigentliche Problem ist ja, daß das SBUS-Protokoll nicht in der Saleae-Software bekannt ist.
Vielleicht gibt es in den englischsprachigen Foren eine Info, daß dieses Protokoll implementiert wurde bzw. mit welchem Equipment man es "im Klartext" lesen kann. Das würde für die Software-Spezis auch eine große Hilfe sein, ich denke, da gibt es schon Lösungen, denn die testen auch nicht alles "per Hand".
Ansonsten muß sich jemand an die Fleißarbeit machen und das Protokoll für diesen "arme Leute 8Kanal Logikanalysator" schreiben. Dann hätten alle was von.

Viele Protokolle sind schon implementiert, und mit dem SDK kann man eigene kreieren.
Zitat: Most digital communication uses a particular protocol that specifies how information is transferred. The Logic software has protocol analyzers that can automatically decode SPI, I2C, serial, 1-Wire, CAN, UNI/O, I2S/PCM, MP Mode, Manchester, Modbus, DMX-512, Parallel, JTAG, LIN, Atmel SWI, MDIO, SWD, LCD HD44780, BiSS C, HDLC, HDMI CEC, PS/2, USB 1.1, Midi – or create your own with the SDK.


Gruß Bussard

 

[Carbonator]

Viele Protokolle sind schon implementiert, und mit dem SDK kann man eigene kreieren.

Wenn man es kann und den nötigen Fleiß mitbringt, 2 x nogo, sorry
Ich hab mal in RCG noch gefragt, vielleicht sind dort die erforderlichen Faulenzer unterwegs

Übrigens 22,5 - 32ms end to end, das ist nicht schlecht

 

[Bussard]

Wenn man es kann und den nötigen Fleiß mitbringt, 2 x nogo, sorry
Ich hab mal in RCG noch gefragt, vielleicht sind dort die erforderlichen Faulenzer unterwegs

Ich bin schon fast mit "hello world" überansprucht . Also auch nada.
Mach doch ne Ausschreibung für nightworker mit Pizza-Entlohnung, daaaaa könnte es was werden...

Gruß

 

[Carbonator]

SBus ist ja nicht das over the air Protokoll, das heißt, es wird erst im Empfänger "gebaut". Vermutlich kommen SBus und PWM deswegen gleichzeitig, dann bleibt nur noch das PXX Protokoll. Damit hätte man das Delay im Sender und die Differenz zum Gesamtdelay ergibt dann die HF-Strecke mit Kodierung und Dekodierung und Bildung der der Ausgangssignale im RX.

Leider ist PXX extrem verschachtelt, da werden die Bits und Bytes nur so ineinandergewurstelt, um "Platz zu sparen".

 

[Carbonator]

Mit Geduld war doch ein Muster zu finden, und zwar bei den Frameerrors im async decodierten Stream. Da kamen entweder immer 4, oder immer 3 nacheinander. Damit konnte ich dann die Latenz des Senders errechnen: Minimum 10ms, Maximum 19ms.

 

[Bussard]

Das ist ja dann wohl "über Alles". Hätte ich jetzt schlechter erwartet, [SUP]1[/SUP]/50 Sekunde ist echt nicht viel.

Gruß

 

[Carbonator]

Nicht ganz, das ist sozusagen nur unser OpenTX, vom User zum Sendemodul.
Insgesamt ist es dann 22,5 - 32ms vom User zur FC, bzw. zum Servo im 9ms HS mode, also 1/30s. Auch nicht schlecht.

 

[Bussard]

Ja, die FC oder die Kanalaufbereitung gehen bis zum Servo/ Motorsteuerung ja auch noch ganz unterschiedliche Wege. Dazu noch eventuell das Servo.
Ich weiß jetzt gar nicht, ob die Receiver mit PCM die Kanäle nacheinander bereitstellen oder parallel. Oder ob das auch wieder je nach Receiver und Modus verschieden ist.

Gruß Bussard

 

[Carbonator]

Mit Schrecken ist mir eingefallen, dass ich für crossfire und r9 doch das SBus Protokoll brauche. Mit diesen Einstellungen kriegt man es decodiert. Byte1 ist immer 0x0F, dann kommen 22 Byte mit 11Bit pro Kanal byteübergreifend. Aber im zweiten Byte steht schon meine gesuchte Info drin - alles easy....

 

[mastersurferde]

@Bussard: Die Bereitstellung der Receiver für die PCM Kanäle ist unterschiedlich - je nach Hersteller und Modell. Der Grund für unterschiedlich getimte Ausgänge liegt schlichtweg in der Belastung des BEC durch die Anlaufströme der Servos. Wichtig beim konventionellen Heli ist z.B. dass die 3 Taumelscheibenservos gleichzeitig angesteuert werden. Im Internet findet man für einige Empfänger die Timingdiagramme.

@Carbonator: Wir hatten das auch so ähnlich gemacht. Einfach nach dem Header den ersten echten Veränderten "Hügel" im Diagramm als Referenz genommen. Das reicht vollkommen.
Leider wissen wir halt gar nix über die Schnittstelle zwischen Taranis und XJT (oder zumindest ich nicht )

Gruß
Stefan

 

[Carbonator]

Leider wissen wir halt gar nix über die Schnittstelle zwischen Taranis und XJT (oder zumindest ich nicht )

Ist alles open source, aber in diesem Leben verstehe ich nicht mehr, was da passiert

 

[Bussard]

@Bussard: Die Bereitstellung der Receiver für die PCM Kanäle ist unterschiedlich - je nach Hersteller und Modell. Der Grund für unterschiedlich getimte Ausgänge liegt schlichtweg in der Belastung des BEC durch die Anlaufströme der Servos. Wichtig beim konventionellen Heli ist z.B. dass die 3 Taumelscheibenservos gleichzeitig angesteuert werden. Im Internet findet man für einige Empfänger die Timingdiagramme.

Ja ist klar, seriell rausgeschobene Pulse an den Servoausgängen sorgen dafür, daß nicht alle Servos gleichzeitig anlaufen und reduziert die Stromspitzen.
Aber genau das Gegenteil wird ja manchmal gebraucht, ich denke da an Großmodelle, wo am Höhenruder schon mal 2 bis 4 Servos absolut synchron laufen müssen (genauso Ruder, Klappen, ..), da ist die parallele Ausgabe der Servopulse zwingend. Es gibt Anlagen, da kann man genau das für jeden oder bestimmte Servokanäle programmieren/ einstellen.

Ist sicher auch über BUS-Servos (alle Servos eines Kanals erhalten das gleiche Signal) und die Weganpassung je programmierbarem Servo machbar, sicher eine Kostenfrage auf Modellbauer-Seite.

Bei beiden Varianten unterscheidet sich die Latenz sicher auch schon auf Empfängerseite, nur wieviel? Dazu gibt es kaum Angaben, und wenn, dann von Leuten, die es ermittelt haben, nicht vom Hersteller.

Würde mir wünschen, daß solche Verhaltensweisen neben zig weiteren Angaben in einer ausführlichen Empfängerbeschreibung von FrSky aufgeführt werde, welche meinethalben zusätzlich zum derzeitigen "Faltblatt" bereitgestellt werden.

Gruß

 

[Bussard]

ist alles open source, aber in diesem leben verstehe ich nicht mehr, was da passiert :d

ack .

 

[Leo1962]

Aber merkt man das im Flug ? da gibt es doch auch eine gewisse Trägheit die dazu beiträgt das die ms Verzögerung der servos gar nicht bemerkt wird.

Was aber mit Sicherheit bemerkt würde wen alte sevo die Strom Versorgung jedes mal an den Anschlag bringt und es zum abrauchen Bringt OK man kann dass mit immer grösser werdenden Netzteilen abfangen und mit immer dicker werdenden kabeln die spitzen Belastungen würden aber Trotzdem Bleiben. ich stelle mir das dann so fohr mit den takten wie ein Hemerschlag der ständig drauf haut irgend wann Bricht das teil und wen es dann gleich mehrere Servos miteinander Trifft oder das Neztteil????

 

[Carbonator]

Aber merkt man das im Flug ?

Sobald eine Mechanik im Spiel ist, definitiv nicht. Bussard hat ja schon mal im Spaß 500ms Delay für die Segelflieger genannt und wenn man ehrlich ist, bis sich die Mühle im Thermikflug mal bequemt, eine Fluglagenänderung anzudeuten, dauert schon einige Zeit

Aber die ADHSler im FPV-Racing könnten möglicherweise einen Unterschied bemerken, da bin ich nicht sicher. Die Regler und Motoren reagieren extrem schnell und das Leistungsgewicht ist auch extrem.

Ganz sicher ist das ein wichtiges Thema am Stammtisch, wenn die Jungs mit den 5mm Ruderspiel über Crossfire Latenz schwadronieren

 

[helle]

Hy,

Mike Blandfort hat da mal was ganz genau ermittlen und Testsoftware geschrieben für
die Übertragung openTx ans interne XJT-Sendemodul

Synchronisation mit Heartbeat und Timming mit Zeitfenster ca 6,5ms vor frame send

Mit seinen Testanpassungen für 8 Kanal kommt er damit auf Latenzzeiten 9ms-16ms
Das wird wohl auch mal in openTx übernommern werden,
ist noch in der Entwicklung und Testphase


Siehe rcgroups

 

[Carbonator]

Da die Damen heute abgelenkt waren, habe ich mal das R9 System gemessen. Durch die 7ms SBus Framerate ergeben sich 2ms Vorteil gegenüber 2.4GHz. Mit 8 Kanälen lag ich zwischen 20 und 26ms, mit 16 Kanälen zwischen 20 und knapp 34ms.

Da sehe ich kaum noch Verbesserungspotential auf FrSky Seite, da ist jetzt OpenTX am Zug, sie haben ja schon 4ms PXX-Update in der Pipeline, wenn ich das richtig verstehe.



Messung wieder von Gimbal bis zum vollständig übertragenen SBus Frame, PXX habe ich mir geschenkt, dafür SPort vom Sender noch gelogt. Falls jemand Interesse hat, reinzuschauen, lade ich die Dateien hoch.