---

Geschrieben von Scanner am 19.05.2012 um 15:27:
  Intervall bei taktgesteuertem Frequenzgenerator?
Hallo,

ich hab ein Problem mit der Taktung meines Frequenzgenerators, folgender Code:

C#-Code:

double dSwIntervall = Stopwatch.Frequency / iHertz);             clientSock.Send(_Messenger.SendMessage(SignalMessenger.MessageType.StartMonitoring));             sw.Start();             while (true)             {                 if (sw.ElapsedTicks >= dSwIntervall)                 {                     clientSock.Send(_Messenger.SendMessage(SignalMessenger.MessageType.Data32));                     _Benchmark.UpdateSent();                     sw.Restart();                 }             }

Ziel ist, nach einem auf der GUI gewählten Takt, z.B. 100 Hz, Datenpakete auf die Socket zu senden. Die Daten werden von einer anderen Applikation aufgenommen und dort auf einen Stack gelegt. Klappt soweit wunderbar, jedoch arbeitet die Taktung nach meiner Methode nicht korrekt.

Nehme ich die Stopwatch raus und sende ungetaktet auf die Socket, komme ich laut Benchmark auf 10.000 Hz, ich muss jedoch zwischen 100 Hz und 1000 Hz erzeugen können. Die Taktung schwankt auch erheblich bei jedem neuen Start bzw. Senden. Zeitweise bekomme ich bei 100 Hz auch wirklich 100 Hz auf den Sockel (+/- 30 Hz, das ist okay), aber dann steigt die Taktung plötzlich auf 200 Hz oder senkt sich auf 30-40 Hz, um dann wieder später anzusteigen. Ohne die Parameter zu ändern starte ich den Sendevorgang erneut mit z.B. 500 Hz eingestellt und die Taktung geht nicht über 300 Hz hinaus.

Mir ist klar, dass es sich hier um Systemschwankungen handeln muss, aber das ist vermutlich nicht der einzige Faktor. Wie realisiert man sowas am besten, ist es überhaupt möglich ohne spezielle Hardware? Ich hatte es mit einem ereignisbasierten Timer schon probiert, der war aber noch schlechter und nicht granular genug. Meine Idee wäre hier, den aktuell erzeugten Takt vom Benchmark jede Sekunde auszulesen und dann mit einem Faktor gegenzusteuern, also z.B. +1 auf den Takt, wenn dieser niedriger als der gwünschte Wert ist und -1 falls höher -- aber das kanns doch nicht sein, oder?

---

Geschrieben von talla am 19.05.2012 um 16:20:
 
Hallo,

Was du auf jeden Fall nicht berücksichtigst, sind die Laufzeiten deiner Send Methode. Die führst du aus nachdem dSwIntervall vergangen ist und nach der Send Methode, startest du den Timer neu. Mal angenommen die Send dauert ebenfalls so lang wie dSwIntervall hast du auf einmal nur noch die halbe gewünschte Frequenz.

So oder so wirst du deine Zeiteinschränkungen kaum so einhalten können. 1000 Hz sind immerhin eine Millisekunde Sendeabstand. Daher wirst du alleine durchs Threadscheduling des OS locker Ungenauigkeiten die im hundert Hz Bereich liegen haben und nicht 30 Hz. Und dann hast du ja auch noch das Netzwerk als Kommunikationsstrecke wo Netzwerktreiber, eventuelle Router etc. jeweils puffern und gewisse Laufzeiten haben.

---

Geschrieben von Scanner am 19.05.2012 um 16:26:
 
danke, das hab ich befürchtet. der transfer ist eigentlich für ein spezielles lan vorgesehen, wo man möglichst viele störfaktoren beseitigt, also z.b. jeweilige dienste abschaltet und auch nicht im internet ist. gibt es denn spezielle hardware für solche zwecke oder wie realisiert man sowas sonst?

---

Geschrieben von talla am 19.05.2012 um 16:29:
 
Für was dient das denn eigentlich? Gibst du einen Takt vor oder überträgst du Nutzdaten?

---

Geschrieben von Scanner am 19.05.2012 um 16:34:
 
das ist ein simulator für eingehende eeg-daten. die werden meist mit 100 Hz erfasst, intervalle bis 1000 Hz sind aber auch üblich mittlerweile. die bestehende software zur erfassung solcher daten hat zwar einen simulationsmodus, aber der hat so gut wie keine parameter, geschweige denn eine möglichkeit, die signale künstlich zu modellieren. die genaue erzeugung der frequenz ist halt auch nützlich, wenn man mit realzeit-analyse experimentieren will.