Public Support

Supportanfrage

Eine Frage zum Filter Trace View:

Berechnet der die Datenraten anhand der StreamTime oder gegen eine freilaufende System-Zeit?

Wir haben Funktionen aus einer Steuergeräte-SW in ADTF eingebunden, gehen damit ins Fahrzeug und machen auch ein Replay der Daten.
Bisher wurde ein cKernelThread genutzt, um die Funktionen im 10 ms Takt aufzurufen.
Das funktioniert im Fahrzeug sehr gut, im Replay jedoch nicht zu meiner Zufriedenheit. Zum Beispiel stimmen die Datenraten dann nicht mehr, wenn ich die Abspielgeschwindigkeit auf Faktor 4 setze. Zudem befürchte ich, dass ich mit einer Thread-Steuerung jedes mal andere Ergebnisse erhalte, wenn ich die gleiche Aufnahme mehrmals abspiele.

Daher habe ich eine zweite Option fürs Replay implementiert, die einen cKernelTimer zum Aufruf der Funktionen nutzt. Damit funktioniert das Abspielen mit Faktor 4 auch. Und die Reproduzierbarkeit sollte somit auch gegeben sein?

Die angezeigte Datenrate bzw. die SamplesPerSecond im Replay geht jedoch unter die Erwartung zurück. Meiner Meinung nach ist das aber okay, wenn eben mal nicht genügend Rechenleistung zur Verfügung steht...

Lösung

cKernelTimer ist für genau diese Anwendungsfälle gedacht (Um eben auch im Playback zu funktionieren und genauer zu sein als ein Sleep). Und ja das Filter Trace View nutzt immer "Echtzeit", also einfach die System Zeit zur Berechnung der Datenrate (und nicht die Stream Time).

Filter sollten und müssen eigentlich nie selbst eine Unterscheidung zwischen Live- und Playbackbetrieb machen.
Der cKernelCyclicThread ist eher dafür gedacht, auf ein Event zu warten (Condition Variable) um dann Daten asynchron zu verarbeiten, als dass man einen Timer mittels Sleep simuliert.