"Quicky mit Ingmar" #18... Telemetrie-Latenz die 2.

Hi,

die Abstände zwischen 2 Werten derselben ID sind dem System und wie man es umsetzt geschuldet.

Technisch sind im EX-Protokoll ungefähr 10 Pakete pro Sekunde möglich. Mehr wenn man nur 1 Wert überträgt - ist aber uneffizient. 1 Paket kann max 10 Werte enthalten mit 6 Bit. Oder 4 Werte mit 30 Bit. Und alles dazwischen.

Die Lib von Bernd nutzt das Mögliche nicht vollständig aus.Priorisierung ist nicht vorgesehen.

Das Jeti Studio mischt dann auch noch mit. Es würde die Diskussion um die Telemetrie vereinfachen wenn man die Logfiles betrachtet wie Lukas das gemacht hat.

Gruß

Jetzt habe ich auch noch den Log von WalterL aus dem Quicky #17 Thread ausgewertet: www.jetiforum.de/index.php/4-jeti-sender...atenz?start=0#121235

Dieser Beitrag hat ja den Stein ins Rollen gebracht und wahrscheinlich zum Quicky #18 geführt.

Hier die Ergebnisse der Auswertung:
Updateintervall RX1 (U, A1, A2, Q): Median 569 ms, Max 625 ms
Updateintervall RX2 (U, A1, A2, Q): Median 569 ms, Max 625 ms
Updateintervall CB220: Median 127 ms, Max 255 ms
Updateintervall Powerbox Spark Switch Pro: Median 912 ms, Max 2213 ms

Dieses Ergebnis ist sehr interessant. Die CB220-Werte werden im Schnitt alle 127 ms geupdatet und auch im schlechtesten Falle immer noch alle 255 ms und dies bei Realbedingungen im Flug. Diese Werte werden ja über den Ex-Bus an die Empfänger gesendet. Bei richtiger implementierung des Ex-Bus scheint es also keinen Knoten mit lückenhaften Werten zu geben und es kann Telemetrie quasi in Echtzeit umgesetzt werden.
Beim Powerbox Spark Switch Pro sieht es nicht so gut aus. Hier gibt es Lücken > 2 Sekunden.
Die Umsetzung des Jeti-Protokolls im Sensor scheint also erheblichen Einfluss auf die Telemetrielücken zu haben.

Gruss Lukas

gecko_749 wrote:

IG-Modellbau wrote: ....
Das Ex-Trelemetrie-Protokoll ist von Jeti zu 100% offengelegt.

Ingmar

Hi,

das stimmt nicht. Die Jeti-Sensoren übertragen die Werte encryptet. Dies ist nicht von Jeti offengelegt, aber bekannt

Die Aussetzer in Deinem Log kommen nach meinen Erfahrungen von dem Sensor der fehlerhaft ist.

Wenn Du lua-Scripte laufen hast beeinflusst das die Aufzeichnung im Log geauso auch wie eine langsame SD-Karte.

Ist dein Sensor veröffentlicht ?

Gruß

Hallo zusammen,

also encryptet liegt sicherlich im Auge des Betrachters, ich würde das aber so nicht behaupten.

Bei Jeti EX gibt es halt einige, ich möchte einmal sagen "Fallstricke"!!

1. Ein propritäres UART Format mit 9 Datenbits und einem ODD Parity Bit
2. Der Punkt "Little Endian"
3. 9600.bis 9800 Baud

Diese Punkte sind in der Protokollbeschreibung dokumentiert. In der Dokumentation ist auch eine 3rd Party "Manufacturer ID" (Nummerkreis) für den HEX Bereich 0xA400 bis 0xA41F definiert. Damit ist ein 3rd Party Sensor kenntlich.


Viele Grüße aus Schöneck
Dirk
CB Elektronics

Hallo Lukas,
ist das Format der Logfiles irgendwo dokumentiert, oder hast Du Dir das selbst erarbeitet?
Dann deutet sich ja unter Umständen an, dass das Lückenproblem gar kein Übertragungsproblem ist, sondern erst im JetiStudio zu einem wird.
Sprich es ist evtl. ein Fehler in der Auswertung im Jeti-Studio.

Um das zu verifizieren, müsste man ein Auswerteprogramm selber erstellen und mit der Auswertung vom Studio vergleichen.

Ingmar

Das Logdateiformat ist ziemlich einfach zu lesen. Erst werden immer Blöcke mit bis 5 Telemetriewerte pro Zeile geschrieben. Am Anfang der Zeile steht der Timestamp in Millisekunden. Dann kommt die ID des Sensors. Eine Zeile beinhaltet immer nur Werte welche vom gleichen Sensor kommen. Dann folgen die eigentlichen Datenblöcke bestehend aus je vier Werten. Der erste Wert eines Blocks ist der Index des Telemetriewerts des Sensors und der letzte Wert ist der eigentliche Telemetriewert.
Am Anfang des Logfiles ist immer eine Legende der Sensoren wo man die ID und Zuordnung Index zu Telemetriewert rauslesen kann.

Gruss Lukas

Ich denke dass das Lückenproblem aus mehren Komponenten besteht.
Zum eine ist da das Jetistudio welches aus unerfindlichen Gründen Lücken länger macht als sie tatsächlich da sind.
Zum zweiten scheint die Umsetzung des Protokolls im Sensor erheblichen Einfluss zu haben. Zumindest der Ex-Bus ist in der Lage relativ schnell und viele Daten zu übertragen, zumindest wenn die Anzahl Sensorwerte ein kritisches Mass nicht überschreitet und der Empfänger in der Lage ist die Datenmenge zu verarbeiten und zu senden.
Einen Aspekt der bisher eher vernachlässigt wurde, da nicht ganz einfach testbar ist die Auswirkung schlechter Funkbedingungen. Wenn bei einem Sensor wie der Powerbox Spark Switch Pro der nur jede Sekunde einmal sendet zwei drei Pakete verloren gehen hat man schnell Lücken von mehreren Sekunden.
Da hilft nur den Sensor so zu programmieren, dass er öfter sendet.

Die Ex-Telemetrie-Lib von Bernd sendet meines Wissen ca. alle 150ms. Ich versuche mal rauszufinden ob man das Timing noch ein wenig beschleunigen kann.
Interessant wäre wenn jemand Logs von einem MVario2 hier reinstellt, dieses soll nämlich ziemlich schnell updaten. Auch Logs mit einem Unisens oder MGPS mit vielen Daten wären interessant.

Gruss Lukas