Descriptions:
Quicky #19… Telemetrie-Latenz Teil-3
Beschreibung zum Video:
Lücken in der Telemetrie?
Oder doch nicht?
Wie lang ist die Zeit bis ein Telemetriewert vom Empfänger am Sender ankommt, dass zeige ich in diesem Video, nun aber mit vielen Telemetriewerten.
IG-Development (
IG-Modellbau (
Gemafreier Soundtrack von Frametraxx
Subscribe on Youtube: Ingmar Grote, click here
Freitag – Newsletter zu allen aktuellen Videos der Woche aus 17 Channels, jetzt anmelden!
Vollständiger Text aus dem Video: Quicky #19… Telemetrie-Latenz Teil-3
Hinweis: Text aus der automatischen Spracherkennung aus dem Video ist allgemein bekannt ungenau!
servus freunde und herzlich willkommen zu einem weiteren quickie mit immer wie ihr in den letzten zwei quickies ja gesehen habt gab es daher diskrepanzen bei der jede telemetry übertragung dachten wir zumindest oder ich da sah das so aus ich habe das hier gerade noch mal offen das ist am eine excel tabelle vom letzten mal mit den 24 telemetrie werten die mine sensor übermittelt hat und da gab es riesige lücken da oben sind noch werte lücke dann kommen erst wieder werde das waren richtig große lücken so 2 bis 4 6 sekunden lange lücken das hat mich doch etwas enttäuscht das kann doch nicht angehen dass es in unserer yeti telemetrie übertragung solche großen datenlücken gibt wo einfach nichts drin steht um es kurz vorweg zu nehmen die lücken sind auch gar nicht da ja die jetzt da sind sie doch ja man sieht sie aber sie sind nicht da erklärung folgt auf dem fuße das ganze ist ein missverständnis oder eine missinterpretation dazu gehen wir mal in das jedes studio disney studio hat ja diese daten erzeugt also ich habe hier meinen test sensor mit 24 telemetrie werden ich nehme mir mal so und ich habe eine datentabelle offen in der datentabelle habe ich hier diesen haken weil nur gültige daten anzeigen damals rein gemacht und auch genau dieser haken ist es der für diese lücken verantwortlich ist klingt bescheuert ist es aber nicht es ist eine missinterpretation ich habe diesen haken nur gültige daten anzeigen so interpretiert dass wenn ich den haken reinmachen ich tatsächlich nur die telemetrie daten angezeigt bekommen die auch vom empfänger an den sender gesendet wurden also nicht irgendwelche künstlich dazu gedachten konstruierten wie auch immer daten deswegen habe ich diesen haken da immer rein gemacht ich nehme an das ging den meisten so die damit ein bisschen intensiver rum gespielt haben die haben auch gesagt okay wenn ich den haken daran mache dann sehe ich tatsächlich nur die echten telemetriedaten und das ist genau falsch was dieser haken macht erklärt gleich ich will bloß erst mal zeigen wie er funktioniert wir machen ihn erst einmal raus also das ist die grundeinstellung so kommt das yeti studio wenn man es auf macht der haken ist übrigens jedes mal wieder weg wenn man eine neue datentabelle anlegt also grundeinstellung ohne haken ich ziehe mir mal testweise zwei daten rüber oder drei meinetwegen daten vom sensor 1 da machen wir mal vom sensor 16 das entspricht immerhin einem testprogramm und daten vom sensor 24 so dann haben wir hier die echten daten also die telemetriedaten und hier vorne den jeweiligen zeit stempeln ich jetzt hier runter rolle dann sehen wir das war der daten wehrt sich ändert das war auch so gedacht weil mein sensor erzeugt eben je nach druck entweder den sensor wert mit 1000 höher oder eben den sensor wert ohne die 1000 von lücken keine spur soll jetzt gehen vorüber in einstellungen und machen wir unser haken kann weil ich will ja nur daten sehen die auch wirklich physikalisch übertragen worden sind so mein jetzt wissen da weise falscher gedankengang ich gucke wieder bei daten fangen wir ganz oben an scrollen ein bisschen runter alles gut eine lücke nanu so ähnlich aus wie auf meinem excel sheet nein es sieht sogar ganz genau so aus weil die daten wurden ja von dieser datentabelle in excel exportiert das heißt dieser haken erzeugt uns die lücken haken wieder raus alles wieder gut stellt sich natürlich die frage ist diese annahme dass der haken tatsächlich nur echte daten anzeigt richtig dann heißt es ja es müssten die lücken im logfile drin sein ist die annahme dass er nur echte daten anzeigt falsch wie ich mittlerweile weiß ist sie falsch dann müssten die daten ich mache den nochmal rein sicherheit sei aber dann müssten da wo hier jetzt lücken angezeigt werden richtig lange locken teilweise etwas über vier sekunden eigentlich daten seien und dass rauszukriegen habe ich ein kleines programm geschrieben ich mach das mal auf das ist dieses programm das liest direkt die logfiles aus da ist also kein yeti studio dazwischen sondern ich nehme mir hier tatsächlich das reine pure logfile und lese die daten aus je nachdem wie viele daten in dem loch fall drin sind in der ersten spalte stehen immer die ersten sensorwerte entspricht also hier unsere datentabelle erster wert in jetzt verhalten spalte lese ich die daten werte vom sensor wert 16 aus in der dritten vom sensor wird 24 und hier hinten vom sensor wert 32 denn ich hatte ja damals und die gleichen daten verwende ich jetzt das also keine neuaufnahmen sondern ich nehme tatsächlich die gleichen logfiles so dass ich hier vorne immer den sensor wert 1 da 16 24 132 habe also öffnen wir doch einfach mal das log file was wir hier auch verwendet haben im genick studio das mit den 24 daten das ist das da das programm liest jetzt alles ein was in dem logfile drin steht zur erklärung was wir hier sehen in der im vordersten bereich jeder spalte ist der aktuelle zeitstempel so wie er im logfile rind steht die zweite spalte gekennzeichnet mit offset ist jeweils die zeit die vergangen ist von einem zeitstempel zum nächsten zeit stellen will aufgeschrieben wird hier nur dann etwas in diese spalte wenn tatsächlich der sensor wert 1 im logfile vorkommt hier wenn der wert 16 also der sensor wert 16 vorkommt wird hier was rein geschrieben und so weiter zum schluss habe ich diese offset werte ausgewertet hier gibt es ein offset min und ein offset max die zahl repräsentiert in sekunden 0,7 19 sekunden heißt also dass der die zeit von einem eintrag eines sensorwerte zum nächsten eintrag des sensorwerte science minimal 07 19 sekunden gebraucht hat maximal hat die zeit von einem sensor wert 1 zum zweiten sensor wert 1 1,5 24 sekunden gebraucht das gleiche habe ich gemacht für eben den sensor et 16 und hier für den sensor wert 24 was wir sehen die zeiten sind teilweise identisch teilweise ganz nah aneinander es ist also definitiv schon mal so dass kein sensor wert bevorzugt wird alle vom empfänger zum sender gesendeten sensorwerte haben die gleiche priorität das mag sinnvoll sein das mag in manchen fällen aber auch nicht sinnvoll sein aber das ist nicht gegenstand von diesen quickie wichtig ist wir haben hier einen wert mindest einem minimum zeitverzug bis der nächste wert kam und einen maximalen zeitverzug aber es sind eben keine lücken drin wenn der rücken von vier sekunden wären dann wäre genau diese offset max wert hier unten deutlich höher der wäre dann nämlich bei vier oder sechs oder ich weiß nicht bei 32 werden waren sogar teilweise acht sekunden lücken sind hier nicht zu sehen also die lücken sind definitiv in den logfiles nicht drin so dann habe ich natürlich bei jedem nachgefragt was ist denn das mit dem haken also mit diesem haken was macht denn der haken der haken also wenn man ihn einsetzt läuft dort drin eine logik ab die die daten hier bewertet und das tut sie dann in einer art und weise die sich mir noch nicht ganz erschließt wenn also eine zeit vergeht von einem sensor wert zum nächsten sensor wert der größer ist als 1,5 sekunden und wie man sieht bei den 24 lok fall kommt das vor dass der größer ist als 1,5 sekunden nämlich 1,5 24 sekunden dann wird dieser daten wert als ungültig eingestuft also der haken nimmt uns daten raus aus dem logfile die sich zu lange nicht geändert haben oder zu lange nicht vom empfänger an den sender übertragen wurden sei es weil die daten aufgrund einer großen flugentfernung fehlerhaft übertragen wurden und deswegen erst einmal im empfänger schon verworfen wurden also einfach weil die zeit von einem sensor einer übertragung eines sensorwerte es zu einer zur nächsten übertragung des selben sensorwerte es über 1,5 sekunden beträgt dann filtert dieser haken diese daten raus wenn man also wirklich alle daten so sehen will wie sie tatsächlich im logfile sind muss dieser haken raus der macht also genau das gegenteil von dem was ich angenommen habe er entfernt daten die er für ungültig hält wollte ich eigentlich nicht ich wollte eigentlich pure daten sehen und das kriegt man wenn man den haken nicht reinmacht da war gerade so schön dabei waren und hier mal gucken können wie lange denn das dauert habe ich natürlich auch die anderen logfiles noch mal aufgerufen und zwar das mit 32 fangen wir damit mal an das dauert dann schon ein bisschen länger das einlesen 32 werte der schnellste update rate ist 1,021 sekunden also alle eine sekunde kriegen wir das dauert mindestens eine sekunde bis wir neue aktuelle daten kriegen bei 32 sensordaten übertragen werden maximale zeit ist 21 44 auch hier sieht man egal welchen sensor wertig aus dem logfile auslese die zeiten sind nahezu identisch also braucht man jetzt wirklich bloß bei einem zugucken man muss nicht die anderen aber das musste ich vorher noch nicht deswegen habe ich das einfach mal so gemacht also spätestens alle 2,14 sekunden bekommen wir einen neuen messwert und mindestens dauert eine sekunde bis wir einen aktualisierten messwert bekommen bei 32 messwerten gehen wir weiter runter bei 16 es werden da sieht das dann schon anders aus da kriegen wir schnellstens alle 0,44 sekunden einen neuen messwert und spätestens 1,2 sekunden einen neuen messwert jetzt springe ich noch mal ein kleines bisschen zurück wer an mein vorheriges quickie mit den telemetriedaten denkt da war es so dass bei der excel tabelle mit 16 werten keine lücken drin waren und wenn wir jetzt noch marie kapitulieren was ich eben gesagt habe was mir gesagt hat dass dieser haken daten rauschfilter die sich länger als 1,5 sekunden nicht geändert haben dann passt das hier wie die faust aufs auge denn bei dem bei der übertragung von 16 sensor werten kommt spätestens alle 1,2 sekunden ein neuer messwert also alle messwerte liegen innerhalb dieser 1,5 sekunden und deswegen wird da nichts rausgefiltert das passt also alles jetzt habe ich noch mal zwei sensoren währte gerade heute form aufnehmen des videos eingelesen und zwar einmal mit acht sensor werden das geht natürlich fix da sind wir dann bei 0,14 sekunden die wir mindestens warten müssen und maximal bei 0,6 0 3 sekunden und spätestens dann haben wir wieder einen neuen aktuellen wert wir sehen also ganz deutlich je weniger daten übertragen werden müssen desto höher ist die update rate aber das ist natürlich auch verständlich denn so ein armer empfänger hat nur eine gewisse menge an daten die er in einem zyklus abschicken kann da passen halt sagen wir mal vier fünf sechs daten rein und dann muss er warten bis zum nächsten zyklus deswegen je mehr daten umso langsamer wird das ganze aber das hat nichts mit geld zu tun das ist reine physik man kann nicht beliebig viele daten in einem rutsch also in einem bestimmten zeitfenster wir haben ja nur ein zeitfenster von ich glaube es sind und um die anderthalb millionen dauert so eine rücksendung vom empfänger zum sender alle zehn millisekunden für 15 millisekunden da passt nicht beliebig viel daten rein mache ich da mehr rein wird die bandbreite größer wird die band bright größer muss ich mit der sender energie runtergehen um eben diese 100 milliwatt erp nicht zu überschreiten jetzt habe ich natürlich noch geguckt und zwar mit vier sensor werden das ist nicht viel schneller warum ist das jetzt nicht viel schneller erstens vier daten wird da gehe ich von aus in einem rutsch übertragen können die zeit die wir hier sehen alle zehn millisekunden wird so ein wunsch an daten übertragen das ist aber viel länger warum will sie das keine zehn millisekunden hmm da kommt natürlich auch noch die sendedaten rate vom sensor dazu der sensor den ich hier verwende ich hab nicht genau nachgeguckt aber ich lege nehme da an er liegt so zwischen 100 und 150 millisekunden also alle 100 bis 150 millisekunden sendet er neue daten das würde hier auch passen extremfall 120 millisekunden das haut hin dann hat man gerade mal zwei abtastung ‘nen quasi gerade hintereinander erfasst und bei zwei daten wenn also einer dazwischen mal verloren geht dann kommt man aus doppelte 0,3 sekunden das passt zur übersicht und sozusagen zum schluss eines quickies mit ingwer habe ich euch hier die ganzen werte nochmals gestapelt übereinander gelegt so hat man die die zeiten die für die übertragung von 4 8 16 24 oder 32 telemetriedaten werden benötigt wird hier nochmal übersichtlich untereinander also zusammengefasst es gibt keine lücken in den datenübertragungen einer die anlage die lücken entstehen in der tat erst im jedes studio wenn man fälschlicherweise missverständlicherweise diesen bewussten haken dort aktiviert also lasst den haken raus der verwirrten uhr und noch einmal zusammengefasst für die die es wissen wollen dieser haken filtert daten raus die länger als 1,5 sekunden nicht aktualisiert worden sind im logfile wodurch auch immer kann halt sein dass durch große entfernung beim fliegen ein paar datenübertragung einmal verloren gegangen sind und dadurch ein wert nicht aktualisiert wurde und wenn diese zeit eben über 1,5 sekunden geht dann filtert dieser haken diesen wert raus bis er wieder auftaucht dann ist er wieder drin ja das war große verwirrung aber jetzt aufgeklärt wie sich das verhält in diesem sinne ich wünsche euch eine gute zeit und verbleibe immer bis zum nächsten quickie oder vielleicht in 14 tagen mal zu einem der großen videos vielen dank bis dann zschau
Für den Inhalt des Videos ist der VideoCreator: Ingmar Grote verantwortlich.
#Quicky #19.. #TelemetrieLatenz #Teil3
ingmar grote, source
