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

Hallo Igmar,

dass wäre aber nicht schön, wenn Lücken durch das Jeti Studio entstehen würden....; aber Du bist ja mit Jeti in KOntakt und mal schauen, was da rauskommt.


Gruss
PW

IG-Modellbau wrote: Hallo Peter,
ich glaube die nächsten Quicky's sind gesichert....
Der ExBus ist zwar von der Datenrate deutlich schneller, hat aber auch mehr Overhead.
Die Kommunikation zwischen Sensor und RX ist mit absoluter Sicherheit erheblich schneller als die Übertragung zum Sender....

Wie kommst du darauf ? Die Daten die der RX bekommt schickt er nach unten. Ob der RX die Daten der Sensoren anschaut weiß nur Jeti. Der TX prüft sie mit Sicherheit und verwirft fehlerhafte Daten.

Deine Lücken imExcel sind sicher auf das Jetistudio zurückzuführen, das hat Lukas doch gezeigt. Keine Ahnung was das Jetistudio mit ungültigen Daten meint. Der TX hat sie geprüft und dann ins Log geschrieben, also könnten ungültige Daten nur durch Schreibfehler entstehen. Die habe ich noch nicht gefunden.Wenn der TX nicht zum schreiben kommt wirft er die Daten weg. Das passiert bei vielen Daten und langsamen Karten.

Gruß

gecko_749 wrote: Der TX hat sie geprüft und dann ins Log geschrieben, also könnten ungültige Daten nur durch Schreibfehler entstehen. Die habe ich noch nicht gefunden.Wenn der TX nicht zum schreiben kommt wirft er die Daten weg. Das passiert bei vielen Daten und langsamen Karten.

Bei Schreibfehlern auf der SD-Karte müsste aber auch beim Import des Logs direkt in Excel komisches auftreten. Zudem waren in Ingmars Video die Verzögerungen auch auf der Telemetrieanzeige des Senders deutlich zu sehen. Dies sollte vom Schreiben auf die SD-Karte unabhängig sein. Was Jeti Studio mit den Log-Daten macht ist mir absolut schleierhaft, auf jeden Fall kann man das besser umsetzen.

Ich glaube der Flaschenhals ist die Kombination Sensor - Implementierung Protokoll - Empfänger. Ich kann mir gut vorstellen dass ein schlecht programmierter Sensor den Empfänger telemetriemässig aus dem Takt bringt. Alte R-Empfänger sind dann wahrscheinlich auch anfälliger als neuere REX-Empfänger. Auch zwischen Ex-Telemetrie und EX-Bus wird es sicher Unterschiede geben.

Bernd (Sepp62) hat ja neben der JetiExSensor-Lib auch eine JetiExBus-Lib veröffentlicht: github.com/Sepp62
So könnte man die zwei Protokolle mit der gleichen Hardware direkt vergleichen. Bisher habe ich nur mit JetiExSensor-Lib gearbeitet. Ich glaube ich muss mich mal in die JetiExBus-Lib reinfuchsen.

Gruss Lukas

Hi Lukas,

mit dem JetiStudio gebe ich dir insofern Recht das bei der Tabelle bzw.dem Excel-Export komische Sachen passieren.

Ich glaube nicht das ein Sensor den RX aus dem Tritt bringt - das wäre eine Katastrophe. Hab ich auch noch nicht geschafft

Vielmehr ist es bei EX so das der RX die Daten die er bekommt weiter reicht. Die gemütlichen 9600 Baud machen da keine Probleme.

Beim EXBus fragt der RX den Sensor nach Daten. Wenn er wegen anderen Dingen beschäftigt ist fragt er halt nicht. Ist ein Paket zu lang wird es wahrscheinlich abgeschnitten und dann vom Sender mit CRC-Fehler verworfen. Ist es zu spät ebenso.

Im TX passieren dann viiele Dinge - updates der Telemetrieanzeigen haben da sicherlich eine niedrige Priorität. Ein lua Script beeinflußt zum Beispiel wieviele Daten auf die SD-Karte geschrieben werden - wenn man viele Daten schickt. Bei einem EX-Sensor fällt das nicht auf.

Gruß

@FunCapi:
Vielen Dank für deine Analyse meiner Logfiles.

M.f.G.
STer

Warum ist es so schwer, von Jeti eine Erklärung dafür zu erhalten, warum im Jetistudio immer wieder Daten als ungültig erkannt werden?
Welches Kriterium wird dafür verwendet?
Es kann doch nicht sein , das die das nicht wissen.
Gruß Volker