PIC - Frequenzzähler weit über 50 MHz auf die minimalistische Art

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.

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.

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 :-)

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?

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.

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.

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 :-)

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.

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

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"

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.

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 :-)

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.

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.

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 :-)