INFO: Dieses Forum nutzt Cookies...
Cookies sind für den Betrieb des Forums unverzichtbar. Mit der Nutzung des Forums erklärst Du dich damit einverstanden, dass wir Cookies verwenden.

Es wird in jedem Fall ein Cookie gesetzt um diesen Hinweis nicht mehr zu erhalten. Desweiteren setzen wir Google Adsense und Google Analytics ein.


Antwort schreiben 

Desynchronisierung bei längerer Datenerfassung



Wenn dein Problem oder deine Frage geklärt worden ist, markiere den Beitrag als "Lösung",
indem du auf den "Lösung" Button rechts unter dem entsprechenden Beitrag klickst. Vielen Dank!

28.04.2008, 14:46 (Dieser Beitrag wurde zuletzt bearbeitet: 28.04.2008 14:57 von m0n0g0n.)
Beitrag #1

m0n0g0n Offline
LVF-Gelegenheitsschreiber
**


Beiträge: 65
Registriert seit: Mar 2008

8.5.1
2007
de

13507
Deutschland
Desynchronisierung bei längerer Datenerfassung
Hi leute,

ich hab hier ein zweikanal messgerät (USB) welches ich mit hilfe einer hersteller dll ansteuere. Nun bekomme ich pro abfrage ein array aus double werten und daraus bau ich mir mein datentyp Signalverlauf.
Um den signalverlauf korrekt darzustellen ermittle ich das dt mit einer funktion aus der dll (getFreq()).

Nun hat sich aber rausgestellt das diese funktion einen recht groben wert liefert und somit führt dies bei erfassung mehrer kanäle (mit leicht unterschiedlichen datenraten) früher oder später zu einer desynchronisierung.

Noch etwas zum besseren verständnis:
Ich erfasse pro schleifendurchgang ein array aus double werten (pro Kanal).. dann mach ich daraus ein Signalverlauf.. und hänge es an mein Signalverlauf (Signalverlaufsarray) welches sich in einem Schieberegister befindet. Das problem ist... das der Datentyp Signalverlauf in LabVIEW aus nem array aus messwerten (Y) besteht, einem dt und einem zeitstempel t0. also selbst bei sehr geringen abweichungen von dt wird es auf lange sich zu desynchronisierung kommen. wie löst ihr solche probleme? Das ist doch ein 0815 problem oder nicht?

Naja jedenfalls.. dachte ich mir.. wenn man pro schleifendurchgang sich die systemzeit schnappen würde.. also das t0 neu ermitteln würde.. könnte es das problem lösen.. aber das wird ja verworfen wenn man einen neuen signalverlauf an einen alten anfügt (da wird ja nur das erste t0 verwendet).

Falls noch einiges unklar sein sollte erkläre ich gerne mehr.

mfg
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
Anzeige
30
Antwort schreiben 


Gehe zu: