Hi, ich bastel an einem Frequenzzähler. Aus folgenden Gründen möchte ich den internen AVR-Timer nicht nutzen: - zu Langsam (max. 20mhz/2) - nur 16 bit (lange messzeit erhöht den Softwareaufwand) -> Daher habe ich mich entschieden einen 32 bit zähler aus ttl bausteinen diskret aufzubauen. Auf einigen threads hier im Forum habe ich nun herausgelesen, das sich der hc590 von nxp nur bis maximal 16 bit kaskadieren lässt. Der baustein ist ausserdem nur bis max. 50 mhz Meine Fragen: 1) Welche Logikreihe kann ich bis 100mhz nutzen? (zur Not würde ich einen 1/2 Teiler vorsetzen und damit auf die Meßgenauigkeit bei >50mhz verzichten) 2) Hat jemand eine Schaltung oder Vorschlag wie ich einen zuverlässigen zähler realisieren könnte? Niedriger Schaltungsaufwand ist dabei weniger wichtig.
Basti schrieb: > 1) Welche Logikreihe kann ich bis 100mhz nutzen? 100 mHz sind doch kein Problem. Man muß nur darauf achten, daß alle Stufen DC-gekoppelt sind. Und wer 100 MHz messen will, kann den 74VHC4040 nehmen. Beide Frequenzen kann man mit sehr hoher Auflösung messen: reziproker Frequenzzähler. Sag mir doch welchen Link ich Dir geben soll. Für AVR-Studio, Arduino oder BASCOM? Für STM32F407-Fans gibt es sogar 8-stellige Werte 2 x pro Sekunde.
Hallo, hier ist ein fertiges Projekt: * 400-MHz-Frequenzzähler nach dem Reziprokverfahren (2) Rudolf Faulhaber, DC2YFFA 1/2012, S. 40 * 400-MHz-Frequenzzähler nach dem Reziprokverfahren (1) Rudolf Faulhaber, DC2YFFA 12/2011, S. 1283 http://www.funkamateur.de/
Basti schrieb: > Aus folgenden Gründen möchte ich den internen AVR-Timer nicht nutzen: > - zu Langsam (max. 20mhz/2) > - nur 16 bit (lange messzeit erhöht den Softwareaufwand) > > -> Daher habe ich mich entschieden einen 32 bit zähler aus ttl > bausteinen diskret aufzubauen. Ein Zwischending wäre, einen 1/16-Vorteiler zu verwenden und dessen 4 Ausgangsleitungen über den AVR einzulesen.
Uwe S. schrieb: > hier ist ein fertiges Projekt: Und wo kann man die ansehen? Markus Weber schrieb: > Ein Zwischending wäre, einen 1/16-Vorteiler zu verwenden und dessen 4 > Ausgangsleitungen über den AVR einzulesen. Braucht man doch Alles garnicht: http://www.mino-elektronik.de/fmeter/fm_software.htm#bsp1
Angehängte Dateien:
-
counter.png
37 KB
aha. im Datenblatt steht zwar: A ripple carry output (RCO) is provided for cascading. Cascading is accomplished by connecting RCO of the first stage to CE of the second stage aber: Cascading for larger count chains can be accomplished by connecting RCO of each stage to the counter clock (CPC) input of the following stage. also sollte es sich wir im anhang verschaltet umsetzen lassen. naja kosten ja nurn euro pro stück. da werden wohl mal 4 stück fürs steckbrett fällig
m.n. schrieb: > Braucht man doch Alles garnicht: > http://www.mino-elektronik.de/fmeter/fm_software.htm#bsp1 Korrekt, aber ich ging davon aus, dass der TO keine "lange Messzeit" haben will, sonst hätte er ja gleich einfach so einen Vorteiler nutzen können. Wenn man z.B. alle 100 ms einen 10 Hz genauen Messwert haben will, bleibt nur, immer auch den Zählwert des Vorteilers auszulesen.
Externer 8-Bit Zähler reicht völlig. Referenzfrequenz so hoch machen wie möglich. Von den normalen 10 MHz aus würde sich ein Resonanzverstärker für 50 MHz anbieten. Dafür dann auch wieder ein externer 8-Bit "Vorzähler". Die '590 haben ein internes Register + Tri-State Ausgänge, können also auf einen 8-Bit-Bus geführt werden. Allerdings wird auch das noch deutlich langsamer sein als gute kommerzielle Zähler, die typ. höhere Referenzfrequenzen einsetzen (HP in den 70ern: 500(!) MHz, mit ECL-Logik) und/oder Poly-Phase Referenzen nutzten, was die effektive Referenzfrequenz vervielfacht. Z.B. vier Phasen je 300 MHz. Dazu kommt dann, dass kommerzielle Zähler idR Interpolationsschaltungen einsetzen, die die nochmal etwa 1-1.5 Digit/s Messgeschwindigkeit liefern.
:
Bearbeitet durch User
m.n. schrieb: > Uwe S. schrieb: >> hier ist ein fertiges Projekt: > > Und wo kann man die ansehen? Beim Funkamateur (PDF) und in der Printausgabe der Zeitschrift.
Aktuelle Zähler erreichen mit all dem zusammen eine Messgeschwindigkeit von so 11-12 digit/s.
Markus Weber schrieb: > Wenn man z.B. alle 100 ms einen 10 Hz genauen Messwert haben will, > bleibt nur, immer auch den Zählwert des Vorteilers auszulesen. Das ist aber eine sehr schwammige Aussage, die ich nicht unterstreichen kann. Was ist denn zum Beispiel 'genau'? Die Schaltung/Programm zu meinem Link liefert bei 20 Messungen/s 6-stellige Ergebnisse. Ob da nun ein Vorteiler dabei ist, ist ohne Bedeutung.
Die Methode der Wahl für einen Frequenzzähler ist heute ein Reziproker Zähler. Für hohe Frequenzen verliert man da durch einen Vorteiler nichts an Auflösung. Entsprechend reicht es wenn der µC selber die Reziproke Messung bis z.B. 10 kHz ausführen kann. Als schnellen Vorteiler gibt es z.B. U813 oder 74VHC4040 usw. Gemessen wird dabei die Zeit für eine Zahl an Perioden, die etwa der gewünschten Messzeit entsprechen. Die Zahl der Perioden wird einfach in Software gezählt. Ein Atmel AVR schaft das bis gut 100 kHz, und auch bei 100 Hz hat man noch keine merklichen Einschränkungen bei der Auswahl der Messzeit. Entsprechend darf die Umschaltung beim Vorteiler auch recht groß ausfallen, z.B. :1 oder 1:1024 für Frequenzen bis 100 MHz. Die Auflösung wird durch Messzeit und Timer Takt vorgegeben - beim 20 MHz AVR hat man nach 0,5 s bereits 7 Stellen. Wenn man mehr will, wäre ein schnellerer µC angesagt, der dann meist auch 2 Kanäle mitbringt, um auch kurze Zeiten ( < 5 µs) als Start - Stop messen zu können. Dazu wäre zu überlegen einen guten Ref. Takt zu besorgen, damit man auch die Genauigkeit stimmt und nicht nur die Auflösung.
Es ergibt eigentlich immer Sinn einen externen Referenzeingang vorzusehen. Den kann man auch problemlos mit nahezu jedem beliebigen Multiplexer auswählen, sind ja nur 10 MHz (üblicherweise). Ich persönlich sehe kaum einen Grund den Vorteiler nicht auszulesen. Die paar Leitungen bringen einen nicht um - gut man braucht einen Vorteiler bevorzugt mit eingebautem Register, aber die gibt es ja - und dafür bekommt man länger gleichbleibende Messgeschwindigkeit.
Marian B. schrieb: > Also etwa 7 1/3 digit/s. 20 MHz Referenz? Nach üblicher Lesart 7 1/2 Stellen, oder verständlicher 2 Messungen/s bei 7-stelliger Anzeige. Wie Lurchi schrieb: > Die > Auflösung wird durch Messzeit und Timer Takt vorgegeben - beim 20 MHz > AVR hat man nach 0,5 s bereits 7 Stellen. Ein STM32F407 kann mit 168 MHz Referenztakt laufen und liefert damit immer noch bessere Ergebnisse als ein torzeitgesteuerter Zähler. Beispiel: http://www.mino-elektronik.de/FM_407/fmeter_407.htm Wer mag, kann dazu eine unbestückte Platine bekommen.
Basti schrieb: > ich bastel an einem Frequenzzähler. Das ist recht und gut und immer wieder für jedermann ein nettes Projekt. Aber davor haben die Götter das Nachdenken gesetzt. Du hast erstmal nur von einem 32 Bit Zähler geschrieben, aber nix davon, welche Eckdaten du anstrebst. Also welche Auflösung, welche Meßgenauigkeit und so. Also bedenke: 1. Du brauchst eine Zeitbasis, auf die du dich verlassen kannst. der Quarz am µC ist für 100 ppm gut und wenn du es besser haben willst, sieh dich nach einem TCXO um oder nach einem OCXO. 2. Quarze gibt's in jeder Frequenz, TCXO's gibt es zumeist in Frequenzen, wie sie für Mobiltelefone und solch Zeugs gebraucht werden - und das sind oft genug relativ krumme Frequenzen im Bereich 12..14 MHz. OCXO's gelten als edelste Zeitbasis vor den "Echten" a la Rubidium. Deshalb ist dort die Frequenzauswahl eher bescheiden, am häufigsten 10 MHz. 3. Für eine möglichst hohe Auflösung brauchst du eben auch eine möglichst hohe Referenzfrequenz, da du ja letztlich 2 Integerzahlen durch einander teilen mußt. Wenn du nun schon Eingangssignale bis 100 MHz messen willst, dann sollte deine Referenzfrequenz eben auch in 100 MHz Bereich liegen. Also wäre da ein Takt-IC angesagt, ich kann die hier sowas wie CDCE913 von TI empfehlen, um aus 10 MHz Referenz einen genau so stabilen 100 MHz Takt zu erzeugen. 4. Du brauchst eigentlich 2 Zähler: einen, der den Input zählt und einen zweiten, der die Referenz zählt. Das macht man am besten mit einem CPLD. Mit einem kleinen Coolrunner von Xilinx kommst du spielend aus, die Dinger sind bis über 400 MHz gut. Da macht der Eingangs-Komparator schon eher Probleme. 5. Du brauchst ein Meßtor VOR jeglichen Zählern. Laß dir nicht den Kopf verwirren von Leuten, die zu Vorteilern und dergleichen raten. Das wäre Murks. Grund: Nur mit einem tatsächlich auf der höchsten Frequenz arbeitenden Tor kannst du synchron zum Eingangssignal (für Reziprokzähler) oder zum Referenztakt (Un-Reziprokzähler) das Zählen starten und stoppen. Leute, die sowas per Software in µC machen wollen, vergessen immerzu, daß ja sämtliche µC-internen Abläufe stets nur synchron zum Systemtakt (und nicht zum Eingangs-Signal) stattfinden - und der ist immer deutlich niedriger als die angestrebten 100 MHz. Das Abtast-Theorem läßt hier grüßen. 6. Es gibt eine Ausnahme von Punkt 5, nämlich die kleinen PIC's von Microchip. Denn die haben einen oder zwei asynchrone Vorteiler eingebaut, welche tatsächlich unabhängig vom Systemtakt zählen können. Trotzdem brauchst du auch bei denen ein davor gesetztes Tor. Also, gönne dir ein einfaches CPLD, einen ordentlichen TCXO, ein CDCExxx und einen ordentlichen Komparator für den Eingang (z.B. ADCMP600 oder so ähnlich) ein LVDS-Empfänger a la FIN1002 mir diskreter Hysterese-Erzeugung geht auch, damit wirst du am ehesten glücklich. W.S.
Wenn man das trotzdem diskret in Logik aufbauen will, reicht für das Tor ein einfaches AND/NAND und für die Torsteuerung ein J/K-Flipflop. Der Takt vom Flipflop ist dann entsprechend Eingangssignal oder Referenztakt.
W.S. schrieb: > 5. Du brauchst ein Meßtor VOR jeglichen Zählern. Laß dir nicht den > Kopf verwirren von Leuten, die zu Vorteilern und dergleichen raten. Das > wäre Murks. Ich mache es äußerst ungern, aber heute muß ich Dir glatt widersprechen ;-) Zwei Tore braucht man zum Beispiel beim Fußball, hier aber nicht. Die betreffenden Timer vom F407 laufen mit 168 MHz. Schnelle hochauflösende Messungen sind damit kein Problem. Und wie gesagt, Vorteiler stören nicht.
Hallo Leute :-(( Wer hat gesagt das ich den avr quarz als taktquelle nutzen will, oder nen ST controller? Mir ist klar das es bessere Wege gibt als den, den ich vorgeschlagen habe. Ich bedanke mich für die vielen vorschläge. ich habe mich bewusst für den o.g Weg entschieden - man muss doch nicht immer alles breittreten. Es waren doch zwei ganz simple fragen. Ich habe mich jetzt für eine kompromißlösung entschieden. Ich benötige keinen Zähler der 1 mal pro sekunde oder öfter mißt. Ich will langzeitmessungen vornehmen. und auch nicht 4 gleichzeitig, sondern 1 - und das möglichst akkurat. Die gate-Steuerung evtl per RB-Normal oder GPS oder DCF. Die Gatesteuerung wird nen programmierbaren vorteiler bekommen, das man mit der Gate-Quelle flexibel ist. Ich möchte auch nicht einfach n fertiges Projekt nachbauen. Ich ,möchte die Schaltung planen, ein Layout machen, und wenn ich irgendwelche abweichungen gegenüber meinem Labormeßgerät auf Arbeit feststelle durch messungen den Fehler finden. Nur so lernt man was. Nicht durch "so geht das nicht mach mal lieber so und so"
Warum so traurig? Du hast viele Hinweise und Vorschläge bekommen, das ist doch toll. Zum Thema, ich habe das Gefühl, dass du noch nicht ganz vertraut bist mit digitalen Frequenzmessverfahren. Daher hier ein Link: http://www.spectracomcorp.com/Desktopmodules/Bring2Mind/DMX/Download.aspx?EntryId=446&PortalId=0
74AC160, 74AC161, 74AC162 und 74AC163. Davon kannst Du Dir einen ausgucken. Eine Spezies zaehlt Dezimal, die andere Binaer. Dann unterscheiden sich beide noch im Uebertragsverfahren. Synchrone Zaehler sind alle Vier. Und die 100 MHz knacken natuerlich auch alle. Segor koennte vllt noch welche haben.
Basti schrieb: > Ich möchte auch nicht einfach n fertiges Projekt nachbauen. Ich ,möchte > die Schaltung planen, ein Layout machen, und wenn ich irgendwelche > abweichungen gegenüber meinem Labormeßgerät auf Arbeit feststelle durch > messungen den Fehler finden. Da klang der Punkt 2) Deines Eingangsbeitrages aber anders. Daß Du ganz langsam messen möchtest, lese ich zum ersten Mal. Aber warum Du ein TTL-Grab ausheben willst, verstehe ich nach wie vor nicht.
m.n. schrieb: > Ich mache es äußerst ungern, aber heute muß ich Dir glatt widersprechen > ;-) > Zwei Tore braucht man zum Beispiel beim Fußball, hier aber nicht. Die > betreffenden Timer vom F407 laufen mit 168 MHz. Jaja, du hättest es besser bleiben lassen, Peter Dannegger hatte auch schon mal einen ähnlichen Murks von sich gegeben ("wie gut, daß sein ATtiny mit 20 MHz Systemtakt nicht weiß, daß er nur Signale bis 10 MHz zählen kann..."), das war genauso ignorant - ist aber schon lang her.. vergeben aber nicht vergessen. Also, was zählt denn dein 168 MHz Timer? Ach nein, er läuft mit 168 MHz. Das mag wohl sein, aber damit kann er noch lange nicht 100 MHz zählen, sondern allerbestenfalls 83.999999 MHz. Ahnst du jetzt, was du gedanklich falsch gemacht hast? Ich versuch, es dir zu erklären: Also, so ein chipinterner Timer wird tatsächlich mit einem der Systemtakte getaktet - ob man da den CPU-Takt oder einen niedrigen AHB-Takt ansetzen muß, klärt ein Blick ins Handbuch. ABER: das heißt noch lange nicht, daß er auch so schnell zählen kann, denn er ist wie alle anderen Teile im µC ein abtastendes Wesen, was heißt, er kann ein von außen angelegtes Signal nur dann als Wechselspannungssignal erkennen, wenn dessen Frequenz kleiner oder höchstens gleich der halben Taktfrequenz ist. Er will in einer Taktperiode das Signal zum Abtastzeitpunkt high sehen und in einer nächsten dann low sehen - dazu braucht es definitiv 2 (ZWEI) Systemtakte. Eben Abtast-Theorem wie ich bereits ausführte. Da kommst auch du nicht drumherum - und wer da öffentlich dagegenspricht und das Abtasttheorem nicht akzeptieren will, ist ein Scharlatan. So. Von solchen Spezereien wie ungleichem Tastverhältnis und so will ich hier mal absehen, sowas kriegt man NUR ordentlich erfaßt, wenn man tatsächlich eine flankenerkennende Zähleinrichtung benutzt. Geh mal in dich und lies mal wieder ein gutes Buch über digitale Signalverarbeitung - mein Tip dazu: ne gute Flasche Rotwein dabei zur Hand zu haben, macht das Ganze sehr viel angenehmer... W.S.
W.S. schrieb: > Also, was zählt denn dein 168 MHz Timer? Ach nein, er läuft mit 168 > MHz. Das mag wohl sein, aber damit kann er noch lange nicht 100 MHz > zählen, sondern allerbestenfalls 83.999999 MHz. Ahnst du jetzt, Meine Vorahnung wird zur Gewissheit: Du hast Dir meinen 407er-Zähler nicht angesehen. W.S. schrieb: > sowas kriegt man NUR ordentlich erfaßt, wenn man > tatsächlich eine flankenerkennende Zähleinrichtung benutzt. Das habe ich Dir zuliebe schon gemacht ;-) W.S. schrieb: > - mein Tip dazu: ne gute Flasche Rotwein dabei zur Hand zu haben, macht > das Ganze sehr viel angenehmer... Ich weiß, am besten auf dem Dachboden ;-)
m.n. schrieb: > Meine Vorahnung wird zur Gewissheit: Du hast Dir meinen 407er-Zähler > nicht angesehen. Du hast das elektronische Perpetuum Mobile erfunden? Gratulation! So, ich mach jetzt aber, was ich dir angeraten hab: ne Flasche Roten auf.. W.S.
W.S. schrieb: > Du hast das elektronische Perpetuum Mobile erfunden? Gratulation! Danke! Aber sieh Dir Schaltung und Programm doch noch an. Sei aber bitte nicht enttäuscht, wenn Du keine Tore findest. Ich lasse die Zähler immer frei durchlaufen. Doch, doch, es funktioniert!
Im Resziprokzähler kann der µC interne Timer schon den vollen µC Takt zählen. Der Trick dabei ist es den µC mit der Ref. Frequenz (oder einem vielfachen davon) laufen zu lassen. So zählt der Timer dann den Ref. Takt. Externe Signal kann der µC Timer in der Regel nicht so schnell zählen - das muss er aber auch nicht. Da reicht es dann einen Externen Teiler zu haben, der den Takt runter setzt, auf einen Bereich den der µC auch noch in Software handhaben kann. Die Torschaltung liefert die capture Einheit des Timers, mit der chip internen Synchronisation auf den Systemtakt. Wenn man unbedingt will könnte man im synchronen auslesen des Timers das 2. Tor sehen - es ist aber gut versteckt und muss sich nicht explizit drum kümmern.
Basti schrieb: > Ich benötige keinen Zähler der 1 mal pro sekunde oder öfter mißt. Ich > will langzeitmessungen vornehmen. und auch nicht 4 gleichzeitig, sondern > 1 - und das möglichst akkurat Genaues weiß ich ja nicht, aber es könnte günstig sein, einen µC zu verwenden, der gut mit double-Variablen umgehen kann, auch wenn Du das jetzt noch nicht nachvollziehen kannst.
Lurchi schrieb: > Externe Signal kann der µC Timer in der Regel nicht so schnell zählen - > das muss er aber auch nicht. Da reicht es dann einen Externen Teiler zu > haben, der den Takt runter setzt, auf einen Bereich den der µC auch noch > in Software handhaben kann. > > Die Torschaltung liefert die capture Einheit des Timers, mit der chip > internen Synchronisation auf den Systemtakt. Na toll. Also ich bring's mal auf den Punkt: Der Systemtakt ist zwar der Referenztakt, aber das Eingangssignal muß erstmal extern runtergeteilt werden, da sonst ein 100 MHz Signal mit einem 168 MHz µC (gleich welcher Bauart) eben NICHT erfaßbar ist. JAJA! Ja, danke, volle Bestätigung all dessen, was ICH geschrieben habe. Mit einem hinreichend großen externen Vorteiler kann man auch den lahmsten µC benutzen. Da ist es schnurz, ob man dann einen AVR oder einen 168MHz-STM32 dranhängt. Leute, was für abenteuerliche Klimmzüge unternehmt ihr denn, bloß darum, daß ihr euch um zwei externe Bustreiber und einen externen Flipflop herumdrücken wollt. Ist es der magische Reiz, mit irgend einer Capture/Compare-Einheit an einem internen Counter herumzuprogrammieren? Mal abgesehen von dem Mund, den m.n. wieder mal zu voll genommen hat, als er sachlich falsche Aussagen gepostet und dabei das Abtast-Theorem ignoriert hat, ist eine solche Programmierer-Akrobatik einfach bloß unnützes Herumgespiele. Es kommt dabei nix Brauchbares heraus. Ich hab - als Alternative - mit einem stinkeinfachen PIC, einem externen FF, zwei externen Bustreibern und einem externen Komparator (alles im SOT23-5) hingegen Frequenzzähler gebaut, die von 1 Hz bis tatsächlich etwa 140 MHz funktionieren. OK, ab 100 MHz braucht es ne relativ reichliche Amplitude, da der Komparator so langsam an seine Grenzen gekommen ist. Aber die Frage der tatsächlichen analogen Signal-Aufbereitung ist all den Capture-Register-Leuten ja noch garnicht gekommen. Also: laßt die Klimmzüge einfach bleiben und kommt zur Vernunft. W.S.
W.S. schrieb: > Leute, was für abenteuerliche Klimmzüge unternehmt ihr denn, bloß darum, > daß ihr euch um zwei externe Bustreiber und einen externen Flipflop > herumdrücken wollt. Ist es der magische Reiz, mit irgend einer > Capture/Compare-Einheit an einem internen Counter herumzuprogrammieren? Gut, Du hast es nicht verstanden und willst es auch garnicht verstehen. W.S. schrieb: > Aber die Frage der tatsächlichen analogen Signal-Aufbereitung ist all > den Capture-Register-Leuten ja noch garnicht gekommen. Den betreffenden Beitrag dazu hier im Forum zu finden, verhindern wohl auch Deine Scheuklappen. Gegen Ignoranz kann man nicht argumentieren.
Nein, meinen Frequenzzähler habe ich nicht weiter gebaut, einer der vielen Pflastersteine auf dem Weg zur Hölle... (Die Frage stand im parallelen Thread zum selben Thema). Ein interessanter Ansatz zu reziproker Zählung mit hoher Auflösung stand im Skript zur UKW-Tagung Weinheim 2012. Das geht leider nicht mit AVR, nur mit speziellen PIC. Die haben eine Schaltung für kapazitive Touchscreens drin, mit denen man trickreich eine analoge Interpolation ausführen kann. http://ukw-tagung.org/60_ukw-tagung_2015/vortraege_seit_1982/index.html "2012 Vollhardt, Dr. Achim DH2VA 9-stelliger Low-Cost PIC-Frequenzzähler bis 4 GHz" Laut Datenblatt von Microchip taugt die Schaltung auch zur Rettung der Welt, neben vielen anderen ernster gemeinten Vorschlägen.
Mit den vielen angezeigten Stellen kommt rasch ein Punkt, wo der eigene Aufwand fraglich wird. Sei es die Auswertung des Signals selber oder auch die hinreichend stabile Referenz. Gedanklich hatte ich auch schon Zähler mit 10 Stellen bei 1 s Meßzeit bei niedrigen Frequenzen angedacht. Dagegen sind 9-stellige 4 GHz in einer Sekunde ja eher banal: einfach zählen und den Zählerstand am Ende auslesen ;-) ABER: man wird dabei nicht annähernd die Qualität bzw. Stabilität bekommen, die ein renomierter Meßgerätehersteller sich in Stückzahlen in Silizium gießen lassen kann. Was im µm-Bereich mit passender Technik erreichbar ist, bleibt bei eigenen Lötaufbauten ein unerfüllbarer Traum. Mit 6 - 8 Stellen bei sekündlichem Ergebnis ist man so gut bedient, daß man quarzstabilisierte Schaltungen gut abgleichen und bewerten kann. Sobald es um Signale aus RC-Oszillatoren geht, reichen 4 - 5 Stellen, wenn man eine halbwegs stabile Anzeige haben möchte. Mit dem oben verlinkten reziproken Zähler mit F407 werden 8-stellige Ergebnisse bei zwei Messungen/s erreicht. Wartet man 5 Sekunden oder länger, bekommt man auch 9-stellige Ergebnisse und mehr. Allein beim Messen eines 1pps-GPS-Signals kann man mit 8-stelliger Auflösung schon gut dessen Jitter erfassen. Da ist m.E. das Ende der Fahnenstange für den Hausgebrauch erreicht.
m.n. schrieb: > Allein beim Messen eines 1pps-GPS-Signals kann man mit 8-stelliger > Auflösung schon gut dessen Jitter erfassen. Da ist m.E. das Ende der > Fahnenstange für den Hausgebrauch erreicht. 1 pps hat auch eine beschissene Kurzzeitstabilität (RMS-Jitter im ns-Bereich), als Takt für irgendwas anderes als eine Wanduhr ungeeignet. Die Pendulum-Zähler sind übrigens mit Standardbauteilen aufgebaut. Sie benutzen zwar einen Zähler-ASIC, aber da ist nur Digitalkram drin. Die HP-Zähler haben bzw. hatten soweit ich weiß auch keine analogen ASICs. Yokogawa hat die Interpolatoren in der TA-Serie auch mit Standardteilen gebaut und die haben 20 (oder warens 50?) ps TI Auflösung. Allerdings keine Schaltpläne dazu, gibt nur einige wenige Fotos im Netz... TA320 sind recht billig zu haben, 90er Jahre Technik, aber der "schlechteste" YEW-TIA.
:
Bearbeitet durch User
m.n. schrieb: > Mit 6 - 8 Stellen bei sekündlichem Ergebnis ist man so gut bedient, daß > man quarzstabilisierte Schaltungen gut abgleichen und bewerten kann. 7 stabile Stellen habe ich mit einem PIC32 ohne externe Vorteiler und einem Referenztakt von 25 MHz leicht erreicht. Und habe mir Gedanken über einen höheren Takt für 8 Stellen gemacht ... > Sobald es um Signale aus RC-Oszillatoren geht, reichen 4 - 5 Stellen, > wenn man eine halbwegs stabile Anzeige haben möchte. ... und diese Gedanken genau aus diesem Grund wieder verworfen. So eine hohe Genauigkeit lohnt sich wohl nur, wenn die Genauigkeit des zu messenden Signals auch irgendwo in dieser Gegend liegt. Ansonsten habe ich nur eine wild springende Anzeige.
...und jitter macht sich genau ab wann nicht mehr bemerkbar? hat jemand was von sekunden messung gesagt?
m.n. schrieb: > Gut, Du hast es nicht verstanden und willst es auch garnicht verstehen. Mein lieber Scholli, jetzt hör mir mal ganz genau zu: Wenn jemand mit einem neuen Perpetuum Mobile zum Patentamt geht, dann wird er dort OHNE Prüfung der Details wieder hinauskomplimentiert. Das ist Usus, seit es erwiesen ist, daß so etwas nicht gehen kann. Wenn du nun ständig lamentierst, "lies meine Werke, du Unverständiger", dann halte ich es ganz genau so wie das Patentamt. Du willst mit deiner Erfindung zwar das Abtast-Theorem außer Kraft setzen, scheust dich jedoch, hier wenigstens in groben Zügen mal zu erläutern, wie du das denn anstellen willst. Glaubst du, daß ich oder sonst wer, der was von der Materie versteht, sich die Details deiner Erfindung anschauen wird? Nein, natürlich nicht. Dinge, die nicht möglich sind, sind eben nicht möglich - und das war's dann. Du hast noch ne Chance, indem du hier mal in einem Fünfzeiler darlegst, wie du 100 MHz mit einem 168 MHz Cortex erfassen willst. W.S.
W.S. schrieb: > Du hast noch ne Chance, indem du hier mal in einem Fünfzeiler darlegst, > wie du 100 MHz mit einem 168 MHz Cortex erfassen willst. Indem er Zähler nutzt, die nicht mit dem Systemtakt vom Cortex synchronisiert sind? Manche MCUs haben sowas...
Der Witz beim Reziproken Zähler ist, das die Messung auch für niedrige Signal-Frequenzen mit hoher Auflösung möglich ist. Für hohe Signalfrequenzen nutzt man entsprechend einen einfachen Vorteiler. Der µC sieht also die voll Signalfrequenz gar nicht - da sind dann z.B. 200 kHz das Limit. Als externe Logic recht dafür ein Vorteiler und MUX zur Auswahl. Einige µC (z.B. dsPic) haben auch einen asynchronen Vorteiler integriert und kommen so ggf. ohne externe Logic aus.
So, und nun noch einmal zum eigentlichen Thema. Bleibt nur zu hoffen, daß ihr den Basti nicht vergrault habt. Basti schrieb: > ich bastel an einem Frequenzzähler. > ..... > -> Daher habe ich mich entschieden einen 32 bit zähler aus ttl > bausteinen diskret aufzubauen. Dazu hab ich ein paar ganz grundsätzliche Fragen: 1. Warum soll es denn ein Atmel AVR sein? Geht vielleicht auch ein anderer µC? Oder ist dir die Verwendung eines AVR so wichtig, daß dies die oberste Priorität hat? 2. Warum fängst du mit TTL an? CPLD's gibt's doch sogar bei Reichelt. Ein CPLD wäre genau das Mittel der Wahl - und genau dazu würde ich dir raten, wenn es ein richtiges Labor-Gerät werden soll. Außerdem würde ich dir ernsthaft von jeglichem AVR abraten, denn bei denen hat man m.W. nur single und kein echtes double zum Rechnen - und das braucht man bei einem ordentlichen 100 MHz Zähler. Mit single kommt man lediglich bis 16 MHz ohne Abstriche (wegen der nur 24 Mantissenbits) 3. Was für ein Zähler soll's denn werden? Ein richtiger "großer" für den Laborarbeitsplatz? Oder ein kleiner Taschenzähler? Oder ein "Wanzensuchzähler", also ein tragbarer mit empfindlichem HF-Eingang und Breitbandantenne? Für den 'richtigen großen' rate ich dir dringend zum CPLD, für den Taschenzähler zu einem einfachen PIC16F (auch wenn der mit 100 MHz über's Datenblatt hinaus gestreßt wird) und bei einem Wanzensuchzähler kanst du beim AVR bleiben - allerdings davor einen als Downkonverter mißbrauchten PLL-Chip davor, sowas wie dei ADF4002 oder so. Das ergibt nur 2 Chips auf der LP und für diese Anwendung brauchst du ja kein Zählen von Frequenzen unterhalb einiger 100 kHz. W.S.
Lurchi schrieb: > Einige µC (z.B. dsPic) haben auch einen asynchronen Vorteiler integriert > und kommen so ggf. ohne externe Logic aus. Es haben m.W. fast ALLE PIC's einen asynchronen Vorteiler. Aber davor muß man eben noch das Meßtor setzen. Ich hab's weiter oben schon geschrieben. Und ich hab's selbst schon gebaut - funktioniert gut und zuverlässig. Lediglich mit dem Referenztakt hat es bei einer solchen Minimal-Variante ne Grenze nach oben. Ich hatte den PIC16F716 benutzt, der hat vor Timer0 und vor Timer1 jeweils einen asynchronen Prescaler, beim Timer1 bis zu 1:8, womit man dann mit der Referenz bis knapp unter 40 MHz kommt - falls man dafür nen passenden TCXO findet. Ich hatte glaub ich 26.xxx MHz benutzt. Den gab's mal bei Ebay. Wie gesagt, ein µC, ein Einzelgatter D-FF, zwei Einzelgatter Bustreiber, ein Komparator oder ein FIN100x als Komparator mit diskreter Hysterese und fertig ist der Taschenzähler, der bei etwa 1/2 Sekunde Meßzeit allemal zwischen 10.000.000 Hz und 10.000.001 Hz unterscheiden kann. Sollte für den Hausgebrauch ausreichen. Der Knackpunkt sind eben die zwei asynchronen Vorteiler auf dem Chip. Die sind flankengetriggerte Ripplecounter und das ist hier in solcher Anwendung genau richtig. Zusammen mit 2 Bustreibern gestattet dieses Konstrukt, nach Meßende in aller Ruhe die Vorteiler auszulesen. das ist einer der entscheidenden Unterschiede zu allen Versuchen mit Capture-Registern. Aber bei einem Cortex M4 ist mir noch nirgendwo ein asynchroner Vorteiler aufgefallen. Und selbst wenn es sowas gäbe, bräuchte man dazu immer noch das Tor davor, um den Vorteiler "ausrippeln" zu lassen und ihn auszulesen. W.S.
Hi W.S ist doch eher wichtig für den compiler, oder?? Der AVR ist für mich der µCOM der Wahl - und wegen seiner einschränkungen habe ich mich ntschieden alles wichtige auszulagern. Ich habe null ahnung von cpld und ehrlich gesagt auch keine zeit mich einzuarbeiten. Reizen würde es mich schon. Mal ein Eval-Board auf die Merklise tun. Also BASCOM scheint mit doubles hantieren zu können. Warscheinlich werden so lange variablen dann simuliert. Double. Doubles are stored as signed 64 bit binary numbers. Ranging in value from 5.0 x 10^–324 to 1.7 x 10^308 Zunächst soll ein OCXO über lange zeit mit gps pps verglichen werden und dann dementsprechen nachgeregelt werden. wenn mein großer laborzähler auf arbeit dann den korrekten wert anzeigt geht es weiter ;-) Für mich ist es wichtig das ich nicht gleich bei Version 3 anfange... Die erste version wird wohl schon zwei zähler haben, sowie ein diskret aufgebautes gate, um interruptverzögerungen in der software vorzubeugen. der avr soll mit der messung nicht zu tun haben. nur auslesen -> Rechnen -> Anzeigen (grad bei reziproken zählern ist ne rechenmaschine ganz wichtig) Für das bisschen was da gerechnet wird reicht ein avr allemal hin. dann dauerts halt 1ms länger.
Ein Reziproker Zähler mit Hilfe der Capture Funktion braucht kein extra externes Tor davor. Dafür reicht die µC interne Synchronisation. Die Einzige Einschränkung ist halt das die Capture events in Software (bzw. ggf. mit spezieller HW ?) mit gezählt werden können. Entsprechend braucht man für hohe Frequenzen (z.B. ab ca. 500 kHz beim AVR) einen Vorteiler. Mit 2 Eingängen für das Capture braucht man auch wirklich nur den Teiler (z.B. 8 Bit) extern, mehr nicht. Bei den PIC16 / PIC18 hat man zwar interne Vorteiler, kommt aber trotzdem nicht so wirklich ohne externe Logic aus. Man braucht halt die externen Tore um 2 Timer zu nutzen. Der Alternative Weg mit externem Vorteiler um Capture-funktion geht natürlich auch mit den PICs PIC18s habe sogar auch Vorteiler für Capture-Eingänge, aber so weit ich weiss nur als 1:16. Das könnte immerhin für vielleicht 5-20 MHz als Rezirokzähler ohne extra Hardware ausreichen könnte. Darüber könnte man dann klassisch zählen. Die unterstützten Datenformate sind eine Frage der Compiler, weniger des µC. GCC unterstützt am AVR soweit ich weiss keine double, aber z.B. 64 Bit Integer. Andere Compiler unterstützen auch Double. Außerdem hat man beim Zähler alle Zeit der Welt für die eine Division - das kann man auch zu Fuss als BCD machen. Für Aufwändigere Logic bieten sich CPLDs an - die sind teils auch recht schnell. Allerdings braucht es etwas die programmieren zu können. Für so etwas einfaches wie die Torschaltung kann man auch noch Standard Logic ICs nehmen.
W.S. schrieb: > Zusammen mit 2 Bustreibern gestattet dieses Konstrukt, nach Meßende in > aller Ruhe die Vorteiler auszulesen. das ist einer der entscheidenden > Unterschiede zu allen Versuchen mit Capture-Registern. Vor Jahrzehnten hatte ich das auch mal gemacht. http://www.mino-elektronik.de/Archiv/Elektronik25_1984.pdf Dieses Verfahren hat den Nachteil, daß weitere ext. Logik notwendig ist und nur lückend gemessen werden kann. Bei 1 Hz Signalen kann daher nur jedes 2. Intervall erfaßt werden. Ein neues Ergebnis wird erst nach zwei Sekunden geliefert. Bei hohen Eingangsfrequenzen ist es eher unerheblich, aber bei Frequenzen < 1 Hz nervt es. W.S. schrieb: > Aber bei einem Cortex M4 ist mir noch nirgendwo ein asynchroner > Vorteiler aufgefallen. Deine synchron - asynchron Einwände sind lächerlich. Letztlich synchronisiertst Du selber mit dem D-FF, wo hingegen eine Capture-Einheit die Synchronisierung mit auf dem Chip bietet. Du synchronisiert vor dem Vorteiler und mußt ihn daher mit auslesen und ich synchronisiere nach dem Vorteiler und kann diesen Zählerstand daher ignorieren. Bei der Messung mit Capture-Einheit braucht man kein Tor, es gibt keine Torzeit, sondern die Zähler laufen frei durch. Was das mit perpetuum mobile oder Patent zu tun haben soll, ist mir nicht klar. Ich würde eher mit veralteter und aktueller Technik argumentieren.
Einen OCXO an GPS anzubinden ist schon was anderes als ein Frequenzzähler. Dafür braucht man einen PLL, den man in der Regel wohl digital (per µC) realisiert. Dafür braucht man keinen 32 Bit zähler - die "ungefähre" Frequenz kennt man, so dass die unteren etwa 8 Bit ausreichen. Wenn man es unbedingt zu Fuß machen will, dann eher so etwas wie ein 74xx590 und falls nötig ein D-FF zur Synchronisation. Einfacher geht aber noch die Capture einheit im µC, sofern der mit dem OCOX Takt (oder synchron dazu) laufen kann. Das Ergebnis aus der Capture-einheit auszulesen ist eher weniger Aufwand als einen externen Zähler auszulesen. Probleme mit Interrupt Verzögerungen hat man da nicht, die eigentliche Messung geht komplett mit der µC internen Hardware. Der µC kann sich also voll auf den PLL zum Nachregeln des OCXO konzentrieren. Wenn man mag kann das auf ein 2. µC sein, und nicht der für die Anzeige. Von daher lohnt sich ein externer Zähler nur wenn es schneller (für mehr Auflösung) sein muss. Die maximal 20 MHz beim AVR sind ggf. noch noch nicht ganz ausreichend um das pps Signal voll auszunutzen, viel fehlt aber nicht. Die Alternative für mehr Auflösung wäre eine analoge Interpolation - das fängt z.B. mit einem HC4046 PLL IC und 1 Hz Signal vom µC an. Das bringt zwar nicht unbedingt sub ns Auflösung, aber für das übliche pps Signal reicht es. Wenn man für die Ref. schon einen OCXO an GPS anbinden will, wird man für den eigentlichen Zähler wohl schon auf CPLD und wohl auch eine analoge Interpolation zurückgreifen. p.s. bis 100 mHz tut es fast jede Logic, auch CD40xx und ggf. sogar noch Relais. Das 1 pps Signal hat aber schon 1000 mHz.
Ich habe mir Achims Vortragsskript von 2012 nochmal angeschaut. Der PIC muss eine CTMU haben: http://ww1.microchip.com/downloads/en/AppNotes/CTMU%2001375a.pdf "AN1375, See What You Can Do with the CTMU" Bei einem Frequenzzähler kann nur eines der beiden Signale synchron zum Tor sein, das andere ist immer asynchron. Daraus resultiert eine Schwankung der Messung in der letzten Stelle. Mit dem CTMU wird genau diese Schwankung ausgemessen und interpoliert. Er erreicht damit mit einem 10MHz OCXO eine Auflösung von 1 ns, die Messergebnisse hatten bei 1 Stunde Beobachtung nur Streuungen von "2" bis "6" in der 0,01 sec-Stelle bei 10.000.000,0x MHz Anzeige. Als Vorteiler benutzt er einen PLL-Chip von Analog Devices aus der Sat-TV-Technik.
Basti schrieb: > Ich habe null ahnung von cpld und ehrlich gesagt auch keine zeit mich > einzuarbeiten. Reizen würde es mich schon. Mal ein Eval-Board auf die > Merklise tun. ich kann's dir nur anraten. Selbst das allerkleinste CPLD würde für die Sache ausreichen. Guck mal da, kostet dort 2.99 Euro: "http://www.reichelt.de/XC-9572XL-VQ44/3/index.html?&ACTION=3&LA=446&ARTICLE=40159&artnr=XC+9572XL+VQ44&SEARCH=cpld"; So ein XC9572XL hat 72 Flipflops drin, da kannst du problemlos sowohl den Inputzähler als auch den Referenzzähler mit machen. Und mit 44 Beinen ist es auch nicht allzu groß - jedenfalls handlicher als diskrete TTL. Die Soft dazu namens "Webpack" gibt's gratis bei Xilinx und man kann sowas noch ganz bequem mit Schematics programmieren, wenn man kein Verilog oder vhdl lernen will. Bleibt nur noch der Brenner dazu (JTAG ist hier gefragt), aber den kann man sich im billigsten Falle selber basteln, man braucht nur einen Parallelport dafür - jaja.. jetzt nicht kreischen, als Bastler sollte man sowas haben. Bei mir tut's eine Einsteckkarte von Pollin ohne Probleme. Aber fang nicht mit sowas wie Eval-Board für ein CPLD an. Das ist kompletter Quatsch. So ein Ding setzt man auf die Leiterplatte, schließt Masse und Versorgungsspannung an, schließt die JTAG-Strippen an (ich nehme dazu eine stinknormale Stiftleiste mit 6 Pins, das reicht. Und die übrigen Beine verdrahtet man so, daß es auf der Leiterplatte möglichst kreuzungsfrei zugeht. Die gewünschte Funktion der Beine legt man im Webpack-Projekt mit einem kleinen Textfile (*.ucf) fest. Das ist dann alles. Also: trau dich, du wirst es nicht bereuen. Naja, und da dann das CPLD die eigentliche Arbeit macht, hast du keinerlei Probleme mit deinem AVR. W.S.
m.n. schrieb: > Bei der Messung mit Capture-Einheit braucht man kein Tor, es > gibt keine Torzeit, sondern die Zähler laufen frei durch. Wenn es nicht so traurig wäre, was du da schreibst, wäre es zum Grölen. Also: Was ist überhaupt eine Frequenz? ich erkläre es dir: Im Prinzip ist eine Frequnenz die Anzahl von Ereignissen pro Zeitspanne. Man braucht folglich zum Ansagen einer Frequenz immer zwei Dinge: a) eine gezählte Anzahl b) einen Zeitraum, in welchem gezählt wurde. a ist der Zählerstand und b ist die Torzeit. Es geht prinzipiell nicht ohne eine Torzeit. Aber wenn dir das Wort mißfällt, dann kannst du auch "Bewertungszeitspanne" dazu sagen. Ist mir aber zu lang. m.n. schrieb: > Letztlich > synchronisiertst Du selber mit dem D-FF, wo hingegen eine > Capture-Einheit die Synchronisierung mit auf dem Chip bietet. Herrje, du hast aber ein dickes Brett vor dem Kopf, mein Lieber. Also, ich erkläre es dir NOCHMAL: Das D-FF wird von dem zu messenden Signal getaktet. Es macht damit exakt synchron zur Eingangsfrequenz auf und zu. Damit und NUR damit ist gewährleistet, daß die Torzeit in allen Lebenslagen wirklich ein exaktes Vielfaches der Eingangsperiode ist. Wenn du hingegen irgendwelche Logik im µC benutzest, dann bist du IMMER nur synchron zum Systemtakt, also in deinem Fall zur Referenzfrequenz. Das ist kein echter Reziprok-Zähler, sondern nur ein näherungsweiser Reziprokzähler. Die Näherung kann man exakt benennen: Eine Referenzperiode am Anfang der Torzeit und noch eine an deren Ende. Macht eine zeitliche Unsicherheit von zwei Systemtakten für das Eingangssignal. Das ist nicht viel, aber was wollen wir denn bauen? Ein Schätzeisen oder einen Frequenzzähler? Dazu kommt noch der begrenzte Frequenzbereich, in dem so ein Softwarezähler funktioniert. Ich sehe da wirklich nur Nachteile: 1. Begrenzung nach oben am halben Systemtakt 2. Probleme bei Tastverhältnissen ungleich 1:1 3. Restfehler von 2 LSB wegen oben genannter Torzeit-Unsicherheit. Daher entweder bloß halbe Auflösung oder doppelte Torzeit nötig. 4. Für höhere Frequenzen ist dann ja doch ein externer Zähler und zusätzlich noch eine Art Umschaltung "höher/niedriger" vonnöten. Man muß also vorher schon wissen, was einen am Meßeingang erwarten darf.. Ach nee, das sind mir alles viel zu viele Einschränkungen. Ich will ein verläßliches Instrument und kein Wenn und Aber-Gerät. Ein Zähler mit einem echten Hardwaretor ganz am Anfang kann alles in einem Rutsch: von 0 bis zur höchsten Frequenz, die der Inputzähler bzw. Vorteiler zählen kann. Ohne Umschalterei und mit beliebigen Tastverhältnissen. Im Falle eines CPLD's geht das spielend von 0 bis weit über 100 MHz (bei Coolrunnern bis über 400 MHz). Selbst bei einem Minimal-Zähler, wie ich ihn beschrieben habe, geht das bis ca. 140 MHz. Und alles ohne jegliche Umschalterei. W.S.
So schlecht sind die Capture Einheiten auch wieder nicht: Auch mit der Capture Einheit im µC "zählt" man die Flanken des Ref Taktes genau für eine definierte Zahl an Perioden. Die Unsicherheit mit der nicht vollständigen Taktperiode am Anfang und Ende hat man in beiden Fällen. Der Fehler ist also nicht größer als beim externen Tor. Ein wirklicher Fehler kann entstehen, wenn die Flanken vom Signal und dem Ref. Takt so genau zusammenfallen dass am Flipflop Metastabile Zustände entstehen. Die µC nutzen dafür in der Regel 2 Stufige Synchronisation um die Wahrscheinlichkeit für den Fehler noch einmal zu reduzieren. Bei der Synchronisation auf das Externe Signal macht man die 2 Stufige Synchronisation im allgemeinen nicht: zum einen wegen dem Aufwand und auch Nachteilen bei niedriger Frequenz. Man nimmt also die minimal größeren Fehlerwahrscheinlichkeit in Kauf (ggf. auch aus Unwissen). Der Unterschied ist aber auch eher klein, jedenfalls wenn der Takt nicht die Grenzen der Logic-bausteine erreicht. Das Tastverhältnis ist relativ unkritisch - einzig sehr kurze Pulse mit niedriger Frequenz (so dass man ohne Vorteiler arbeitet) wären ggf. ein Problem. Sofern der µC mehr als einen Capture Eingang hat, kann man auch mit und ohne Vorteiler parallel messen - hätte das Problem also nicht. Die Unterscheidung in Hohe und niedrige Frequenzen ist recht unkritisch. Beim AVR gehen die niedrigen Frequenzen (d.h. ohne Vorteiler) bis etwa 200-500 kHz und je nach Vorteiler hat der Bereich für hohe Frequenzen schon ab etwa 500 Hz keinen wesentlich Nachteil mehr. Je nach µC können die beiden Fälle sogar parallel erfasst werden - man verliert also nicht unbedingt noch Zeit. Die Messung über die Capture funktion hat gerade für niedrige Frequenzen auch ein paar Vorteile: mit externem Tor hat man zwischen den Messungen immer eine Periode Pause. Bei sehr kleinen Frequenzen (so dass nur 1 Periode gemessen wird) verdoppelt sich dadurch die Messrate bzw. die Auflösung gegenüber der Messung mit externem Tor. Der Hardware Aufwand ist oft geringer - es reicht halt in der Regel ein Vorteiler IC. Nur wenn der µC keinen 2. Eingang bietet bräuchte man noch so etwas wie einen MUX, den man aber oft sowieso gebrauchen kann, etwa um andere Eingänge auszuwählen. Man kann mit der gleichen HW auch die Zeiten für weitere Flanken auswerten: je nach Art der Fehler kann damit eine höhere Auflösung und eine geringere Empfindlichkeit auf Triggerfehler erreicht werden. Hilfreich ist das vor allem bei Signalen wie der 50 Hz Netzfrequenz, wo oft Triggerfehler dominieren, die eigentliche Taktquelle aber stabiler ist.
Lurchi schrieb: > Die Unsicherheit mit > der nicht vollständigen Taktperiode am Anfang und Ende hat man in beiden > Fällen. Der Fehler ist also nicht größer als beim externen Tor. Jetzt fängst du auch noch an. Also, diese Unsicherheit von 2 Ref-Perioden hat man NUR bei der Capture-Variante. Nicht aber bei der echten Hardware-Variante. Dort hat man nur eine einzige Ref-Periode an Unsicherheit. Mal es dir mal auf, dann wirst du es sehen: egal, wie die Lage zwischen Input-Zählflanke und Referenz-Zählflanke ist, es kann niemals zu zwei Ref-Perioden an Unsicherheit führen. Das macht in der Endkonsequenz ein Bit mehr für die Hardware-Methode - verglichen mit der Capture-Methode, vorausgesetzt natürlich gleiche Randbedingungen, also gleiche Referenzfrequenz und gleiche Torzeit. Für die gleiche Auflösung muß man bei der Capture-Methode also die doppelte Zeit messen. OK, für extrem niedrige Frequenzen läuft das auf ein Patt hinaus: Während man nach unserem m.n. die Zähler durchlaufen lassen kann und z.B. bei dem Messen von 1pps Signalen jede Sekunde ein Ergebnis hat, muß man bei der Hardware-Methode nach einer Messung ne Sekunde warten. Aber bei der Capture-Methode hat man eben 1 Bit weniger und für die gleiche genauigkeit müßte man 2 Sekunden lang messen. Das wiederum kommt auf's Gleichen raus wie bei der Hardware-Methode. Ändern tut sich das aber bei Frequenzen größer als 1 Hz, da hat die Hardware-Methode in allen Lebenslagen ein Bit mehr an Genauigkeit als die Capture-Methode. Oder andersherum ist sie für gleiche Auflösung doppelt so schnell als die Capture-Methode. Und sie ist frei von den anderen Beschränkungen. Ach ja, nochwas: Es ist natürlich bei der Capture-Methode so, daß man durchaus was angezeigt bekommt, wenn die Eingangsfrequenz größer ist als die halbe Systemtakt-Frequenz. Das ist in der Natur von abtastenden Systemen begründet. Nennt man Alias, da werden die Signale an der halben Abtastfrequenz gespiegelt und erscheinen dann als Geistersignale im Basisband. Aber da man beim Frequenzzähler das Signal ja nicht sehen kann wie beim Oszi, kann man die derart erzeugten Hausnummern auch nicht unterscheiden von echten Resultaten. Ist für mich ein weiterer Grund, von sowas gehörigen Abstand zu nehmen. W.S.
Ob man die Messung mit dem Capture oder per externem Tor macht, macht keinen wirklichen Unterschied bei der Genauigkeit: In beiden Fällen hat man sowohl bei Start als auch beim Stop die prinzipielle Unsicherheit zwischen 0 und 1 Ref. Perioden. Man Zählt halt nur ganz Perioden, egal wie man es macht. In der Summe hat man also die Unsicherheit um +-1 Perioden maximal. Wenn man nicht aufpasst kommt beim Externen Tor da ggf. noch ein kleiner Systematischer Fehler im ns Bereich dazu, wenn die Übergänge in die eine oder andere Richtung unterschiedlich schnell sind. Zur gezählten Zeit kommt halt ggf. noch die eine oder andere Gatterlaufzeit dazu. Je nachdem wie man das externe Tor in Hardware realisiert hat man dabei ggf. sogar noch einen größeren Fehler, weil ggf. auch zu kurze Pulse an den Zähler geschickt werden und dieses kritische Signal vom Tor zum Zähler muss, also ggf.zwischen zwei ICs läuft. Die Capture Einheiten im µC nutzen in der Regel die zuverlässigere 2-Stufige Synchronisation mit 2 Flipflops, und das alles im µC, also gut vor äußeren Einflüssen geschützt. Es kommt auch nur darauf an wie stabil die Laufzeiten sind - es werden beim start und "stop" die selben Gatter genutzt. Bei der Realisierung in einem FPGA hat die Zählmethode mit externem Gate von der Tendenz her den Vorteil, das der Zähler einen etwas höheren Takt erlauben könnte und einfacher ist. Außerdem könnten Ref. Takt und µC Takt verschieden sein.
W.S. schrieb: > Ach ja, nochwas: Es ist natürlich bei der Capture-Methode so, daß man > durchaus was angezeigt bekommt, wenn die Eingangsfrequenz größer ist als > die halbe Systemtakt-Frequenz. Warum wiederholst Du nur penetrant diesen Müll? Niemand hat die Absicht, den µC am Eingang zu übertakten. Für höhere Frequenzen nimmt man einen Vorteiler. Der oben genannte 74VHC4040 reicht bis 200 MHz Eingangsfrequenz, wogegen Deine 50 MHz ja schon recht blaß aussehen. Und auch die im Betreff gewünschten 100 mHz schafft Dein Zähler nicht, da er erst ab 1 Hz arbeitet. Was willst Du eigentlich? Da für Dich Vorteiler tabu sind, hast Du ja auch keine Möglichkeit, höhere Signalfrequenzen zu erfassen. Für den GHz-Bereich würde ich einfach einen passenden Vorteiler ergänzen, ohne damit Auflösung, Genauigkeit oder Meßzeit zu verschlechtern.
m.n. schrieb: > Niemand hat die Absicht, den µC am Eingang zu übertakten. Jaja, "niemand hat die Absicht, eine Mauer zu erbauen.." Solche Sprüche kennt man noch. Aber mit der Absicht ist es nicht weit her, denn dazu müßtest du schon vorher wissen, was auf deinen Frequenzzähler denn so an seinem Eingang zukommen wird. Aber das kannst du nicht, denn eben dieses willst du ja erstmal mit diesem Gerät ermitteln. Der gute Münchhausen hatte dies erledigt, indem er sich am eigenen Zopf aus dem Sumpf zog... Weißt du, diese Bockigkeit geht mir inzwischen auf den Nerv, also laß ich dich in deinem eigenen Saft weiterschmoren. Alles Wesentliche ist ja bereits gesagt - und wer gewillt und in der Lage ist, es zu überdenken, wird selbiges auch tun. W.S.
Bei der Messung per Capture Funktion hat man nicht nur die Begrenzung darauf, dass die H und L Phase mindestens eine Takt-periode lang sind, sondern in der Regel auch noch eine Begrenzung durch das Auslesen des Timers durch den µC. Wenn man da kein extra Unterstützung durch DMA oder ähnliches hat, darf die Frequenz am µC bei weitem nicht so hoch sein. Beim 20 MHz getaktetem AVR liegt das Limit da eher so bei rund 500 kHz. Die Erkennung ob eine hohe Frequenz vorliegt, ist aber nicht so schwierig. Im Zweifelsfall kann man auch noch relativ niedrige Frequenzen (bis z.B. 1 kHz runter) mit Vorteiler messen - im ungünstigen Fall wird die Messzeit halt etwas länger. Der Bereich der mit oder ohne Vorteiler zu messen ist, ist recht groß, so dass die Erkennung des Bereichs nicht so schwer ist. Der Streit geht aber so oder so am Problem des TO vorbei: Der sucht erst einmal so etwas wie einen digitalen PLL. Für die Anwendung ist die Capture funktion gerade zu wie gemacht. Die Frage ist da höchstens wie gut das PPS Signal seines GPS Empfängers ist, und wie genau er es auswerten will. Soweit ich es kenne ist das PPS Signal oft etwas (aber nicht unbedingt viel) besser als die 50 ns Auflösung, die der AVR liefern kann. Wenn man später für einen universellen Frequenzzähler die Wahl des Verfahrens hat, ist noch die Frage ob man rein zählen will, oder auch eine Interpolation nutzen will. Mit Interpolation geht die Tendenz jedenfalls eindeutig in Richtung Synchronisation mit dem Takt, und nicht mit dem Eingangssignal. Für die Interpolation wäre z.B. einer der oben erwählten PIC18 eine Möglichkeit, ggf. auch für die GPS Anbindung (dann wohl als ein 2. µC).
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.