Hallo zusammen, Ich weiß, das Thema Frequenzzähler ist ein EWIGES Thema, aber als ich hier im Forum danach gesucht habe, ist mir aufgefallen, daß viel zu viel herum theoretisiert und "gerechthabert" wurde. Ich hab deshalb mal einen winzigen Frequenzzähler konstruiert, der sich leicht nachbauen läßt und weit mehr als 50 MHz messen kann. Ein Exemplar, was ich vorab aufgebaut habe, kommt bis über 150 MHz. Von der Schaltung her kann dieser Zähler problemlos 7 1/2 Stellen bei ca. 1 Sek Meßzeit auflösen. Das Begrenzende dürfte der Quarztakt sein, denn einfache "Takt"-Quarze haben typische Stabilitäten so um 25 oder 50 ppm und wenn man es besser haben will, dann braucht man einen guten TCXO oder gar OCXO und das geht ins Geld, kostet relativ viel Strom und ist mechanisch groß (relativ zum Rest der Schaltung). Ziel ist also ein Zähler, den ich auf möglichst minimalistische Weise konstruiert habe. Der allererste Platz gebührt allerdings der Firma MicroChip, denn die hatten vor über 15 Jahren einen Frequenzzähler vorgestellt, der aus nichts anderem als einem PIC (nebst Quarz) und einem einfachen Widerstand besteht. DAS ist wahrer Minimalismus, der auf seine Weise für Fachleute was Faszinierendes hat. Viel Aufwand treiben kann ja jeder, aber hier geht es nicht um's gegenseitige Übertrumpfen, sondern darum, mit möglichst wenig Aufwand etwas möglichst Nützliches zu bauen. An Bauelementen braucht es für dieses Projekt: - einen PIC, - ein Text-LCD - ein paar Einzelgatter von Fairchild oder Texas Instruments. Ach ja, das Ganze ist nur so groß wie eine Streichholzschachtel. Die angehängte PDF-Datei enthält alles Wichtige. Viel Spaß euch allen W.S.
"Wenn es denn unbedingt kein PIC sein müßte, wäre mein Favorit der 74VHC393, der locker auf 170 MHz kommt. Damit müßte der nachfolgende Controller nur noch 10.7 MHz zählen können - immer noch zu viel für einen Atmel..." Nö, der 393 enthält 2*4Bit Teiler: 170MHz / 256 = 0,7MHz, also überhaupt kein Problem für nen AVR. Ich hab damals nen AT90S2313 genommen. Das Aufwendigste an nem Frequenzmesser ist die Eingangsstufe. Peter
Wie sehen denn bei diesem Projekt die Analogintegratoren aus? Erfassen die auch die Removal-Zeiten (CLR...1st Count) des Vorteilers? Ansonsten: Schnelle Logic-Gates gibts viele. Schlau eingesetzt erreicht man damit tolle Ergebnisse. ABER die schnelle Logik-kompatible Aufbereitung beliebiger Analogsignale ist für den Liebhaber meist DAS Problem.
Angehängte Dateien:
-
fm48.png
11 KB
Ich nehme immer gerne einen ATmega48. Der liefert 7-Stellen von 0,005Hz - 170MHz bei 0,5ppm. Viele Bauteile sind auch nicht nötig. Man kann ein LCD ergänzen; mit dem UART oder IIC ist der Aufwand geringer und die Messung kann in ein System integriert werden. Nur so als Vorschlag.
Peter Dannegger schrieb: > Nö, der 393 enthält 2*4Bit Teiler: > 170MHz / 256 = 0,7MHz, also überhaupt kein Problem für nen AVR. > Ich hab damals nen AT90S2313 genommen. Ich glaub, du hast nicht gründlich genug meine Bemerkungen über die Atmels gelesen: ein 4 Bit-Zähler wird als Vorteiler für die Referenz gebraucht und der andere als Vorteiler für das Input-Signal. Also nix mit 2*4Bit=256. Also bei einem ATmega gilt 7.5 MHz * 16 --> 120 MHz maximal. Aber das ist ja auch nicht nichts. und an Ralli: Bei diesem Projekt gibt es keine Analogintegratoren, ich glaube, dies deutlich genug geschrieben und auch begründet zu haben. Sowas gehört in eine andere Liga von Frequenzzählern. Ich hab sowas auch auf meinem Plan: CPLD + ARM. Aber darum geht es mir HIER nicht. Natürlich kann man beliebig viele TTL-IC's einbauen, aber genau so ein TTL-Bergwerk soll es eben NICHT werden. W.S.
W.S. schrieb: > Ich glaub, du hast nicht gründlich genug meine Bemerkungen über die > Atmels gelesen: ein 4 Bit-Zähler wird als Vorteiler für die Referenz > gebraucht und der andere als Vorteiler für das Input-Signal. Ja, ich hab nicht den ganzen Artikel gelesen. Ich nehme die Referenz als CPU-Takt und daher kann der 393 komplett als Vorteiler dienen. Peter
Du brauchst also nur einen beliebigen µC mit zwei asynchronen Zählern, einem Timer und baust damit einen reziproken Frequenzzähler. Sehr schön. Nur dass „professionelle“ Frequenzzähler heute noch mit analogen Zeitintegratoren arbeiten, ist vielleicht etwas weit aus dem Fenster gelehnt… Auch werde ich das Gefühl nicht los, dass du die Hardware um einen PIC maßgeschneidert hast und dann behauptest, dass nur ein PIC mit dieser Hardware funktioniert. Und wäre es nicht noch mehr Minimalismus, die ganzen 3 ICs durch einen FPGA zu ersetzen, der dann > 200 MHz schafft? :-D
erstmal an den Peter: du schriebest: "Ich nehme die Referenz als CPU-Takt und daher kann der 393 komplett als Vorteiler dienen." Das kann man nicht mit einem ATmega. Der kann es eben NICHT!!!! Wenn du das nicht glaubst, dann lies bitte die Doku zu diesen ICs. Abgesehen davon ist ein Zählbereich bis 120 MHz auch nicht zu verachten. Also layoute mal deine Atmel-Version und laß sie uns sehen. Aber die Diskussion über Atmels ist hier und jetzt nicht mein Thema. Ich hab diese Abwägung bereits erledigt und hinter mir. Bei diesem Projekt sollen 2 Dinge herauskommen: ein möglichst kleiner Modul zum nachträglichen Einbauen in andere Geräte und ein Taschen-Frequenzzähler. Sowas gab's mal von Radio Shack vor vielen Jahren. Ist ne ganz praktische Sache sowas. So, und nun nochwas zu Dennis: Lies dir mal die Manuals von HP oder Racal Dana durch. Und was deine Gefühle betrifft: Ich hab den PIC ausgesucht, weil er am besten in das Konzept paßt und nicht umgekehrt. Abgesehen davon kann man das Prinzip mit jedem anderen Controller auch realisieren, es ist eben bloß aufwendiger. Und wenn ich richtigen Aufwand treiben will, dann mit nem ARM weil der für's Programm mehr bietet als ein Atmel und ein CPLD, weil das schlichtweg schneller ist als ein FPGA. Aber SOWAS ist eine andere Liga. Wir wollen ja schließlich auf dem Teppich bleiben, gelle? Und nochwas zu "m.n.": "Ich nehme immer gerne einen ATmega48. Der liefert 7-Stellen.." Oh ja, ich nehme auch immer gern ein Bier, das liefert meistens 5 Umdrehungen... Im Ernst: Wozu sollen solche Beiträge gut sein? In diesem Sinne PROSIT! W.S.
Hi >Das kann man nicht mit einem ATmega. Der kann es eben NICHT!!!! Wenn du >das nicht glaubst, dann lies bitte die Doku zu diesen ICs. Da hast du etwas nicht verstanden. Peter schrieb; "Ich nehme die Referenz als CPU-Takt und daher kann der 393 komplett als Vorteiler dienen." Und das geht problemlos. MfG Spess
Die PICs haben durch den asyncronen Vorteiler da schon einen Vorteil. Die extra Tor-schaltung ist aber schon aufwendiger als ein externer Vorteiler. Auch die PICs sollten mit dem Ref.-takt für den µC laufen. Meine Wahl für den µC wäre nach der Papierform eher ein dsPic33: Da hat man einen vernünftigen Compiler (wie bei dem AVRs) und einen zuschaltbaren internen Vorteiler auch für die Messung mit Hilfe der Zeitmessung. Bis rund 50 MHz könnte es noch ganz ohne externe Logic gehen, darüber halt wie beim AVR ggf. ein Vorteiler oder als klassischer Zähler mit reduzierter Auflösung (wie beim PIC18xxx). Die Rechenleistung sollte ausreichen um das Timing von vielen Flanken auszuwerten, um auch bei einem nicht so idealen Eingangssignal mehr Auflösung heraus zu hohlen als ein Reziprokzähler.
Ich wäre auch für einen dsPIC33, der hat ja auch ein sehr schnelles Rechenwerk. Der dsPIC33FJ12GP201 hat nur 18 Pins und es gibt ihn als DIP und SOIC. Der Timer 1 hat 16-bit und kann asynchron bis 50 MHz zählen (im Datenblatt ist ein Druckfehler, da steht 50 kHz).
W.S. schrieb: > Im Ernst: Wozu sollen solche Beiträge gut sein? Zu zeigen, dass ein AVR eine mindest ebenso gute Lösung bietet, wie der von Dir über Alles gelobte PIC. Dein Gerede von teuren TCXOs oder TTL-Gräbern ist doch absoluter Blödsinn. Dein obiger Artikel - bin wohl der Einzige, der ihn gelesen hat - ist mir einen Tick zu überheblich. Aber schrei ruhig weiter :-)
W.S. schrieb: > dann mit > nem ARM weil der für's Programm mehr bietet als ein Atmel Das ist eine komplett sinnfreie Behauptung. Atmel baut nämlich seit vielen Jahren auch ARM-Controller und -Prozessoren. ;-) Nur, weil Microchip sämtliche seine Controller "PIC" nennt, egal was gerade drin ist, muss man davon nicht darauf schließen, dass andere Firmen dies ebenso tun würden.
m.n. schrieb: > Dein Gerede von teuren TCXOs Eine labbrige Referenzfrquenz kann auch eine noch so tolle Software nicht ausbügeln.
Luk4s K. schrieb: > Eine labbrige Referenzfrquenz kann auch eine noch so tolle Software > nicht ausbügeln. Der Satz ist mehrdeutig; wer bügelt wen nicht aus und was willst Du sagen?
Und kaum piekt man ihn mal an, geht er gleich in die Luft, tse. :-D Seien es nun die asbach-uralten Zeitinterpolatoren, nach denen schon vor langer Zeit eine Art digitalen Nonius (time-triggered vernier oscillators) oder gestaffelte Verzögerungsleitungen erfunden wurden… Denn, ja, ich habe die verfügbare HP-Doku + Journale gelesen. ;) Ich muss m.n. Recht geben, wenn man sein PDF liest, denkt man schon, der Oberlehrer höchstpersönlich doziert über die Zeitmessung. Hat mich gestern wirklich erheitert. :-D So, genug Smilies für einen Text und genug Spaß für heute.
W.S. schrieb: > erstmal an den Peter: > du schriebest: "Ich nehme die Referenz als CPU-Takt und daher kann der > 393 komplett als Vorteiler dienen." > Das kann man nicht mit einem ATmega. Der kann es eben NICHT!!!! Wie schön, daß mein ATtiny2313 Deine graue Theorie nicht kennt, er funktioniert nämlich einwandfrei. Ich hatte davor auch einen AT89C2051 verwendet, obwohl ja Deiner Meinung nach die 8051 völlig untauglich sind. Anbei der Schaltplan. Ich hatte damals keinen schnellen 2*4Bit-Zähler, also habe ich 2 einzelne genommen. Es macht Dir doch niemand einen Vorwurf, daß Du Dich mit AVR bzw. 8051 nicht so gut auskennst. Aber das ist noch lange kein Grund, sie nieder zu machen. Jeder baut sich nen Frequenzzähler mit dem MC, den er am besten kennt und funktionieren tun sie alle und der Schaltungsaufwand ist auch vergleichbar. Peter
m.n. schrieb: > Luk4s K. schrieb: >> Eine labbrige Referenzfrquenz kann auch eine noch so tolle Software >> nicht ausbügeln. > > Der Satz ist mehrdeutig; wer bügelt wen nicht aus und was willst Du > sagen? Andres ausgedrückt: Wenn die Referenzfrequenz Müll ist, hilft auch die tollste Software nichts.
Ulrich schrieb: > Meine Wahl für den µC wäre nach der Papierform eher ein dsPic33: Da hat > man einen vernünftigen Compiler.. Ich nehme mal an, daß der besagte Vorteiler eine Standardbaugruppe ist, die sich wohl in allen PIC's wiederfindet. Ist ja auch was Nützliches. Aber einen dsPic33 würde ich für dieses Vorhaben nicht nehmen: Denk doch mal an den Strom, den der zieht. Mit nur 3..4 mA wie der kleine PIC16 kommt der nicht aus. Lt. Datenblatt braucht der eher 50..120 mA je nach Taktfrequenz. Für ein batteriebetriebenes Taschengerät ist mir das zuviel. Im übrigen frage ich mich, warum du so eine Scheu vor Assembler hast. Ich habe - wie gesagt - schon ein Versuchsmuster aufgebaut und getestet. Mit den 2 K komme ich in Assembler plenty aus - und zwar inclusive Gleitkommapaket. Ansonsten bin ich diese fruchtlose Atmel-Diskussion leid. Man schreibt in großen Lettern in die Überschrift "PIC-Frequenzzähler", versucht dem Thread mit einem ausgearbeiteten Dokument (was auf einem Stück Vorarbeit zum Thema basiert) eine möglichst ordentliche Diskussionsbasis zu geben, und es finden sich zuallererst die Leute ein, die ständig nur "Ich nehme immer gerne einen ATmega48" schreiben. So. Richtige Leiterplatten fange ich erst dann an, wenn Stromversorgung und Eingangsbeschaltung klar sind - also voraussichtlich erst in einigen Wochen. Eine Gehäusevorstellung für das Taschengerät hab ich inzwischen: das ABS100 bei TME. Das ist von der Größe her ganz gut passend, billig und recht sauber gespritzt. Mit etwas Glück bekommt man da einen Li-Akku aus der Smartphone-Szene hinein. Vielleicht kommt in der Zwischenzeit doch noch etwas Sachdiskussion hier herein. W.S.
W.S. schrieb: > Im übrigen frage ich mich, warum du so eine Scheu vor Assembler hast. Weil Assembler hierfür keinerlei Vorteile hat. W.S. schrieb: > Ich habe - wie gesagt - schon ein Versuchsmuster aufgebaut und getestet. > Mit den 2 K komme ich in Assembler plenty aus - und zwar inclusive > Gleitkommapaket. Mein Frequenzmesser ist natürlich in C geschrieben und benutzt float. Das paßt in den AT89C2051 (2kB Flash) bequem rein. W.S. schrieb: > Ansonsten bin ich diese fruchtlose Atmel-Diskussion leid. Schau mal auf das Symbol neben Deinem Bookmark für dieses Forum, da steht AVR drauf. Daher wirst Du entweder damit leben müssen, daß sich auch AVR-User melden oder das Forum wechseln müssen. Peter
Ich habe keine Probleme mit ASM, meinen Zähler habe ich komplett in ASM geschrieben. Bei dem Verfahren viele Flanken auszuwerten kommt es auch auf die Rechenzeit an. Außerdem gibt es nur wenige C Compiler die Zahlen mit 40 Bit und 48 Bit Auflösung oder unsymetrische Operationen (z.B. 32 Bit Zahl mal 8 Bit Zahl) unterstützen. Entsprechend ist hier der Geschwindigkeitsvorteil von ASM relativ groß. Für einen einfachen Reziprokzähler tut es aber auch C. Der Stromverbrauch bei einem schnelleren µC ist nicht so viel höher: Wenn man die Rechenzeit nicht wirklich braucht, wird auch nicht so viel Strom verbraucht. Die dsPic33 scheinen da aber nicht besonders sparsam zu sein. Zu dem Vorgeschalgenen Entwurf: Man kann sich vermutlich einiges, oder alles von der externen Torschaltung sparen, wenn man den µC gleich mit dem stabilen Ref. Takt laufen lässt. Das könnte auch gleich noch den Quantisierungsfehler etwas reduzieren. So wie es aussieht wird ja schon der selbe Takt genutzt. Das im Plan gezeigte externe abgreifen des Taktes direkt am Quarz ist für einen stabilen Takt eigentlich ein No-Go. Die Empfindlichkeit des Taktes auf Änderungen der Versorgungsspannung steigt so noch zusätzlich an. Auch sollte die Spannung geregelt sein - sonst ändert sich die Quarz-frequenz mit der Spannung.
Die typische Diskussion unter Männern: meiner ist der grösste!!! Der eine fährt Opel, der andere Ford. Ich fahre natürlich Ferrari, darunter ist alles sch...
Ulrich schrieb: > Das im Plan gezeigte externe abgreifen des > Taktes direkt am Quarz ist für einen stabilen Takt eigentlich ein No-Go. Dass der PIC hier mit 28MHz um 40% übertaktet wird kommt noch dazu.
henri schrieb: > Die typische Diskussion unter Männern: meiner ist der grösste!!! Dabei ist es vollkommen egal ob AVR, PIC, 8051 oder sonstwas. Wer meint, er müsse sich an ARM und FGPA aufgeilen, der soll das machen. Notwendig ist das nicht. Viele diese Frequenzzähler-Threads hier im Forum haben einen Nachteil: Die Protagonisten sind alles Supertolle Programmierer. Sie posten Schaltpläne mit minimalistischer Hardware und genialen SW-Routinen. Aber an der analogen Signalverarbeitung scheitern sie. Wie ein Messignal von 0,5Hz bis 150MHz mit 50mVss auf TTL-Niveau verstärkt wird erfährt man hier nicht. Zumindest gibt es keine konkreten Bauvorschläge mit Funktionsgarantie. Solange ein Referenzdesign fehlt, kann ein jeder behaupten, er hat den Längsten, zumindest auf dem Papier...
Gala Peter schrieb: > Wie ein Messignal von 0,5Hz bis 150MHz mit 50mVss auf TTL-Niveau > verstärkt wird erfährt man hier nicht. Zumindest gibt es keine konkreten > Bauvorschläge mit Funktionsgarantie. Weil das nicht trivial ist. Wie schon oben gesagt, das aufwendigste ist eben die Eingangsschaltung. Ich hab da auch keine einfache und breitbandig funktionierende Lösung gefunden. Auf Arbeit nehme ich daher oft den Oszi und lasse die Frequenz anzeigen. Man sieht dann, daß er auch die gewünschte Signalform mißt und nicht irgendwelche Störungen. 6 Stellen Genauigkeit liefert der natürlich nicht, aber das brauche ich auch nicht. Der MC und das bischen SW ist dagegen nur Pillepalle. Peter
Gala Peter schrieb: > Wie ein Messignal von 0,5Hz bis 150MHz mit 50mVss auf TTL-Niveau > verstärkt wird erfährt man hier nicht. Das Problem dabei ist, das die richtige Funktion sehr vom Aufbau abhängt. 'Profis' können ihr Problem selber lösen; 'Bastler', die nicht viel investieren wollen, werden am Nachbau scheitern (zumindest bei der HF). > Zumindest gibt es keine konkreten Bauvorschläge mit Funktionsgarantie. Vielleicht hilft Dir dies: http://www.mino-elektronik.de/fmeter/eingangsstufe.htm Zur Zeit bereite ich eine neue Version mit MAX961 vor, mit der 100MHz machbar sein sollten. Die kann/darf man dann für PIC+AVR verwenden :-)
Gala Peter schrieb: > Wie ein Messignal von 0,5Hz bis 150MHz mit 50mVss auf TTL-Niveau > verstärkt wird erfährt man hier nicht. Zumindest gibt es keine konkreten > Bauvorschläge mit Funktionsgarantie. 0,5MHz-150MHz zu (x10) Verstärken sollte mit >2GHz GBW Opamps (CFA) nicht das Problem sein. Als Komparator kann man dann was schnelles in ECL-Technik, wie den MAX9691 nehmen. Wer einen hochohmigen Eingang wünscht, der hängt noch branadics Tastkopf vorne dran.
Luk4s K. schrieb: > Als Komparator kann man dann was schnelles in > ECL-Technik, wie den MAX9691 nehmen. Eine Aneinanderreihung beliebiger Bauteile ist keinesfalls eine brauchbare Eingansstufe! Unabhängig von der Verfügbarkeit+Preis für Jedermann, sieh Dir das Datenblatt vom MAXen an. Wie willst Du die geforderte minimale Anstiegszeit von 1V/µs bei NF sicherstellen? Der Vorschlag eignet sich eher als HF-Generator mit undefinierter Frequenz.
Luk4s K. schrieb: > Nächster Versuch: LT1715 Papier ist geduldig. Bau damit eine Schaltung auf und zeige, dass sie funktioniert. Dann stelle sie hier vor und als 1. Killer-Argument wirst Du hören: "Das ist ja blöd, da braucht man ja -5V."
Also erst mal an m.n: >"Dass der PIC hier mit 28MHz um 40% übertaktet wird kommt noch dazu." Bitte richtig hinschauen: der Quarztakt in der abgedruckten Schaltung beträgt 20 MHz (zwanzig Megahertz). Und zu den Anderen: Ich hab ja bereits geschrieben, daß ich mit Musterleiterplatten erst dann anfange, wenn Eingang und Stromversorgung klar sind - und das sind sie im Moment noch nicht. Ich hab einen Musteraufbau, der noch lange nicht dem eigentlichen Entwicklungsziel entspricht. Dort ist z.B. auch noch ein ECL-Vorteiler mit drin, um eventuell auch Frequenzen im GHz-Bereich messen zu können. Ich weiß schon jetzt, daß das fertige Ding SO nicht aussehen wird. Aber an dem Musteraufbau kann ich schon jetzt einiges an Messungen tun. Dieser hat einen Stepup-Wandler mit dem TPS61041, um aus der variablen Spannung am Li-Akku eine stabile 5 Volt zu machen. Das ist auch nötig, weil das von mir verwendete LCD (das Pollin-LCD für 0.95 Euro mit 2x8 Zeichen) unterhalb von ca. 4.2 Volt keinen brauchbaren Kontrast mehr bringt. Änderungen an der Batteriespannung haben deshalb bei den bisherigen Messungen nicht meßbar auf's Ergebnis durchgeschlagen. Mehr Sorgen mache ich mir da über den Temperaturgang, aber was wäre die Alternative? Kennt jemand eine für Bastler zugängliche Quelle für billige kleine TCXO's mit 20 MHz, die es auch in 6 Monaten noch gibt? ... Und der in seinem Stromverbrauch für ein Batteriegerät noch tragbar ist? Wenn nicht, dann bleibt es wohl beim diskreten Quarz am PIC. Soviel zum Ist-Stand beim Quarz. Zur Stromversorgung: Bei dem o.g. Musteraufbau hat das so ausgesehen: - nur PIC, NC7SZ125 etc. ohne jegliches Signal: ca. 11 mA aus dem Akku - mit ECL Prescaler: ca. 36 mA ohne jegliches Signal. - dasselbe mit 10 MHz Input: auch 36 mA - dito 30 MHz: 43 mA - dito 50 MHz: 48 mA - dito 70 MHz: 54 mA - dito 90 MHz: 59 mA - dito 120 MHz: 65 mA - dito 150 MHz: 70 mA Alle Ströme so wie aus dem Akku gezogen (vor dem StepUp-Wandler). Selbst wenn wir jetzt 25 mA für den ECL-Prescaler abziehen, kommen immer noch ganz schön große Ströme und entsprechend kurze Akku-Laufzeiten dabei heraus. Entweder kippt damit die Li-Akku-Versorgung oder es braucht eine Notbremse gegen Tiefentladung, was Auswirkung auf den Wandleraufbau hat. Zur Eingangsbeschaltung: Das ist wieder eine Strom- und Kostenfrage. Ich tendiere eher zu einer Variante mit einem Schmitt-Trigger-Eingang (NC7SZ14 o.ä.) und ggf. einem linearen Verstärker davor. Ein AD8000 würde das zuverlässig bis weit über 150 MHz erledigen, aber er ist am Ausgang nicht R2R, weswegen er mit +/- 5V betrieben werden müßte - und er ist wohl für viele Leute schwer beschaffbar. Gleiches gilt für Eingangsstufen mit dem ADA4817. Damit kann man Standardeingänge (1 MOhm//20pF) bauen, wo man bequem einen Oszi-Tastkopf anschließen kann. Hab's bereits ausprobiert - ABER: ist alles für dieses Projekt viel zu teuer und zu schwer zu beschaffen. Also suche ich nach bescheideneren Lösungen, wo möglich. Ich denke mal, daß es für manche schon schwer genug sein dürfte, die diversen Einzelgatter zu besorgen, da muß die Hürde nicht noch mit seltenen OpV's erhöht werden. Die Alternative wäre ein Einzelgatter ohne Hysterese und eine Vorspannung so etwa 20..30 mV neben der Schaltschwelle und das Ganze ohne Vorverstärker. Ist billiger aber eben nicht so gut. Ideal wäre eine kleine Hysterese, so etwa 10 mV. Vielleicht kann man sowas mit einem NC7SZ08 o.ä. bauen ohne damit einen UHF-Oszilator zu konstruieren. Wohlgemerkt: Für einen Einbau-Zähler ist das alles viel leichter, denn da weiß man vorher, wie das Signal aussieht und kann die Eingangsbeschaltung danach einrichten. Für reine NF-Zwecke wäre in diesem Einsatzfall ein normaler OpV und dahinter ein Gatter mit Hysterese wohl eine einfache Lösung. W.S.
Wenn man den µC während der Messung in einen Sparmodus versetzt sollte man auch da noch etwas beim Stromverbrauch runter kommen können. Mit der externen Torschaltung sollte das gehen. Als Eingansgverstärker habe ich mal einen diskreten Verstärker mit einem JFET (z.B: BF245) gefunden - die sind relativ leicht zu bekommen. Man benötigt nur einen Abgleich wegen der recht großen Exemplar-streuungen. Den Weg Verstärker und dann ein Schmidt-trigger halte ich schon für sinnvoll um den Aufwand klein zu halten. Als nicht ganz so schöne Alternative zum TCXO könnte man ggf. die Temperatur einfach messen und in Software Korrigieren. Die Kalibrierung ist aber nicht so ganz einfach und zeitaufwendig.
Angehängte Dateien:
-
Eingangsstufe_Fmeter.png
5,5 KB
Anbei ein Vorschlag für eine Eingangsstufe für einen Frequenzzähler. Die Schaltung kommt mit einer Versorgungsspannung von 5V aus. Von links nach rechts sind folgende Elemente vorgesehen: 1. Eingangsbuchse 2. zuschaltbarer Pullup für passive Signalgeber (Schalter) 3. zuschaltbarer Hochpass zur Entfernung von DC-Anteilen 4. kompensierter Eingangsabschwächer 1-3-10... 5. Überspannungsschutz (2 x Dioden) 6. hochohmiger Impedanzwandler 7. Tiefpass zur HF-Unterdrückung 8. 2. Impedanzwandler für Hysterese/Temp.Kompensation 9. Offsetregler für optimalen Triggerpunkt 10. Anzeige des Triggerpunktes mit LED 11. Ausgang mit Stromversorgung Gezeigt ist eine brauchbare und kostengünstige Lösung von DC- xxMHz, wobei die xx vom Aufbau abhängen. Es geht nicht um die Eingangsstufe eines Oszilloskopes! Die Werte der Bauteile sind noch tbd.
W.S. schrieb: > Kennt jemand eine für Bastler zugängliche Quelle für > billige kleine TCXO's mit 20 MHz, die es auch in 6 Monaten noch gibt? Ich habe jetzt die TYETADSANF-20.0MHz von RS erhalten: 20MHz, 0,5ppm, 2,5x2,0mm² klein. Die ca. 1Vss Ausgangsspannung reicht für AVRs; wenn ein PIC damit nicht klar kommt, braucht man noch einen xx04 Inverter zur Pegelanhebung. Gegen Unkostenbeitrag kann ich Dir einen abgeben, oder ich besorg Dir eine ganze Rolle :-) > Bitte richtig hinschauen: der Quarztakt in der abgedruckten Schaltung > beträgt 20 MHz (zwanzig Megahertz). Stimmt, die Null mit Durchstrich sieht aber sehr nach einer '8' aus.
m.n. schrieb: > Ich habe jetzt die TYETADSANF-20.0MHz von RS erhalten: 20MHz, 0,5ppm, > > 2,5x2,0mm² klein. Das ist ein richtig guter Vorschlag! Besserer Vorschlag! Bitte geh' einen Schritt weiter. Nicht 20MHz als Ref- bzw. Prozessorfrequenz sondern gleich 40MHz als Referenz und geteilt durch 2 als Proz.-Frequenz. Dadurch entsteht sinngemäß ein 7 3/4 Zähler. Dann macht auch die Überlegung mit den asynchronen Zählern des PIC Sinn. Die Diskussion ob PIC oder AVR erschlägst damit. BTW: Kann man bei RS auch privat kaufen? mfg Padex
Ich hätte noch neue 26MHz OCXO im montagefreundlichen DIP-Gehäuse für 15 Euronen + 6 Euros für versicherten Versand/Trackingnummer. Wer interessiert ist, melde sich bitte per PM. 26MHz kann man runterteilen auf 13MHz (Standard GMS-Frequenz) oder eben noch weiter bis es paßt. Die gemessene Drift ist 1ppb pro Tag! Normalerweise kostet sowas stolze 100+ Euro.
Padex schrieb: > Dadurch entsteht sinngemäß ein 7 3/4 Zähler. Das "sinngemäß" solltest Du näher erläutern. Man könnte aber auch einfach eine längere Meßzeit nehmen, um mehr Stellen zu erhalten. Aber alles nur wieder auf dem Papier! 7 Stellen ist das Maximum, was eine 32bit-Floatberechnung hergibt. Mehr Stellen erfordern dann die Verwendung von double-Typen oder speziellen Verrenkungen bei der Programmierung. Für den AVR hatte ich schon double verwendet; die Referenzfrequenz muß dann aber auch besser als die kostengünstigen 0,5ppm sein. Das sprengt aber den Rahmen eines kleinen, feinen und günstigen Zählers der "minimalistischen Art".
Abdul K. schrieb: > Ich hätte noch neue 26MHz OCXO im montagefreundlichen DIP-Gehäuse für 15 > Euronen + 6 Euros für versicherten Versand/Trackingnummer. Die gab's die Tage noch günstiger: Beitrag "OCXO 26MHz DIP trimmbar 5V"
m.n. schrieb: > Die gab's die Tage noch günstiger Und auf eBay gibt es sie sogar um ein Zehntel des Preises, wobei der Versand aus den USA für ein paar Stück auch nicht viel mehr als 6 Euro kosten.
10 Euro empfand ich nach googlen dann als zu billig. Habe noch 4 da. Ich weiß nicht obs die gleichen sind. Allerdings wartet man 4-6 Wochen auf eine Sendung aus USA. Unversichert und nicht nach deutschem Recht.
Mal ne Frage, wozu braucht ihr immer diese super-duper genauen Frequenzmesser. Nur um anzugeben oder habt ihr dafür auch praktische Anwendungsgebiete? Peter
Peter Dannegger schrieb: > Mal ne Frage, wozu braucht ihr immer diese super-duper genauen > Frequenzmesser. Genau dafür wo ich auch die genauen Voltmeter, Ohmmeter, Ampermeter, Leistungsmessgeräte, Generatoren und Spectrumanalyser brauche... > Nur um anzugeben oder habt ihr dafür auch praktische Anwendungsgebiete? > > Peter Jupp ist alles Angabe - Der R&S MEssplatz auf dem Labortisch ist für den Ingenieur das was der Porsche für den Manager ist... MErkwürdig das die Firmen das noch nicht gemerkt haben und die teuren Präzisionsgeräte für ihre Angestellten nicht schon längst gestrichen haben. Nee, aber mal im Ernst: Für eine nachträgliche Frequenzanzeige an einem Radio ist das sicherlich blödsinn. da kommt es auf 10Khz mehr oder weniger nicht an. Wenn ich aber an das GErät mit dem defekten PLL Mutterquarz denke was ich vorhin repariert habe, da bedeutet eine Abweichung von nur einem Herz bei der Referenzfrequenz eine um 88KHz verschobene Arbeitsfrequenz, das sind mehr als VIER KANÄLE daneben. Und das ist nur EINE Anwendugn von vielen wo man möglichst genaue Zähler braucht. GRuß Carsten
1Hz ==> 88Khz, vier Kanäle... Wie hoch ist die Referenzfrequenz?
Michael G. schrieb: > 1Hz ==> 88Khz, vier Kanäle... > > Wie hoch ist die Referenzfrequenz? (f)ref= 5Khz jetzt kannst du die (ungefähre) Arbeitsfrequenz des Gerätes ja ausrechnen. Natürlich sind fälle wo man die Referenzfrequenz direkt -genau- messen muss eher selten. Aber es gibt sie -wie vorhin gehabt- Bei normalen Reparaturen in Standartschaltungstechnik reicht es die Frequenz eines Mutterquarzes der im MHz bereicht schwingt möglichst genau zu ermitteln, wo es dann nicht mehr auf einen sondern auf 100Hz - manchmal auch 10Hz oder bloß 1Khz ankommt. Diese Frequenz wird dann ja entweder durch Vorteiler - entweder extern oder im PLL Bastein selber - auf f(ref) heruntergeteilt. Da reicht dann eine grobe kontrolle der resultierenden Vergleichsfrequenz. Wird die f(ref) aber anders erzeugt... NAtürlich kann man Zähler mit diesen Anforderungen noch relativ einfach bauen wenn man viele verschiedene Messbereiche einplant. Will man aber mit einem Messbereich auskommen, zum Beispiel weil man während der Gerätereparatur sich quer durch die Frequenzaufbereitung vortatstet und der erste MEsspunkt der LO mit 140Mhz, der zweite aber die 2. ZF mit 455Khz, der Dritte dann wieder der "Mutterquarz" mit 5,12Mhz ist. Bei jedem Punkt manuell die Auflösung zu ändern ist sehr nervig. Wo ich natürlich zustimmen muss, das ist die "nutzenfrage" von hochleistungszählern im Hobbybereich die ein 23GHz Signal dann bis auf 1/10 Hz auflösen (mal übertrieben gesagt). Soetwas BRAUCHT man vieleicht in der Forschung... Aber ein Zähler der ein 10GHz signal auf 1Khz stimmig darstellen kann wird durchaus auch von AFUs im Hobybereich sinnvoll eingesetzt. ISt natürlich nicht mehr die breite Masse sondern eine hochqualifizierte Minderheit. Gruß Carsten
Sagen wir es mal so: Die Auflösung sollte die Leistungsfähigkeit des Referenzoszillators möglichst voll ausnutzen. Ich entwickle z.B. PSK-Transceiver mit extrem niedriger ZF. Da kommts bei 30MHz aufs Hertz drauf an. Mit meinem Multimeter mit 3,5 Stellen bin ich da komplett aufgeschmissen. <Beispiel aus der schnöden ernüchternden Praxis>
Hallo zusammen, so, jetzt kommt der zweite Teil des Epos von mir. Diesmal hab ich mich NICHT mit dem ganzen Digitalteil befaßt, sondern erst mal versucht, etwas mehr Klarheit in das Frontteil zu bekommen. Vielleicht klappt das ja doch noch, ohne Verrenkungen ein stromsparendes Frontend hinzubekommen, ohne Schaltungsakrobatik betreiben zu müssen. Ach ja, ich selber kann bei RS und Konsorten einkaufen, aber genau DAS ist hier nicht so sehr mein Thema. Mir wäre es am liebsten, wenn jedermann die benötigten Teile bei Pollin oder Reichelt einkaufen könnte. Schließlich soll es ja so sein, daß auch die hier mitlesenden Leuten was davon haben. W.S.
So, es gibt Neuigkeiten und zwar bei Ebay: beim Ebay-Seller "rfextra" (USA) (http://stores.ebay.de/RF-Basic-Store?_trksid=p4340.l2563) gibt es 13 MHz TCXO's von TOYOCOM, Typ TCO-990N. Beschreibung hier: (http://www.epsontoyocom.co.jp/discon/toyocomdiscon/toyocom1999/tco_977.pdf) Die Dinger sind recht klein und flach und ziehen nur ca. 2..3 mA. Ich hab mir davon welche gekauft und näher angesehen. Die Ausgangskurvenform sieht zwar relativ häßlich asymmetrisch aus, aber angesichts der angegebenen 0.5ppm sollte man das wohl in Kauf nehmen. Damit wäre das eine geeignete Zeitbasis für den Frequenzzähler. W.S.
So, nachdem sich das Thema hier zum Monolog entwickelt hat, schließe ich es erstmal ab. Die Muster-LP läuft schon sehr schön, das Gehäuse muß ich aber noch mit den nötigen Löchern versehen und ich werde in der nächsten Zeit mal ein bissel Vergleichsmessungen anstellen, je nachdem, was ich für Vergleichsequipment unter die Finger kriege. Sollte jemand Bedarf an den Files haben, hier ansagen. Frohes Basteln wünscht W.S.
W.S. schrieb: > So, nachdem sich das Thema hier zum Monolog entwickelt hat, Du läßt einen ja auch nie zu Wort kommen. Stell mal den Quellcode ein, schon kommen die "schwarzen Raben" und hacken auf Dich ein :-) Hattest Du mal den MAX999 als Eingangsstufe getestet? Den (MAX91) verwende ich wobei R13 und R14 in meiner Schaltung 100 bzw. 10k betragen. Deine recht hochohmige Beschaltung bildet mit Cin einen Tiefpass und begünstig m.E. die Schwingneigung. Für Vergleichsmessungen könnte ich Dir auch einen Zähler von mir zur Verfügung stellen. Als Eingangsteiler nehme ich u.a. den 74VHC4040.
Nö, den MAX999 hab ich nicht als Eingang getestet, denn er ist langsamer als der von AD. Wozu also? Und den 74VHC4040 brauch ich hier nicht, denn der PIC hat ja die Vorteiler bereits an Board. Wenn man ein Atmel-Fan ist, dann wäre ein 74VHC393 wohl die bessere Wahl, weil er zwei ausreichende Vorteiler enthält (einen für Fin und den anderen Fref, da ist man recht frei mit der Wahl von Fref) und schnell genug ist. W.S.
W.S. schrieb: > Und den 74VHC4040 brauch ich hier nicht, denn der PIC hat ja die > Vorteiler bereits an Board. Ich habe den Anfang des Beitrags noch einmal überflogen. Du brauchst ja 2 x Vorteiler, was ich ganz vergessen hatte. Für mich hat der 4040 den Vorteil der noch höheren Geschwindigkeit und bis zu 4096 teilen zu können, wenn man es braucht. Maximal teile ich durch 1024, wodurch bei Fin 200MHz der (böse) AVR nur rund 500kHz zu verabeiten hat. Wegen des MAXs: meine obige 'Stummelbezeichnung' sollte MAX961 heißen, der in die gleiche Gruppe wie der MAX999 fällt. Der 961 hat einen separten /Q-Ausgang, womit die Erzeugung einer Hysterese unabhängig vom Q-Ausgang möglich ist. Da Du an einer Stelle den MAX999 einsetzt und am Eingang den ADCMP600 war ich irritiert, dass Du nicht den gleichen Typ verwendest. Daher meine Überlegung, warum der MAX999 nicht auch am Eingang sitzt. Meinen 961 bekomme ich für rund zweieinhalb Euro; die anderen Typen sind deutlich teuerer. Auf zufällige Musterlieferungen, wie Du sie bekommen hattest, würde ich nie setzen. Da bei Deiner Schaltung der DC-Anteil des Eingangssignals abgetrennt wird, könnte der Eingangskomparator doch auch massebezogen den Eingang und die Hysterese verarbeiten. Beim ADCMP600 sieht das Datenblatt so aus, als würde das Teil mit 3Vcc schneller laufen. Hast Du das mal probiert? Noch ein Punkt: die gekappten 1Vss vom TCXO lassen sich recht günstig mit einem 74LVC1G04 als AC-Inverter aufbereiten; Du merkst, ich bin ein Geizhals :-) Nach den vielen Worten möchte ich auf die Weiterentwicklungen bei mir verweisen: http://www.mino-elektronik.de/fmeter/neue_versionen.htm Wenn die Tage kürzer werden, wird es neben mehr Erläuterungen noch eine Eingangstufe mit Abschwächer geben, die von DC bis xxMHz arbeitet und mit +5V auskommt. Ich hoffe, das aus 'xx' noch 'xxx' werden kann :-)
m.n. schrieb: > der (böse) AVR Nee, die ATmega's und Konsorten sind nicht böse. Es ist nur so, daß diese Controller wie die meisten anderen eben keinen asynchron zum Prozessortakt betreibbaren Zähler bzw. Vorteiler haben, sondern alles, was an irgendeinen Zähleingang kommt, mit dem internen Takt synchronisieren. Deshalb ist die maximale Zählfrequenz um den 'Jitterbetrag' niedriger als die halbe interne Taktfrequenz. Bei neueren Chips, z.B. den diversen ARM's hat es intern ne PLL und die Dinger laufen intern meist mit dem Vielfachen der äußeren Quarzfrequenz. Deshalb können sie ihren eigenen Quarztakt selber zählen. Aber die ATmegas können sowas nicht mangels interner PLL. Da ist man eben auf einen zusätzlichen IC angewiesen, der die Vorteiler enthält. Wenn man den sich spendieren will, dann ist allerdings fast jeder x-beliebige uC für dieses Projekt geeignet. Bloß wozu, wenn doch ein billiger kleiner PIC die Sache ohne zusätzlichen Aufwand bereits erledigt hat? Und wegen der Muster: Ich kann bei Farnell und Konsorten einkaufen, das ist nicht MEIN Problem. Ich wollte allerdings hier was ganz anderes tun, nämlich möglichst mit Teilen auskommen, die man sich auch als armer Student oder Küchentischbastler besorgen kann. Deswegen die ganze Kniebeuge mit Muster schnorren, per Ebay die TCXO's einkaufen, bei TME die Gehäuse und Pollin das Display... und so weiter. Mit Teilen, die stinketeuer sind oder die es nur für Firmen gibt, kann ja jeder Laffe herumprahlen, sowas finde ich albern und für diejenigen, die hier mitlesen, um einen (geistigen) Nutzen aus diesem Forum zu ziehen, eher abstoßend und unpädagogisch. Andererseits ist ein Herumwurschteln in veralteten Strukturen und ollen Bauelementen auch nicht gut, denn es bildet nicht und ist rückwärtsgewandt - ich denke da an Controller in DIL Gehäusen auf Stecksockeln, diskret aufgebaute Eingangsstufen, 7-Segment LED-Anzeigen usw. Im Moment bereite ich ne andere Sache vor, einen 'besseren' Zähler, aus dem mal ein richtiger Laborzähler werden soll. Der Aufwand wird ein bissel größer werden, denn ich will so etwa folgende Eckpunkte realisieren: - wenigstens 8 gültige Stellen (nen OCXO dafür hab ich bereits) - niederfrequenten Zähleingang von 0 bis ca. 400 MHz mit 1M//20pF, so daß man einen üblichen Oszi-Tastkopf dranstecken kann (Schaltung bereits weitgehend erprobt und läuft bis 160MHz ohne Abfall) - zweiter Eingang mit 50 Ohm und bis 10 GHz. - Anzeige per monochromem Grafik-LCD (um von den elenden Alpha-LCD's wegzukommen) Eine Probierhardware mit LPC2103 und Xilinx Coolrunner ist schon fertig aufgebaut, aber ich werde wohl frühestens im Winter zum echten Anwerfen kommen, denn ich hab noch einige andere Projekte auf Kiel liegen. W.S.
W.S. schrieb: > nämlich möglichst mit Teilen auskommen, die man sich auch als armer > Student oder Küchentischbastler besorgen kann. > Andererseits ist ein Herumwurschteln in > veralteten Strukturen und ollen Bauelementen auch nicht gut, denn es > bildet nicht und ist rückwärtsgewandt - ich denke da an Controller in > DIL Gehäusen auf Stecksockeln, diskret aufgebaute Eingangsstufen, > 7-Segment LED-Anzeigen usw. Aber diese 'ollen Bauelemente' werden doch gerade von 'Küchentischbastlern' gerne verwendet. Ihnen sollte man daher auch entgegenkommen, wenn die Schaltung kein Unikat bleiben soll. Für mich war das ein Grund, auch ein neues Layout noch mit einem DIL20 µC auszustatten, obwohl ein SO-Gehäuse möglich (und kostengünstiger) gewesen wäre.
m.n. schrieb: > Ihnen sollte man daher auch > entgegenkommen, wenn die Schaltung kein Unikat bleiben soll. Nö. Sowas sehe ich wieder mal ganz anders. Kann ja sein, daß man jemandem, der es nicht besser weiß, scheinbar entgegenkommt, aber das hat bei dem Betreffenden keinen Lerneffekt, bringt kein Vorwärtskommen und keinen ideellen Wert. Woran soll jemand denn lernen, wenn nicht an einem Beispiel, das ihn fordert? Ich glaube, du ärgerst dich innerlich über deine Kniebeuge, Kraft in eine unoptimale Sache gesteckt zu haben, bloß um Lob von Leuten zu bekommen, die nicht dazulernen wollen. Meine Sachen entwickele ich selber und für mich und wenn jemand dran teilhaben will, dann geb ich's gerne, aber Abstriche wider besseres Wissen mach ich nicht. W.S.
@W.S. Welchen Vorteil hat die extra Tor-schaltung gegenüber einer Lösung die ohne auskommt?
> Andererseits ist ein Herumwurschteln in > veralteten Strukturen und ollen Bauelementen auch nicht gut, denn es > bildet nicht und ist rückwärtsgewandt - ich denke da an Controller in > DIL Gehäusen auf Stecksockeln, diskret aufgebaute Eingangsstufen, > 7-Segment LED-Anzeigen usw. Es kann aber je nach persönlichem Geschmack viel Spass machen, und um nichts anderes sollte es dem geneigten Amateur gehen.
ralf schrieb: > Welchen Vorteil hat die extra Tor-schaltung gegenüber einer Lösung die > ohne auskommt? Eine Lösung, die ohne Torschaltung auskommt, gibt es nicht - und zwar aus Prinzip. Man muß eben IMMER für eine gewisse Torzeit die Eingangsimpulse oder für eine gewisse Anzahl Perioden der Eingangsimpulse die Referenz zählen - und dazu braucht es eine Torschaltung. So isses. und an rackandboneman: Ja, es ist ein Unterschied zwischen Spaß haben am Herumbasteln oder Basteln und was dabei dazulernen. Ich hab da ein Beispiel: Ich hatte früher alte Radios ausgeschlachtet, um mir z.B. nen Wienbrücken-Sinusgenerator a la Heathkit zu bauen - und mein Schwager hatte seinen Spaß daran, die Elkos aus alten Radios auszubauen, mit langen Litzen an 220V zu hängen und sich drüber zu freuen, wie doll die Dinger dann explodiert sind. Das ist der Unterschied. W.S.
W.S. schrieb: > Eine Lösung, die ohne Torschaltung auskommt, gibt es nicht - und zwar > aus Prinzip. Man muß eben IMMER für eine gewisse Torzeit die > Eingangsimpulse oder für eine gewisse Anzahl Perioden der > Eingangsimpulse die Referenz zählen - und dazu braucht es eine > Torschaltung. So isses. Na wenn du dir so sicher bist, muss ich doch mal etwas schelmisch nachfragen: Wo ist die Torschaltung bei modernen Zählern, die mit Zeitstempeln arbeiten, versteckt? http://mwrf.com/Files/30/12529/Figure_03.gif aus http://mwrf.com/Articles/Index.cfm?ArticleID=12529&pg=2 gibt eine kurze Übersicht.
http://mwrf.com/Files/30/12529/Figure_03.gif Der Block "Synchronization and control logic" erzeugt den Torimpuls. Zähler 1 zählt die Eingangsfrequenz solange dieses Signal 1 ist, also Frequenzmessung. Zähler zwei zählt die Perioden der Referenz solange das Eingangssignal 1 ist, also Periodendauermessung. Der Interpolator misst den Versatz zwischen der Flanke des Eingangssignals und der Flanke des Zeitbasissignals. Damit kann man die Auflösung auf einen Bruchteil der Periodendauer der Zeitbasis bzw. der Eingangsfrequenz erhöhen.
Dennis S. schrieb: > ... gibt eine kurze Übersicht. Dank Dir Dennis, denn jetzt habe ich erfahren, dass ich Zeitstempelzähler entwickelt habe. Bislang hatte ich die Eigenschaft immer als 'kontinuierliche Messung' bezeichnet. Ab sofort mache ich nur noch 'Time-Stamping-Counter'; das klingt doch richtig wichtig :-)
m.n. schrieb: > Dank Dir Dennis, denn jetzt habe ich erfahren, dass ich > Zeitstempelzähler entwickelt habe. Bislang hatte ich die Eigenschaft > immer als 'kontinuierliche Messung' bezeichnet. Ich freue mich immer, helfen zu können. ;) > Ab sofort mache ich nur noch 'Time-Stamping-Counter'; das klingt doch > richtig wichtig :-) Ja, die Zähler werden auch so beworben: Continious Time-Stamping Counter Und das „kontinuierlich“ ist auch wichtig: Denn du hast deswegen halt keine Totzeit wie bei den normalen Zählern mit Torzeiten. Genau das meine ich wohl damit: Dass das Eingangssignal halt nicht mit einem Tor zugemacht wird. Ja, vielleicht ist der Interpolator nicht allzeitbereit und lässt mal ein paar Impulse durchgehen. Da könnte man in der Tat von einem Tor reden, aber das Eingangssignal wird ja weiterhin mit Zeitstempeln versehen.
W.S. schrieb: > Eine Lösung, die ohne Torschaltung auskommt, gibt es nicht - und zwar > aus Prinzip. Man muß eben IMMER für eine gewisse Torzeit die > Eingangsimpulse oder für eine gewisse Anzahl Perioden der > Eingangsimpulse die Referenz zählen - und dazu braucht es eine > Torschaltung. So isses. Du sagst also das es diese Lösung aus Prinzip nicht gibt: Beitrag "Re: PIC - Frequenzzähler weit über 50 MHz auf die minimalistische Art" Denk nochmal darüber nach.
Eine Schaltung für die Torfunktion braucht man im Prinzip schon. Bei der Methode mit den Zeitstempeln (ggf. auch in der einfachen Form mit nur Zeiten wie im Plan oben mit dem Mega88) für Start und Stop übernimmt die Synchronisation mit dem Takt die Funktion. Man braucht die Funktion schon kann da aber auf schon µC interne Teile Zurückgreifen. Das ist aber nicht auf die AVRs begrenzt, sondern geht genau so gut mit einem PIC. Den kleinen Vorteil den man durch die externe Torschaltung hat, ist das man die Zahl der Perioden die man zum Zählen nutzt frei Wählen kann. Mit nur einem Vorteiler ist man da etwas eingeschränkt auf Vielfache des Vorteilers. Wirklich wesentlich ist die Einschränkung aber nicht, nur die Zeit über die gemittelt wird entspricht damit vielleicht nicht ganz so gut der Vorgabe. Ob man aber einen Wert jede Sekunden, oder satt dessen etwa alle 1,01 s bekommt ist meist egal.
Ich denke wenn kontinuierlich gezählt wird kann nicht wirklich von einer Torfunktion gesprochen werden.
Ulrich schrieb: > Eine Schaltung für die Torfunktion braucht man im Prinzip schon. Wenn bei meiner Schaltung ein Tor drin wäre, wüßte ich es :-) Ein Tor gäbe doch nur dann einen Sinn, wenn es mal offen und mal geschlossen wäre. Aber ein geschlossenes Tor würde die Zeitmessung unterbrechen und eine kontinuierliche Messung verhindern.
Angehängte Dateien:
-
FMeter88-OCXO.jpg
76 KB -
FMeter88-Anzeige.jpg
44 KB
W.S. schrieb: > Im Moment bereite ich ne andere Sache vor, einen 'besseren' Zähler, aus > dem mal ein richtiger Laborzähler werden soll. Der Aufwand wird ein > bissel größer werden, ... Wozu der ganze Aufwand mit Kaltläufer und einem ARMen Prozessor? Es geht doch auch mit einem ATmega88, wie man sehen kann. Was man sieht, misst von 5mHz - 200MHz. Ein weiterer Vorteiler ist kein Problem: 'minimalistisch', wenn man so will :-) Was man nicht sieht, dass das Programm noch Drehzahl- und Ereignismessung beherrscht und per RS232 bedienbar ist. W.S. schrieb: > Ich glaube, du ärgerst dich innerlich über deine Kniebeuge, Kraft in > eine unoptimale Sache gesteckt zu haben, bloß um Lob von Leuten zu > bekommen, die nicht dazulernen wollen. Ach, das sehe ich ganz anders. Die Leute, die immer noch meinen, eine Torzeit sei Pflicht, melden sich doch garnicht. Und die Anderen sind einfach nur zufrieden. Kein Grund, mich zu ärgern.
"Hey, wo ist meine Torzeit abgeblieben?... :-) " So, jetzt hab ich mir mal das ganze Zeugs von m.n.'s Zeitstempelcounter angesehen. Soweit ich das sehe, funktioniert der Kram so: 1. sowohl Fin als auch Fref werden kontinuierlich von jeweils einem Zähler gezählt. Diese Zähler laufen natürlich alle Nase lang über, weswegen sie so groß sein müssen, daß ein uC, der ständig dort draufschaut, mit dem Draufschauen hinterher kommt. 2. am Zähler, der Fin zählt, hängt ein schneller RAM mit seinen Adreßbeinen. In diesen RAM wird mit jedem Impuls von Fin der aktuelle Zählerstand von Fref eingetragen. Wenn's mit Fin zu schnell sein sollte, dann kann man es auch so halten, daß nur jeder 2. oder 4. oder oder 8. .... 256. Impuls von Fin zum Schreiben in's RAM benützt wird, man also quasi einen Vorteiler benutzt. 3. Die Abtastung von Fref muß natürlich irgendwie mit Fin synchronisiert werden, damit man beim (zu Fin synchronem, zu Fref aber unsynchronem) Schreiben ins RAM keinen Müll hineinbekommt. 4. Die eigentliche Frequenzmessung macht man so, daß man zwei hinreichend weit auseinanderliegende Stellen im RAM liest, die Differenz der dort stehenden Werte (die ja die zugehörigen Zählerstände von Fref enthalten) unter Berücksichtigung der evtl. dazwischen liegenden Überläufe bildet und beides (Abstand und Differenz) ins Verhältnis setzt. Prinzip im Groben: Ergebnis = ( Adressdifferenz im RAM / Wertedifferenz im RAM ); Das Ganze ist damit wieder ein klassischer Reziprokzähler und die Torzeit ist rein softwaremäßig gemacht. Sie ist die Differenz der Adressen der zwei ausgewählten Stellen im RAM. Die Torzeit steckt also im Programm. SO, da haben wir's. Beim klassischen Reziprokzähler wird die Torzeit mit Hardware gemacht und sitzt direkt vor allen beteiligten Zählern. Deswegen können alle anschließenden Zählstufen irgendwie sein, also so asynchron wie sie wollen, auch als Ripplecounter. Wenn das Tor zu ist, hat man ja genug Zeit, bis daß sich alles ausgerippelt hat und die finalen Zählerstände vorliegen. Beim Zeitstempelcounter ist das GANZ anders. Der setzt voraus, daß man zu bestimmten Zeitpunkten (den Sample-Zeitpunkten) exakt in allen Bits gültige Zählerstände für exakt DIESEN ZEITPUNKT hat, sonst kriegt man Garbage in den RAM. Was kann man erwarten? a) Da uC, RAM, Fin-Counter und Fref-Counter alle zueinander synchron laufen müssen, damit nicht an irgendeiner Stelle Garbage entsteht, hängt einiges davon ab, wie schnell, das heißt mit welcher Synchronisierfrequenz der ganze Aufbau betrieben werden kann. Höhere Frequenzen brauchen also einen ausreichend großen Vorteiler, aber niedrigere Frequenzen können ihn garnicht gebrauchen. Man will ja bei 50 Hz nicht 5.12 Sekunden auf's nächste Ergebnis warten.. Fazit: man braucht je nach Fin unterschiedliche Vorteiler von 1:1 bis (weiß der Kuckuck). Finde ich nicht angenehm, daß man dem Zähler vorher sagen muß, was er zu erwarten hat. b) Als Raster bleibt nach wie vor das Verhältnis von Meßzeit zur Periodenzeit von Fref. Innerhalb der (softwaremäßig gewählten) Torzeit kann der Fref Zähler ja nur soviel Impulse zählen, wie der Referenzoszillator ihm liefert. Wer oberschlau ist, meint vielleicht, daß man durch Mittelwertbildung aus einer Anzahl von Paaren an gewählten Stützstellen im RAM noch eine Stelle dazugewinnen könnte, aber das erscheint mir trügerisch, da es sich in jedem Fall um diskrete Referenzwerte handelt und das Bit, was per Jitter bei einer Stützstelle fehlt, bei der anderen zuviel ist. Ergibt in Summe wieder das, was ohnehin bekannt war. Hab's aber noch nicht durchgerechnet. Die Kommerziellen haben parallel zu den 2 Zählern auch noch eine analoge Phasenmessung von Fref, deren Ergebnis ebenfalls im besagten RAM gespeichert wird. Damit hat man allerdings etwas, mit dem man die Auflösung des Zählers wirklich erhöhen kann, denn damit hat man eine größere Auflösung für Fref als es die bloße Zählrate hergeben würde. Fazit: ohne analogen Phasenkomparator bleibt die Auflösung auf das beschränkt, was der verwendete uC als Referenz zählen kann. Bei angenommen 1 Sekunde Torzeit und 10 MHz Referenz also etwa 7 Stellen. Aber das ist ja auch ganz ordentlich und liegt schon über den Werten, die man mit einem einfachen TCXO so erreicht. c) Ich hab mir auch mal m.n.'s Schaltung mit einem ATmega48 angesehen: Fin geht an einen Vorteiler 1:256 und an PD7 (entweder Port oder PinChange-Interrupt) Der Ausgang des Vorteilers geht an PB0 (Port oder Counter 1 Capture Input oder PinChange-Interrupt) und an PD4 (Port oder Timer 0 Count Input). Eine Hardware-Umschaltung des Vorteilers gibt es nicht, also nehme ich an, daß die Fin-Counterei für niedrige Frequenzen per Interrupt gemacht wird. Nun, man kann es so machen wenn man will. Mein Fall ist das nicht, denn es führt zu einer ziemlichen Softwareakrobatik durch die anfallenden Positions- und Überlaufkalkulationen und die Notwendigkeit, je nach Eingangsfrequenz den Vorteiler umzuschalten (und sei es nur von 1:1 auf 1:256 und zurück). Dazu kommt, daß mit diesem Verfahren die Auflösung auch nicht größer ist als das, was ein einfacher Reziprokzähler hergibt, da der analoge Phasenmesser und damit die feinere Auflösung von Fref fehlt. Irgendwie empfinde ich diese Zeitstempelei so ähnlich wie den LCD-Controller mit nem ATmega, den hier jemand mal vorgestellt hat. Ein Software-Kunstwerk und sehr rühmlich, sowas tatsächlich der Welt mal demonstriert zu haben, aber nix für mich. Prinzipiell ist dieses Zeitstempel-Verfahren ausbaubar, aber dazu müßte man das Ganze in ein FPGA verfrachten, damit man sowohl schnelle Logik als auch schnellen und saubreiten RAM hat, obendrein wäre der analoge Phasenmesser angesagt, kurzum, man müßte alles ganz anders machen und es wird verdammt aufwendig. Ich denke mal, als Bastler kommt man einfacher zum Ziel, wenn man einen simpleren Reziprokzähler baut und ihn mit einer Referenzfrequenz von 100..400 MHz betreibt (je nachdem, was man sich als Oszillator beschaffen kann und was die verwendete Logik im konkreten Fall so hergibt). W.S.
W.S. schrieb: > Das Ganze ist damit wieder ein klassischer Reziprokzähler > und die Torzeit ist rein softwaremäßig gemacht. Man kann es so programmieren wenn man möchte aber es besteht auch die Möglichkeit die Auflösung zu erhöhen. aus dem Link von Dennis S. http://mwrf.com/Articles/Index.cfm?ArticleID=12529&pg=2 > By applying a well-known statistical method—linear regression—it is > possible to improve the resolution of the line's inclination (the > time of the measurement period) by a factor of (N)0.5/2.4, where N > is the number of measurement points during a given measurement time. > For example, with 1000 points, the resolution is improved by a > factor of (1000)0.5/2.4 = 31.622/2.4 = 13.176. (Fig. 5) and (Fig. 6) > show how the resolution (or uncertainty of the line's inclination) > can be improved through the application of linear regression > compared to startstop measurements (see sidebar). Bei entsprechender Programmierung kann so die Auflösung durchaus eine Zehnerpotenz besser sein als bei einem einfachen reziproken Frequenzzähler. Außerdem entfällt die extra Torschaltung.
Zugespitzt: Wenn man nur einen Reziprokzähler baut, dann muss man sich auch nicht wundern, wenn man nur einen Reziprokzähler bekommt. Wenn ich nämlich so etwas lese (frei rausgegriffen): > a) Da uC, RAM, Fin-Counter und Fref-Counter alle zueinander synchron laufen > müssen, Dann zweifle ich schon ein wenig, was für ein Zähler hier erdacht wurde. Denn jeder Eingang (auch die Referenz ist nur ein Eingang, zur Symmetrierung des Problems) hat seinen eigenen, zum Eingang synchron laufenden Zähler. Dass man diese Zählerwerte auf ein Abtastsignal konsistent kopieren können muss, wurde richtig erkannt. Ja, mir ist es nicht gelungen, eine befriedigend detaillierte Beschreibung dieser Zeitstempelzähler zu bekommen. HP hat das in der frühesten Veröffentlichung, die ich zu dem Thema finden konnte, auch nur grob umrissen: http://www.hpl.hp.com/hpjournal/pdfs/IssuePDFs/1989-02.pdf (zero-dead-time-counter)
W.S. schrieb: > So, jetzt hab ich mir mal das ganze Zeugs von m.n.'s Zeitstempelcounter > angesehen. Soweit ich das sehe, funktioniert der Kram so: Du hast mit Scheuklappen auf ein Schaltbild gekuckt und dazu eine freie Fehlinterpretation erdacht. Mit einem kleinen Seitenblick hätte man die Beschreibung der I/O-Pins gefunden, und nachvollziehen können, wie einfach das Programm im Grunde gestrickt ist. Viele, viele Jahre habe ich gegen (verbissene) "Torzeitanhänger" argumentiert - meist ohne Erfolg. Ich muß das nicht mehr machen :-)
Dennis S. schrieb: > Wenn ich nämlich so etwas lese (frei rausgegriffen): > >> a) Da uC, RAM, Fin-Counter und Fref-Counter alle zueinander synchron laufen >> müssen, > > Dann zweifle ich schon ein wenig, was für ein Zähler hier erdacht wurde. Hallo Dennis, ja, ich schließe mich deinem Zweifel an. Wenn man gültige Werte in den besagten schnellen RAM bekommen will, dann muß man dafür sorgen, daß die Zeitstempelwerte sich genau zum Abtastzeitpunkt nicht gerade ändern. Also muss man den zum Eingangssignal ja asynchron laufenden Referenzzähler irgendwie so mit dem Eingangssignal synchronisieren, daß er zum Abtastzeitpunkt nicht gerade umschaltet oder daß dessen Umschaltung keinen Müll erzeugt. Das wirklich sauber hinzukriegen, ist sicherlich schwierig, ich denke gerade an Gray-Code-Zähler oder so, wo sich definitiv immer nur nur 1 Bit ändert. m.n. hat es aber ganz anders gemacht, dort sind die Abtastzeitpunkte NICHT synchron zu Fin, sondern synchron zu Fref, denn der ATmega synchronisiert ja das Signal an seinem Zähleingang mit seinem Systemtakt. Ein "echter" Zeitstempelzähler ist das also nicht. m.n. muß daher bei seinem 20 MHz Takt mit 2 Zeitunsicheheiten rechnen: 50 ns für den ersten Samplepunkt und nochmal 50 ns für den letzten. Effektiv arbeitet er also mit einer Rasterung von 100 ns oder anders gesagt 10 MHz effektiver Referenzfrequenz. und nochwas: > By applying a well-known statistical method—linear regression... Sowas geht nur, wenn man in die Rechnung die Ergebnisse eines analogen Interpolators einbezieht, also Bruchteile der Referenzperiode in den Samplepunkten zur Verfügung hat. Das ähnelt dem Verfahren, bei einem ADC noch ein Bit herauszuholen, indem man etwas Rauschen auf das zu messende Signal gibt und dann den Mittelwert aus N ADC-Werten bildet. Aber m.n. hat ja sowas garnicht, denn letztendlich ergeben alle Teilsummen seiner Fref immer Integerwerte und zusammen sind sie die Torzeit mit einer endlichen Anzahl Bits. W.S.
W.S. schrieb: > denn der ATmega > synchronisiert ja das Signal an seinem Zähleingang mit seinem > Systemtakt. zum Glück! Dadurch spare ich dann ein externes D-FF zur Synchronisierung. Ich will mal ganz ehrlich sein: Fin und Fref beachte ich garnicht! Ich verwende den internen RC-Oszillator und betreibe damit einen Zufallszahlengenerator :-) :-) :-) @W.S. Soll man Dich noch ernst nehmen?
m.n. schrieb: > Du hast mit Scheuklappen auf ein Schaltbild gekuckt und dazu eine freie > Fehlinterpretation erdacht. Mit einem kleinen Seitenblick hätte man die > Beschreibung der I/O-Pins gefunden, und nachvollziehen können, wie > einfach das Programm im Grunde gestrickt ist. > Viele, viele Jahre habe ich gegen (verbissene) "Torzeitanhänger" > argumentiert - meist ohne Erfolg. Ich muß das nicht mehr machen Nanana, mein lieber, anstatt derart ausfällig zu werden, hättest du dein Projekt mal sachlich darstellen können. Also ne Beschreibung des Prinzips, dazu vielleicht noch eine Skizze oder Blockschaltbild und eine Beschreibung, wie du es konkret umgesetzt hast und dann das Ganze als PDF hier gepostet, damit man es sich in Ruhe durchlesen kann. Das wäre viel besser gewesen als herumzumotzen. Ich hab mir ja auch die Mühe gemacht, meine Gedanken beim Entwickeln darzustellen und meine Gründe dafür, wie ich es gemacht hab, offenzulegen. Sowas kann man dann sachlich diskutieren und sich über das Für und Wider diverser Details streiten. Ich für meinen Teil hab nicht mit Scheuklappen auf ein Schaltbild geschaut, sondern genau DAS mir so gründlich wie nur möglich angesehen, was du gepostet hast. Mehr hab ich (und all die anderen, die hier mitlesen) nämlich nicht zur Verfügung und was du innerhalb Controller machst hast du niemandem gezeigt. Also ist es nur natürlich, daß man mit Schaltbild und PDF von Atmel nachschaut, was sich hinter diesen Pins abspielen könnte. Ja, das ist schlichtweg vermutet und nicht gewußt. Wenn du - wie du schreibst - schon jahrelang gegen verbissene Torzeitanhänger vergeblich argumentiert hast, dann wäre es vielleicht bedenkenswert, sich mal ganz sachlich zu fragen, woran das liegen könnte. Entweder hast du ein schlechteres Konzept als diese Torzeitanhänger oder du hast es nicht geschafft, die Vorzüge deines Konzeptes all den anderen begreiflich zu machen. In beiden Fällen könntest du was tun, aber es liegt an dir und an niemandem sonst. Im ersteren Falle wäre ein Überdenken des Konzeptes angeraten und im anderen eine bessere Darstellung. Alle anderen irgendwann mal für blöd zu erklären und sich bockig zu haben nützt nix. Mich hast du jetzt auch nicht überzeugen können, denn ich halte es schlichtweg für einfacher und geradliniger (und genau deshalb besser), all die Dinge, die wirklich schnell sein sollen, mit Hardware zu machen - und zwar mit der schnellsten, die ich kriegen und benutzen kann. So, und nochmal zu dem Link von Dennis S. http://mwrf.com/Articles/Index.cfm?ArticleID=12529&pg=2 Ich habe das sehr bestimmte Gefühl, daß die Jungs dort auch bloß nicht die ganze Wahrheit geschrieben haben. Das mit dem schnellen RAM (in Figure_03.gif) kommt mir verdächtig vor. Wahrscheinlicher dürfte folgender Ablauf sein: (auch wieder nur ne Vermutung) 1. der uC setzt ein "arming" Signal, wenn er wieder mal einen Meßpunkt haben will. 2. bei der nächsten Zählflanke von Fin speichert eine mit dieser Flanke getriggerte Logik den aktuellen Stand des Fin-Zählers in einem Register, setzt das "arming" des uC zurück, setzt ein zweites "arming" Signal und startet einen analogen Rampengenerator. 3. bei der nächsten Zählflanke von Fref stoppt eine mit der Zählflanke von Fref getriggerte Logik den Rampengenerator, setzt das zweite "arming" Signal zurück, speichert den aktuellen Stand des Fref-Zählers in einem anderen Register und setzt ein "fertig" Signal. 4. Sobald der uC das "fertig" Signal sieht, merkt er sich in aller Ruhe die beiden aktuellen Registerinhalte, mißt die Höhe der Rampe und speichert auch sie. Damit hätten wir dann einen Meßpunkt und nach einer (willkürlich wählbaren) Zeit kann das Spielchen wieder stattfinden und den nächsten Meßpunkt ergeben. So hat man dann so viele Meßpunkte wie man haben will und kann in aller Ruhe damit herumrechnen. Jeder Meßpunkt enthält den Stand von Fin sowie den letzten Stand von Fref und die Höhe der gemessenen Rampe. Bedingung: man braucht für beide Zähler Synchronzähler und zwar voneinander unabhängigie - in einem CPLD keine unüberwindliche Hürde - im krassen Gegensatz zu meinem armen kleinen PIC, der ja nur einen Ripplecounter als Vorteiler hat. W.S.
Sowohl die AVRs als auch die PICs haben schon viel Hardware drin, die man für das Zählen nach der Time Stamp Methode nutzen kann. Beim AVR heißt die Einheit Input Capture, beim PIC Capture/Compare. Dabei hat der PIC sogar einen kleinen Vorteil, denn da hat man einen internen zuschaltbaren Asynchronen Vorteiler (:16 oder :4). Zum Ausgleich ist der AVR vermutlich etwas schneller beim verarbeiten der Daten. Eine Voraussetzung dafür ist, das der µC mit dem Ref-Takt betreiben wird, was aber keine größeres Problem ist. Der Überlauf des 16 Bit Timers erfordert tatsächlich ein wenig Programmierkunst, um da das richtige Ergebnis zu bekommen. Wenn man weiss wie es geht ist es aber nicht so aufwendig. Bei der low cost Version direkt im µC wird das "schnelle RAM" für die Zeiten durch das µC Programm ersetzt und halt wenn nötig das Eingangssignal per Vorteiler so weit reduziert das der µC noch mit kommt. Beim AVR liegt das Limit bei ca. 100 kHz - 500 kHz je nachdem was man in Echtzeit so mit den Daten noch macht. Die Zählung des Eingangssignals erfolgt dabei rein in Software. Für die üblichen Torzeiten im Bereich 0,1 s bis 1 s (oder länger) ist die Umschaltung des Vorteilers nicht so kritisch. Wenn der µC 200 kHz verarbeiten kann, kommt man mit einem Teiler von 256 oder ggf. 512 aus. Für höhere Frequenzen ( >100 MHz) hat man in der Regel eine extra Eingangsstufe mit festem Vorteiler. Mit einem Vorteiler von 512 kann man auch bei einer Frequenz von 10 kHz noch einigermaßen messen. Man hat also ein großen Fenster wo es mit und ohne Vorteiler noch geht. Eine zu hohe Frequenz für die Messung ohne Vorteiler kann man auch sehr schnell (Größenordnung < 1 ms) erkennen und dann mit dem Vorteiler messen. Mit analoger Interpolation wäre das einfache Verfahren vermutlich auch ein umschaltbarer Vorteiler. Die Eingangsfrequenz wird so weit runter geteilt (Potenzen von 2 oder 4) bis der µC mit dem Verarbeiten der Flanken nachkommt. Der grobe Teil der Zeit wird dann aus den Timer Capture Registern ausgelesen, und für den feinen Teil der AD Wandler genutzt. Dadurch das immer eine konstante Zahl an Flanken dazwischen ist, vereinfacht sich die Rechnung so dass man ggf. schon während der Messung rechnen kann. Die analoge Interpolation würde ich nicht überbewerten, denn die setzt eine sehr gute Eingangstufe voraus. Dagegen hilft der zusätzliche Gewinn an Auflösung durch die lineare Interpolation der Zeiten unabhängig von Jitter im Signal. Man wird bei einem Signal mit nennenswertem Jitter damit zwar keine 8 statt 7 Stellen bekommen, aber halt mehr Auflösung als ein noch so fein auflösender Reziprokzähler mit Interpolation.
W.S. schrieb: > hättest du dein Projekt mal sachlich > darstellen können. Also ne Beschreibung des Prinzips, W.S. schrieb: > So, jetzt hab ich mir mal das ganze Zeugs von m.n.'s Zeitstempelcounter > angesehen. Offensichtlich hast Du Dir das Zeugs doch nicht angesehen: http://www.mino-elektronik.de/fmeter/fmeter.htm ist uralt. http://www.mino-elektronik.de/fmeter/neue_versionen.htm Zeigt den aktuellen Stand. Dazu gibt es Beispielprogramme und .HEX-Dateien zum Download: http://www.mino-elektronik.de/download/fmeter20.zip Bei Dir muß man sich ja den HEX-Code aus einem Listing abtippen :-( Ferner gibt es ein Datenblatt zu den ATmegas. Zumindest einen Teil dieser Quellen hättest Du beachten müssen, um unqualifizierte Kommentare zu vermeiden.
Aktuell habe ich einen Vorschlag für eine Eingangsstufe eingestellt, die im Prinzip der weiter oben gezeigten Schaltung entspricht. Beitrag "Eingangsstufe für Frequenzzähler DC-50MHz, +5V" Das Hauptaugenmerk liegt dabei auf 'DC' statt 'GHz', um sehr kleine Frequenzen zu messen oder Ereignisse zu zählen. Ferner habe ich ein Programmbeispiel für eine Drehzahlmessung in die Codesammlung gestellt, die auf einer torzeitlosen Frequenzmessung (natürlich mit einem AVR :-) beruht: Beitrag "einfache Drehzahlmessung mit ATmega88" Auch ohne große Programmierkenntnisse wird deutlich, dass es keinerlei Verrenkungen bedarf, um Zeiten und Ereignisse richtig zu verrechnen. Das wollte ich abschließend noch klarstellen :-)
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.