Hallo Forum, ich bitte um Eure Hilfe bei folgender Problemstellung: Es sollen Frequenzen gemessen werden, gleichzeitig an drei Wellen. Frequenzbereich je Welle bis ca. 2000 Hz, das Mess-Signal des Geschwindigkeits-Sensors ist sinusförmig, Bereich 0..5V oder 5V ... 10V Diese Frequenzinfo benötige ich in eimen PC-Programm (vorzugsweise Visual C++) Per Software möchte ich entweder die Analogwerte der am Eingang anliegenden Sinusspannung erkennen (denke, dazu reichen 16 oder 12 bit Auflösung) oder ich forme das Sinussignal zuvor per Hardware in ein Rechtecksignal um (mittels Komparator, Schmitt-Trigger, ...) Sinn ist letztlich, per Software unmittelbar die garade am Eingang anliegende Frequenz bzw. Periodendauer zu erkennen/ermitteln. Das ganze soll mit einem Notebook laufen, das HW-Interface wird also höchstwahrscheinlichein USB-Interface haben. Das Problem dabei scheint zu sein, dass die von mir bisher gefundenen USB-Interfaces nur bis max. 1000 mal je Sekunde ihre gemessenen Werte per USB an den Rechner weitergeben können. Sie sind zwar problemlos in der Lage, höhere Frequenzen als 2000Hz zu erfassen, aber können nicht jede Schwingung 1:1 via USB an den PC geben. Ich möchte aber zu jedem Zeitpunkt der anliegenden max. 2000Hz möglichtst schnell die Periodendauer oder Frequenz der soeben anliegenden Schwingung ermitteln. Dazu benötige ich wohl eine Art schnellen Zähler oder Timer. Ist sowas in C++ softwaretechnisch genau und verlässlich zu realisieren oder macht hier ein HW-Zähler mehr Sinn? Wie lese ich den dann ein? Ich hoffe ich habe mich halbweg klar ausgedrückt ... Eine Menge Fragen jedenfalls, ich danke Euch für jeden Tipp, Hinweis und Vorschläge zur Umsetztung. Auch Infos zu Firmen, die geeignete Interfaces anbieten, sind willkommen. MfG euroretter
Markus S. schrieb: > Das Problem dabei scheint zu sein, dass die von mir bisher gefundenen > USB-Interfaces nur bis max. 1000 mal je Sekunde ihre gemessenen Werte > per USB an den Rechner weitergeben können. Sie sind zwar problemlos in > der Lage, höhere Frequenzen als 2000Hz zu erfassen, aber können nicht > jede Schwingung 1:1 via USB an den PC geben. Ist ja nicht so schlimm: wenn der USB-Wandler z.B. mit 20kHz abtastet, und dir jede ms 20 Messwerte schickt, dann kannst du die problemlos wieder zusammensetzen. So wird das bei USB-Oszilloskopen und Logicanalytern auch gemacht...
Also mit USB High Speed und Interrupt Transfer geht das ohne weiteres. Da ist ein Update alle 125µs möglich. Daher könntest du den Zähler auf einem modernen ARM implementieren, also Tiva C 129 Series oder STM32F4xx. Die USB Enumeration ist nicht so hart, wie sie zu sein scheint, man muss nur viel lesen. Hässlich könnte allerdings dann die PC-seitige Software werden, da ein eigener USB Treiber nötig wäre.
Der einfache Weg wäre es das Signal mit der Soundkarte oder ähnlichem Aufzunehmen und dann digital auszuwerten. Je nach Signalqualität sollte man zu erst digital filtern und kann dann eine Sinusfunktion an die Daten anpassen. Je nach Vorwissen wäre der erste Schätzwert ggf. per FFT zu bekommen, oder halt aus der letzten Messung. Die Auflösung bzw. das Rauschen in der Frequenz hängt von der Länge des Datensatzes ab (nimmt etwa mit Länge hoch 3/2 ab). Wenn das Signal wenig Störungen enthält reicht schon eine relativ kurze Messzeit (so im Bereich 0.01 s) für eine gute Auflösung - sonst braucht es halt etwa länger. Als Referenz dient der Takt der Soundkarte - wenn man hohe Anforderungen (besser als etwa 0.01%-0.001%) hat, muss man da ggf. aussuchen und ggf. im Wechsel ein externes Referenzsignal messen.
Markus S. schrieb: > Diese Frequenzinfo benötige ich in eimen PC-Programm (vorzugsweise > Visual C++) Dient das nur zum Anzeigen, oder willst du damit noch irgendwas zeitkritisches machen?
Ulrich H. schrieb: > Der einfache Weg wäre es das Signal mit der Soundkarte oder > ähnlichem > Aufzunehmen und dann digital auszuwerten. Je nach Signalqualität sollte > man zu erst digital filtern und kann dann eine Sinusfunktion an die > Daten anpassen. Je nach Vorwissen wäre der erste Schätzwert ggf. per FFT > zu bekommen, oder halt aus der letzten Messung. > Die Auflösung bzw. das Rauschen in der Frequenz hängt von der Länge des > Datensatzes ab (nimmt etwa mit Länge hoch 3/2 ab). Wenn das Signal wenig > Störungen enthält reicht schon eine relativ kurze Messzeit (so im > Bereich 0.01 s) für eine gute Auflösung - sonst braucht es halt etwa > länger. > > Als Referenz dient der Takt der Soundkarte - wenn man hohe Anforderungen > (besser als etwa 0.01%-0.001%) hat, muss man da ggf. aussuchen und ggf. > im Wechsel ein externes Referenzsignal messen. Das Problem sehe ich allerdings dort, daß die Soundkarte nur 2 Kanäle hat, links und rechts. Und außerdem könnte es bei niedrigen Frequenzen schwierig werden, da die Soundkarten nicht bis Null Hertz erfassen können (C-Kopplung). Für 3 Messkanäle (Sinus) wäre vielleicht ein USB-A/D-Wandler mit mehreren Kanälen geeignet. Da gibts meist auch eine Software-Schnittstelle, um die für eigene Anwendungen abzufragen.
Da würde ich einen Arduino Uno nehmen, der über T1-Capture schnell die Periodendauer messen kann und per auf dem Board vorhandenen RS232->USB-Wandler den Wert ausgibt. Eine weitere Möglichkeit wäre, das mit einem STM32F4-Discovery-Board zu erledigen; T8 mit seinen 4xCapture-Eingängen an PC6 - PC9 ist frei verfügbar. Aktuell baue ich mit dem STM32F407 einen 4-Kanal Frequenzzähler, der neben der Ausgabe per RS232 (optional USB) die Werte auch noch auf einem LCD anzeigt. Dies sind nur ein paar Möglichkeiten.
Natürlich wird es auch mit einem PC hinzukriegen sein. Einfacher wäre es sicherlich, für die Frequenzmessung einen kleinen µC abzustellen, der die ausgewertete Frequenz als Zahl per USB an den PC weiterreicht.
Markus S. schrieb: > Das Problem dabei scheint zu sein, dass die von mir bisher gefundenen > USB-Interfaces nur bis max. 1000 mal je Sekunde ihre gemessenen Werte > per USB an den Rechner weitergeben können. Sie sind zwar problemlos in > der Lage, höhere Frequenzen als 2000Hz zu erfassen, aber können nicht > jede Schwingung 1:1 via USB an den PC geben. Wenn es nur um das Feststellen der Frequenz geht, sollte man auch mal ins Auge fassen, dass die externe Hardware die Frequenz ausmisst und nur noch diesen Zahlenwert fix&fertig an den PC weiter gibt. Denn wenn sich Windows ein Päuschen gönnt, weil der Virenchecker wieder mal drann ist, oder die Festplatte aufgeräumt werden muss, ist es dann recht schnell auch mal Essig mit dem ermitteln der Frequenz aus den Messwerten. Für einen externen µC hingegen, auf dem dieses Programm und nur dieses Programm ganz alleine läuft, ist das Ausmessen von einer paar Analogsignalen im Bereich bis 2kHz ein Kinderspiel. Edit: 2 Köpfe (Wolfgang + moi), 1 Gedanke
:
Bearbeitet durch User
Karl Heinz schrieb: > Edit: 2 Köpfe (Wolfgang + moi), 1 Gedanke Dafür war deiner viel liebevoller ausgemalt ;-)
ohnePlan schrieb: >> Diese Frequenzinfo benötige ich in eimen PC-Programm (vorzugsweise >> Visual C++) > > Dient das nur zum Anzeigen, oder willst du damit noch irgendwas > zeitkritisches machen? Die gemessenen Periodendauern werden für weitere Berechnungen im Programm verwendet. Wichtig ist, dass jede anliegende Schwingung gemessen wird, bei der Messung keine Schwingung 'verloren' geht oder über mehrere Schwingungen gemittelt wird.
m.n. schrieb: > Da würde ich einen Arduino Uno nehmen, der über T1-Capture schnell die > Periodendauer messen kann und per auf dem Board vorhandenen > RS232->USB-Wandler den Wert ausgibt. > > Eine weitere Möglichkeit wäre, das mit einem STM32F4-Discovery-Board zu > erledigen; T8 mit seinen 4xCapture-Eingängen an PC6 - PC9 ist frei > verfügbar. > > Aktuell baue ich mit dem STM32F407 einen 4-Kanal Frequenzzähler, der > neben der Ausgabe per RS232 (optional USB) die Werte auch noch auf einem > LCD anzeigt. Das hört sich gut an. Der Arduino Uno ist ja sehr weit verbreitet. Wie 'schwer' ist die Lernkurve, wenn Kenntnisse in C Programmierung vorhanden sind? Kann denn der Arduino Uno via USB 2000 mal in der Sekunde Werte zum PC schicken oder ist dann er bzw. der PC dann voll ausgelastet? Alternativ könnte ich doch auch z.B. 1 Sekunde lang Messwerte mit dem Arduino Uno erfassen, in einem Array speichern und denn in einem 'Rutsch' via USB zum PC übertragen. Unklar ist mir noch, wie ich USB Werte einlese auf PC Seite, gib es dafür fertige Klassen/Funktionen/ in bzw. für Visual C++ 2013 ? euroretter
?!? schrieb: > Das Problem sehe ich allerdings dort, daß die Soundkarte nur 2 Kanäle > hat, links und rechts. Das Problem ist keins, auch 24 Kanäle mit 192kHz/24bit sind nur eine Kostenfrage. http://www.thomann.de/de/search.html?KF=on&gk=coaius&oa=pra&bn=&pr=&wgfid1=7574&wgf7574=4&wgfid2=7575&wgf7575=&wgfid3=7572&wgf7572=&wgfid4=2091&wgf2091=&wgfid5=7573&wgf7573=&wgfid6=7576&wgf7576=&wgfid7=7577&wgf7577=&wgfid8=7578&wgf7578=&wgfid9=7413&wgf7413=&wgfid10=2096&wgf2096=&wgfid11=2099&wgf2099=&wgfid12=7581&wgf7581=&wgfid13=7580&wgf7580=&wgfid14=2100&wgf2100=&wgfid15=2101&wgf2101=&kf=on Ob man daraus mit Software das gewünschte Ergebnis erzielt, ist eine reine Frage der Programmierkünste... Latenz hat man am PC immer, die Frage ist, was > möglichtst schnell bedeutet.
Markus S. schrieb: > Die gemessenen Periodendauern werden für weitere Berechnungen im > Programm verwendet. Wichtig ist, dass jede anliegende Schwingung > gemessen wird, bei der Messung keine Schwingung 'verloren' geht oder > über mehrere Schwingungen gemittelt wird. Damit scheidet Arduino Uno aus. Dieser würde sich eignen, mit einer einfachen Hardware Stichproben der Perioden zu erfassen und zu übertragen. Für die Erfassung jeder einzelnen Periode ist er meiner Meinung nach zu schnell an seinen Grenzen. Cäsars 'parte et divide' zu Folge könnte man die Erfassung auf drei AVRs aufteilen; pro Kanal ein ATTiny2313/4213, der per T1-capture jede Periode erfaßt und per TxD ausgibt. Die Zusammenführung der Kanäle würde dann über eine entsprechende Anzahl von RS232->USB-Adaptern erfolgen. Für max. 200 Messungen/s habe ich eine fertige € 3,--/Kanal Lösung, wobei die Messrate durch die 'float'-Ausgabe begrenzt wird. http://www.mino-elektronik.de/fmeter/neue_versionen.htm Bleibt aus meiner Sicht der STM32F407. Die Erfassung ist für ihn keinerlei Problem; auch hat er genug RAM, um über mehrere Sekunden Periode für Periode aufzuzeichen. Auch eine Datenübertragung per USB wird hinreichend schnell sein. Eigene USB-Routinen habe ich keine. Am besten sucht man sich ein Projekt, das die USB-Verbindung sauber gelöst hat und ergänzt die Periodendauermessungen. Ein anderer Weg wäre, die Vorverarbeitung im STM32 vorzunehmen; anschließend überläßt man dem PC die aufbereiteten Daten. Dafür würde wieder eine RS232-Verbindung reichen.
Eine Frage wurde hier m.E. noch nicht deutlich gestellt und beantwortet: Muss die Messung längere Zeit und live erfolgen oder genügt auch das Samplen über einen gewissen Zeitraum und dann eine Auswertung "in aller Ruhe"? Das würde den Spielraum hinsichtlich geeigneter Lösungen deutlich erweitern. Und dann wundert mich hier noch 'was Allgemeines: Wieso wird hier immer noch und immer wieder auf dem alten Zopf RS232 herumgeritten? Zur Verbindung zu einem modernen Computer/Laptop ist ja wohl USB das Mindeste. Viele meiner Projekte mache ich gar mit Netzwerk (Arduino Nano + Netzwerkadapter = 20 Euro), wenngleich USB den Vorteil der einfachen Spannungsversorgung bietet (solange diese bezüglich der Stromstärke ausreicht) ...
Frank Esselbach schrieb: > Und dann wundert mich hier noch 'was Allgemeines: Wieso wird hier immer > noch und immer wieder auf dem alten Zopf RS232 herumgeritten? Zur > Verbindung zu einem modernen Computer/Laptop ist ja wohl USB das > Mindeste. Warum gehen Leute immer noch zu Fuß zum Bäcker, obwohl man doch mit einem Geländewagen die schnelle Abkürzung über Nachbars Felder nehmen könnte? Hast Du für den STM32F4 stabile USB-Treiber, die an allen Rechnern unter allen Betriebssystemen funktionieren? Die verwende ich dann sofort. Oder ist zu befürchten, dass sich ein Kunde von sonstwo auf der Erde meldet, um mitzuteilen, dass sein Rechner nach 1-2 Stunden abstürzt, nachdem er Dein USB-Gerät angestöpselt hat? USARTs (RS232 ist ja nur ein allgemein verwendeter Oberbegriff) sind dagegen ein Kinderspiel mit garantierbarer Funktion. Die Problematik der Kompatibilität kann man dann auf den RS232->USB-Adapter verlagern, für deren Funktion sicherlich viele Programmierer mit speziellem know how sorgen. Warum soll ich für eine einfache Datenübertragung eine Technik verwenden, die komplette Filme in Echtzeit wiedergeben kann? Man kann sich natürlich verschiedene Quellcodes zusammenkopieren und sich freuen, wenn es läuft. Wenn nicht, dann sieht man vor lauter Bäumen den Wald nicht mehr. Für eine kommerzielle Lösung wird man sich sicherlich passende Treiber kaufen, wenn man zügig zum Ziel kommen muß, oder entsprechende Arbeitszeit einplanen müssen. Ich habe weder Zeit noch Geld ;-) m.n. schrieb: > Am besten sucht man sich ein > Projekt, das die USB-Verbindung sauber gelöst hat und ergänzt die > Periodendauermessungen. Das hatte ich ja vorgeschlagen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.