Forum: Mikrocontroller und Digitale Elektronik Frequenzzähler 1Hz - 40MHz


von Ulrich (Gast)


Lesenswert?

Für eine hohe Auflösung bei niedrigen Frequenzen ist die 
Triggerschaltung entscheidend. Wenn man ein gutes Rechtecksignal hat, 
ist es kein wirkliches Problem. Je nach Messverfahren gehen aber höhere 
Frequenzen auch da besser.

Wenn man niedrige Frequenzen mit Sinussignal ( < 10 kHz) unbedingt mit 
hoher Auflösung messen will, kann man dass ggf. mit der Soundkarte am PC 
machen. Signal aufzeichnen und dann eine passende Kurve (z.B. Sinus) 
anpassen lassen. Da kriegt man dann ggf. auch mehr als 7 Stellen bei 50 
Hz und 1 Sekunge Messzeit aufgelöset. Die Genauigkeit ist aber durch den 
Teils miesen Quarz begrenzt.  Man verschiebt damit sozusagen das 
Triggern und ein Filter auch auf die Digitale Seite.

So schlecht sind da DDS Generatoren auch nicht - nur das Rechecksignal 
kann man da auch schlecht realisieren, muss es aber nicht. Ich kann mich 
an etwa 7-8 Stellen Auflösung mit 1 KHz und 0,1 s Messzeit erinnern. Ein 
alter Phillips DDS-generator (der DA Wandler (9Bit) noch diskret 
aufgebaut) und mit der Soundkarte gemessen.

von Axel S. (a-za-z0-9)


Lesenswert?

Moin,

Ralph Berres schrieb:

> Niedrige Frequenzen mit hoher Auflösung zu zählen ist immer eine
> Herausforderung.

Yep

> Zum einen, weil die Signalquelle , dessen Frequenz man messen will,
> entsprechend stabil sein muss, und entsprechend geringes Phasenrauschen
> besitzen muss.  DDS Synthesizer zählen gerade nicht dazu. Eher ein mit
> ganzaligen Teiler runtergeteilte Quarzoszillatoren .
> Zum anderen weil sich das Rauschen an den Übergangsbereiche des
> Komperators im Counter negativ als Jitter bemerkbar macht.

So ist es. "Jitter" ist ja nur ein anderer Name für Phasenmodulation. 
Und eine Phasenmodulation ist immer auch eine Frequenzmodulation.

Wenn wir also das Modell einer Signalquelle mit fester Frequenz und 
zufälligem (z.B. normalverteilt mit Mittelwert 0) Jitter annehmen, dann 
müßten wir zur exakten Bestimmung der Frequenz über unendlich viele 
Perioden des verjitterten Signals messen. Eine Messung mit endlicher 
Torzeit wird immer nur eine Näherung liefern.

Wenn mich meine Statistik-Kenntnisse nicht verlassen haben, dann fällt 
bei normalverteilten Zufallsgrößen die Standardabweichung um sqrt(N) 
wenn man zu Mittelwerten über N Zufallswerte übergeht.

> Wie weit das Programm des Mikroprozessors darauf Einwirkung hat vermag
> ich nicht zu beurteilen , das ist sicherlich eine Sache der
> intelligenten Programmierung des Prozessors.

Wie bereits gesagt: das einzige Rezept zum Herausrechnen des Jitters ist 
Mittelwertbildung über möglichst viele Perioden des Meßsignals. Das 
Meßkonzept verwendet eine variable Torzeit von minimal 4*1024*1024/fref. 
Da das Tor synchron zum Meßsignal öffnet und schließt, ist die effektive 
Meßzeit immer das nächstgrößere Vielfache der Periodendauer des Signals.

Der Faktor 4*1024*1024 ist in der aktuellen Firmware (die derzeit nur 
Papi zum Testen hat) per C-Makro MINCYCLES veränderbar. Minimum für 6 
Stellen Auflösung ist MINCYCLES=1000000. Der aktuell gewählte, etwas 
größere Wert ist ein Kompromiss: zum einen werden Dreckeffekte so sicher 
unter 1/2 Digit gedrückt, zum anderen hat man mit ~3 Messungen pro 
Sekunde eine akzeptable Abtastrate (für eine menschenlesbare Anzeige).

Dieser Wert ließe sich auch problemlos per Jumper verändern.

> Auch professionelle Counter wie der Racal Dana 1992 hat da ganz große
> Probleme mit niedrigen Frequenzen. Mehr als 7 Stellen bei 1KHz
> Messfrequenz sind einfach nicht drin.

Nominale Meßzeit bei fref=14.31Mhz ist 292.9ms. Der Meßwert für 1kHz ist 
also der Mittelwert der Frequenz über 293 Perioden. Höhere Meßfrequenzen 
mitteln über mehr Perioden, niedrigere über weniger. Dementsprechend hat 
der Jitter einen umso größeren Einfluß, je geringer die Meßfrequenz ist.

Einer stumpfen Verlängerung der Meßzeit steht vor allem die 
Praktikabilität im Weg. Ein hochgenauer Meßwert alle 100 Sekunden ist 
nur in wenigen Fällen hilfreich. Eine Variante wäre eine gleitende 
Mittelwertbildung. RAM hat man im Controller ja reichlich. Ich setz das 
mal auf die Liste mit den Feature-Wünschen.


XL

von Ulrich (Gast)


Lesenswert?

Für die Messung niedriger Frequenzen kann man ein etwas anderes 
Verfahren wählen und so Jitter bzw. Störungen an Trigger etwas besser 
unterdrücken.  Kommerzielle Zähler bieten das Teils auch an.

Es wird die Zeit zu jedem Trigger-event (z.B. steigende Flanke) 
gemessen, und dann eine lineare Regression von Zeit über Nummer 
duchgeführt. Die lineare Regression kann man direkt per Formel berechnen 
und muss dazu auch nicht alle Zeiten Speichern. Bis vielleicht 20 kHz 
sollte das der Mega88 auch noch in Echtzeit schaffen können. In C könnte 
es aber schwer werden weil man für Zwischenwerte ggf. mehr als 32 Bit 
Zahlen braucht.
Man gewinnt dadurch gegenüber der Messung nur der ersten und letzten 
Zeit, so wie es jetzt gemacht wird, etwa einen Faktor  sqrt (N/ 
sqrt(12)) im Rauschen.

von Alex H. (hoal) Benutzerseite


Lesenswert?

Axel Schwenke schrieb:
> Wenn mich meine Statistik-Kenntnisse nicht verlassen haben, dann fällt
> bei normalverteilten Zufallsgrößen die Standardabweichung um sqrt(N)
> wenn man zu Mittelwerten über N Zufallswerte übergeht.

Das gilt für die Poissonverteilung. Ihre Standardabweichung beträgt bei 
N Messwerten gerade sqrt(N). Relative Abweichung ist also 1/sqrt(N).

Die Frequenzmessung wird aber normalverteilt sein und damit eine feste 
Standardabweichung haben.

von Axel S. (a-za-z0-9)


Lesenswert?

Alex H. schrieb:
> Axel Schwenke schrieb:
>> Wenn mich meine Statistik-Kenntnisse nicht verlassen haben, dann fällt
>> bei normalverteilten Zufallsgrößen die Standardabweichung um sqrt(N)
>> wenn man zu Mittelwerten über N Zufallswerte übergeht.
>
> Das gilt für die Poissonverteilung. Ihre Standardabweichung beträgt bei
> N Messwerten gerade sqrt(N). Relative Abweichung ist also 1/sqrt(N).
>
> Die Frequenzmessung wird aber normalverteilt sein und damit eine feste
> Standardabweichung haben.

Das ist nicht das, was ich meinte. Nochmal:

Angenommen ich habe eine normalverteilte Zufallsgröße x1 mit Mittelwert 
m1 und Standardabweichung s1. Daraus konstruiere ich mir eine neue 
Zufallsgröße x2, wobei jeder Wert von x2 das Mittel von N Werten von x1 
ist.

Dann sollte x2 den gleichen Mittelwert m2 = m1 haben und eine 
Standardabweichung s2 = s1/sqrt(N). Korrekt?

PS: Statistik ist laaaange her...


XL

von Frank (Gast)


Lesenswert?

Verstehe ich das richtig: wenn man Statistik anwendet, braucht man 
keinen Komparator mehr am Eingang? ;-)

von Alex H. (hoal) Benutzerseite


Lesenswert?

Axel Schwenke schrieb:
> Angenommen ich habe eine normalverteilte Zufallsgröße x1 mit Mittelwert
> m1 und Standardabweichung s1. Daraus konstruiere ich mir eine neue
> Zufallsgröße x2, wobei jeder Wert von x2 das Mittel von N Werten von x1
> ist.
>
> Dann sollte x2 den gleichen Mittelwert m2 = m1 haben und eine
> Standardabweichung s2 = s1/sqrt(N). Korrekt?

Nein. Wenn man eine Verteilung voraussetzt, sind mit ihr bereits ein 
Erwartungswert und eine Standardabweichung gegeben. Sie werden mit mehr 
Messwerten besser angenähert, jedoch wird die Standardabweichung dadurch 
nicht kleiner.

Aus N Messwerten errechnest du die Standardabweichung

Wenn du nun N um einen Faktor erhöhst, teilst du zwar durch diesen 
höheren Wert, die Summe hat aber auch entsprechend mehr Summanden. Die 
Standardabweichung bleibt bis auf statistische Schwankungen gleich.

von Axel S. (a-za-z0-9)


Lesenswert?

Alex H. schrieb:
> Axel Schwenke schrieb:
>> Angenommen ich habe eine normalverteilte Zufallsgröße x1 mit Mittelwert
>> m1 und Standardabweichung s1. Daraus konstruiere ich mir eine neue
>> Zufallsgröße x2, wobei jeder Wert von x2 das Mittel von N Werten von x1
>> ist.
>>
>> Dann sollte x2 den gleichen Mittelwert m2 = m1 haben und eine
>> Standardabweichung s2 = s1/sqrt(N). Korrekt?
>
> Nein. Wenn man eine Verteilung voraussetzt, sind mit ihr bereits ein
> Erwartungswert und eine Standardabweichung gegeben. Sie werden mit mehr
> Messwerten besser angenähert, jedoch wird die Standardabweichung dadurch
> nicht kleiner.

Wir reden offensichtlich vollkommen aneinander vorbei.

Dann laß mich meine Frage aus deiner deskriptiven Sicht der Dinge neu 
formulieren: Wenn ich N Meßwerte habe und eine Normalverteilung 
unterstelle, dann kann ich Schätzwerte für die Verteilungsparameter m 
(Mittelwert) und s (Standardabweichung) anhand der bekannten Formeln 
berechnen. So weit, so gut.

Nun stellt sich aber die nächste Frage: wie genau sind diese 
Schätzungen? Insbesondere interessiert mich, wie nah liegt der 
Mittelwert m_N aus meinen N Messungen am wahren Mittelwert m der 
Zufallsquelle?

Und dafür kann man m_N wieder selber als Zufallsgröße ansehen. Wenn man 
immer wieder N Messungen machen und den Mittelwert bilden würde, dann 
wären diese Mittelwerte wieder eine Zufallsfolge. Es ist leicht 
einzusehen, daß der echte Mittelwert dieser Folge auch wieder m ist. Es 
ist auch intuitiv klar, daß die Streuung der m_N kleiner sein wird als 
die Streuung der ursprünglichen Meßwerte. Und ich glaube mich zu 
erinnern, daß es genau ein Faktor von sqrt(N) ist.

So, jetzt ist mir gerade noch das Stichwort dazu eingefallen: "mittlerer 
Fehler des Mittelwerts". Damit findet Google dann auch 
http://wwwex.physik.uni-ulm.de/lehre/fehlerrechnung/node15.html

Alzheimer hat mich also noch nicht :)


XL

von Alex H. (hoal) Benutzerseite


Lesenswert?

Axel Schwenke schrieb:
> Wir reden offensichtlich vollkommen aneinander vorbei.
> [...]
> So, jetzt ist mir gerade noch das Stichwort dazu eingefallen: "mittlerer
> Fehler des Mittelwerts". Damit findet Google dann auch
> http://wwwex.physik.uni-ulm.de/lehre/fehlerrechnung/node15.html

Stimmt, da haben wir verschiedene Dinge gemeint. Die _Standardabweichung 
des Mittelwertes_ wird mit mehr Messungen genau wie im Link beschrieben 
kleiner. Um es mit den Bezeichnungen von vorhin auszudrücken:
mit
> Alzheimer hat mich also noch nicht :)

Nein, hat es nicht :)

von Ulrich (Gast)


Lesenswert?

Um die Sache mit der Statistik noch etwas komplizierter zu machen, sind 
die Zeiten für die einzelnen Perioden in der Regel nicht unabhängig 
voneinander. Eine bessere Annahme ist das die Fehler bei den einzelnen 
Zeitpunkten unabhängig sind. Die mittlere Periodenlänge bestimmt man als 
/Endzeit - Startzeit) / N . Als mittlere Fehler für die Periodenlänge 
hat man so Wurzel 2 mal dem Fehler der einzelnen Zeitmessung geteilt 
durch N.

Sonst kommt auch beim mitteln unabhängiger normalverteilter Größen der 
Farkor Wurzel N mit rein. Für die Standardabweichung ist das Unabhängig 
von der Verteilung, solange man da keine Unendlichkeiten mit rein 
bekommt.

Mit dem Weg über die Geradensteigung könnte man statt dem N im Nenner 
auf etwa 1/ sqrt(12) * N^1,5  kommen.  Das ist etwas besser, aber bei 
dem eher kleinen N ( z.B. etwa 300 für 1 kHz) für kleine Frequenzen auch 
nicht so viel.

von Axel S. (a-za-z0-9)


Lesenswert?

Ulrich schrieb:
> Mit dem Weg über die Geradensteigung könnte man statt dem N im Nenner
> auf etwa 1/ sqrt(12) * N^1,5  kommen.  Das ist etwas besser, aber bei
> dem eher kleinen N ( z.B. etwa 300 für 1 kHz) für kleine Frequenzen auch
> nicht so viel.

Hast du dazu mal noch ein paar Details? Pointer reicht.

Mir ist nicht klar, was du aus den einzelnen Meßwerten an zusätzlicher 
Information rausholen willst. Oder worauf sich die Vermutung gründet, 
der Jitter einzelner Signalflanken wäre statistisch nicht unabhängig.

Wenn wir z.B. von überlagertem Rauschen ausgehen, das die 
Triggerschwelle verschiebt, denn ist das statistisch sauber.


XL

von Ulrich (Gast)


Lesenswert?

Die einzelnen Zeiten der Flanke sind schon mit relativ unabhängigen 
Fehlern behaftet. Wenn man aber die Periodenlänge über viele Perioden 
mittelt, sind die einzelnen Periodenlängen korreliert, weil die 
Startzeit der einen gerade die Stoppzeit der vorherigen ist.

Ein Link für die Frequenzbestimmung per Regression:
http://www.mwrf.com/Articles/Index.cfm?ArticleID=12529&pg=2


Das einfache Verfahren, so wie es der hier in Thread beschriebene Zähler 
nutzt, nutzt nur die Zeiten zur ersten und letzten Flanke.

Zusätzliche Information kann man aus den Zeiten der anderen Flanken 
gewinnen.
Man kann z.B. auch die Periodenlänge aus der 2.ten und vorletzen Flanke 
bestimmen. Das ist weniger genau, aber hinsichtlich Jitter eine 
unabhängige Messung. Wenn man das dann über alle Daten macht, und 
gewichtet mittelt, kommt auch auf die gleiche Formel wie bei der 
Regression.

von Old P. (Gast)


Lesenswert?

Frank schrieb:
>>Mehr als 7 Stellen bei 1KHz Messfrequenz sind einfach nicht drin.
>
> Damit wäre Opa ja schon überglücklich ;-)

Nö, 6 Stellen reichen, die siebente würde eh nur zappeln. Aber zum 
testen wäre es schon interessant.

>>Dämpfung und LP fallen allerdings aus, bleibt noch etwas, ...
>
> Warum? Soll es funktionieren oder nur schön aussehen?

Nochmal nö, irgendwie ist aber die Forderung nach hoher oberer 
Grenzfrequenz und dann ein LP ein Widerspruch. Und Dämpfung mach bei eh 
schon schwachen Signalen auch nicht wirklich Sinn. Oder habe ich was 
missverstanden?

> OPVs sind für höhere Frequenzen als Komparator nicht gut geeignet.

Ich meinte ja auch. mit OPV vorverstärken und dann in den HC132 rein. 
Das ist mit dieser Platine ja durchaus möglich, etwas frickeln muss man 
dann.

Old-Papa

von Axel S. (a-za-z0-9)


Lesenswert?

Moin Uli,

Ulrich schrieb:

> Ein Link für die Frequenzbestimmung per Regression:
> http://www.mwrf.com/Articles/Index.cfm?ArticleID=12529&pg=2

Danke. Mit besseren Suchbegriffen habe ich dieses schöne Paper gefunden:

http://www.cqham.ru/forum/attachment.php?attachmentid=72572

> Das einfache Verfahren, so wie es der hier in Thread beschriebene Zähler
> nutzt, nutzt nur die Zeiten zur ersten und letzten Flanke.

Richtig. Bezugnehmend auf obigen Artikel ist das das einfache 
"Reciprocal Counter" Verfahren mit einem statistischen Fehler von 
sqrt(2)/MINCYCLES.

> Zusätzliche Information kann man aus den Zeiten der anderen Flanken
> gewinnen.

Wobei die von dir gezeigten Artikel aber zuvörderst die Erhöhung der 
Auflösung bei gegebener Meßzeit und gegebener Referenzfrequenz 
verfolgen. Mit etwaigem Jitter hat das erstmal nichts zu tun.

Allerdings (und da muß ich erst noch mal etwas länger drüber nachdenken) 
könnte die Regressionsmethode auch gegen Jitter helfen. Leider sind die 
letzen Seiten zur Allan-Abweichung etwas knapp.

Übrigens: ich glaube, man könnte das Regressionsverfahren mit nur 
minimalen Änderungen an meiner Hardware implementieren. Der 74HC590 hat 
ja ein Latch. Man müßte nur das Gate-Flipflop zur Steuerung des Latches 
verwenden. Der Zähler würde dann permanent durchlaufen und zu bestimmten 
Zeitpunkten (synchron zu f_x) würde man einen Timestamp nehmen (per 
Capture-Unit) und den Zählerstand latchen. Die beschränkte Leistug des 
Mega8 würde dann nur den minimalen Zeitabstand zwischen den Samples (das 
pacing interval) beschränken. Und RAM könnte knapp werden.

Eine andere Frage ist natürlich, ob man das wirklich braucht. 
Schließlich muß man erstmal eine Referenz haben, die die notwendige 
Grundgenauigkeit und Stabilität für mehr als 7 Stellen hat.

PS: die Suche nach Pendulum AB führt hier her 
http://www.spectracomcorp.com/Support/HowCanWeHelpYou/Library/tabid/59/Default.aspx?EntryId=311


XL

von Ralph B. (rberres)


Lesenswert?

Axel Schwenke schrieb:
> Schließlich muß man erstmal eine Referenz haben, die die notwendige
>
> Grundgenauigkeit und Stabilität für mehr als 7 Stellen hat.

Das hängt davon ab wie man ihn einsetzen will. Als Display für einen 
einfachen NF Generator mag der Quarz auf der Leiterplatte sicherlich 
stabil genug sein. Will man aber dieses Modul für einen vollwertigen 
Laborfrequenzzähler einsetzen, dann wär ohnehin sinnvoll einen 10MHz 
Referenzfrequenzeingang vorzusehen. Ob man dann einen teuren Quarzofen 
mit ins Gehäuse setzt, einen Rubidiumnormal . oder ob man das Gerät an 
eine für alle Laborgeräte gemeinsam genutzte Referenzfrequenz 
anschließt, so wie ich es z.B. mache, sollte dann jeden freigestellt 
bleiben.

Ralph Berres

von Old P. (Gast)


Angehängte Dateien:

Lesenswert?

Hallo Ralph,

als Laborfrequenzzähler wird man dieses "Mörkelteil" eher nicht 
verwenden. Als "Skala" für Eigenbaugeneratoren ist der aber gut 
geeignet. Meins kommt in einen kleinen Rechteckgenerator mit dem 
LTC1799. Eventuell auch noch in einen NF-Generator und mal sehen wo 
noch....

Ansonsten habe ich heute noch ein paar Versuche mit dem bösen Komparator 
gemacht. Fazit: Bringt bei NF nur bedingt was. Wenn ich in den mit 
Rechteck reingehe, schaltet sein Ausgang bei etwa 200mV(ss) sauber 
durch. Bei Sinus erst bei etwa 300mV(SS) und unter 200Hz wirds unsauber 
(ja Franz, Du hattes ja recht... ;-)) Ab etwa 5kHz geht das dagegen sehr 
gut, dazwischen ist Glücksache....

Jetzt habe ich nur noch den HC132 drauf, wobei ich an dessen Eingang je 
10k nach Masse und Ub gelegt habe. Der 10k nach Masse ersetzt den in der 
Platinenzeichnung angegebenen 51Ohm, den 10k nach Ub habe ich direkt am 
IC gelötet (s. Foto).
Fazit: Bei Rechteck braucht das jetzt ca. 1,5V(ss) um sauber zu zählen. 
Bei Sinus etwa 1,7V(ss).

So lass ich das jetzt, wenn die Zielgeräte diese Spannung nicht liefern, 
muss halt vorverstärkt werden. Wie schon geschrieben, eventuell kann man 
die Lötpads für den TLV3501 dafür verwursten. Pinkompatible OPVs gibt es 
ja.

Old-Papa

von Uwe S. (de0508)


Angehängte Dateien:

Lesenswert?

Hallo Old-Papa,

ich möchte Dir und euch die von mir verwendet Eingangsbeschaltung vor 
einem 74HC132 vorstellen. Sie stammt von einem QRPProjekt: "Digital 
Readout".
Im Qrpshop findet man ihn unter "ZaehlerLCD".

Ich habe diesen Vorverstärker auch x-mal aufgebaut und betreibe ihn mit 
dem

Beitrag "Reziproker Frequenzzähler+ Optimierte 64bit uint Routinen"

.

von Frank (Gast)


Lesenswert?

Old -papa schrieb:
> (ja Franz, Du hattes ja recht... ;-))

Und ich dachte, das rafft er nie ;-)
..HC132 ist keine gute Wahl für hohe Frequenzen. 74AC04 ist schneller.

Auf der mino Seite ist eine Schaltung mit Komparator.
http://www.mino-elektronik.de/fmeter/eingangsstufe.htm
Die scheint stabil zu arbeiten; probiere es doch einmal damit.

von Old P. (Gast)


Lesenswert?

Frank schrieb:
> Und ich dachte, das rafft er nie ;-)

Ja und Nein! Klar habe ich das gerafft, hatte ich auch schon vorher 
geahnt. Aber Versuch macht (erst) kluch.... Ich gehöre zu den Menschen, 
die manchmal ihre schlechten Erfahrungen noch selbst machen wollen ;-)))

> ..HC132 ist keine gute Wahl für hohe Frequenzen. 74AC04 ist schneller.

Bis 66MHz keine Probleme und das ist eh mehr als die anderen ICs 
eigentlich können sollen. Reicht also. Der 74xy04 ist auch kein 
Trigger....

> Auf der mino Seite ist eine Schaltung mit Komparator.
> http://www.mino-elektronik.de/fmeter/eingangsstufe.htm
> Die scheint stabil zu arbeiten; probiere es doch einmal damit.

Bestimmt nicht! Viel zuviele Bauteile (zumindest für diese Platine) und 
dann auch noch +/- 9Volt. Absolut nogo!

Dann doch lieber die Schaltung von Uwe S. In SMD könnte das Zeugs sogar 
noch auf die Platine passen. Aber Uwe will ja eine komplett-SMD-Platine 
routen, das hat dann mehr Sinn.

Gruß
Old-Papa

von Ulrich (Gast)


Lesenswert?

Das Verfahren mit der Regression hilft genauso auch gegen Jitter. Es 
wird einfach verbessert wie sich der Fehler der Zeitmessung in den 
Frequenzfehler fortpflanzt.  Allerdings ist der Vorteil auch nicht so 
groß. 1 s Torzeit und 50 Hz liegt der Gewinn bei knapp einem Faktor 3 im 
Rauschen. Bei 600 Hz dann etwa ein Faktor 10, also eine Stelle mehr.

Das RAM ist nicht das Problem, denn man muss nicht alle Messwerte 
speichern man muss nur ein paar Summen bilden und kann den größten Teil 
der Rechnung in Echtzeit durchführen. Als RAM sollten dafür etwa 50 
Bytes reichen. Eine gewisse Begrenzung ist die Geschwindigkeit, um es in 
Echtzeit zu schaffen. In ASM würde ich schätzen das man es vielleicht 
bis 50 kHz schafft mit dem Mega88. In C könnte es einiges Langsamer 
werden, weil man wohl mehr als 32 Bit Auflösung braucht. ASM ist da bei 
Multiplikationen von 24 Bit x 24 Bit einfach im Vorteil.

Hardwaremäßig ist der Aufwand nicht unbedingt größer als bei der 
Schaltung oben. Einfach nur ein Umschaltbarer Vorteiler, um die Frequenz 
auf unter ca. 20 kHz runter zu teilen. Der Aufwand ist eher auf der 
Softwareseite - vielleicht 1 kByte in ASM.  Dabei wäre dann zu überlegen 
ob man dann nicht lieber einen schnelleren µC nimmt und dann zusätzliche 
Funktionen wie Jittermessung und ggf. eine Erkennung von 
Fehltriggerungen mit integriert.

von Axel S. (a-za-z0-9)


Angehängte Dateien:

Lesenswert?

Moin,

hier kommt eine Variante des Frequenzzählermoduls, stilecht mit 6-Digit 
LED-Display. Das LED-Display kann einfach an die 14-Pin Schnittstelle 
für das LCD angeflanscht werden mit folgender Pinbelegung:

1. GND
2. +5V
3 . nicht benutzt (LCD: Konstrastspannung)
4. Digit-Select 0 (LCD: RS)
5. Digit-Select 1 (LCD: R/W)
6. Digit-Select 2 (LCD: E)
7-14. Segment A-G, Dezimalpunkt

Digit-Select 0-2 kommen an A,B,C eines 74HC138 (oder ähnlich). Die 6 
Stellen sind gemappt auf Q0..Q5 (vlnr). Q6 steuert 4 Einzel-LED für die 
Anzeige der Einheit Hz (Segment A), kHz (Segment B), MHz (Segment C) und 
Overflow (Dezimalpunkt).

In meinem Testaufbau treibt der Mega8 die Segment-Kathoden direkt (mit 
82R Vorwiderständen). Die Anoden werden von BC327 geschaltet. Die LED 
sind 2x TOT-4301FG (Pollin).

Wer mehr Strom braucht, kann Treiber für die Segmente vorsehen. Die 
Zuordung von Segmenten zu Bits und eine evtl. Inversionsmaske sind in 
ports.h definiert. Wenn man die Konfiguration über Jumper verwenden will 
(derzeit ungenutzt) müssen die Segment-Treiber hochohmig genug sein, um 
die Eingänge des Mega8 mit aktivierten Pullups ein H sehen zu lassen. 
Das ist praktisch nur mit FETs zu schaffen.


Viel Spaß damit!

XL

von Old P. (Gast)


Angehängte Dateien:

Lesenswert?

Hallo Axel,

feine Sache. Für meinen Zweck (Batterieversorgung) nicht machbar, doch 
wo das passt....
Vor Jahren hatte ich mal für eine ähnliche Aufgabe und für mein 
Universaltestboard eine "LCD-Kompatibele" LED-Platine gestrickt. Zum WE 
könnte ich ja mal versuchen eine neue Platine zu häkeln.

Gruß
Old-Papa

von Axel S. (a-za-z0-9)


Lesenswert?

Moin,

Old -papa schrieb:
> Vor Jahren hatte ich mal für eine ähnliche Aufgabe und für mein
> Universaltestboard eine "LCD-Kompatibele" LED-Platine gestrickt.

Hmm. Wobei mehr als 8 Stellen mit LED ja nicht realistisch sind.

> Zum WE könnte ich ja mal versuchen eine neue Platine zu häkeln.

Mir schwebt eine SMD-Variante vor. Segmenttreiber BSS138 o.ä. 
Digittreiber BC807. Leider ist die Pinbelegung bei LED-Displays sehr 
heterogen, so daß ein Universal-Layout kaum machbar ist.

Wenn man sich nicht auf die 14-Pin Schnittstelle festlegt, kann man auch 
noch ein paar Pins am Mega8 umwidmen und auf den Digit-Decoder 
verzichten. Für den Einsatz als digitale Skala würden ja auch schon 4 
Stellen reichen.


XL

von Old P. (Gast)


Lesenswert?

Hallo Axel,

nein, 6 Stellen reichen durchaus, aber vier Stellen finde ich für eine 
Skala schon zu wenig.

Schick mir doch mal ne Mail mit Deinen Vorstellungen, ich könnte ja eine 
Platine zeichnen. SMD ist zwar möglich, doch nur bei vielen 
Durchkontaktierungen oder sehr dünnen Leiterbahen mit knappem Abstand. 
Für industrielle Platine durchaus gut machbar, bei Homemade-Platinen 
zwar auch, doch die Durchkontaktierungen nerven dann. Mal sehen wie ich 
mit den Größen so hinkomme. Notfalls werden das wieder 2 Platinen im 
Sandwich. DIL hat halt den Vorteil, dass man bequem zwischen den Pins 
hindurch Leiterbahnen verlegen kann.

Die LED-Anzeigen haben bei Einzelelementen schon ein 
"Fast-Standardpinning", zumindest habe ich viele unterschiedliche Teile 
mit dem gleichen Pinning, mal oben/unten quer oder links/rechts 
senkrecht.

Gruß
Old-papa

von Günter F. (steiner)


Lesenswert?

Hallo zusammen,
geht's hier noch weiter ???
Ich suche immer noch einen Frequenzzähler
als Bausatz, 1Mhz reicht.

mfg steiner

von Old P. (Gast)


Lesenswert?

Hallo Günter,

einen kompletten Bausatz hatte hier wohl keiner versprochen....
Doch wenn das sein muss, stellt Dir mein Bastelkumpel gerne alles 
zusammen (incl. Platine). Das müsstest Du dann mit ihm aushandeln: 
lilliput ät uwe-treutler.de Er ist aber nicht täglich an seinen Mails, 
es kann halt 2-3 Tage dauern bis er antwortet.

Das gilt auch für andere Interessenten, zumindest Platinen hat er wohl 
noch welche da.

Gruß
Old-Papa

von m.n. (Gast)


Lesenswert?

Christian K. schrieb:
> Ich habe den Zähler von MiNo nachgebaut und bin begeistert. Wenn man
> noch einen 20-MHz-TCXO spendiert, dürfte auch die letzte Stelle bei
> schwankender Temperatur stillstehen.

Hast Du schon etwas in Richtung TCXO unternommen?
Aktuell habe ich mir Winzlinge mit 16,3676MHz herausgesucht, wie sie in 
GPS-Anwendungen eingesetzt werden. Der große Vorteil: kleiner Preis und 
sehr stabil mit 0,5ppm über -30/+75°C.

Diese TCXOs liefern bei 3,3V nur ein Signal mit ca. 1Vss, was aber kein 
Problem ist. Das Signal kann man über 1-100nF direkt an XTAL1 einkoppeln 
und den µC so betreiben, als ob er einen ext. Quarz verwenden soll. 'Low 
power' oder 'full swing' Modus funktionieren beide zuverlässig.

Das dürfte auch für andere Anwendungen interessant sein. Man muß sich 
die Software nur für diese Frequenz anpassen.

Vielleicht mache ich noch einmal eine Leiterplatte, die auf diese TCXOs 
abgestimmt ist und als Eingangsstufe ggf. einen MAX961 dazu - wenn Zeit 
dafür ist.

von Charly B. (charly)


Lesenswert?

m.n. schrieb:

> Aktuell habe ich mir Winzlinge mit 16,3676MHz herausgesucht, wie sie in
> GPS-Anwendungen eingesetzt werden. Der große Vorteil: kleiner Preis und
> sehr stabil mit 0,5ppm über -30/+75°C.

Ja unn wo iss das Datenblatt ??? damit die anderen sich auch daran
erfreuen koennen .......

von m.n. (Gast)


Lesenswert?


von Charly B. (charly)


Lesenswert?

m.n. schrieb:

> Immer diese Drängler :-)
ja genau, i kann die auch nicht leiden :)

unn wo kann man das Teil f. kleines Geld kaufen ?

von m.n. (Gast)


Lesenswert?


von Christian K. (at90s2313)


Lesenswert?

m.n. schrieb:
> Christian K. schrieb:
>> Ich habe den Zähler von MiNo nachgebaut und bin begeistert. Wenn man
>> noch einen 20-MHz-TCXO spendiert, dürfte auch die letzte Stelle bei
>> schwankender Temperatur stillstehen.
>
> Hast Du schon etwas in Richtung TCXO unternommen?

Ja, ich habe einen TCXO von IQD Typ CFPT-141 20 MHz +- 2,5 ppm (Farnell 
1100745) eingesetzt.

> Aktuell habe ich mir Winzlinge mit 16,3676MHz herausgesucht, wie sie in
> GPS-Anwendungen eingesetzt werden. Der große Vorteil: kleiner Preis und
> sehr stabil mit 0,5ppm über -30/+75°C.
>
> Diese TCXOs liefern bei 3,3V nur ein Signal mit ca. 1Vss, was aber kein
> Problem ist. Das Signal kann man über 1-100nF direkt an XTAL1 einkoppeln
> und den µC so betreiben, als ob er einen ext. Quarz verwenden soll.

Die Erfahrung habe ich auch gemacht. Sieht etwa so aus wie auf folgendem 
Bild: http://www.qsl.net/k0lr/ZL1BPU%20Exciter/all-1dds.gif

> 'Low power' oder 'full swing' Modus funktionieren beide zuverlässig.

Gut zu wissen.

> Das dürfte auch für andere Anwendungen interessant sein. Man muß sich
> die Software nur für diese Frequenz anpassen.

Die Software liegt nur als HEX-File vor. Und dort ist eine Frequenz von
20 MHz fest "verdrahtet". Deshalb mußte ich einen TCXO mit 20 MHz 
verwenden. Andererseits ergibt sich damit auch eine hohe Meßrate bei 
gegebener Auflösung.

Christian.

von m.n. (Gast)


Lesenswert?

Christian K. schrieb:

> Ja, ich habe einen TCXO von IQD Typ CFPT-141 20 MHz +- 2,5 ppm (Farnell
> 1100745) eingesetzt.

Gut, man muß seinen Kompromiß zwischen Preis und Stabilität finden; mit 
1100754 gäbe es auch eine 0,5ppm 20MHz Ausführung zu dreifachem Preis.

>> 'Low power' oder 'full swing' Modus funktionieren beide zuverlässig.
>
> Gut zu wissen.

Der ATtiny2313 hat wohl nur den 'low power' Modus, bei dem an XTAL2 kein 
brauchbares Taktsignal ausgegeben wird. Das hatte mich anfangs 
irritiert. Bei einem Mega48 usw. gehen beide Einstellungen.

> Die Software liegt nur als HEX-File vor. Und dort ist eine Frequenz von
> 20 MHz fest "verdrahtet". Deshalb mußte ich einen TCXO mit 20 MHz
> verwenden. Andererseits ergibt sich damit auch eine hohe Meßrate bei
> gegebener Auflösung.

Es gibt jetzt auch eine 16,3676MHz Version. Oft passe ich meine 
Schaltungen den verfügbaren Bauteile an und nicht dem, was optimal wäre.
Damit vermeidet man Lieferschwierigkeiten und unnötige Kosten :-)

von Christian K. (at90s2313)


Lesenswert?

m.n. schrieb:
> Christian K. schrieb:
>> Ja, ich habe einen TCXO von IQD Typ CFPT-141 20 MHz +- 2,5 ppm (Farnell
>> 1100745) eingesetzt.
>
> Gut, man muß seinen Kompromiß zwischen Preis und Stabilität finden; mit
> 1100754 gäbe es auch eine 0,5ppm 20MHz Ausführung zu dreifachem Preis.

Gerade habe ich bei RS einen 20-MHz-TCXO mit einer Stabilität von 
±0,5ppm für 2,90 EUR gefunden: 
http://de.rs-online.com/web/search/searchBrowseAction.html?method=getProduct&R=7099379
Dieser TCXO ist damit etwas billiger als der weiter o.g. von Digikey.

> Der ATtiny2313 hat wohl nur den 'low power' Modus, bei dem an XTAL2 kein
> brauchbares Taktsignal ausgegeben wird. Das hatte mich anfangs
> irritiert.

Ja, so steht es z.B. in der Application Note AVR091: Replacing AT90S2313 
by ATtiny2313:
1
The crystal Oscillator in AT90S2313 is capable of driving an additional clock buffer from
2
the XTAL2 output. The ATtiny2313 does not have a rail-to-rail swing on oscillator pins
3
and can therefore not be used for this purpose. Note however that the new Clock Out
4
(CKOUT) feature could alternatively be used to drive an additional clock buffer.

> Es gibt jetzt auch eine 16,3676MHz Version. Oft passe ich meine
> Schaltungen den verfügbaren Bauteile an und nicht dem, was optimal wäre.
> Damit vermeidet man Lieferschwierigkeiten und unnötige Kosten :-)

Klar :-)

Christian.

von m.n. (Gast)


Lesenswert?

Christian K. schrieb:
> Gerade habe ich bei RS einen 20-MHz-TCXO mit einer Stabilität von
> ±0,5ppm für 2,90 EUR gefunden:
> http://de.rs-online.com/web/search/searchBrowseAct...
> Dieser TCXO ist damit etwas billiger als der weiter o.g. von Digikey

Der Preis für einen TCXO ist äußerst günstig.
Aber: an keiner Stelle finde ich im Datenblatt eine explizite Aussage, 
dass die Frequenzstabilität über -20/+70°C ±0,5ppm beträgt. Und was RS 
als allgemeine Daten angibt, ist zu oberflächlich und frei 
interpretierbar.

Aber selbst, wenn nur ±2,5ppm über den Temperaturbereich erreicht 
werden, ist das ein sehr verlockendes Angebot. Der Oszillator ist damit 
mindestens Faktor 10 besser als ein einfacher Quarz und auch ohne 
Abgleich "gebrauchsfertig".

Ein guter Tipp!

von Christian K. (at90s2313)


Lesenswert?

m.n. schrieb:
> Christian K. schrieb:
>> Gerade habe ich bei RS einen 20-MHz-TCXO mit einer Stabilität von
>> ±0,5ppm für 2,90 EUR gefunden:
>> http://de.rs-online.com/web/search/searchBrowseAct...
>> Dieser TCXO ist damit etwas billiger als der weiter o.g. von Digikey
>
> Der Preis für einen TCXO ist äußerst günstig.
> Aber: an keiner Stelle finde ich im Datenblatt eine explizite Aussage,
> dass die Frequenzstabilität über -20/+70°C ±0,5ppm beträgt. Und was RS
> als allgemeine Daten angibt, ist zu oberflächlich und frei
> interpretierbar.

Auf der Hersteller-Website

http://www.taitien.com.tw/en/products_vctcxo.aspx

gibt es ein Datenblatt und ein Model Numbering Guide-TCXO. Im Datenblatt 
wird bzgl. der ppm-Kategorien von "FREQ. STABILITY vs. TEMP. RANGE" 
geschrieben. RS gibt folgende Typenbezeichnung an: TVETADSANF-20.0MHZ. 
Demnach erstreckt sich der Temperaturbereich A von -30 bis +85°C. Also 
sollte die ±0,5ppm Stabilität in diesem Temperaturbereich eingehalten 
werden. Die Frequenztoleranz bei 25°C beträgt laut Datenblatt ±2ppm.

Christian.

von Schimmelreiter (Gast)


Lesenswert?

Ganz unten auf der Webseite von RS kann man das Datenblatt laden.

Der Preis ist so günstig, dass man sich fragt "wo ist der Haken?"

von Thomas R. (tinman) Benutzerseite


Lesenswert?

Schimmelreiter schrieb:
> Ganz unten auf der Webseite von RS kann man das Datenblatt laden.
>
> Der Preis ist so günstig, dass man sich fragt "wo ist der Haken?"

klar gibt nen Hacken, es ist ein "Clipped Sine Wave" XO mit Vpp von 0.8V
und kein CMOS level XO. So ein signal muss auch erst in rechteck 
umgewandelt werden (sonst wird nix mit gate/count) und natürlich level 
konvertiert.

von Schimmelreiter (Gast)


Lesenswert?

Thomas R. schrieb:
> klar gibt nen Hacken, es ist ein "Clipped Sine Wave"

als Haken seh ich das nicht an, eher als Alternative, hab vor 
Jahresfrist noch für 100 Stück 9,- EUR/Stück gezahlt(+/-1ppm-Typen).

von Christian K. (at90s2313)


Lesenswert?

Thomas R. schrieb:
> Schimmelreiter schrieb:
>> Der Preis ist so günstig, dass man sich fragt "wo ist der Haken?"

Vielleicht hat sich RS bzgl. Preis bei der Kommastelle vertan ;-)
Einen Haken kann man wohl nur ausschließen, wenn man den Frequenzgang 
eines solchen TCXO über der Temperatur ausmißt.

> klar gibt nen Hacken, es ist ein "Clipped Sine Wave" XO mit Vpp von 0.8V
> und kein CMOS level XO. So ein signal muss auch erst in rechteck
> umgewandelt werden (sonst wird nix mit gate/count) und natürlich level
> konvertiert.

Wie oben schon geschrieben, kann man die Clipped Sine Wave direkt an 
XTAL1 des µC einspeisen. Dann kann man bei älteren AVRs an XTAL2 ein 
Clock-Signal abgreifen. Bei neueren AVRs kann man die CKOUT-Fuse setzen 
und den Takt an einem bestimmten Pin abgreifen.

Außerdem beschreibt der TCXO-Hersteller in einer Application Note die 
Signalwandlung, z.B. durch einen 74HC04-Inverter mit 
Rückkopplungs-Widerstand.

Utilize Clipped Sine Waveform in Circuit Design
http://www.taitien.com.tw/db/pictures/modules/CMS/CMS060207001/AP20100105-Utilize%20Clipped%20Sine%20Waveform%20in%20Circuit%20Design.pdf

Christian.

von m.n. (Gast)


Lesenswert?

Christian K. schrieb:
> Auf der Hersteller-Website
> http://www.taitien.com.tw/en/products_vctcxo.aspx
> gibt es ein Datenblatt und ein Model Numbering Guide-TCXO.

Ich hatte auch noch beim Hersteller nachgesehen, aber nichts Eindeutiges 
gefunden. Beim Kyocera-TCXO stehen alle Angaben im Datenblatt, sodass 
man nicht suchen oder raten muß.

Schimmelreiter schrieb:
> Der Preis ist so günstig, dass man sich fragt "wo ist der Haken?"

Das war der Grund für meine Suche :-)
Der von mir genannte KT3225 ist noch abstimmbar, was dann nützlich ist, 
wenn die Frequenz exakt benötigt wird und nicht per µC 'trimmbar' ist.

Wie auch immer, die Teile sind klein und fein!

von W.S. (Gast)


Lesenswert?

Hallo ihr Bastler!
Dieser Thread ist ja ganz schön lang und stellenweise auch recht 
interessant, aber mir kommen da ein paar ganz grundsätzliche Fragen:

1. Warum muß es denn ein Atmel als Rechenkern sein, wenn ihr schon bei 
den kleinsten Berechnungen damit an die Speicherecken anstoßt? 
Mittlerweile gibt es wirklich billige ARMs, wo man bequem alles in 
'double' rechnen kann und gut ist. Ist es die Lust am Minimalismus? Nun, 
ich hatte vor über 10 Jahren mir meinen Frequenzzähler für den 
Bastelkeller mit einem simplen PIC und einem Einzelgatter-Bustreiber 
(UHS-Serie von Fairchild), einem aus einem alten Radio ausgelöteten 
Sanyo-LCD-Treiber und einem 6 stelligen LCD gebastelt - aber nicht aus 
Drang nach 'QRP', sondern aus der Not heraus. Ein entsprechend hartes 
Brot war deshalb auch die ganze Programmierung (Ich mache sowas nie 
wieder!). Das sieht heutzutage alles ganz anders aus. Aber immerhin, der 
PIC-Zähler geht bis etwa 85 MHz.

2. Warum benutzt ihr immer noch Standard-TTL für das Frontend? Die auf 
der Leiterplatte herumgerouteten Verbindungen zwischen den einzelnen 
Gattern machen euch das Leben nur schwer, denn sie sind (neben der 
Masseproblematik) ein Grund dafür, daß die Zahl der benutzbaren Stellen 
niedriger ist als erhofft. Nehmt ein kleines CPLD (hab eben grad bei 
TME.EU nachgeguckt, ein XC9536 von Xilinx kostet dort so etwa 2..3 
Euro). Mit so einem Teil kann man die Leitungsführung auf der LP 
dramatisch vereinfachen und verkürzen und hat damit deutlich weniger an 
layoutbedingten Störungen. Obendrein hat man da drin das Äquivalent von 
36 Flipflops und einer Menge Gattern und 100 MHZ schaffen die Dinger 
auch. Und die Soft dazu gibt's für umsonst. Das sollte doch Grund genug 
sein - oder?

3. Warum all diese Eingangsschaltungsprobleme? Ich hatte mal für 
ähnliche Zwecke eine recht einfache Eingangsschaltung mit einem ADA4871 
(Analog Devices) ausprobiert, mit der man bequem einen üblichen 
Oszillografen-Eingang hinbekommt, also 1 MOhm und 20..30pF und ne 
Bandbreite weit über die 160 MHz hinaus, die ich mit meinem 
Netzwerkanalysator messen kann. Hinter diesem OpV kann's dann mit 50 Ohm 
weitergehen, also Filter usw. vor dem eigentlichen Zähleingang. Prinzip: 
Vorteiler 180k/820k, kompensiert mit 10pF/39pF (ausprobieren), dann 
nichtinvertierender Verstärker V=2 bis höchstens 4 und fertig.

Ach ja, Fragen über Fragen. Aber vielleicht ist das was uns ärgert 
irgendwann auch mal eine Anregung...

Frohes Basteln wünscht
W.S.

von Bastler (Gast)


Lesenswert?

W.S. schrieb:
> 1. Warum muß es denn ein Atmel als Rechenkern sein, wenn ihr schon bei
> den kleinsten Berechnungen damit an die Speicherecken anstoßt?

Stimmt doch garnicht. Und was ist denn ein "Atmel"?

4. Warum werden die Schaltungen mit 5V versorgt, eine Batterie hat doch 
nur 1,5V?

5. Warum wird denn als Anzeige kein TFT verwendet?

Man kann alles in Frage stellen, aber reale Lösungen erfordern, sich auf 
einen Weg festzulegen.
Ein ADA4871 kostet natürlich nur 50 Cent und wird von Jedermann 
stangenweise eingesetzt? Wohl kaum!

von Padex (Gast)


Lesenswert?

W.S. Willkommen in der Frequenzzähler-Gemeinde.
Danke für den guten Tipp mit dem ADA4871. Darüber sollte
man mal gründlich nachdenken.

Aber nun zu meinem eigentlichen Grund dieses Posts.
Danke an Axel, für diesen Super-Thread und an die anderen
die sich hier so erfolgreich engagiert haben. Ich habe hier
viel gelernt.

Ich weiß, es ist nicht mein Thread. Aber dennoch.

Ausgangspunkt war es, ein Frequenzmeßverfahren vorzustellen
"kombinierter Frequenzzähler mit Periodendauermessung"
und die Probleme und weiteren Möglichkeiten mit anderen hier
im Forum zu diskutieren.

Ziel war es nicht, einen kompletten Bausatz zu entwickeln.

Das Wunderbare an diesem Thread ist aber nicht die Entwicklung
des Zählers selbst, sondern wie das Ganze abgelaufen ist.
Da sind Meinungen unterschiedlichsten Niveaus aufeinander
getroffen, aber der Thread hat es bis heute überlebt.
Das was leider hier immer wieder zu oft geschieht, dass eine
gut gemeinte Idee von den anderen hoffnungslos zerredet wird.
Axel nochmal Gratulation. Dir ist das nicht passiert.
Das nun über die Zeit ein durchaus passables Gerätchen ent-
standen ist, zeigt eine neue Qualität des Miteinander-Umganges
hier im Forum.

Es liegt ein Ergebnis vor, der Weg war gut. Axel hat es getan.
Andere stehen noch am Anfang des Umsetzens ihrer Gedanken.

mfg Padex

von Axel S. (a-za-z0-9)


Lesenswert?

Hallo Gast,

W.S. schrieb:
> 1. Warum muß es denn ein Atmel als Rechenkern sein, wenn ihr schon bei
> den kleinsten Berechnungen damit an die Speicherecken anstoßt?

Tun wir doch nicht. Der Mega8 reicht mehr als aus - nur der gcc 
implementiert die benötigte Arithmetik auf eine ziemlich platzfressende 
Weise. Deswegen Assembler. Mittlerweile überlege ich, das komplett in 
Assembler zu schreiben. Anderseits war Einarbeitung in die Toolchain und 
insbesondere die Verheiratung von C und ASM eins meiner Ziele.

> Mittlerweile gibt es wirklich billige ARMs, wo man bequem alles in
> 'double' rechnen kann und gut ist. Ist es die Lust am Minimalismus?

Für meinen Teil schon. Zumindest ein bisschen. Schließlich könnte man 
das ja auch alles fertig kaufen. Oder einen PC dazu mißbrauchen.

Aber zumindest mir widerstrebt es, mit Kanonen auf Spatzen zu schießen. 
Schon der Mega8 ist größer als nötig.

> 2. Warum benutzt ihr immer noch Standard-TTL für das Frontend?
...
> Nehmt ein kleines CPLD (hab eben grad bei
> TME.EU nachgeguckt, ein XC9536 von Xilinx kostet dort so etwa 2..3
> Euro).
...
> Und die Soft dazu gibt's für umsonst. Das sollte doch Grund genug
> sein - oder?

Die Software gibts nicht für umsonst. Dafür bräuchte ich z.B. erstmal 
ein Windows. Ansonsten werde ich mir CPLDs vielleicht irgendwann mal 
ansehen. Im Moment besteht dafür kein Bedarf. Der 74HC590 kostet 28 Cent 
und ist im fädelfreundlichen Gehäuse erhältlich.

Vielleicht implementiert ja demnächst mal jemand in einem anderen Thread 
einen Frequenzzähler mit einem PLD. Werde ich mir dann gerne ansehen.
</Zaunpfahl>

> 3. Warum all diese Eingangsschaltungsprobleme?

Welche Probleme?


XL

von Axel S. (a-za-z0-9)


Lesenswert?

Hi Padex,

Padex schrieb:

> Das Wunderbare an diesem Thread ist aber nicht die Entwicklung
> des Zählers selbst, sondern wie das Ganze abgelaufen ist.
> Da sind Meinungen unterschiedlichsten Niveaus aufeinander
> getroffen, aber der Thread hat es bis heute überlebt.
> Das was leider hier immer wieder zu oft geschieht, dass eine
> gut gemeinte Idee von den anderen hoffnungslos zerredet wird.

Stimmt. Das habe ich in anderen Threads dieses Forums sehr häufig 
gesehen. Und auch hier scheint außer dem Opi niemand auch nur versucht 
zu haben,  meinen Zähler nachzubauen :-/

> Axel nochmal Gratulation. Dir ist das nicht passiert.
> Das nun über die Zeit ein durchaus passables Gerätchen ent-
> standen ist, zeigt eine neue Qualität des Miteinander-Umganges
> hier im Forum.

Ich denke mal, es liegt an zwei Gründen:

1. ich habe einige Jahre Usenet-Erfahrung. Da lernt man recht effektiv, 
Krakeeler zu ignorieren. Natürlich ist es nicht leicht, die zuverlässig 
zu identifizieren. Z.B. habe ich Ulrich am Anfang nicht ernst genommen 
('tschuldige! :)

2. ich war zu 90% fertig, als ich mein Projekt hier vorgestellt habe. 
Und ich wußte, was ich will und was nicht.

> Es liegt ein Ergebnis vor, der Weg war gut. Axel hat es getan.
> Andere stehen noch am Anfang des Umsetzens ihrer Gedanken.

BTW, es ist noch nicht zu Ende. Mittlerweile habe ich den Sourcecode für 
die Variante mit LED-Display schon mal gebrancht und einen Schaltplan 
dazu gemalt. Im Moment bohre ich die Arithmetik auf 64 Bit auf und 
danach will ich mich an die Vorteiler-Option und die Berechnung der 
Periodendauer machen.

Leider bin ich im Moment anderweitig gut ausgelastet, so daß wenig Zeit 
für das Hobby bleibt. Aber der Thread ist nicht tot; der schläft nur!


XL

von Padex (Gast)


Lesenswert?

@ W.S.
Wir hoffen alle, dass Du Dich hier noch einmal
chreativ meldest!
Die vorangegangen Kritiken sind selbstverständlich positiv
gemeint (bezogen auf dich). Deine Vorstellungen zur Thematik
möchten wir gerne in die Weiterführung des Projektes eingeflossen
sehen.
'Hallo ihr Bastler': So wie Du Dich beschreibst, war'st Du ja vor
10 Jahren auch 'so einer'.
Da du den Ausdruck "QRP" kennst, mach bitte mit.

73 Ande.

von W.S. (Gast)


Lesenswert?

Hehe, ich bin immer noch selbst ein Bastler!
Und das aus Freude über's Selbermachen.
Aber meine Freude über nostalgische Projekte hält sich in Grenzen. Sie 
ist aber nicht NULL.

Die Idee finde ich gut, es beim bastelnden Frequenzzählen ebenso zu 
machen wie die professionellen Zählerbauer (HP und Konsorten), die schon 
lange für eine ganze Anzahl von Input-Perioden die Anzahl der 
Referenzperioden zählen und dann beides ins Verhältnis setzen. Das 
ergibt ne konstante Anzahl gültiger Stellen bei allen Frequenzen kleiner 
als die Referenzfrequenz. Bloß bei Frequenzen oberhalb der Referenz 
verschenkt man was. Die Analog-Interpolation wie z.B. beim Racal Dana 
1998 usw. finde ich sehr interessant - aber möglicherweise zu hoch für 
den Basteltisch. Da tut eine hohe Referenzfrequenz viel besser.

Wie gesagt, ich hatte vor langer Zeit die Sache mit nem PIC zelebriert 
und weiß, was für eine Arbeit es ist, das alles in Assembler zu machen. 
Den Zähler hab ich übrigens immer noch in Benutzung obwohl er technisch 
gesehen schon längst überholt ist.

Mir ist mein eigenes Bastelprojekt eine Lehre, euch offenbar nicht, also 
sag ich es mal direkt heraus: Gelegentlich muß man (nicht nur als 
Bastler, sondern auch als professioneller Geräteentwickler) die Kröte 
schlucken, sein eigenes Kind in die Tonne zu kloppen, den Tisch frei zu 
räumen und mit den gesammelten schlechten Erfahrungen im Kreuz nochmal 
ganz von vorn anzufangen. Und da liegt bei fast allen Beiträgen, die ich 
hier so gelesen habe, die Sache im Argen, denn an irgend so etwas wie 
ein ganz am Anfang zu formulierendes Entwicklungsziel (vulgo 
'Pflichtenheft') denkt keiner. Ist ja auch viel schöner, erstmal 
draufloszubasteln. Ja, ich kenne das. Ich bastle auch gern drauflos - 
aber ich weiß, daß das eigentlich ein Kardinalfehler ist, der meistens 
in die Tonne führt.

Stand der dem Bastler verfügbaren Bauteilebasis ist, daß man zwar nicht 
die allerschönsten, aber durchaus verwendbaren CPLD's und 32 Bit CPU's 
für erträgliches Geld bekommt. Mit Displays geht's auch so, wenn man 
nicht versucht, sich auf die stromfressenden und Störungen 
produzierenden LED-Anzeigen zu versteifen, sondern ein Grafik-LCD von 
Pollin kauft. Auf so einem Ding kann man die schönsten Zahlen 
darstellen, die einem so einfallen. Bei UHF-Vorteilern sieht es eher mau 
aus, die sind inzwischen ausgestorben. Aber man könnte den Vorteiler aus 
einem PLL-IC von Analog Devices nehmen (MUX-Ausgang). Ich hatte vor ein 
paar Jahren sowas auf der Hamrad für billig Geld gekauft. Dort gab's 
ebenso auch (steinalte) TCXO's, allerdings für eher seltenere Frequenzen 
(139 oder 145 MHz) Aber das ist ja eigentlich egal, denn man rechnet ja 
sowieso nen Quotienten aus. Und das mit dem OpV war ein Zahlendreher 
(richtig: ADA4817) Ja, die sind teuer, so etwa 7..9 Euro das Stück. Wenn 
man nur 40 MHz als oberste Grenze anzielt, dann sind die dafür 
überdimensioniert. Aber mir wären 40 MHz viel zu wenig. Bei mir liegt 
derzeit ein Projekt auf Kiel, bei dem ich folgende Eckwerte anziele:
- Ein Eingang 1 MOhm//20pF zum Anschließen eines üblichen 
Oszi-Tastkopfes, Meßbereich bis 300 MHz (mit etwas Glück auch mehr)
- ein Eingang 50 Ohm auf Vorteiler, angezielt sind wenigstens 3..4 GHz
- OCXO um wenigstens auf echte +/- 200 ppb zu kommen
Ich hab vorab schon mal so eine Gesamtschaltung entworfen und trassiert 
- aber eigentlich NUR zu dem Zweck, daß ich mir einen Überblick 
verschaffe, ob und wie das Ganze in ein Gehäuse hineinpaßt. Was die 
eigentliche elektronische Entwicklung angeht, ist der Stand der Dinge, 
daß ich bis jetzt eine Reihe von Eingangsschaltungen ausprobiert habe 
(mit o.g. Opv, mit AD8000, mit MMIC, mit Fet-Tetrode). Festgelegt auf 
eine Variante hab ich mich noch nicht, ist noch zu früh. Das Nächste 
wäre dann ein Zählkern, also CPLD und CPU, was auch wieder erstmal NUR 
zum Herausfinden von Schwierigkeiten und Fallstricken gedacht ist. 
Trassiert ist das ganze auch schon, hab bloß noch keine LP (und wenig 
Zeit...). Dann käme der 'Zwischen-Analogteil' also zum einen eine 
Filterbaugruppe (z.B. 0..150 kHz, 100kHz..300MHz oder so) und zum 
anderen eine Pegelmessung. Die halte ich für einen Frequenzzähler für 
extrem wichtig, damit man weiß, ob man gerade das Rauschen mißt oder ein 
echtes Signal hat. Erledigt sind all die reinen Softwaresachen wie 
Grafikdisplay-Ansteuerung, Zeichen darstellen usw.

So. Wir könnten (Konjunktiv) die ganze Sache nochmal neu aufziehen, aber 
ich habe leise Zweifel, wenn ich die Antworten auf meinen ersten Schrieb 
mir anschaue. Wer mit dem Argument kontert, daß man ja für ne 
CPLD-Entwicklung sich erstmal ein Windows anschaffen müßte, will sich ja 
gar nicht dafür interessieren. Abgesehen davon ist gerade dieses 
Argument falsch. Und Aussagen wie "ist im fädelfreundlichen Gehäuse" 
zeugen von eher geringem Interesse sich mit den Tücken der HF-gerechten 
Leiterplattengestaltung zu befassen.

Hach, nun ist es bei diesem Roman schon so spät geworden.
Viel Spaß beim Basteln.
W.S.

von Ulrich (Gast)


Lesenswert?

Für einen einfachen Frequenzzähler, der die Zeit für eine Feste Zahl an 
Perioden misst, braucht man noch keinen CPLD oder ähnliches. Da reicht 
ein einfacher, ggf. zuschaltbarer Vorteiler um in den Bereich 0...100 
kHz (je nach µC auch 1 MHz) - dafür reichen 1-2 TTL ICs.

Wenn man mehr will, würde ich gleich den Weg über die Messung vieler 
Flanken gehen (Geraden Fit): damit hat man mehr Auflösung auch bei einem 
Signal mit Jitter und kann in Grenzen auch gleich das Phasenrauschen mit 
messen. Dafür wäre dann ein leistungsfähigerer µC (ARM ? oder dsPic) 
schon gut.

Das Projekt hier hat schon seine Berechtigung, die Teile sind noch auf 
Lochraster zu verarbeiten, gut zu bekommen, günstig und leicht zu 
programmieren. Oft reicht ein Bereich bis 40 MHz auch aus. Für einen 
Zäher bis 40 MHz ist die gewählte Lösung schon recht günstig.

von Axel S. (a-za-z0-9)


Angehängte Dateien:

Lesenswert?

Hallo,

hier endlich mal das Schaltbild und nochmal die Firmware für die 
Variante mit LED-Display.


XL

von Old P. (Gast)


Lesenswert?

@WS,

wenn Du ein solches Projekt aufziehen möchtest, nur zu! Hier allerdings 
ging es vorrangig um einen einfachen Frequenzzähler mit sinnvoller 
Auflösung und Genauigkeit zur Nachrüstung älterer Generatoren. Es sollte 
ein einfaches Modul entstehen, das man ähnlich der bekannten 
DVM-Panelmeter universell einsetzen kann. Preiswert, mit handesüblichen 
Bauteilen und einfach zu programmieren. Was Du beschreibst, scheint eher 
ein vollwertiger Frequenzzähler als Messgerät zu sein. Sowas ist sicher 
für viele die sich mit CPLDs auskennen auch interessant, aber eine ganz, 
ganz andere Baustelle. Ich würde empfehlen dafür einen eigenen Thread 
aufzumachen, so sind die daran interessierten User besser aufgehoben.

@Axel,

vielleicht mach ich mal ne Platine, habe aber im Frühjahr bis Herbst mit 
Haus, Hof und Garten ganz andere Schwerpunkte.

Gruß
Old-Papa

von Ralph B. (rberres)


Lesenswert?

Old -papa schrieb:
> Hier allerdings
>
> ging es vorrangig um einen einfachen Frequenzzähler mit sinnvoller
>
> Auflösung und Genauigkeit zur Nachrüstung älterer Generatoren. Es sollte
>
> ein einfaches Modul entstehen, das man ähnlich der bekannten
>
> DVM-Panelmeter universell einsetzen kann. Preiswert, mit handesüblichen
>
> Bauteilen und einfach zu programmieren.

Genau so sehe ich das auch.

Old Papa und Axel Schwenke.

Ich finde das Projekt wirklich toll. Insbesonders die Version mit der 
LED Anzeige.


Sobald bei mir ein Projekt entsteht, wo genau solch ein Zähler gebraucht 
wird, darf ich mich bei euch melden? wegen Leiterplatte fertig 
programmierten Prozessor und eventuell schwer erhältliche Spezialteile?

Ralph Berres

von W.S. (Gast)


Angehängte Dateien:

Lesenswert?

an Old-Papa: Ja, was ich beschrieben habe, ist ein Projekt für einen 
richtigen Frequenzmesser, was ich mir selbst vorgenommen habe und auch 
selbst durchziehe. Fernziel ist es, einen Satellitenempfänger für die 
Wettersatelliten zu bauen, denn in ein paar Jahren wird wohl mit dem 
Wetterkartenempfang bei 137 MHz Schlusß sein und ab da mut man sich mit 
BPSK bei rund 1.6 GHz befassen. Ach ja, Vorteiler hab ich wieder 
gefunden: bei Peregrine und Hittite. Aber ob die für mich zu kriegen 
sind weiß ich nicht.

Und nochwas für alle, die eine eher einfache Frequenzanzeige basteln 
wollen: Ich hab eben mal ganz tief in die Bastelkiste gegriffen und ein 
Uralt-Teil ausgegraben. Das hatte ich vor etwa 18 Jahren mal gebastelt, 
um damit ein "Selektives Mikrovoltmeter" mit einer Frequenzanzeige 
auszurüsten. Sozusagen ein früher Vorläufer der heutigen SetTop-Boxen 
:-)  Dafür einen TCXO oder gar einen OCXO spendieren zu wollen oder 
irgendwelche ausgebufften Multi-Flanken-Berechnungen angehen zu wollen, 
halte ich für übertrieben.

Das Teil enthält einen damals üblichen PIC, ein EEPROM zum Merken der 
ZF-Frequenz, einen Einzelgatter- HC4066 und am Boden einen 7805. Das ist 
alles - und es kann vierstellig (mehr kann die Anzeige nicht) Frequenzen 
bis ca. 50 MHz messen. Es ist nur ca. 55x60x22 groß, also durchaus in 
der Größe eines Panelmeters. Die Grundidee dazu stammt aus einer ganz 
frühen Applikationsschrift von MicroChip zur Verwendung des Timers in 
diesen PIC's.

Ist sowas eher eure Intention?

W.S.

von Padex (Gast)


Lesenswert?

W.S. schrieb:
> Ist sowas eher eure Intention?

Nöh! meine nicht. Eher was richtiges.

Bitte vergrault hier den WS nicht, den brauchen wir (ich) für das
nächste Projekt. Ich glaube schon, dass seine Hinweise sehr wichtig
sind, obwohl ich in einigen Punkten anderer Meinung bin.

So, bevor ich mich hier verplausche, einiges Konkretes zu meiner
realisierten und getesteten Zwischenlösung:
Ein Schaltbild kann (will) ich erstmal nicht zeigen (auch Absicht damit
nicht gleich losgeroutet wird).

Schaltung in Worten: (geistiges Auge bitte mal einschalten)!

 Den liebgewonnenen 74590 (der vom Speed viel zu schlapp ist
 und etwas besseres sich da offensichtlich nicht er-GOOGLEn lässt)
 habe ich erstmal in den Ordner 'da war doch noch was’
 verschoben und durch einen HC 74393 (HCT wäre Kram) ersetzt,
 von dem nur 3 Bitstellen verwendet werden.
 Das eigentlich ‚freie FF’ vom 7474 (jetzt AC7474) wurde davor
 gestellt, dadurch entstand ein schneller 4Bit-Vorzähler (nicht bloß
 Vorteiler wie in der 'mino-Lösung’ sondern echter Zählerbestandteil)
 der auch eingelesen und in die Berechnung einbezogen wird.
 Allerdings ist nun noch ein einfaches Gatter-IC AC7400 zusätzlich
 notwendig (Impuls-Tor und noch ein Clear-Inverter).
 Das LC-Display arbeitet im 4Bit-Modus, Prozessor ist ein MEGA88
 3 IO-Pins sind noch valent.
Schaltung Ende:

Einen schnellen Schmitt-Trigger ähnlich dem 74132 (statt des
HC7400) habe ich noch nicht gefunden.

Alles Masse- und HF-freundlich auf Lochraster gefädelt.

80 MHz habe ich sicher erreicht (weiter geht meine Quelle nicht).
160 MHz müssten nach den Datenblattangaben möglich sein.
Diese 3 kleinen Fummelteile in CPLD zu gießen, wäre sicher übertrieben,
zumal der von W.S. genannte XC9536 auch noch zu langsam ist.

Falls Interesse besteht, bin ich selbstverständlich bereit, alles
Open-Free im Geiste dieses Threads zur Verfügung zu stellen (ein
paar Ostereier sind schon versteckt).

BTW: Der Frequenzzähler ist bei mir nur eine Komponente eines etwas 
größeren Projektes, welches sich „HF-Messplatz mit PC-Anbindung“ nennt.

Old -papa schrieb im Beitrag #2144358 an W.S.:
> aber eine ganz,
>
> ganz andere Baustelle.

Das sehe ich nicht so. Wenn man den Zaun niedrig hält, wäre es eine
interessante Baustelle nebenan.

Dieser Thread ist schon viel zu lang geworden, es gibt bereits 
Schwierigkeiten mit den Ladezeiten.

W.S. ist längst im Boot ... auf zu neuen Ufern!

Zaunpfahl: Wer eröffnet den neuen Thread ???????

mfg Padex

von Ralph B. (rberres)


Lesenswert?

Padex schrieb:
> Das eigentlich ‚freie FF’ vom 7474 (jetzt AC7474) wurde davor
>
>  gestellt, dadurch entstand ein schneller 4Bit-Vorzähler (nicht bloß
>
>  Vorteiler wie in der 'mino-Lösung’ sondern echter Zählerbestandteil)
>
>  der auch eingelesen und in die Berechnung einbezogen wird.

Da gab es mal von Plessey ein Baustein. Nannte sich SP8634. Es war ein 
echter BCD Zähler mit einen Nandgatter als Eingangstor für die 
Zählimpulse, Reseteingang, Übertragsausgang und BCD Ausgänge. Es zählte 
ohne vorteilen zu müssen bis 600MHz. Damit konnte man richtig schnelle 
Frequenzzähler aufbauen. Als zweite Stelle hat man dann ein 74S196 
genommen. Schade das es diese Bausteine nicht mehr gibt. Oder weis 
jemand eine Alternative ohne gleich CPLDs oder Prozessoren programmieren 
zu müssen?

Ralph Berres

von Padex (Gast)


Lesenswert?

@ Ralph
SP 8634: ja sowas in der Art müßte man finden.
Dann ist aber nichts mehr mit meinen 3 valenten IO-Pins.
Die von mir erwähnten 160 MHz bei 20 MHz-Prozessortakt sind
ja bereits grenzwertig. Bevor es die anderen merken, man muß
dann natürlich einen 5Bit-Vorteiler aufbauen, also noch eine
Leitung vom 74393 ziehen.

mfg Padex

von Ralph B. (rberres)


Lesenswert?

Padex schrieb:
> Bevor es die anderen merken, man muß
>
> dann natürlich einen 5Bit-Vorteiler aufbauen, also noch eine
>
> Leitung vom 74393 ziehen

Ich hatte vor jahrzehnten, muss man fast sagen, einen 9stelligen Zähler 
gebaut. Im NF Teil in der ersten Stufe SP8634, in der nächsten Stufe 
74S196 und din den restlichen Stufen 74LS90. Im HF Teil war noch ein 
SP8590 davor, der fest surch 10 geteilt hat und bis 6GHz teilte.
Es war eine ganz klassische Zählerschaltung wie man es in den 80ger 
Jahren bebaut hatte.
Als Referentfrequenz war damals ein Quarzofen, der mmit DCF77
diszipliniert wurde.

Heute würde man mit 2 solcher SP8634 einen Reziprogzähler aufbauen, als 
Referenzfrequenz nicht 10MHz sondern 500MHz verwenden und somit einen
Zähler erhalten der bezüglich Auflösung in Stellen/Sek. durchaus mit den 
heutigen modernenen Kameraden mithalten kann.

Aber leider gibte es solche Bausteine jahr nicht mehr.

Ralph Berres

von Ulrich (Gast)


Lesenswert?

Für einen Reziprokzähler ist es gar nicht nötig die Pulse des Signals 
wirklich einzeln zu zählen. Da reicht es erstmal die Frequenz durch 
einen Vorteiler in den gut verarbeitbaren Bereich zu bekommen. Es macht 
für die Auflösung keinen Unterschied, wenn die Zahl der Perioden auf 
Vielfache von z.B. 256 eingeschränkt ist.  Lediglich die Messzeit passt 
nicht ganz so genau zur Vorgabe - auf ein paar µs mehr oder weniger 
kommt es da aber kaum an.

von W.S. (Gast)


Lesenswert?

Mein lieber Ulrich, du schreibst Mist. Auch für einen Reziprokzähler 
braucht man Zahlen - und zwar möglichst GROSSE und GENAUE, damit bei der 
Division genügend relevante Stellen herauskommen. Wenn man irgendwie 
durch diverse Vorteiler die Eingangsfrequenz herunterteilt, weil sie 
einem zu hoch ist zum Verarbeiten, dann geht die Rechnung rein 
mathematisch sehr wohl auf - aber an die diversen Pferdefüße denkt 
keiner. Langsamere Zählschaltungen haben nämlich auch langsamere Flanken 
und ein höheres Jitter und begrenzen dadurch die mögliche Auflösung. Mit 
welcher Präzision kannst du die Torzeit denn bestimmen, wenn du
a) 4000er CMOS Logik nimmst,
b) 74HC nimmst,
c) 74VHV nimmst,
d) 10K ECL nimmst
e) ein möglichst schnelles CPLD nimmst ?

(jaja, ECL wäre das Genaueste weil die steilsten Flanken und damit die 
präziseste Torzeit ergebend)

Als grobe Faustformel kann man sagen, daß ein Frequenzzähler gleich 
welcher Bauart nur so viel Stellen liefern kann, wie seine inneren 
Zähler an Impulsen innerhalb der Torzeit zählen können. Beispiel: Wenn 
z.B. ein AVR (oder eben ein anderer uC...) maximal 10 MHz direkt zählen 
kann und die Torzeit 1 Sekunde ist, dann kann man als höchstes 
Zählergebnis 9.999.999, also maximal 7 gültige Stellen erwarten - nicht 
mehr.

Also: Je besser die Zähler, desto größere Aussicht auf viele Stellen. 
Schiefgehen tut sowieso immer was, so daß man von obiger Faustformel 
ruhig eine Stelle abziehen darf, um zu einer Aussage über die beim 
Amateurbasteln zu erwartenden Ergebnisse zu kommen. Deshalb plane ich 
für mein Zählerprojekt, den kleinsten Coolrunner (XC2C32A heißt der 
wohl) zu benutzen. Aber den hab ich nicht bei TME gefunden. Die haben 
einen XC95er für billig Geld und der wäre für das Thema dieses Threads 
(1Hz..40MHz) dicke ausreichend, wahrscheinlich würde er für mehr als 100 
MHz ausreichen und er ist 5V tolerant, was für die Atmel-Liga mit 
gesockelten IC's ja ne wichtige Sache ist.

Aber für einen Frequenzzähler wäre ein Coolrunner deutlich besser. Die 
Makrozellen bei diesen Dingern haben eine typische Arbeitsfrequenz von 
ca. 600 MHz. Das kann man zwar nicht direkt und voll auskosten, denn die 
I/O-Stufen und die Schaltmatrix schlagen auch zu Buche, aber mit einer 
erreichbaren oberen Grenzfrequenz von so etwa 300 MHz rechne ich schon. 
Naja, und passend zum Coolrunner mit 3.3V bieten sich eben diverse ARM's 
an, die ja auch zumeist bei 3.3V betrieben werden und die über die 
nötigen Ressourcen verfügen, daß man sich auf den Zähler konzentrieren 
kann und sich nicht mit den Grenzen des uC herumschlagen muß.


W.S.

von mukl (Gast)


Lesenswert?

Es geht aber auch OHNE uC (40MHz Counter):
http://www.alternatezone.com/electronics/freq.htm

von Ulrich (Gast)


Lesenswert?

Man kann eine Zähler auch ohne µC aufbauen, aber mit µC geht es 
einfacher.  Weil sie schon einen Vorteiler mit drin haben kann man mit 
vielen der PICs auch ohne externe Logic eine Zähler bis etwa 20 MHz 
aufbauen.

Der Vorteiler für einen Hochauflösenden Reziprokzähler sollte schon 
genau sein. Vorteiler in ECL Technik bekommt man noch relativ einfach 
und man spart sich auch einiges an Pegelwandlern gegenüber einem echten 
Zähler. Es ist halt oft einfacher und billiger eine schnellen Vorteiler 
als einen schnellen Zähler zu bekommen. Der Vorteiler legt vor allem die 
obere Messfrequenz fest und weniger die Auflösung. Ein schlechter Teiler 
kann aber natürlich die Auflösung begrenzen. Für die Messung der Zeit 
selber sollte es schon ein schneller Zähler sein, ggf. auch als Teil 
eines µC oder als FPGA. Es geht aber auch eine "analoge" Interpolation, 
denn die Reproduzierbarkeit der Flanken ist deutlich besser als die 
mindeste Periodendauer.

Wenn man schon für eine hohe Auflösung ein FPGA und einen ARM wählt, 
sollte man sich die Technik mit der Messung der Zeit vieler Flanken 
ansehen. Das sollte mit einem FPGA und ARM recht gut gehen und kann bei 
einigermaßen hohen Frequenzen noch einmal 1-2 Stellen mehr an Auflösung 
heraus hohlen, auch wenn die Auflösung bereits durch Jitter im Signal 
oder die Eingangsstufe begrenzt ist. Das bringt mehr als die 
Zählfrequenz von 10 MHz auf 200 MHz zu erhöhen, und ist weniger Aufwand, 
jedenfalls von der Hardware. Ganz nebenbei kann man damit dann auch noch 
Jitter bzw. Allen-Varianz messen, zumindest bei genügender Auflösung und 
genügend schneller µC.

von Hans M. (Firma: mayer) (oe1smc) Benutzerseite


Lesenswert?

hallo old-papa

ich moechte dir mal kurz von einem teilerfolg erzaehlen. das von dir 
entworfene pc-board ist inzwischen bei mir fertig zusammen gebaut.

berufsbedingt hat es ein wenig gedauert bis es fertig war.

mit der software von axel habe ich noch ein wenig probleme. ich habe mir 
die version "V1.3 (c)XL" geholt und hoffe, dass das die letzte ist. das 
problem ist, dass bei der anzeige die buchstaben verwuerfelt werden. so 
wird z.b. anstelle
ADJ=
(off)
folgender text angezeigt
)DJ=
(off
oder aber auch voellig unleserlich.
hin und wieder, so etwa 1 von 10 mal kann man jedoch den richtigen text 
lesen. ich dachte, dass ich vielleicht beim zusammenbau einen fehler 
gemacht hatte. um auszuschliessen, dass es an der hardware od am aufbau 
liegt, habe ich die LCD ansteuerung auf einem anderen evaluations board 
nachgebaut. natuerlich mit einem anderen LCD und einem anderen ATmega8. 
aber gleicher verdrahtung. und siehe da, da habe ich das selbe problem, 
dass der text meist nicht richtig angezeigt wird. wobei ich auf diesem 
board schon etliche projekte mit stabilem und ohne probleme laufendem 
LCD umgesetzt hatte. allerdings mit ATmega32, aber daran wird es ja wohl 
nicht liegen.

woran es liegt weiss ich noch nicht genau. aber ich denke, dass es eine 
art timing geschichte ist. ich habe zwar schon an diversen stellen timer 
eingebaut, aber bis dato ohne erfolg.

jedenfalls recht herzlichen dank, old-papa, fuer das zur verfuegung 
stellen des boards. auch dir axel ein recht herzliches danke schoen fuer 
die software, wenn gleich sie auch noch nicht so funktioniert, wie sie 
funktionieren sollte und all denen, die sich an dem projekt noch 
beteiligt haben.

wenn ich mehr weiss, werde ich mich wieder melden. ein photo wird auch 
folgen.

gruss
hans

--

von Old P. (Gast)


Lesenswert?

Hallo Hans,

genau darüber hatten wir weiter oben diskutiert, war bei mir genauso.
Axel hatte dazu auch Tips gegeben, letztlich hat es dann prima 
funktioniert.
Wenn Du nicht selber kompilieren kannst, kann ich Dir auch eine neuere 
HEX zuschicken oder Axel ließt hier mit und macht das...

Schick mir mal eine PN mit Deine Mailadresse

Gruß
Old-Papa

von Hans M. (Firma: mayer) (oe1smc) Benutzerseite


Lesenswert?

hallo old-papa

danke fuer deine antwort. ich habe zwar deinen beitrag mit den problemen 
gefunden Beitrag "Re: Frequenzzähler 1Hz - 40MHz" aber nicht 
wirklich eine loesung. eine PN folgt sofort.

selbst kompilieren ist kein problem. ich arbeite mit eclipse helios, in 
notfaellen auch mit avrstudio4. vielleicht sollte ich es einmal damit 
probieren. aber vielleicht schickst du mir mal dein hex-file. in diesem 
fall: probieren geht ueber studieren.

vielleicht gibts zu deinem hex file auch einen source code. das waere 
der ueber-hit.


gruss
hans

--

von Old P. (Gast)


Lesenswert?

Hallo Hans,

also HEX und Surce sind kein Problem, die HEX ist allerding für einen 
M8, Du hast ja wohl einen M32 verwandt.

Die nötigen Änderungen in den Surcen hatte Axel aber oben im weiteren 
Verlauf der Diskussion beschrieben, damit hat es ja dann bei mir 
funktioniert. Du musst natürlich noch ein 2-zeilges Display einstellen, 
original ist ja nur einzeilig.

Dann machen wir mal PN

Gruß
Old-Papa

von Axel S. (a-za-z0-9)


Angehängte Dateien:

Lesenswert?

Hallo Hans,

Hans Mayer schrieb:

> selbst kompilieren ist kein problem. ich arbeite mit eclipse helios, in
> notfaellen auch mit avrstudio4. vielleicht sollte ich es einmal damit
> probieren. aber vielleicht schickst du mir mal dein hex-file. in diesem
> fall: probieren geht ueber studieren.
>
> vielleicht gibts zu deinem hex file auch einen source code. das waere
> der ueber-hit.

Version 1.3 ist alt. Ich habe mal die aktuellen 1.4er Quellen hier 
rangehängt. Da ist auch ein .hex dabei für Mega8, 14.31MHz, Display 
1x16. Configuration für das Display ist in config.h.


XL

von Hans M. (Firma: mayer) (oe1smc) Benutzerseite


Lesenswert?

hallo Axel
hallo Old-Papa

vielen dank fuer die antworten. mit der version 1.4 funktioniert es. ich 
habe die software compiliert, geflasht und es spielt schon.

vielen dank an dich Axel fuer die geniale software, vielen dank an dich 
Old-Papa fuer das nette kleine board.
das ganze macht spass.

ich wuensche schoene feiertage
gruss
hans

--

von W.S. (Gast)


Angehängte Dateien:

Lesenswert?

Leute, es gibt Neuigkeiten.

Ich hatte ja viel weiter oben von meinen diversen steinalten 
Frequenzzählern auf PIC-Basis erzählt. Eigentlich wollte ich SOWAS nie 
wieder basteln, aber mich hatte es vor ein paar Tagen in den Fingern 
gejuckt - und so hab ich auf die schnelle Tour eine Versuchsschaltung 
zusammengebastelt, die in ein Handgehäuse "ABS100" von tme.eu 
hineinpaßt. Als Stromversorgung dient ein Li-Akku und das LCD ist von 
Pollin.

Jetzt ist die LP da, also flugs bestückt, eine allererste 
Programmversion geschrieben und ausprobiert und... Jawoll! Mich hatte es 
richtig erstaunt, denn dieser Zähler zählt zuverlässig bis über 150 MHz. 
Richtig gelesen: einhundertfünfzig Megahertz. Ich habe auch noch einen 
GHz-Vorteiler vorgesehen, selbigen aber bislang noch garnicht in Betrieb 
genommen.

Der Zähler geht allerdings ein bissel falsch: anstelle von 155.520 MHz 
mißt er 'nur' 155.513 MHz - das aber mit konstanter Hartnäckigkeit und 
ohne Schwankungen. Naja, als Basis dient ein stinknormaler 18.432 MHz 
SMD-Quarz (wahrscheinlich ca. 100 ppm oder so). Wenn ich Zeit habe, baue 
ich noch einen geeigneten Korrekturfaktor ins Programm und dann ist 
diese kleine LP für 5 gültige Stellen gut.

Dabei ist das Prinzip geradezu simpelst: Vor dem Vorteiler von Timer 0 
ist ein 125er Bustreiber als Einzelgatter aus der UHS-Reihe von 
Fairchild. Davor nur ein Spannungsteiler und ein C zum Gleichspannung 
abtrennen und fertig. Softwaremäßig ist das Ganze erstmal völlig simpel 
aufgebaut: Das Tor und auch der interne Referenzzähler werden per 
Programm ein- und ausgeschaltet, zeitlicher Offset ca. 200 ns und 
Meßzeit 200 ms.

Das Ganze ist ein Schnellschuß, der mir aber zeigt, daß man mit 
minimalem Aufwand einen Zähler bauen kann, der 5 gültige Stellen liefert 
und sich wegen des minimalistischen Prinzipes als 
Nachrüst-Frequenzanzeige eignet.

W.S.

von Willi (Gast)


Lesenswert?

150MHz mit 5 Stellen ist doch langweilig.
Wieviel Stellen Zeigt das Gerät denn bei 150Hz?

von Michel (Gast)


Lesenswert?

Willi schrieb:
> Wieviel Stellen Zeigt das Gerät denn bei 150Hz?
Hast du das Meßprinzip verstanden? Dann erübrigt sich die Frage.

von W.S. (Gast)


Lesenswert?

Willi schrieb:
> 150MHz mit 5 Stellen ist doch langweilig.

Ach ja. Mir ist schon klar, daß du das alles VIEL besser weißt, viel 
besser kannst und hier nur hineinschaust, um dich zu langweilen und 
nebenher deine Weisheit unters Volk zu bringen. Ich hätte da einen 
bescheidenen Vorschlag: Zeig doch mal deinen selbstgebauten 
Frequenzzähler. Die anderen Leute, die hier mitlesen, sind ganz gewiß 
für bessere Ideen sehr aufgeschlossen.

Aber mal an die Anderen:
Das derzeitige Meßprinzip ist erstmal simpelst, eben rein softwaremäßig. 
Ich hab es an dem Abend, wo ich das Ganze ausprobiert hab, in Assembler 
zusammengeschrieben, bloß um zu sehen, ob die LP überhaupt funktioniert. 
Hab nämlich einen für mich ungewohnten PIC (PIC16F716) verwendet.

Das was mich so sehr überrascht hat, war der Umstand, daß dieser PIC 
eine derartig hohe Frequenz an seinem Zähleingang überhaupt verarbeiten 
kann. Das macht diese steinalte PIC-Variante für mich wieder 
interessant. Ebenso hat es mich überrascht, daß man mit einer rein 
softwaremäßigen Torsteuerung 5 Stellen mühelos hinbekommt.

Um es besser zu machen, braucht man einen zweiten NC7SZ125 und einen 
D-Flipflop aus der UHS-Reihe zum Synchronisieren. Mal sehen, auf der 
letzten Embedded hab ich bei Texas Instruments gesehen, daß die jetzt 
auch solche kleinen schnellen Einzelgatter im Programm haben. Vielleicht 
läßt sich da was schnorren. Wenn ja, dann sind bei geeignetem 
Quarzoszillator 7 Stellen, vielleicht 8 Stellen drin. Naja, mehr als 7 
1/2 macht meine Gleitkomma-Arithmetik auch nicht mit und 'double' zu 
implementieren ist auf einem PIC mit 2048 Programmschritten ne echte 
Herausforderung.

Ansonsten ist jetzt meine Versuchs-LP für einen Zählerkern mit nem 
LPC2103 und XC2C32A eingetrudelt. Aber das ist ein etwas größerer 
Brocken, der braucht etwas mehr als mal eben einen verbastelten Abend.

Mal ne abschließende Frage: Gibt es hier in diesem Thread Interessenten, 
die an einer der Varianten ein Interesse haben (also Minmalzähler mit 
PIC und 'richtiger' Zähler mit ARM)? Wenn ja, dann wäre es wohl so 
langsam an der Zeit, dafür einen neuen Thread aufzumachen.

W.S.

von Axel S. (a-za-z0-9)


Lesenswert?

Moin,

W.S. schrieb:

> Das derzeitige Meßprinzip ist erstmal simpelst, eben rein softwaremäßig.
> Ich hab es an dem Abend, wo ich das Ganze ausprobiert hab, in Assembler
> zusammengeschrieben, bloß um zu sehen, ob die LP überhaupt funktioniert.

Schon klar. Auch wenn es dann streng genommen nicht in diesen Thread 
paßt, weil die Auflösung (wie von Willi angemerkt) bei niedrigen 
Frequenzen in den Keller geht.

Ganz davon zu schweigen, daß das rein softwaremäßige Tor auch nicht der 
Weisheit letzter Schluß ist. Bei 200ms Torzeit und 5 Stellen reichen da 
zwar 2µs Genauigkeit, aber mit jeder weiteren Stelle wirds heftiger.

> Hab nämlich einen für mich ungewohnten PIC (PIC16F716) verwendet.
> Das was mich so sehr überrascht hat, war der Umstand, daß dieser PIC
> eine derartig hohe Frequenz an seinem Zähleingang überhaupt verarbeiten
> kann.

Ich hab ja ehrlich gesagt noch nie was mit einem PIC gemacht (und hab 
das auch nicht vor). Aber das Datenblatt sagt für Timer0 20ns und für 
Timer1 30ns minimale Zykluszeit bei externer Speisung. Mithin 50MHz bzw. 
33MHz. Deine 150MHz sind also weit(!) über dem Limit. Allerdings sind 
die Angaben für mich nicht ganz nachvollziebar, insbesondere warum die 
Timer im asynchronen Betrieb langsamer sein sollen.

Um einen reziprok-Zähler zu bauen, reicht der asynchrone Zähler eines 
PIC allerdings nicht aus. Dafür bräuchte man dann auch eine entsprechend 
schnelle Capture-Einheit. Oder die Möglichkeit, das Zählsignal nach dem 
internen Vorteiler zu capturen.

Ein 40MHz PIC-Zählermodul ist übrigens seit Jahren auf dem Markt. Kann 
man z.B. beim "Funkamateur" kaufen. Google findet auch die Website des 
Autors.

> Mal ne abschließende Frage: Gibt es hier in diesem Thread Interessenten,
> die an einer der Varianten ein Interesse haben (also Minmalzähler mit
> PIC und 'richtiger' Zähler mit ARM)? Wenn ja, dann wäre es wohl so
> langsam an der Zeit, dafür einen neuen Thread aufzumachen.

Ganz unabhängig vom Interesse würde ich einen extra Thread begrüßen. Zum 
einen, um verschiedene Projekte sauber zu trennen. Zum anderen weil sich 
schon Leute beschwert haben, daß dieser Thread zu lang wäre.


XL

von Willi (Gast)


Lesenswert?

W.S. schrieb:
> Ach ja. Mir ist schon klar, daß du das alles VIEL besser weißt,

Denn wäre das schon mal geklärt. Aber die Anzahl der Stellen kannst Du 
wohl nicht beantworten.

Axel Schwenke schrieb:
> Schon klar. Auch wenn es dann streng genommen nicht in diesen Thread
> paßt, weil die Auflösung (wie von Willi angemerkt) bei niedrigen
> Frequenzen in den Keller geht.

Das ist der Punkt. Axel hat doch ein ganz anderes Verfahren vorgestellt. 
Eine banale Zählerkette mit speziellen (teuren) Zählerbausteinen passt 
hier nicht hin. Das hatten wir doch schon vor Jahrzehnten.

von Universalcounter (Gast)


Lesenswert?

Ein "richtiger Zähler" braucht keinen ARM, auch keine CPLD oder gar 
FGPA.

Schaut euch mal den Einschubzähler von Hameg an, der läuft seit der 
ersten Generation mit 8051 und diskreter Logik.
Hat 2 Kanäle: ch1 DC bis 150MHz und ch2 50MHz bis 1,6GHz. Und ist dazu 
ein
echter Universalcounter.

Das echte Ingenieuring liegt eh in den Vorverstärkern. Ein VV von DC bis 
150MHz, einschließlich Komparator, verstellbarer Triggerschwelle, 
DC/AC-Umschaltung, Attenuator und Filter bedarf u.U. mehrerer 
Testlayouts.

Das coden eines AVR oder PIC ist da eher PillePalle.

In einem stimme ich aber zu: Die externe Logik würde ich heute in eine 
CPLD setzen. Ist einfach bequemer.

von Ralph B. (rberres)


Lesenswert?

Universalcounter schrieb:
> Schaut euch mal den Einschubzähler von Hameg an, der läuft seit der
>
> ersten Generation mit 8051 und diskreter Logik.

Der zählt ja auch nur maximal 6-7 Stellen/Sek. Schaue dir mal die 
aktuellen Zähler von Agilent mit 10, oder gar 12 Stellen/Sek. Mache das 
mal mit diskreter Logik.

Ralph Berres

von Universalcounter (Gast)


Lesenswert?

Ralph Berres schrieb:
> Der zählt ja auch nur maximal 6-7 Stellen/Sek.

Was sund gegen 7-Stellen bei 1sek zu sagen?

Ein jeder, der hier mitdiskutiert, wäre froh, solch einen Zähler zu 
besitzen.
Siehe: http://www.hameg.com/139.0.html?L=1

Agilent in diesem Thread als Referenz zu nennen ist unsinnig, da deren 
Specs im Selbsbau nie erreichbar sind.

Die Daten des Hameg HM8021 sind dagegen mit AVR und diskreter Logik/CPLD 
einschließlich VV immer erreichbar.

von Ralph B. (rberres)


Lesenswert?

Universalcounter schrieb:
> Was sund gegen 7-Stellen bei 1sek zu sagen?

Das hängt wiederum von den Ansprüchen und dem Einsatzgebiet ab.

Für einen NF Generator ist das sicherlich mehr als ausreichend.

Und genau für solche Anwendungszwecke sind Axels Reziprokzähler ideal 
zugeschnitten. Denn sie lösen auch noch niedrige Frequenzen mit mehreren 
Stellen hinterm Komma auf.

Aber bei einen UKW oder UHF Transceiver welches SSB oder CW kann, und 
endsprechend schmale Filter im ZF Teil besitzt, möchte ich schon die 
Frequenz auf 100Hz oder sogar auf 10Hz auflösen können, und trotzdem 
eine
Aktuallisierungsrate der Frequenzanzeige mit wenigstens 10Hz haben, 
damit ich online sehe wenn ich am VFO drehe. Das hat einfach was mit 
Haptik zu tun. Bei 430MHz und 10Hz Auflösung sind das schon 8Stellen, 
und bei 10Messungen/Sek sind das schon 9Stellen/Sek.

OK bei den heutigen Synthesizern liegt die Frequenzanzeige als 
Abfallprodukt vor, aber es gibt ja auch noch ältere echte VFO 
Transceiver.

Als vollwertiker Laborzähler wären 7Stellen/Sek wirklich die unterste 
(Schmerz)Grenze .

Ralph Berres

von Old P. (Gast)


Lesenswert?

Universalcounter schrieb:
> Ein jeder, der hier mitdiskutiert, wäre froh, solch einen Zähler zu
> besitzen.
> Siehe: http://www.hameg.com/139.0.html?L=1

Ach du Schei*e, wat fürn Mörkel.... Also, jeder wohl nicht, vielleicht 
einige. Ich selbst habe viel bessere (ja, mehrere!) und Ralph soweit ich 
weis auch.
Du musst nicht immer von Dir auf andere schließen.... ;-)

Und ich widerhole mich zum x-ten Mal: Hier wurde von Axel ein kleiner 
universeller Zähler als genaue nachrüstbare Frequenzanzeige für 
Generatoren usw. vorgestellt. Und genau das macht das kleine Modul 
hervorragend!

Wer unbedingt einen Zähler mit allem pipapo entwerfen möchte, der kann 
das gerne tun. Einige der hier vertretenen Interessenten würde auch 
dabei mitdiskutieren. Nur dann bitte einen eigenen Thread dazu 
aufmachen.
Hier kommen wir langsam von "Kuchenbacken" auf "Arschbacken". ;-)
Will sagen, langsam wirds wirklich OT!

Gruß
Old-Papa

von Universalcounter (Gast)


Lesenswert?

Old -papa schrieb:
> Ach du Schei*e, wat fürn Mörkel.... Also, jeder wohl nicht, vielleicht
> einige. Ich selbst habe viel bessere (ja, mehrere!)

Ach komm, Old-Papa, bleib aufm Teppich und verleugne nicht deinen 
eigenen beruflichen Werdegang. Denn da hat es mal eine Zeit gegeben, da 
wärest du dankbar für diesen Hameg-Mörkel gewesen. Schon vergessen?


Old -papa schrieb:
> Und ich widerhole mich zum x-ten Mal: Hier wurde von Axel ein kleiner...

Hat Axel Schwenke es nötig sich von einem Wachhund verteten zu lassen? 
Ich glaube kaum.


Old -papa schrieb:
> Hier kommen wir langsam von "Kuchenbacken" auf "Arschbacken". ;-)

Auch hier dein Irrtum! Wir kommen so allmälich vom Kuchbacken zum 
3-Sternekochen. Und in welchem Thread das stattfindet bestimmst nicht 
DU!

von Old P. (Gast)


Lesenswert?

Hallo Universalcounter,

klar hätte ich mir früher die Finger danach geleckt, doch Du hast das 
sehr absolut und nicht für die Vergangenheit geschrieben!
> Ein jeder, der hier mitdiskutiert, wäre froh, solch einen Zähler zu
besitzen.
Siehst Du hier irgendwas?

Und Axel hat natürlich keinen Wachhund nötig, doch Deine Aussage 
bestätigt, dass Du den Thread nichtmal halbwegs gründlich gelesen hast.
Denn auch Axel hat darum gebeten einen eigenen Thread aufzumachen....

3-Strenekochen kann auch fürchterlich in die Grütze gehen, nämlich dann, 
wenn der geneigte Verbraucher eigentlich nur mal fix ne Currywurst haben 
will. Wenn Du ihm dann nach einer Stunde eine Currywurst in 
3-Sternezubereitung vorsetzt, ist der längst zur nächsten Bude um die 
Ecke.

Also, lies doch mal den ganzen (langen) Thread und entscheide dann, ob 
hier 3-Sterne oder was wirklich einfaches gesucht und entwickelt wurde.

Ach ja, zeige doch mal Deine eigenen Entwürfe in echter Hardware vor, 
dann reden wir weiter ;-)

Old-Papa

von Universalcounter (Gast)


Lesenswert?

Old -papa schrieb:
> Ach ja, zeige doch mal Deine eigenen Entwürfe in echter Hardware vor,
> dann reden wir weiter ;-)

Wie willst du den mitreden, wenn du dich weigerst, wenn hier über einen 
halbprofessionellen Universalcounter diskutiert wird?

von Old P. (Gast)


Lesenswert?

Universalcounter schrieb:
> Wie willst du den mitreden, wenn du dich weigerst, wenn hier über einen
> halbprofessionellen Universalcounter diskutiert wird?

Na mal sehen, ob HIER wirklich über einen "halbprofessionellen" 
Universalcounter oder weiter über einen einfachen, preiswerten und 
schnell aufzubauenden "Counter" diskutiert wird.
Zu "Universalcountern" gab es übrigens schon einige Threads, Hardware 
habe ich davon aber noch nicht gesehen. Warst Du daran auch beteiligt?

Gruß
Old-Papa
Der sich hier aber ab jetzt raushält, das geht ja langsam Richtung 
Flame....

von W.S. (Gast)


Lesenswert?

Schluß jetzt.
Ich meine, das ist eher ein Mißklang zum Ausklang.

Hier nur noch was für den Axel zum Verständnis:
Der Vorteiler vom Timer 0 beim PIC ist im Gegensatz zu den eigentlichen 
Countern/Timern ein asynchroner Teiler - und er ist sehr schnell. So 
schnell, daß es mich überrascht hat. Der Knackpunkt für deine diversen 
Mißverständnisse und Fehleinschätzungen liegt einfach darin, daß du dich 
zu wenig in die PIC's eingearbeitet hast. Das wundert mich nicht, da du 
ja bislang hauptsächlich mit Atmels und noch nie mit PIC's gebastelt 
hast. Nach meiner Erfahrung tun sich Atmel-Leute mit PIC's besonders 
schwer. Das liegt an den völlig unterschiedlichen Architekturen.

W.S.

von Axel S. (a-za-z0-9)


Lesenswert?

Universalcounter schrieb:

> Hat Axel Schwenke es nötig sich von einem Wachhund verteten zu lassen?
> Ich glaube kaum.

Und das ausgerechnet von einem anonymen Troll?

(gut, womöglich bist du im allgemeinen kein Troll, aber deine letzten 
Beiträge hier waren getrollt)

Und was die 7 Stellen/sek und den "Neid" auf das Hameg-Teil angeht: 7 
Stellen pro Sekunde macht meine Hardware ohne Probleme. Allerdings 
bringt das gar nix wenn man nicht wenigstens einen TCXO (eher OCXO) 
verbaut und den auch irgendwo kalibrieren (lassen) kann.


XL

von Axel S. (a-za-z0-9)


Lesenswert?

Hallo W.

W.S. schrieb:

> Hier nur noch was für den Axel zum Verständnis:
> Der Vorteiler vom Timer 0 beim PIC ist im Gegensatz zu den eigentlichen
> Countern/Timern ein asynchroner Teiler - und er ist sehr schnell. So
> schnell, daß es mich überrascht hat.

Ja. Insbesondere eben weit schneller (Faktor 3-5) als im Datenblatt des 
PIC spezifiziert.

> Der Knackpunkt für deine diversen
> Mißverständnisse und Fehleinschätzungen liegt einfach darin, daß du dich
> zu wenig in die PIC's eingearbeitet hast. Das wundert mich nicht, da du
> ja bislang hauptsächlich mit Atmels und noch nie mit PIC's gebastelt
> hast. Nach meiner Erfahrung tun sich Atmel-Leute mit PIC's besonders
> schwer. Das liegt an den völlig unterschiedlichen Architekturen.

Danke, aber ich kann Schaltpläne und Datenblätter lesen. Deswegen ist 
mir durchaus aufgefallen daß die Vorteiler und bei Timer1 sogar der 
Zähler selber asynchron sind (bzw. asynchron konfiguriert werden 
können). Und es ist mir vollkommen klar, daß das für einen reinen 
Zählfrequenzmesser ein Vorteil ist (allerdings für einen Reziprokzähler 
nicht mehr)

Was mich halt erstaunt sind die Angaben im Datenblatt des 16F716 (auf 
Seite 104) die z.B. für "T1CKI input period" mindestens 30ns im 
synchronen Betrieb und mindestens 60ns im asynchronen Betrieb nennen. 
Ich hätte eigentlich erwartet, daß die asynchrone Betriebsart mindestens 
gleich schnell oder gar schneller ist. Für Timer0 sind es 20ns 
(entspreched 50MHz) bei hinreichend hohem Vorteilerfaktor.


XL

von Matthias Fischer (Gast)


Lesenswert?

Hallo Axel,

erstmal tolles Projekt und danke dafür. Habe mir nun auch so ein Teil 
nachgabaut (LED-Verson) und es funktioniert soweit ganz gut, bis auf das 
Problem, dass die angezeigte Frequenz nur 1/4 der eigentlichen ist. 
Statt 4MHz anzuzeigen werden nur 1MHz angezeigt. Habe schon alle 
Verbindungen geprüft und ICs getauscht jedoch ohne Erfolg. Ich frage 
mich nun woran das nur liegen kann ??? Für Hilfe bin sehr dankbar ...

mfg M.

von Michael D. (mike0815)


Angehängte Dateien:

Lesenswert?

moin,
ich möchte mal das Projekt in Angriff nehmen und zwar eine LCD 2x16 
sowie eine LED Version.
In der config.h werden ja die Display-Versionen konfiguriert, da ich im 
Programmieren nicht der 'Profi' bin, hier mein Anliegen:
Wird, wie im Screenshot von mir markiert, die Zeilen einfach 
auskommentiert oder muß noch etwas verändert werden? Wie sieht es mit 
der LED-Version aus, was ist da zu beachten?

Gruß Michael

EDIT:
> Statt 4MHz anzuzeigen werden nur 1MHz angezeigt.
Da stimmt doch was mit dem Vorteiler nicht, oder?

von Axel S. (a-za-z0-9)


Lesenswert?

Hallo Matthias,

Matthias Fischer schrieb:
>
> Habe mir nun auch so ein Teil
> nachgabaut (LED-Verson) und es funktioniert soweit ganz gut, bis auf das
> Problem, dass die angezeigte Frequenz nur 1/4 der eigentlichen ist.
> Statt 4MHz anzuzeigen werden nur 1MHz angezeigt.

Welche Software-Version? (die letzte ist in meinem Post vom 13.04.2011 
20:08)
Das .hex + .eep von mir oder selber compiliert?
Fuses richtig gesetzt?
Das .eep nicht vergessen zu brennen?
Welche Quarzfrequenz?

Hast du das nur bei 4MHz ausprobiert oder bei mehreren Frequenzen?
Ist das immer genau 1/4 ?
Auf die Signalquelle kannst du dich verlassen?
Die liefert auch sauberen HCMOS-Pegel?


XL

von Axel S. (a-za-z0-9)


Lesenswert?

Moin Michael,

> ich möchte mal das Projekt in Angriff nehmen und zwar eine LCD 2x16
> sowie eine LED Version.

OK

> In der config.h werden ja die Display-Versionen konfiguriert, da ich im
> Programmieren nicht der 'Profi' bin, hier mein Anliegen:
> Wird, wie im Screenshot von mir markiert, die Zeilen einfach
> auskommentiert

Nein. Du mußt das Makro CUSTOMIZATION auf die gewünschte Variante 
setzen. In deinem Fall also:

#define CUSTOMIZATION default_2x16

> Wie sieht es mit der LED-Version aus, was ist da zu beachten?

Die Firmware ist separat von der LCD-Version. Zu konfigurieren gibts da 
nix, es sei denn du willst. Wenn sich z.B. das Layout vereinfachen 
würde, wenn die Zuordnung von Portpins zu Segmenten anders wäre, dann 
kann man das in ports.h ändern. Ebenfalls in ports.h müßtest du ändern, 
wenn du invertierende Segment-Treiber einsetzen wölltest.


XL

von Michael D. (mike0815)


Angehängte Dateien:

Lesenswert?

Hi Axel,

ich hab' das jetzt so gesetzt: #define CUSTOMIZATION default_2x16
...lauter Fehlermeldungen.

jetzt net schimpfen ;-(

dann dachte ich setze #define CUSTOMIZATION default_1x16 auf #elif
...war wohl nix, auch Fehlermeldungen...bin ich zu doof, oder was habe 
ich jetzt falsch gemacht? Kann doch nicht so schwer sein!
Ich zeig's noch mal im Shot.

LED-Version: Ich mache da mal ein neues Layout mit den 
7-Segmentanzeigen. Mal schauen, entweder Sandwichmethode oder als 90 
Grad Modul. Auf jeden Fall werde ich die 7-Seg mit gemeinsamer Anode 
verwenden...da habe ich jede Menge.
Selbstverständlich werde ich das dann hier rein setzen, das andere auch 
was davon haben!

Gruß Michael

von Matthias Fischer (Gast)


Lesenswert?

Hallo XL,

>Welche Software-Version? (die letzte ist in meinem Post vom 13.04.2011
>20:08)

Genau diese habe ich verwendet

>Das .hex + .eep von mir oder selber compiliert?
>Fuses richtig gesetzt?

habe nix weiter compiliert, habe es 1:1 so übernommen, fusees sind wie 
im makefile gesezt.

>Das .eep nicht vergessen zu brennen?

habe ich auch gemacht

>Welche Quarzfrequenz?

14,3181 MHz

>Hast du das nur bei 4MHz ausprobiert oder bei mehreren Frequenzen?
>Ist das immer genau 1/4 ?
>Auf die Signalquelle kannst du dich verlassen?

ist immer genau 1/4, habe es mit verschiedenen Taktquellen probiert, wie 
z.B. Takt aus anderem µController, RTC, Schaltregler LM2576 und MC34063. 
Mein Multimeter zeigt dort überall die richtigen Werte an.

>Die liefert auch sauberen HCMOS-Pegel?

hoffe ich doch, ohne Oszi leider schwer zu prüfen

Welche Funktion haben eigentlich die 4 Widerstände (4,7k) über Jumper 
nach Ground? Mit oder ohne Jumper ändert sich nichts...

Gruß M.

von Hans M. (Firma: mayer) (oe1smc) Benutzerseite


Lesenswert?

hallo

> Welche Funktion haben eigentlich die 4 Widerstände (4,7k) über
> Jumper nach Ground? Mit oder ohne Jumper ändert sich nichts...

soweit ich mitbekommen habe: for future use.
also derzeit ohne verwendung.

gruss
hans

--

von Axel S. (a-za-z0-9)


Lesenswert?

Moin,

Michael D. schrieb:
> ich hab' das jetzt so gesetzt: #define CUSTOMIZATION default_2x16
> ...lauter Fehlermeldungen.
...

> dann dachte ich setze #define CUSTOMIZATION default_1x16 auf #elif
> ...war wohl nix, auch Fehlermeldungen...bin ich zu doof, oder was habe
> ich jetzt falsch gemacht? Kann doch nicht so schwer sein!

Fang nochmal von vorn an. Pack mein Archiv aus und compiliere den Kram. 
Geht das? Wenn ja, dann ändere genau die eine Zeile

#define CUSTOMIZATION default_2x16

Wenn es nicht compiliert, bitte die genaue Fehlermeldung zeigen.


XL

von Michael D. (mike0815)


Angehängte Dateien:

Lesenswert?

Hi Axel,

Ich habe ein neues Projekt im Studio4 begonnen, sowie die Quarzfrequenz 
von:
14310000 Hz eingetragen(wie vorher auch)jetzt wird ja auch ein neues 
Makefile generiert.
Jedenfalls lässt sich dein 1x16 Display sowie die geänderte 2x16 
kompilieren!
Wie blöd, ich hatte die falsche Zeile Editiert:
(#define CUSTOMIZATION == default_2x16)statt die von dir angegebene:
(#define CUSTOMIZATION default_2x16)

Ich habe das Bord soweit geroutet. Einseitig, da ich keine 
Doppelseitigen Platinen da habe. Vielleicht komme ich morgen dazu diese 
zu ätzen und gleich zu bestücken, dann die die Soft drauf und 
testen...da bin ich abermal gespannt.
Vorab ein Dankeschön für deine Unterstützung!!!

Anbei noch mall die Shots mit dem Report

Gruß Michael
Edit: Die Fusebits muß ich später manuell setzen, brennen tu ich dann 
mit dem Extrem Burner.
Quarzfrequenz 'External' ist klar, interne 'Cs' auf aus auch. Sind sonst 
noch Fuses zu beachten?
Ach ja, ich habe hier mehrere Schaltpläne aus diesem Thread, da waren 
die die Cs für den Ext.Quarz mit 22nF angegeben, das kann ja nicht 
hinhauen...hoffentlich hat Mathias diese nicht verbaut.

von Matthias Fischer (Gast)


Lesenswert?

@Michael D.
>Ach ja, ich habe hier mehrere Schaltpläne aus diesem Thread, da waren
>die die Cs für den Ext.Quarz mit 22nF angegeben, das kann ja nicht
>hinhauen...hoffentlich hat Mathias diese nicht verbaut.

hallo Michael D., nein, nein, habe natürlich 22pF verbaut. Werde an das 
ganze jetzt mal ein LCD anhängen und schauen ob es da funktioniert. 
Natürlich mit passender Firmware :-) ...

Gruß Matthias

von Michael D. (mike0815)


Lesenswert?

moin Matthias,

> hallo Michael D., nein, nein, habe natürlich 22pF verbaut. Werde an das
> ganze jetzt mal ein LCD anhängen und schauen ob es da funktioniert.
> Natürlich mit passender Firmware :-) ...

Genau aus diesem Grund baue ich erstmal das "Original" auf, um 
eventuellen Eventualitäten den Garaus zu machen :-)

Deinen Automaten bekommen wir auch noch zum laufen, wäre ja gelacht, 
oder?
Vielleicht setzt du mal ein paar Fotos von deinem Werk hier rein, bzw. 
welchen Schaltplan hast du benutzt? Vielleicht kann man visuell den 
Fehler finden...nur so eine Idee.

> Gruß Matthias

bis später dann,

Gruß Michael

von Michael D. (mike0815)


Angehängte Dateien:

Lesenswert?

Ok, ich noch mal

Ich habe eben das Layout für die einseitige Platine fertiggestellt.
Vielleicht schaut ihr noch mal drüber, evtl. kann man was verbessern!

Eines vorab, ich bin teilweise aus dem Raster (0,635mm) , das ging eben 
nicht anders, da der Platz doch sehr begrenzt ist!
Anbei mal das Layout und der dazugehörige Schaltplan im PDF sowie die 
Eagle-Files (Gepackt)
Wenn alles Ok ist, stelle ich die Platine morgen her.
Wünsche Allen noch einen schönen Abend.

Gruß Michael

von Michael D. (mike0815)



Lesenswert?

Ok, jetzt habe ich mir den ganzen Sonntag für den Frquenzzähler 
vorgenommen und das Ergebnis habe ich mal bebildert.
Die Platine bzw. das Layout, habe ich noch mal überarbeitet und alle 
Biegungen in die 90Grad gerückt!
Wenn Bedarf besteht, kann ich die Eagles-Files hier noch mal hochladen.

Das Teil funktioniert einwandfrei nach der Potijustierung(bis auf 3Hz), 
absolut ohne gezappel.
Mit der originalen SW mit 1x16 kann ich ohne Probleme bis 32MHz messen, 
mehr habe ich gerade nicht zur Verfügung.
Wenn ich jedoch die kompilierte 2x16 Display Version in den Mega8 lade, 
komme ich nur bis 222 kHz, darüber geht nichts mehr! Schade, wollte 
schon das komplette Display ausnutzen, wo liegt der Fehler?
Anbei mal ein paar Shots.

Ein kleines Anliegen hätte ich noch: Vielleicht könnte man die Hz, kHz 
usw., zur besseren Übersicht an den rechten Displayrand verschieben?
An dieser Stelle noch mal ein dickes Lob für denn Axel, hast du fein 
hinbekommen!

Was absolut wichtig war, bei meinen Experimenten, war die EEprom Datei 
mit aufzuspielen, sonst kommmt da nur Müll raus! Vielleicht hat Matthias 
die vergessen, könnte das sein?

Gruß Michael

von Michael D. (mike0815)


Lesenswert?

Hm, sind hier alle ausgeflogen?

Ich habe mich noch mal an das Kompilieren mit dem AVR-Studio/4.18 
gemacht und festgestellt, das es definitiv an dessen Ausgabe liegt! Auch 
beim Kompilieren mit Display 1x16!
Die origiginale main.hex funzt ohne Probs. Bei der kompilierten Version, 
geht wohl irgentwas schief(ausser der main.eep, die ist i.O.), wenn ich 
nur wüsste was?
Die Quarzfrequ. im Projekt ist eingetragen mit 14310000 Hz, Fusebits 
LF=0x9F, HF=0x9C Jetzt würde ein wenig Hilfe ganz gut tun...

Ich teste mal die 1.3er Version, mal sehen, was dabei heraus kommt.

Gruß Michael

von Axel S. (a-za-z0-9)


Lesenswert?

Moin,

Michael D. schrieb:
> Hm, sind hier alle ausgeflogen?

Nö. Bloß ein langes Wochenende gehabt :)

> Ich habe mich noch mal an das Kompilieren mit dem AVR-Studio/4.18
> gemacht und festgestellt, das es definitiv an dessen Ausgabe liegt! Auch
> beim Kompilieren mit Display 1x16!
> Die origiginale main.hex funzt ohne Probs. Bei der kompilierten Version,
> geht wohl irgentwas schief(ausser der main.eep, die ist i.O.), wenn ich
> nur wüsste was?

Welche Version von avr-gcc / avr-libc benutzt du? Wird die main.disasm 
gebaut (oder kannst du die mit "avr-objdump -d -S main.elf >main.disasm" 
erzeugen)? Dann schick mir die per Mail.

> Die Quarzfrequ. im Projekt ist eingetragen mit 14310000 Hz, Fusebits
> LF=0x9F, HF=0x9C Jetzt würde ein wenig Hilfe ganz gut tun...

Hoffentlich ist der Dreher nur hier beim Abtippen. Aus meinem Makefile:
1
HFUSE = 0xC9                                                                    
2
LFUSE = 0x9F                                                                    
3
                                                                                
4
# Fuse high byte:                                                               
5
# 0xc9 = 1 1 0 0   1 0 0 1 <-- BOOTRST (boot reset vector at 0x0000)            
6
#        ^ ^ ^ ^   ^ ^ ^------ BOOTSZ0                                          
7
#        | | | |   | +-------- BOOTSZ1                                          
8
#        | | | |   + --------- EESAVE (don't preserve EEPROM over chip erase)   
9
#        | | | +-------------- CKOPT (full output swing)                        
10
#        | | +---------------- SPIEN (allow serial programming)                 
11
#        | +------------------ WDTON (WDT not always on)                        
12
#        +-------------------- RSTDISBL (reset pin is enabled)                  
13
# Fuse low byte:                                                                
14
# 0x9f = 1 0 0 1   1 1 1 1                                                      
15
#        ^ ^ \ /   \--+--/                                                      
16
#        | |  |       +------- CKSEL 3..0 (external >8M crystal)                
17
#        | |  +--------------- SUT 1..0 (crystal osc, BOD enabled)              
18
#        | +------------------ BODEN (BrownOut Detector enabled)                
19
#        +-------------------- BODLEVEL (2.7V)


XL

von Axel S. (a-za-z0-9)


Lesenswert?

Hallo Matthias,

Matthias Fischer schrieb:
>
> habe nix weiter compiliert, habe es 1:1 so übernommen, fusees sind wie
> im makefile gesezt.
>>Das .eep nicht vergessen zu brennen?
> habe ich auch gemacht
>>Welche Quarzfrequenz?
> 14,3181 MHz

Dann ist das ausgesprochen merkwürdig. Ich habe jetzt extra für dich 
nochmal das .hex und .eep aus meinem Post in den Mega8 geflasht, 
Funktioniert so wie es soll. Sowohl mit meinem Test-RC-Generator (unten 
rechts auf dem Breadboard-Foto) als auch mit ein paar testweise 
angehängten Quarz-Oszillatoren. Ein systematischer Fehler mit Faktor 4 
wäre mir da sicher aufgefallen :)

>>Auf die Signalquelle kannst du dich verlassen?
>
> ist immer genau 1/4, habe es mit verschiedenen Taktquellen probiert, wie
> z.B. Takt aus anderem µController, RTC, Schaltregler LM2576 und MC34063.
> Mein Multimeter zeigt dort überall die richtigen Werte an.

Auf die Schaltregler würde ich mich da nicht verlassen. Der µC und die 
RTC sollten allerdings ein sauberes Signal liefern.

Der Unterschied zwischen deinem Multimeter und diesem Modul ist, daß das 
Multimeter einen Verstärker und Impulsformer am Eingang hat. Das 
Zählermodul hat das nicht on Board, weil es ja als "Panelmeter" für den 
Festeinbau gedacht ist und die Anpassung des Signalpegels auf HCMOS dann 
spezifisch für das Gerät drum herum ist. Aber früher in diesem Thread 
haben einige Leser Schaltungen oder Links für Vorverstärker gepostet. 
Für den universellen Einsatz brauchst du einen Vorverstärker.

Als Fehlerquellen vermute ich (in absteigender Wahrscheinlichkeit)

1. einen Verdrahtungsfehler, insbesondere zwischen dem HC590 und dem 
Mega8

2. fehlerhafte Daten im EEPROM. Die ersten 4 Bytes im EEPROM müssen die 
Quarzfrequenz ergeben. Siehe auch CALIBRATE.txt aus der LCD-Firmware.

3. dreckiges Signal und/oder schlechte Masse/Versorgung/Abblockung. Ein 
Oszi ist hier natürlich extrem hilfreich. Aber bei mir funktioniert 
Versorgung aus dem USB und ein Quarz-Oszillator mit 1m Laborstrippen 
(ungeschirmt!) ganz problemlos. Bilder meines Aufbaus findest du im 
Thread.

> Welche Funktion haben eigentlich die 4 Widerstände (4,7k) über Jumper
> nach Ground? Mit oder ohne Jumper ändert sich nichts...

Derzeit keine Funktion. Ein Jumper ist fest eingeplant, um die Anzeige 
zwischen Frequenz und Periodendauer umschalten zu können. Weitere Jumper 
z.B. für die Berücksichtigung eines Vorteilers.


XL

von Michael D. (mike0815)


Lesenswert?

Hi Axel,
Jetzt habe ich erst deine beantwortet und dann hier gelesen, das ist 
jetzt blöd!

> Welche Version von avr-gcc / avr-libc benutzt du? Wird die main.disasm
> gebaut (oder kannst du die mit "avr-objdump -d -S main.elf >main.disasm"
> erzeugen)? Dann schick mir die per Mail.

Die avr-gcc ist doch in der Toolchain oder? Die Toolchain, hatte ich 
schon mal aktualisiert!

Die main.disasm, wird nicht generiert, von was ist die abhängig, bzw. 
kann man das dem Studio erzählen? So langsam komme ich in's Schleudern.

Den Takt habe ich jetzt mit 14318000Hz im Projekt angegeben, die Fuses 
high u. Low stimmen exakt, die internen Kondensatoren(CKOPT) sind 
aktiviert, sehe ich das richtig?

Gruß Michael

EDIT: Wie schon weiter oben gesagt, die originale Hex mit 1x16 funzt 
einwandfrei, der Mattias muß einen Hardwarefehler haben!

Noch was, wenn ich das Signal abklemme, bleibt der Zähler auf der der 
zuletzt gemessen Frequenz stehen, ist das richtig so?

von Michael D. (mike0815)


Angehängte Dateien:

Lesenswert?

Hier noch mal einen Shot von den Fuses.

von Axel S. (a-za-z0-9)


Lesenswert?

Michael D. schrieb:
>
>> Welche Version von avr-gcc / avr-libc benutzt du?
>
> Die avr-gcc ist doch in der Toolchain oder? Die Toolchain, hatte ich
> schon mal aktualisiert!

Das war nicht die Frage. Welche Versionen sind das genau?

> Die main.disasm, wird nicht generiert, von was ist die abhängig, bzw.
> kann man das dem Studio erzählen?

Ich kann nix zum Studio sagen. Aber mein Makefile baut die automatisch.

> die Fuses
> high u. Low stimmen exakt, die internen Kondensatoren(CKOPT) sind
> aktiviert, sehe ich das richtig?

Die Fuses sehen gut aus. Du hattest in deinem vorigen Post aber einen 
Dreher: HFUSE=0x9C was aber 0xC9 sein muß.

> Noch was, wenn ich das Signal abklemme, bleibt der Zähler auf der der
> zuletzt gemessen Frequenz stehen, ist das richtig so?

Ja, das ist Absicht, damit man den Wert auch nach dem Abklemmen des 
Signals noch ablesen kann. Die Unterlauf-Anzeige signalisiert dann, daß 
das Signal fehlt.


XL

von Michael D. (mike0815)


Lesenswert?

Hi Axel,
Ich konnte die 'main.disasm' mit dem Programmer's Notepad und deinem 
Makefile generieren, habe alles in die Post gepackt.
Mit WinAVR besteht dasselbe Problem! Bin ich der einzige hier, der das 
Kompilierproblem hat? Wie sieht's denn bei den Anderen hier aus?

Axel Schwenke schrieb:

>>> Welche Version von avr-gcc / avr-libc benutzt du?
>>
>> Die avr-gcc ist doch in der Toolchain oder? Die Toolchain, hatte ich
>> schon mal aktualisiert!
>
> Das war nicht die Frage. Welche Versionen sind das genau?
Tschuldige!

2.AVR GNU Compiler Collection (GCC) 4.3.3
3.avr-libc 1.6.7cvs
Das steht im Winavr-What's new Guide.
>
>> Die main.disasm, wird nicht generiert, von was ist die abhängig, bzw.
>> kann man das dem Studio erzählen?
>
> Ich kann nix zum Studio sagen. Aber mein Makefile baut die automatisch.
>
...geht ja mittlereweile mit dem Prog.Notepad und 'make all'!

>> die Fuses
>> high u. Low stimmen exakt, die internen Kondensatoren(CKOPT) sind
>> aktiviert, sehe ich das richtig?
>
> Die Fuses sehen gut aus. Du hattest in deinem vorigen Post aber einen
> Dreher: HFUSE=0x9C was aber 0xC9 sein muß.

Kann sein, ist ja auf dem Shot richtig dargestellt.
>
>> Noch was, wenn ich das Signal abklemme, bleibt der Zähler auf der der
>> zuletzt gemessen Frequenz stehen, ist das richtig so?
>
> Ja, das ist Absicht, damit man den Wert auch nach dem Abklemmen des
> Signals noch ablesen kann. Die Unterlauf-Anzeige signalisiert dann, daß
> das Signal fehlt.
>
Stimmt, da wird ein 'U' angezeigt, ist auch ok, passt schon!
Das '=' Zeichen stört mich ein wenig, könnte man weg lassen und evtl. 
noch 1 oder 2 Leerstellen einfügen zwischen den Zahlen und den kHz, 
währe etwas übersichtlicher...
>
> XL
Gruß Michael

von Michael D. (mike0815)



Lesenswert?

Ok, zur Abwechslung mal was Positives! Das Teil begeistert und das mit 
relativ wenig Aufwand!
Die Stabilität ist äusserst zufriedenstellend und als Panelmeter für 
vorhandene Frequenzgeneratoren genial.
Da mein FreqGen. Rechteck nur bis 16MHz bzw. fester Aussentakt 32MHz 
generiert, habe ich mal ein paar Quarzoszillatoren bemüht.

Hier mal die Fotos mit den Oszillatoren: 36MHz, 40MHz und 50MHz(das 
wollte ich jetzt wissen)
Die fuffzich MHz mist er locker...
Leider kann ich zur Zeit nur 2x8 Zeilen zur Schau stellen, da ich ja mit 
dem Kompilieren noch Probleme habe.

Gruß Michael

Edit: Ich sehe gerade, das beim 40MHz die Frequenz etwas daneben ist. 
Könnte am Messaufbau oder am Oszillator liegen, ist alles andere als HF 
gerecht. :-/

von Matthias Fischer (Gast)


Angehängte Dateien:

Lesenswert?

Hallo Axel und Michael,

nach der "Pleite" mit dem LED-Zähler habe ich den LCD-Zähler mal gebaut 
mit dem Layout von Michael. Das Ergebnis seht Ihr auf den Fotos ....

HILFE ......

Gruß Matthias

von Michael D. (mike0815)


Lesenswert?

Ha, das ehrt mich!
Ich hatte 'hier' das überarbeitete Layout angeboten, das waren noch mal 
2STD. Arbeit...hättest mir ja mal ne' PN schicken können ;-/
Das Layout war nicht der Reisser, ist aber i.O.

Wenn du jetzt noch die Quarzfrequenz anpasst und Feintuning am Poti 
vornimmst, hast du genau 1 viertel der Frequenzanzeige...:-)

Jetzt im Ernst, spiel jetzt mal die 'nicht' selbst kompilierte Hex und 
eep(Das Original 1x16) von Alex drauf und berichte mal, was da angezeigt 
wird...das interessiert mich jetzt! Los, ich warte...

Gruß Michael

Edit: Hast du das blaue Display auch von den Hong Konglern?
Was für ein Frequenzgenerator hast du da? Kommt da TTL-Pegel raus?

von Matthias F. (matthiasf)


Angehängte Dateien:

Lesenswert?

So, hier das Ergebnis mit der originalen Version 1.4 mit 1x10 Display 
(nicht wie im Bildnamen 1x16). Ist das selbe Problem wie vorher :-( 
Kann ja nun nur noch an meiner Hadware liegen - trotz das ich die ICs 
schon getauscht habe ...

Als Frequenzgenerator habe ich den aus diesem Forum --> 
Beitrag "Einstellbarer Frequenzgenerator für 0.12 Hz - 8 MHz mit Atmega 8 und Bascom" und das blaue Display kommt 
tatsächlich von unseren chinesischen Freunden ...

Gruss M.

von Michael D. (mike0815)



Lesenswert?

Ok, ich habe jetzt meine mal auseinander genommen!
Ich lade jetzt mal die Bilder hoch und du vergleichst mal dein Layout 
mit meinem, sollte alles ok sein, dann machen wir PN, sonst müllen wir 
ja den Thread zu...

Mein Verdacht liegt bei: Quarz, defekte C's vom Quarz, interner statt 
externer Takt? Den 7474 mal getauscht, vielleicht triggert der nicht 
richtig?

Gruß Michael

Edit: Hoffentlich ist der Alex nicht schon im Urlaub, wollte das Teil 
schon verbauen...

von Old P. (Gast)


Lesenswert?

Matthias F. schrieb:
> Als Frequenzgenerator habe ich den aus diesem Forum -->

Hallo,
ich schau hier auch mal wieder rein....

Also, bist Du sicher, dass der Generator nicht der Übeltäter ist?

Ansonsten hatte ich ja zunächst auch so meine Probleme, doch mit der 
letzten Version lief und läuft das bei mir astrein. Compiliert habe ich 
mit AVR-Studio und nach den Hinweisen (s. weiter oben) von Axel und 
anderen. Inzwischen habe ich mehrere aufgebaut (auf meinem Layout und 
mit HC132-Trigger) und alle laufen wie erwartet. Ich habe aber nur eine 
Zeile meiner 2-zeiligen Displays verwandt, reicht bisher aus.

Gruß
Old-Papa

von Matthias F. (matthiasf)


Lesenswert?

Hallo Old-Papa,

>Also, bist Du sicher, dass der Generator nicht der Übeltäter ist?

bin mir ziemlich sicher, das das nicht der Generator ist. Multimeter 
zeigt richtige Frequenz an. Wenn ich als Taktquelle die RTC DS3232 nehme 
mit 32768 kHz zeigt mein Multimeter das auch an, der Nachbau hier nur 
7.82528 kHz.

Gruß M.

von Michael D. (mike0815)


Lesenswert?

Hallo old-papa,

> Hallo,
> ich schau hier auch mal wieder rein....
fein...

> Also, bist Du sicher, dass der Generator nicht der Übeltäter ist?

Ich habe den gleichen Generator, 1x mega8 mit 10MHz Ausgang und den 
mega48 mit 16MHz bzw. 32MHz Fix Ausgang.
Die Flanken haben bei den Frequenzen eine Rise-und Fall-Time von 3nS ! 
Ich denke, das müsste reichen für eine saubere Messung. In Dem Thread, 
den Mattias angegeben hat, habe ich einige Oszibilder hinterlassen. Es 
müsste echt saudumm gelaufen sein, wenn Mattias nur noch defekte Geräte 
produziert  :-((

Ich habe mir mal die Mühe gemacht und den Fuses gespielt. Es liegt nicht 
am internen Takt, da wird eher die doppelte u. dreifache Frequenz 
angezeigt!
Den EXT.Clock, habe ich jetzt mal nicht getestet, sonst muß ich den Mega 
ausbauen, falls er nicht mehr anschwingt.

 Gruß Michael

EDIT: old-papa, du hast Post!!!

von Axel S. (a-za-z0-9)


Lesenswert?

Hallo Matthias,

Matthias Fischer schrieb:
>
> nach der "Pleite" mit dem LED-Zähler habe ich den LCD-Zähler mal gebaut
> mit dem Layout von Michael. Das Ergebnis seht Ihr auf den Fotos ....
>
> HILFE ......

Nun, als erstes muß ich bemerken, daß der Zähler nicht 1/4 des 
erwarteten Ergebnisses anzeigt, sondern daß das Verhältnis 1:4.185 .. 
1:4.187 ist. Das macht einen riesigen Unterschied, wenn man über 
mögliche Fehlerursachen spekuliert!

Da das Problem auch mit der originalen main.hex und einem nachweislich 
korrekten Layout auftritt, ist der wahrscheinlichste Kandidat der Inhalt 
des EEPROMs. Womit flashst du den Controller? Hast du die main.eep 
wirklich ins EEPROM geschrieben?

Mach doch mal einen Dump des EEPROMs in deinem Controller. Z.B. so:

avrdude -p atmega8 -P usb -c usbasp -U eeprom:r:eeprom.hex:i

(die -P und -c optionen passend zu deinem Brenner setzen)

Dann schau dir eeprom.hex an. Die erste Zeile muß so beginnen:

:20000000667ADA00FFFFFF ...


XL

von Michael D. (mike0815)


Lesenswert?

Hi Axel, da isser ja...

> Nun, als erstes muß ich bemerken, daß der Zähler nicht 1/4 des
> erwarteten Ergebnisses anzeigt, sondern daß das Verhältnis 1:4.185 ..
> 1:4.187 ist. Das macht einen riesigen Unterschied, wenn man über
> mögliche Fehlerursachen spekuliert!

das war jetzt von mir auch nur mal so dumm daher gesagt mit einem 
Lächeln dahinter... :-/

> Da das Problem auch mit der originalen main.hex und einem nachweislich
> korrekten Layout auftritt, ist der wahrscheinlichste Kandidat der Inhalt
> des EEPROMs. Womit flashst du den Controller? Hast du die main.eep
> wirklich ins EEPROM geschrieben?

Ich habe mir mal die Hex u. eep von Mathias schicken lassen und mit dem 
Extrem-Burner geflasht, diese sind völlig i.O.
Dann habe ich nur seine Hex geflasht ohne EEprom, komme aber nicht auf 
'seine' angezeigten Werte, ausserdem zappelt dann die Anzeige wie wild!
Heute Abend werden wir ja erfahren mit was der Mathias da flasht und ob 
da ein Übertragungsfehler vorliegt?!?

Gruß Michael

von Axel S. (a-za-z0-9)


Lesenswert?

Michael D. schrieb:
> Ich habe mir mal die Hex u. eep von Mathias schicken lassen und mit dem
> Extrem-Burner geflasht, diese sind völlig i.O.
> Dann habe ich nur seine Hex geflasht ohne EEprom, komme aber nicht auf
> 'seine' angezeigten Werte, ausserdem zappelt dann die Anzeige wie wild!

Na ja. Wenn du "L14" aka 0x4C 0x31 0x34 an den Anfang des EEPROM 
schreiben würdest, dann würdest du etwa die gleichen Meßergebnisse wie 
Matthias bekommen.

Es gibt ja auch Flash-Programme, die eine Signatur ins EEPROM schreiben. 
Z.B. avrdude schreibt ans Ende des EEPROM, wie oft der AVR schon 
geflasht wurde. Vielleicht verwendet M. ja etwas, das Müll an den Anfang 
des EEPROM schreibt.

Wenns das nicht ist, dann bin ich echt ratlos...


XL

von Michael D. (mike0815)


Lesenswert?

> Na ja. Wenn du "L14" aka 0x4C 0x31 0x34 an den Anfang des EEPROM
> schreiben würdest, dann würdest du etwa die gleichen Meßergebnisse wie
> Matthias bekommen.

Aha, wieder was gelernt...ich probiere das erst garnicht aus, bin froh, 
das mein Teil rennt ;-)

> Es gibt ja auch Flash-Programme, die eine Signatur ins EEPROM schreiben.
> Z.B. avrdude schreibt ans Ende des EEPROM, wie oft der AVR schon
> geflasht wurde. Vielleicht verwendet M. ja etwas, das Müll an den Anfang
> des EEPROM schreibt.

Ach, das wusste ich jetzt auch nicht! Welche Programme machen das denn 
und wo schreiben die das hin...Anfang oder Ende?

> Wenns das nicht ist, dann bin ich echt ratlos...
Ich habe mir gestern Abend auch die Mühe gemacht, das nachzuvollziehen, 
jetzt fällt mir auch nüscht mehr ein!

Gruß Michael

von Axel S. (a-za-z0-9)


Lesenswert?

Michael D. schrieb:
>> Es gibt ja auch Flash-Programme, die eine Signatur ins EEPROM schreiben.
...
> Ach, das wusste ich jetzt auch nicht! Welche Programme machen das denn
> und wo schreiben die das hin...Anfang oder Ende?

Ich kenne es erstmal nur von AVRdude. Siehe Beschreibung der -y Option 
z.B. hier:

http://www.nongnu.org/avrdude/user-manual/avrdude_4.html#Option-Descriptions

Und die GALEP-Software erlaubt auch, die Programmversion und/oder eine 
Seriennummer zu erzeugen und in das Device zu schreiben.

Eine solche Funktion ist sehr praktisch, solange man weiß was sie tut. 
Aber egal, der EEPROM-Dump wird es hoffentlich ans Licht bringen.

Mir fällt grad auf, daß das durchaus "V14" für "Version 1.4" sein 
könnte.


XL

von Michael D. (mike0815)


Lesenswert?

das ist ja interessant,
ich habe mal die generierte EEP ausgelesen und dann den Dump vom 
Controller:
Hier die Einträge

:040000005877DA0053
:00000001FF

ausgelesen:

:100000005877DA00FFFFFFFFFFFFFFFFFFFFFFFF53
:00000001FF

...wie kann man das unterbinden mit den vielen 'F' oder macht das keinen 
Unterschied?
Kann eigentlich nicht sein, da die EEP's ja bei mir Funktionieren oder 
wird beim Übertragen irgentwelcher Müll auch in die Hex geschrieben?

Ich lese das heute Abend mal aus und vergleiche, dann werden wir ja 
sehen ob es am Brennprog. liegt!

Gruß Michael

von Axel S. (a-za-z0-9)


Lesenswert?

Michael D. schrieb:
> das ist ja interessant,

Nein :)

> ich habe mal die generierte EEP ausgelesen und dann den Dump vom
> Controller:
>
> :040000005877DA0053

04: 4 Byte Daten
0000: an Adresse 0
00: die Zeile ist ein Daten-Record
5877DA00: die Daten 0x00DA7758 = 14317400
53: Prüfsumme dieser Zeile

> :00000001FF

Ein Ende-Record. Siehe http://de.wikipedia.org/wiki/Intel_HEX

> ausgelesen:
>
> :100000005877DA00FFFFFFFFFFFFFFFFFFFFFFFF53

16 Bytes ausgelesen. Die ersten 4 Bytes wie geschrieben, der Rest 0xFF.

> ...wie kann man das unterbinden mit den vielen 'F' oder macht das keinen
> Unterschied?

Die erzeugte .eep enthält nur die Speicheradressen, an denen der 
Compiler (bzw. Linker) Variablen aus dem .eeprom Segment hinlegt. 
Derzeit ist das genau eine:
1
/* constants in EEPROM */                                                       
2
3
EEMEM uint32_t ee_fref = F_CPU;

Der Rest des EEPROM ist egal, wird aber beim Löschen des Controllers 
typischerweise mit gelöscht - also auf FF gesetzt. In meinem steht in 
den letzten 4 Bytes des EEPROM noch die Zahl, wie oft ich den Controller 
schon geflasht habe.


XL

von Matthias F. (matthiasf)


Angehängte Dateien:

Lesenswert?

Hallo Jungs,

es ist vollbracht, der Fehler lag wirklich im eep-file. Mein Brenner 
hats nicht richtig ins EEPROM gebrannt :-( Dank Axels Ausführungen über 
I-HEX Format hats nun geklappt.

Mit avrdude war es kein Problem.

Anbei noch der fehlerhafte EEPROM-Dump:

:200000003A3034303030303030313437414441303039340D0A3A3030303030303031464 
695
:200020000D0AFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 
FC7
:20004000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 
FC0
:20006000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 
FA0
:20008000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 
F80
:2000A000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 
F60
:2000C000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 
F40
:2000E000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 
F20
:20010000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 
FFF
:20012000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 
FDF
:20014000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 
FBF
:20016000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 
F9F
:20018000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 
F7F
:2001A000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 
F5F
:2001C000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 
F3F
:2001E000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 
F1F
:00000001FF

Danke für Eure Unterstützung.

Gruß M.

von Michael D. (mike0815)


Lesenswert?

Das glaub' ich doch jetzt nicht, oder? Was für ein 'Miststück', war denn 
jetzt dafür zuständig? War es die Software oder der Brenner selbst?

Sieht chic aus mit den 7-Segment-Anzeigen, nur die Pltine ist ein 
bißchen groß, oder?
Ich will für die LED-Anzeige eine extra Platine fertigen und dann als 
Huckepack aufsetzen, dann hat man beim Einbau weniger Platzprobleme.


Übrigens, ist dein LCD-Display auf der falschen Seite, war das Absicht?

Gruß Michael

von Matthias F. (matthiasf)


Lesenswert?

Hallo Michael,

>War es die Software oder der Brenner selbst?

Schuld war die Brennsoftware - hat bis jezt immer funktioniert 
(BASCOM-intern).

>Übrigens, ist dein LCD-Display auf der falschen Seite, war das Absicht?

Na klar war das "Absicht" :-) hatte die Buchsenleiste auf die falsche 
Seite gelötet...

Wie hast du eigentlich diesen Bestückungsaufdruck hergestellt ??

Matthias

von Old P. (Gast)


Lesenswert?

Matthias F. schrieb:
> Wie hast du eigentlich diesen Bestückungsaufdruck hergestellt ??

Kann man im einfachsten Fall spiegelverkehrt mit Laser drucken und dann 
aufbügeln... ;)
Oder auf transparente Ertikettfolie drucken und aufkleben.
Oder....

Gruß
Old-Papa (der sowas noch nie gebraucht hat)

von Michael D. (mike0815)


Lesenswert?

Hallo Matthias,

> Schuld war die Brennsoftware - hat bis jezt immer funktioniert
> (BASCOM-intern).

Bascom ist gut um die Fuses zu setzen, weil es schön übersichtlich ist.
Brennen kommt nicht mehr in Frage, siehst ja, was dabei raus kommt.
Ich hatte damit schon öfter Probleme, hatte sie zum Glück bemerkt.

Nimm den Extrem-Burner, hat bei mir immer zuverlässig die Daten 
übertragen.
Ponyprog hat mich bei bei einem mega8, mega88 und tiny24V ausgesperrt.
Da lese ich nur noch im absoluten Notfall die Fuses aus!

>> Übrigens, ist dein LCD-Display auf der falschen Seite, war das Absicht?

> Na klar war das "Absicht" :-) hatte die Buchsenleiste auf die falsche
> Seite gelötet...

Du hast wenigstens noch eine gehabt, ich hatte Pech und musste dafür 
eine 34-Pol Pfostenbuchse misbrauchen. Bei der Löterei mit dem fetten 
Teil, haben sich 4 Leiterbahnen verabschiedet, man sieht die Reparatur 
auf den Fotos, glaub' ich.

> Wie hast du eigentlich diesen Bestückungsaufdruck hergestellt ??

Ich mache das immer in einem Aufwisch (Laserdruck) zusammen mit dem 
Layout.
Wenn die Kupferseite geäzt ist, werden die Löcher gebohrt und danach mit 
dem Bestückungsdruck durch den Laminator geschoben, leider ist mir bei 
der Platine das Papier verutscht, wie man sieht!
Auf jeden Fall spart das beim Bestücken eine Menge Zeit und eine 
Fehlbestückung ist 'fast' ausgeschlossen! Wenn du mehr über meine 
Verfahrensweise wissen möchtest, schreib' mir eine PN.

Old-Papa :-)
> Kann man im einfachsten Fall spiegelverkehrt mit Laser drucken und dann
> aufbügeln... ;)

Mit dem Aufbügeln, war ich nicht so begeistert :-(

> Oder auf transparente Ertikettfolie drucken und aufkleben.
> Oder....

Blos net, die Folie wickelt sich um den Bohrer und du ärgerst 
dich...dann lieber Bügeleisen. ;-)

Gruß
Old-Papa (der sowas noch nie gebraucht hat)

Hmm, das Bestücken ist dann wirklich angenehmer, man muß nicht ständig 
auf den Ausdruck glotzen und die Stellen suchen, wo was wohin kommt. 
Probier's doch mal aus?!?

Auweia, schon wieder nach eins, ich muß in's Bett.

Ich wünsche euch eine schicke Nacht!

von Axel S. (a-za-z0-9)


Lesenswert?

Hallo Matthias,

Matthias F. schrieb:

> es ist vollbracht, der Fehler lag wirklich im eep-file. Mein Brenner
> hats nicht richtig ins EEPROM gebrannt :-( Dank Axels Ausführungen über
> I-HEX Format hats nun geklappt.

Na da fällt mir doch ein Stein vom Herzen!

> Anbei noch der fehlerhafte EEPROM-Dump:
>
> :200000003A3034303030303030313437414441303039340D0A3A3030303030303031464 695

Also wenn ich das richtig decodiere, dann enthält der der Datenbereich:
1
> ... 3A3034303030303030313437414441303039340D0A ...
2
       : 0 4 0 0 0 0 0 0 1 4 7 A D A 0 0 9 4\r\n

Das heißt dein Brenner hat das .eep File nicht als .hex erkannt, sondern 
als rohes Binärfile interpretiert und einfach stur Zeichen für Zeichen 
ins EEPROM geschrieben. Vielleicht gibts ja irgendwo eine Option, um das 
einzustellen...


XL

von Michael D. (mike0815)


Angehängte Dateien:

Lesenswert?

Moin Axel,

deine Dekodierung stimmt mit der auf dem Screenshot von Bascom 
überein!!!

1.Screenshot
Ich habe jetzt mal im Bascom das main.eep geladen.
Man sieht deutlich an der Tabelle, das schon beim Laden der Fehler 
auftaucht. Die main.eep ist ja viel zu groß.
Übrigens, habe ich jetzt dieselben Frequenzwerte im Display, wie beim 
Matthias.

2.Screenshot
Man sieht deutlich den Unterschied.
Mit dem Extrem-Burner die main.eep gebrannt und mit Bascom ausgelesen.
Allerdings hat Bascom richtig ausgelesen und man kann es wieder in das 
EEprom schreiben.

Fazit: Lade nie ein EEprom-File mit Bascom
Hier gibt es doch ein Bascom Tourial, ist das denn da beschrieben oder 
hat das nie Jemand bemerkt?

Wenn das bekannt wäre, hätten wir hier nicht so einen Aufriss 
veranstalten müssen.

Gruß Michael

von Michael D. (mike0815)


Lesenswert?

so, mein Kompilierproblem mit Alex's Software ist jetzt auch gelöst!
Es hat tatsächlich an den verschiedenen Kompilierversionen gelegen.
Ich habe zusätzlich zur WinAVR-20100110 Version die WinAVR-20090313 
(Vorgängerversion) die auch statt der 'avr-libc-1.6.7', die 
'avr-libc-1.6.6' beeinhaltet, installiert. Und siehe da, es kompiliert 
mit allem drum u. dran.
Mit dem AVR-Studio4.18 geht's halt nicht, oder man müsste warscheinlich 
die Toolchain downgraden, das lass' ich lieber mal...

Ein schönes Wochenende wünsche ich,
Gruß Michael

von Michael D. (mike0815)



Lesenswert?

Hi,
hier mal meine fertiggestellte LED-Version des Frequenzsählers im 
Sandwichformat.
Das einseitige Layout war ein ganz schönes gequetsche, hier wäre 
wirklich eine Platine mit Top-Layer angebracht.
Die LED-Platine habe ich so dimensioniert, das sie auf die LCD-Version 
passt.

Als nächstes mache ich mich mal an einen Vorverstärker...

Anbei mal ein paar Fotos

Gruß Michael

von Axel S. (a-za-z0-9)


Lesenswert?

Moin,

Michael D. schrieb:
> hier mal meine fertiggestellte LED-Version des Frequenzsählers im
> Sandwichformat.

Schick!

> Das einseitige Layout war ein ganz schönes gequetsche, hier wäre
> wirklich eine Platine mit Top-Layer angebracht.

Oder SMT. Und/oder Displays die die Pins an den Seiten haben (statt oben 
und unten). Und/oder Displays im 2er oder 3er Pack, intern 
multiplex-verdrahtet. Da routet es sich leichter.

Ich werde so eine huckepack-Platine auch noch machen. Allerdings mit 
anderen Displays. Und SMT. Und 50% Print, Rest gefädelt. Ich will ja 
keine Massenfertigung machen.


XL

von Michael D. (mike0815)


Lesenswert?

Axel Schwenke schrieb:
> Moin,
auch moin...
>
> Michael D. schrieb:
>> hier mal meine fertiggestellte LED-Version des Frequenzsählers im
>> Sandwichformat.
>
> Schick!
Danke!
>
>> Das einseitige Layout war ein ganz schönes gequetsche, hier wäre
>> wirklich eine Platine mit Top-Layer angebracht.
>
> Oder SMT. Und/oder Displays die die Pins an den Seiten haben (statt oben
SMT??? Du meinst SMD, oder?
> und unten). Und/oder Displays im 2er oder 3er Pack, intern
> multiplex-verdrahtet. Da routet es sich leichter.
>
Ja, auf jeden Fall! Ich habe bei Pollin, Ebay nach '3Digit' geschaut, 
entweder haben die nur '2,5Digit' oder gleich '4Digit' oder sie waren 
mir zu teuer, sowie Conrad u. Reichelt...
Jetzt mußte ich auf meinen Bestand zurück greifen, 20x '1Digit' mit 
gemeinsamer Anode, das grenzte schon an Massochismus!
Wie ich fertig war, hatte ich doch glatt die 7 Basiswiderstände 
vergessen...die habe ich dann als 402er SMD verbaut, das ging 
nachträglich noch ganz gut.

> Ich werde so eine huckepack-Platine auch noch machen. Allerdings mit
> anderen Displays.
Welche verwendest du da?

>Und SMT. Und 50% Print, Rest gefädelt. Ich will ja
> keine Massenfertigung machen.
>
Hehe, Alex der Fädelkönig.
>
> XL

Gruß Michael

von Nils S. (kruemeltee) Benutzerseite


Lesenswert?

Bei sowas find ich Gequetsche sogar schön, umso enger, umso schöner :) 
Ich kann am Sonntag mal ein Foto von meiner 3 Kanal 230V Lichtorgel auf 
einer ~40x70mm Lochraster machen :P

Lieber so als eine Eurokarte für die Hand voll Bastel-DIP-Chips und 
Transistoren.

von Axel S. (a-za-z0-9)


Lesenswert?

Michael D. schrieb:
> Axel Schwenke schrieb:

>>> Das einseitige Layout war ein ganz schönes gequetsche, hier wäre
>>> wirklich eine Platine mit Top-Layer angebracht.
>>
>> Oder SMT.

> SMT??? Du meinst SMD, oder?

Wird beides verwendet. Das T steht für Technology. D für Device.

>> Ich werde so eine huckepack-Platine auch noch machen. Allerdings mit
>> anderen Displays.

> Welche verwendest du da?

TOT-4301FG. Dreistellig, grün. Gabs mal bei Pollin. Die sind auch auf 
dem Foto von meinem Breadboard-Aufbau.


XL

von Michael D. (mike0815)


Lesenswert?

>
> Wird beides verwendet. Das T steht für Technology. D für Device.
>
hmpf...Surface Mount
>
> TOT-4301FG. Dreistellig, grün. Gabs mal bei Pollin. Die sind auch auf
> dem Foto von meinem Breadboard-Aufbau.
>
Eben, die fände ich äusserst praktisch, nur haben die nur noch 3,5Digit 
und das geht ja mal garnicht!

Gleich habe ich meine 2. Platine bestückt, nur diesmal nehme ich ein 
Floppykabel und lege das um die Platine herum, das gepopel auf der 
Kupferseite tue ich mir nicht mehr an, habe dadurch einige Augen 
gelyncht und dann reparier das mal. :-/
Also, es gibt dann noch eine Version mit flexibler Displayleitung,
soll ich ein paar Bildchen davon machen?
>
Ach ja, es gibt bestimmte Frequenzen die der Freq.Messer nicht so gerne 
hat, z.B. 1,33333 MHz und 888.888 kHz und noch ein paar! Im Debugmodus 
werden Diese allerdings korrekt angezeigt, woran kann das liegen?

Gruß Michael

PS. Alex: Hast du meine Post bekommen?

von Steve (Gast)


Lesenswert?

Hallo,

wirklich interessantes Projekt. Es hat eine ganze Zeit gebraucht um den 
Thread durchzulesen, allerdings habe ich noch keine SMD-Version 
gefunden. Hab ich die schlichtweg übersehen oder gibt es die tatsächlich 
nicht? In der Version SMD2 von Charly B. finden sich auch nur 
THT-Bauelemente, von SMD keine Spur:

Beitrag "Re: Frequenzzähler 1Hz - 40MHz"

Wenn es einen aktuellen Schaltplan gibt, bei den vielen Änderungen 
blickt man irgendwann nicht mehr genau was noch aktuell ist und was 
nicht, dann würde ich eine echte SMD-Version layouten.
Die Verwendung eines TCXO finde ich auch vorteilhaft. Ich habe zumindest 
die Möglichkeit die Frequenz des TCXO mit einem HP-Frequenzzähler mit 7 
Stellen zu verifizieren. Damit lässt sich auch eine Frequenz im 
zweistelligen MHz-Bereich auf 0.1Hz auflösen, indem die erste Stelle für 
einen Overflow sorgt.

Grüße, Steve

von Charly B. (charly)


Lesenswert?

Steve schrieb:

> In der Version SMD2 von Charly B. finden sich auch nur
> THT-Bauelemente, von SMD keine Spur:

guggst du nicht richtig ;)

z.B. sind die C's vom Quarz und noch ein paar andere
in SMD, rest halt Konventionell, i hab das Layout auch nur
'uebernommen' und 'verbessert' als kleiner service.

vlG
Charly

von Steve (Gast)


Lesenswert?

Hi Charly,

okay, okay, eine SMD-Version ist es dann aber auch nicht wirklich, nur 
eine Hybridversion.
Ich erwehre mich ein wenig gegen diese Platzverschwendung durch 
bedrahtete Bauteile in alle drei Dimensionen, daher die Nachfrage nach 
einer echten SMD-Version.
Ist dein Schaltplan aus der SMD2.zip auf aktuellem Stand oder sind da 
noch Änderungen eingeflossen? Dann würde ich die mal als Grundlage für 
eine echte SMD-Version hernehmen wollen.

Grüße, Steve

von Michael D. (mike0815)


Lesenswert?

Steve schrieb:
>
> okay, okay, eine SMD-Version ist es dann aber auch nicht wirklich, nur
> eine Hybridversion.

Wohl war, nur rein SMD bringt vom Platz hier nicht soviel Vorteile, sind 
ja gerade mal 3 Widerstände und eine Hand voll C's...

> Ich erwehre mich ein wenig gegen diese Platzverschwendung durch
> bedrahtete Bauteile in alle drei Dimensionen, daher die Nachfrage nach
> einer echten SMD-Version.

Dann müssten alle 3 Chips in SMD bestückt werden, hat jetzt nicht jeder 
zur Hand, das wäre hier der Nachteil!
Ausserdem kann der Alex dann nicht fädeln... ;-)

> Ist dein Schaltplan aus der SMD2.zip auf aktuellem Stand oder sind da
> noch Änderungen eingeflossen? Dann würde ich die mal als Grundlage für
> eine echte SMD-Version hernehmen wollen.

Aber wenn's geht, keine Doppel-Layer...

SMD2.zip ist von mir und ist auf dem zur Zeit aktuellen Stand, hatte den 
aber auch von Charly genommen und für ein einseitiges Layout 
modifiziert, was auch reichlich Zeit in Anspruch genommen hat. :-/

Was noch zu ergänzen wäre, evtl. noch einen Vorverstärker für den 
Eingang!
Da bin ich noch dran...zur Zeit habe ich gerade ein Problem zu 
bewältigen, das bei meinem 2. Aufbau kein Signal ankommt, ist zum Haare 
raufen...

Gruß Michael

von Axel S. (a-za-z0-9)


Lesenswert?

Moin,

Steve schrieb:
>
> wirklich interessantes Projekt. Es hat eine ganze Zeit gebraucht um den
> Thread durchzulesen, allerdings habe ich noch keine SMD-Version
> gefunden. Hab ich die schlichtweg übersehen oder gibt es die tatsächlich
> nicht?

Eine reine SMD-Version gibts tatsächlich nicht. Bringt aber auch nicht 
so wahnsinnig viel. Die Platine ist auch mit THT auf die Größe eines 
LCD-Moduls zu bringen, so daß sich ein schönes Sandwich ergibt. Und bei 
der LED-Version war es dann eher das Problem, die Display-Platine wieder 
auf diese Größe zu bringen...

> Wenn es einen aktuellen Schaltplan gibt, bei den vielen Änderungen
> blickt man irgendwann nicht mehr genau was noch aktuell ist und was
> nicht, dann würde ich eine echte SMD-Version layouten.

Mein Post vom 13.4. enthält die letzte LED-Version. Der vom 21.4. die 
letzte Version mit LCD. Das tar.gz enthält die Firmware und den 
Schaltplan.

> Die Verwendung eines TCXO finde ich auch vorteilhaft.

Sicher. Wenn man einen hat :)

Die zwei TCXO die ich hier habe, liefern allerdings kein Logiksignal, 
sondern einen Sinus mit ca. 1V_pp. Da muß noch ein Treiber dahinter.

> Ich habe zumindest
> die Möglichkeit die Frequenz des TCXO mit einem HP-Frequenzzähler mit 7
> Stellen zu verifizieren. Damit lässt sich auch eine Frequenz im
> zweistelligen MHz-Bereich auf 0.1Hz auflösen, indem die erste Stelle für
> einen Overflow sorgt.

Sieben Stellen ließen sich aus der Software noch rausquetschen - mit 
weniger Messungen pro Sekunde. Aber bei 7 Stellen entspricht ein Digit 
0.1ppm. Auch mit einem TCXO darf da die Temperatur nicht zu sehr 
schwanken.


XL

von W.S. (Gast)


Lesenswert?

Ach.. ihr seid ja immer noch nicht weiter gekommen. Noch immer keine 
Eingangsstufe, keine Stromversorgung, kein Gehäuse...

W.S.

von Old P. (Gast)


Lesenswert?

W.S. schrieb:
> Ach.. ihr seid ja immer noch nicht weiter gekommen. Noch immer keine
> Eingangsstufe, keine Stromversorgung, kein Gehäuse...
>
> W.S.

Und Du bist auch noch nicht weiter ;-) Noch immer kein Verständnis für 
den eigentlichen Einsatzzweck derartiger Module.
Gehäuse: Nicht nötig, kommt in ein Gerät rein
Stromversorgung: Nicht nötig, kommt aus dem Gerät
Eingangsstufe: Meistens entbehrlich, findet sich immer eine 
Abgreifstelle im Gerät.

Old-Papa

von Michael D. (mike0815)



Lesenswert?

W.S. schrieb:
> Ach.. ihr seid ja immer noch nicht weiter gekommen. Noch immer keine
> Eingangsstufe, keine Stromversorgung, kein Gehäuse...
>
> W.S.
Sicher, ich zu mindest...und  wer ist W.S.??? Ein Name wäre mal was!

Ich habe soeben mein 2. Modul fertiggestellt!
An dieser Stelle noch mal ein dickes Lob an Axel!
(Hast du mich vergessen?)

Die "mikroskopischen" Kurzschlüsse am 74HC74 habe ich auch eliminieren 
können, jetzt rennt auch das Teil.
Ich habe das Modul mit einem modifizierten Floppykabel aufgebaut, 
dadurch könnte man es für einen 90 Grad oder Sandwich Einbau verwenden, 
ohne herumlöten zu müssen.
Auch der 2. Aufbau läuft sehr stabil, mein Layout scheint gar nicht so 
schlecht zu sein. :-)

Diesmal habe ich die Kalibrierung rein mit der Software 
durchgeführt...durch "Try and error" im Makefile hat das ein bißchen 
gedauert.

Anbei wieder mal was für's Auge

Gruß Michael

EDIT: W.S. oder wie immer du auch heißt, du könntest ja mal eine 
Eingangsstufe vorstellen, wie wär's?

von Axel S. (a-za-z0-9)


Lesenswert?

Moin,

Michael D. schrieb:
> W.S. schrieb:

[unbedeutend]

> ... wer ist W.S.??? Ein Name wäre mal was!

Das ist nur ein Troll

> An dieser Stelle noch mal ein dickes Lob an Axel!
> (Hast du mich vergessen?)

Danke! Und nein, deine Mail liegt hier in meinem "zu bearbeiten" Stapel. 
Ich habe auch fest vor, herauszufinden warum das mit avr-libc-1.6.7 
nicht funktioniert und wenn möglich zu reparieren.

> Diesmal habe ich die Kalibrierung rein mit der Software
> durchgeführt...durch "Try and error" im Makefile hat das ein bißchen
> gedauert.

In meinem tar.gz ist auch ein File CALIBRATE.txt mit einer Anleitung zum 
kalibrieren. Ich übersetze es hier gleich mal ins Deutsche:

---

2. Digitale Kalibrierung

Die digitale Kalibrierung verzichtet auf den (potentiell 
unzuverlässigen) Trimmer. Und sie kann mehr als +/- 511Hz (bezogen auf 
fref) Abweichung korrigieren.

Zur digitalen Kalibrierung den Trimmer auf 0 drehen, oder ADC5 per 
Jumper auf GND legen. Damit ist die analoge Trimmung deaktiviert.

Ein Frequenznormal anschließen und den angezeigten Wert notieren. Wenn 
fn die echte Meßfrequenz ist, fx der angezeigte Wert und fref die 
derzeit programmierte Referenzfrequenz, dann gibt

fref * fn / fx

den wahren Wert für fref.

Beispiel: fref = 14318182Hz = 0xDA7A66, fn = 40.0MHz, fx = 39.9987MHz

$perl -e 'printf "%08X\n", int(0xDA7A66 * 40.0 / 39.9987)'
00DA7C37

Hinweis: die ersten beiden Ziffern müssen immer 00 sein. Wenn nicht, 
dann kommt es zu einem unbemerkten Überlauf in der Arithmetik!

Jetzt kann man den neuen Wert für fref ins EEPROM schreiben (ab Adresse 
0x0000). Der AVR ist little-endian, die Bytes müssen also umgekehrt 
werden. Für obigen Wert wäre das 0x37, 0x7C, 0xDA, 0x00.

Wenn man die zusätzliche Möglichkeit der analogen Kalibrierung behalten 
möchte, kann man jetzt ADC5 wieder an den Trimmer jumpern und bei 
angeschlossenem Frequenznormal den Trimmer auf die Nominalfrequenz 
stellen.

Fertig.

---


XL

von Michael D. (mike0815)


Lesenswert?

Axel Schwenke schrieb:
> Moin,
>
auch Moin,

> Das ist nur ein Troll
Achso... :-)
>
> Danke! Und nein, deine Mail liegt hier in meinem "zu bearbeiten" Stapel.
> Ich habe auch fest vor, herauszufinden warum das mit avr-libc-1.6.7
> nicht funktioniert und wenn möglich zu reparieren.
>
Das würde mich auch mal interessieren warum das mit dem Update nicht 
klappt!
>
> In meinem tar.gz ist auch ein File CALIBRATE.txt mit einer Anleitung zum
> kalibrieren. Ich übersetze es hier gleich mal ins Deutsche:
>
> ---
>
> 2. Digitale Kalibrierung
>
> Die digitale Kalibrierung verzichtet auf den (potentiell
> unzuverlässigen) Trimmer. Und sie kann mehr als +/- 511Hz (bezogen auf
> fref) Abweichung korrigieren.
>
Ich muß aber sagen, das das 10-Gang Poti sich auf Bezug der Kalibrierung 
sehr gut schlägt! Natürlich läuft eine digitale Kalibrierung stabiler.
>
> Beispiel: fref = 14318182Hz = 0xDA7A66, fn = 40.0MHz, fx = 39.9987MHz
>
Welche Kalibrier-Frequ. wäre den da am besten geeignet? 40MHz oder eher 
ein Mittelwert, so um die 20MHz-30MHz ?
>
> Fertig.
gut!

> XL

Gruß Michael

von Axel S. (a-za-z0-9)


Lesenswert?

Michael D. schrieb:

> Welche Kalibrier-Frequ. wäre den da am besten geeignet? 40MHz oder eher
> ein Mittelwert, so um die 20MHz-30MHz ?

In erster Linie eine stabile :)

Das Meßprinzip ist bei hohen Frequenzen toleranter gegen Jitter, so daß 
bei niedrigen Kalibrierfrequenzen (sagen wir mal: dem pps Signal aus 
einem GPS) die Anforderungen an Jitter höher werden. Wenn das Signal 
Jitter hat, sieht man das gleich, weil man keine stabile Anzeige 
bekommt.


XL

von Axel S. (a-za-z0-9)


Angehängte Dateien:

Lesenswert?

Moin!

heute gibt es ein Tutorial, wie man sich seine eigene Anzeige für die 
LCD-Version bastelt.

Nehmen wir an, ihr heißt Michael und wollt eine angepaßte Version des 
Moduls mit folgenden Eckpunkten:

1. basierend auf der 2x16 Version
2. statt "F=###.###UUU" soll die Anzeige so aussehen: "F ###.### UUU"
3. keine Anzeige der Torphasen, bei Unterlauf ein "U" am Ende der 
zweiten Zeile, das bei einem korrekten Meßwert wieder verschwindet.

Dazu müssen die folgenen Änderungen am Code vorgenommen werden:

Definition einer neuen CUSTOMIZATION in config.h. Ziemlich am Anfang von 
config.h werden die verfügbaren Anpassungen aufgezählt. Wir fügen eine 
neue hinzu:
1
#define michael_2x16 4

und wählen sie aus:
1
#define CUSTOMIZATION michael_2x16

in dem folgenen #if Block müssen wir nun unsere Anpassung beschreiben. 
Dazu müssen wir im Prinzip ein paar C-Makros definieren. Wir fügen unter 
dem Block für default_2x16 einen weiteren #elif Block ein:
1
#elif CUSTOMIZATION == michael_2x16                                            
2
                                                                               
3
#define SHOW_GREETING show_greeting_michael_2x16                               
4
#define SHOW_RESULT   show_result_michael_2x16                                 
5
#define PHASE1()                                                               
6
#define PHASE2()                                                               
7
#define PHASE3()                                                               
8
#define UNDERFLOW()   lcd_gotoxy(15,1); lcd_putc('U')                          
9
#define IS_VALID()    lcd_gotoxy(15,1); lcd_putc(' ');                         
10
#define LCD_LINES     2                                                        
11
#define LCD_DISP_LEN  16                                                       
12
#define DEBUG         0

Eigentlich ganz simpel: SHOW_GREETING und SHOW_RESULT verweisen auf neue 
(noch zu schreibende) Funktionen. Die PHASE Makros tun nix. Und 
UNDERFLOW und IS_VALID setzen bzw. löschen die Underflow-Anzeige.

Und schon sind wir halb fertig. Der zweite Teil ist auch nicht schwerer. 
Da müssen wir die neuen Funktionen show_greeting_michael_2x16() und 
show_result_michael_2x16() in main.c einfügen. Die Funktionen kopiert 
man am besten von einer existierenden Anpassung, benennt sie um und paßt 
sie dann schrittweise an.

Die neue SHOW_GREETING FUnktion könnte z.B. so aussehen:
1
void show_greeting_michael_2x16(void)                                          
2
{                                                                              
3
    lcd_puts(VERSION"\nHallo Michael!");                                       
4
    _delay_ms(2000);                                                           
5
}

Hier machen wir uns zu Nutze, daß der C-Compiler aufeinanderfolgende 
Stringliterale zusammenfaßt.

Die SHOW_RESULT Funktion ist eine Abwandlung der normalen 2x16 Variante:
1
void show_result_michael_2x16(void)                                            
2
{                                                                              
3
    unsigned char len= calculate_frequency();                                  
4
    char* bufptr= buffer;                                                      
5
                                                                               
6
    lcd_clrscr();                                                              
7
    lcd_putc('F');                                                             
8
    lcd_putc(' ');                                                             
9
                                                                               
10
    /* nur die Zahl ausgeben */                                                
11
    while ((*bufptr == '.' || (*bufptr >= '0' && *bufptr <= '9')) && len--) {  
12
        lcd_putc(*bufptr++);                                                   
13
    }                                                                          
14
                                                                               
15
    /* Trennzeichen nach Geschmack */                                          
16
    lcd_putc(' ');                                                             
17
                                                                               
18
    /* und jetzt noch die Einheit */                                           
19
    while (len--) {                                                            
20
        lcd_putc(*bufptr++);                                                   
21
    }                                                                          
22
                                                                               
23
    IS_VALID();                                                                
24
}

Im Prinzip hätte man das einfacher haben können, wenn man sich darauf 
verläßt, daß immer die ersten 7 Zeichen im Buffer die Zahl und die 
letzten 3 die Einheit sind. Aber wir wollen uns ja nicht den Weg 
verbauen, wenn mal jemand eine Änderung auf 7 Stellen schreiben sollte. 
Also erkennen wir die Zahl lieber am Inhalt.

Angehängt sind die neue config.h, main.c und ein diff (basierend auf 
Version 1.4), um die oben besprochenen Änderungen auf eine eigene 
Version des Quellcodes anwenden zu können.


XL

von Michael D. (mike0815)



Lesenswert?

Ich habe dann mal angepasst. :-|
Anbei mal wieder ein paar Bildchen!
Auf dem grünen Display habe ich mal das Signal weggenommen, zeigt dann 
statt dem 'U' eine Raute an, das knallt mir besser in's Auge.

Danke noch mal an Axel, für das nette Gimmick! ;-)

Da bei einem 2x16 Display noch so viel Platz ist, kam mir die Idee einer 
Pegelanzeige für die 2. Zeile. Geht das noch zu realisieren? Was meint 
ihr?

Gruß Michael

von Ralph B. (rberres)


Lesenswert?

Für Pegelanzeige müßte man ein Teil der Eingangsspannung für einen 
Pegeldedektor abzweigen. Über einen großen Dynamikbereich den Pegel 
anzuzeigen beinhaltet zwei Probleme.

1. Bei niedrigen Frequenzen müsste der Integrationskondensator des 
Gleichrichters eine hohe Zeitkonstante haben, welche eine lange Messzeit 
nach sich zieht.

2. niedrige Pegel ( < 100mV ) gleichzurichten ist nicht ganz einfach, 
insbesonders dann , wenn Pegelunabhängig Effektivwert angezeigt werden 
soll.

3. Für über sagen wir mal 1MHz den Pege zu messen braucht es eine andere 
Schaltung als im NF Bereich.

Im NF Bereich könnte man einen AD636 oder einen Spitzenwertgleichrichter 
mit Opamp nehmen. Ab ca 1MHz geht das aber nicht mehr so einfach. Da 
läuft es dann schon auf eine Schaltung mit 2 Diodenpärchen und einen 
Regelkreis ala Rhode&Schwarz URV hinaus. Oder man müsste mit einer 
Schottky oder Germaniumdiode Spitzenwertgleichrichtung machen und die 
Kennlinie entzerren, was mit Drift und Temperaturprobleme verbunden ist.

Ehrlich gesagt. Ich würde es lassen.

Es ist und soll ein realtiv überschaubares Einbaufrequenzzählermodul 
sein, welches eigenständig läuft, nicht viel Platz wegnimmt, und für 
viele Anwendungen ideal ist. Mein Glückwunsch zu diesem Projekt.

Pegelmessung über einen Bereich von NF bis übers KW Band wäre ein 
eigenständiges Projekt, welches mit Sicherheit aufwändiger wird.
Unterhalte dich mal mit Bernd Kaa DG4RBF hat der glaube ich. Der hat 
sowas veröffentlicht.

Ralph Berres

von Eric (Gast)


Lesenswert?

Ralph Berres schrieb:
> Es ist und soll ein realtiv überschaubares Einbaufrequenzzählermodul
> sein, welches eigenständig läuft, nicht viel Platz wegnimmt, und für
> viele Anwendungen ideal ist. Mein Glückwunsch zu diesem Projekt.

Hallo Ralph
ich stimme Deiner Einschätzung aund auch dem Glückwunsch voll zu

aber weil es mich juckte :-) :
habe ich mal fix nachgesehen, ab welcher Frequenz der AD8307 anfängt zu 
arbeiten ?
das ist laut Dateblatt DC
Mit einem resistiven Splitter und dem AD8307 könnte man evtl. so eine 
Lösung angehen.
Aber wie Du schon schriebst liegt der Teufel im Entwicklungsdetail  !

Gruß, Eric

von Ralph B. (rberres)


Lesenswert?

Hallo Eric

Mit dem AD8307 könnte es in der Tat gehen. Ich muss das mal zu Hause 
ausprobieren. Da ich so einen AD8307 einmal als HF Demodulator und als 
NF Demodulator aufgebaut habe , in jeweils einen Blechkistchen.

Ralph Berres

von Uwe S. (de0508)


Lesenswert?

Hallo Eric und Ralph,

und vergesst nicht den AD8310 damit habe ich für den fa-nwt weitere 
Tastköpfe entwickelt.

- http://www.qrpforum.de/index.php?page=Thread&threadID=4591

Bei mir laufen die nun in SMA und BNC Bestückung sehr gut.

Technische Daten
AD8310: Fast, Voltage-Out, DC to 440 MHz, 95 dB Logarithmic Amplifier

Datenblatt:
http://www.analog.com/static/imported-files/data_sheets/AD8310.pdf

von Eric (Gast)


Lesenswert?

Uwe S. schrieb:
> und vergesst nicht den AD8310 damit habe ich für den fa-nwt weitere
> Tastköpfe entwickelt.

Jepp, Uwe geht auch, guter Punkt !

Gruß, Eric

von Axel S. (a-za-z0-9)


Angehängte Dateien:

Lesenswert?

Hallo Leute,

heute habe ich ein feines Leckerli für euch: Firmware Version 1.5 für 
die LCD Version. Das bahnbrechende ;) neue Feature ist die Berechnung 
der Periodendauer, die jetzt zusätzlich/alternativ zur Frequenz 
angezeigt werden kann.

Die Firmware verwendet jetzt erstmals einen der Jumper; und zwar den an 
Bit 0 des Datenbusses (ist in ports.h konfigurierbar). Die Anzeige in 
den vordefinieren Modi ist jetzt wie folgt (#=Ziffer oder Dezimalpunkt, 
U=Einheit, P=Torphase, V=Unterlauf):

default_1x10

#######UUU (die Frequenz wenn der Jumper nicht steckt)
#######UU  (bzw. die Periodendauer wenn der Jumper steckt)

default_1x16

F=#######UUU  PV (die Frequenz wenn der Jumper nicht steckt)
T=#######UU   PV (bzw. die Periodendauer wenn der Jumper steckt)

default_2x16

F=#######UUU     (in Zeile 1: Frequenz)
T=#######UU   PV (in Zeile 2: Periodendauer)

Die Periodendauer wird in ns, µs, ms oder s angezeigt. Das 'µ' Zeichen 
steht in meinen Displays auf Code 0xE4, das ist so in config.h 
vordefiniert. Falls euer Display das µ woanders hat, definiert das dort 
um. Im Zweifelsfall nehmt das 'u', das sollte jedes Display haben.

Wie immer bitte ich um fleißiges Testen und Feedback!

PS: das angehänge tar.gz enthält das .hex für die "default2x16" 
Konfiguration

XL

von Old P. (Gast)


Lesenswert?

Das wird ja noch richtig interessant hier ;)

Ich selbst bin erst wieder in den dunkleren Monaten oben im 
"Elektroniklabor"...

Gruß
Old-Papa

von Axel S. (a-za-z0-9)


Lesenswert?

Für dieses Projekt gibt es jetzt auch einen eigenen Artikel im Wiki:

http://www.mikrocontroller.net/articles/Frequenzz%C3%A4hlermodul


XL

von Michael D. (mike0815)


Angehängte Dateien:

Lesenswert?

Der Axel, ich muß schon sagen: Das ist der absolute Brüller!!!

Ich konnte es natürlich nicht lassen und habe die SW gleich für mich 
optisch angepasst. Hat zwar bis eben gedauert, für eine bildliche 
Dokumentation war aber noch Zeit.
Ich habe da mal mit der Belichtung der Kamera gespielt, jetzt kommt das 
Display optisch ganz gut rüber...

Habe mal kurz bei Wiki vorbei geschaut.
Das ist wohl war, das nur mit deinem Makefile und der z.B. 
"WinAVR-20090313" Version(für Windows) deine SW anzupassen ist! 
Bearbeitet und kompiliert wird mit "Programmers Notepad"(im WinAVR 
enthalten), welches auch alle erforderlichen Files generiert!

Ich bin absolut begeistert von deiner Arbeit und möchte auch hier noch 
mal ein dickes Lob aussprechen!!!

Anbei die angedrohten Fotos von den Leckerlies

Gruß Michael

EDIT: Eine Pegelanzeige könnte man doch trotzdem als zusätzliche 
'Option' in's Auge fassen, so als drittes Sandwich vielleicht...

von Timo (Gast)


Lesenswert?


von Stephan H. (stephan-)


Lesenswert?

W.S. schrieb:
> Ach.. ihr seid ja immer noch nicht weiter gekommen. Noch immer keine
> Eingangsstufe, keine Stromversorgung, kein Gehäuse...
>
> W.S.

in der Zeit wo du den Müll schreibst hättest Du ja mal ein Eingangsteil 
bauen und beisteuern können. Aber auf die Lösung warten ist je 
einfacher.

von Old P. (Gast)


Lesenswert?

Timo schrieb:
> Wäre das nicht was für den Frequenzzähler?
>
> 
http://cgi.ebay.de/10MHZ-ISOTEMP-131-OCXO-OSCILLATOR-square-wave-VCC-small-/170558942064?pt=LH_DefaultDomain_0&hash=item27b61aeb70
>
> MFG

Radio Eriwan würde sagen: Im Prinzip ja, aber....
Die Dinger sind nicht schlecht, habe irgendwo auch noch 2-3 Stück, doch 
für dieses Modul der blanke Overkill. Schon die Größe spricht dagegen, 
die sind ja fast so groß wie das ganze Modul.


Old-Papa

von Uwe S. (de0508)


Lesenswert?

Hallo !

ich lese gerade etwas von einer Eingangsbeschaltung; meine habe ich 
hier:

Beitrag "Re: Frequenzzähler 1Hz - 40MHz"

beschrieben.

Das sollte auch für Euch passen.

von Michael D. (mike0815)


Lesenswert?

jo, stimmt!
Und ein Eingangsverstärker ist ja auch noch vorhanden mit dem 74HC132 
von Old-Papa!!!
Also was will er denn noch?

@Uwe

Der E310 ist schon ein Exote oder? Den SF245 hat jetzt auch nicht jeder 
in der Kiste und nicht so leicht zu beschaffen!
Hast du da evtl. was Equivalentes als Vorschlag?
Ich hätte da noch einen E300, der ist uralt und wahrscheinlich wird der 
garnicht mehr hergestellt...

Gruß Michael

von Uwe S. (de0508)


Lesenswert?

Hallo Michael,

Da hast Du etwas falsch gelesen, das ist ein J310 oder BF245 o. ä. alles 
ganz harmlos !

Der Vorschlag mit dem 74HC132 vor dem AVR Eingang ist auch von mir, nur 
mal zur Info.

von Ulrich (Gast)


Lesenswert?

Da ist in dem Plan schon noch ein SF245 als NPN-Transistor drin.  Der 
sollte aber nicht so kritisch sein. Da könnte ggf. schon ein 2N3904, 
oder wenn es schneller sein sollte ein BF198 reichen. So kritisch ist 
der Typ des Transistors nicht.

Der Vorverstärker hat aber auch eine untere Grenzfrequenz, ist also noch 
nicht so universell.

von W.S. (Gast)


Lesenswert?

Stephan Henning schrieb:
> in der Zeit wo du den Müll schreibst hättest Du ja mal ein Eingangsteil
> bauen und beisteuern können. Aber auf die Lösung warten ist je
> einfacher.

Nanana mein Lieber,

ich habe in der Zwischenzeit eine ganze Menge beigesteuert - und ich 
warte auch nicht auf Axels Lösungen (die ich für unoptimal halte), 
sondern hab mir ein anderes Thema aufgemacht, um dieses hier nicht gar 
zu sehr anschwellen zu lassen. Siehe 
"Beitrag "PIC - Frequenzzähler weit über 50 MHz auf die minimalistische Art";

Dort findest du zwar auch die üblichen Atmel-Streitigkeiten 
(atmelbesessene Linuxer scheinen besonders aggressiv zu sein..), aber 
eben auch einiges anderes, was ich für lesenswert halte.

Inzwischen hab ich mich um Muster gekümmert, eine LP aufgebaut und die 
SW geschrieben. Die obere Grenzfrequenz liegt erwartungsgemäß bei ca. 
120 MHz und wenn ich wieder etwas Zeit habe, poste ich die finale 
Schaltung als PDF. In der Zwischenzeit kannst du dir ja mal meine 
Überlegungen zu verschiedenen Eingangsstufen durchlesen. Vielleicht ist 
was nach deinem Geschmack dabei.

W.S.

von Michael D. (mike0815)


Lesenswert?

Hallo Uwe,

> Da hast Du etwas falsch gelesen, das ist ein J310 oder BF245 o. ä. alles
> ganz harmlos !
Stimmt, J310 steht da, aber SF245 steht trotzdem auf dem Plan! Also ist 
damit der "BF245" gemeint? ...dann wäre das ja gar kein Problem!

> Der Vorschlag mit dem 74HC132 vor dem AVR Eingang ist auch von mir, nur
> mal zur Info.
Achso? Ich habe den Thread zig mal gelesen und trotzdem was übersehen, 
unglaublich...

Gruß Michael

EDIT:
und hier

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

schaue ich gleich mal vorbei...

von Uwe S. (de0508)


Lesenswert?

Den SF245 habe ich gegen den BF199 ersetzt.

Ist halt ein NPN HF Transistor, ft=1,1GHz und sollte auch etwas 
Verstärkung beta haben.

Über Vorverstärker habe ich mir hier ausgelassen:

http://www.qrpforum.de/index.php?page=Thread&postID=46013#post46013

von Old P. (Gast)


Lesenswert?

Uwe S. schrieb:
> Der Vorschlag mit dem 74HC132 vor dem AVR Eingang ist auch von mir, nur
> mal zur Info.

Wo er Recht hat, hat er.... ;-)
Andererseits ist das ja schon fast eine Standardlösung. Ersetzt kein 
aufwändiges HF-Eingangsteil, doch für mich reicht das vollkommen.
"Quadratisch-praktisch-gut" ;)

Old-Papa

von afu_frank (Gast)


Lesenswert?

Hallo Zählerfreunde,

ich habe den ganzen "Batzen" hier durchgearbeitet und hoffe das man mir 
hier etwas weiter helfen kann. Ich frage mich wie ich es schaffe meine 
Messfrequenz so zu dem Zähler zu bekommen ohne das Signal zu belasten. 
:-(

Es ist eine ausgekoppelte HF Spannung (-30dB) in einem SWR Meter. Da 
möchte ich nun einen Frequenzzähler anschließen. Sobald ich ihn jetzt 
anklemme stimmen die SWR Anzeigen nicht mehr. :-( Der Zähler läuft, 
allerdings dann nur bis 21MHz 1A doch dann reicht der Pegel nicht mehr 
aus.

Ich brauche im Prinzip eine Eingangsstufe die von 1-30MHz eine Spannung 
von 0,1 Vss bis 25 Vss Zähler tauglich aufbereitet.

Beitrag "Re: Frequenzzähler 1Hz - 40MHz"

Zeigt ja ein paar Beispiele, doch sind die hochohmig genug und auch 
Spannungsfest wenn in der Zukunft mal etwas mehr HF erzeugt wird?

Sie muss in der Lage sein kleine Spannungen entsprechend zu verstärken 
und der Eingang muss auch hohe HF Spannungen wegstecken können.

73 de Frank

von Ralph B. (rberres)


Lesenswert?

afu_frank schrieb:
> Ich brauche im Prinzip eine Eingangsstufe die von 1-30MHz eine Spannung
>
> von 0,1 Vss bis 25 Vss Zähler tauglich aufbereitet.

Mein Vorschlag wäre das zu messende Signal über einen 1Kohm Widerstand 
und zwei dahinter angeordnete antiparallel geschaltete Shottkydioden als 
Begrenzer auf das Gate eines J310 als FETverstärker zu geben. Man müste 
das in LTspice mal simulieren wie sich das benimmt. Bis 30MHz könnte das 
eventuell sogar noch funktionieren.

Ralph Berres

von Lukas K. (carrotindustries)


Lesenswert?

Ich evaluiere geraden den TLV3502 Komparator als Eingangsstufe für einen 
Frequenzzähler; man bekommt auch noch bei Amplituden von <50mvPP ein 
brauchbares Signal. Auch wenn die Maximale Togglefrequenz mit 80MHz 
angegeben ist, liefert der auch noch bei 100MHz ein brauchbares Signal. 
Außerdem hat der TLV3502 nen FET-Eingang, man spart sich also einen 
FET-Puffer.

von Michael (Gast)


Lesenswert?

Old -papa schrieb:
> ... für dieses Modul der blanke Overkill. Schon die Größe
> spricht dagegen ...

Seit wann wird die Qualität von Meßgeräten primäer nach der Größe 
beurteilt und wieso "overkill". Mit dem Argument müßte man als erstes 
das Display verkleinern, wozu 6 Stellen bei einer einfachen 
Quarzzeitbasis, wenn man mehr als Relativmessungen machen möchte.

Warum soll ein kleiner Frequenzzähler nicht genau sein. Je nach 
Einsatzzweck, ist eine solide Zeitbasis durchaus 19 cm^3 wert und wenn 
du das nicht brauchst, warum hast du die Teile dann rumliegen.

Gruß Michael

von branadic (Gast)


Lesenswert?

Hallo,

wie wäre es mit einem logarithmischen Verstärker und FET-Sourcefolger am 
Eingang? Das sollte sich doch recht unproblematisch und vergleichsweise 
kostengünstig gestalten.

branadic

von Ralph B. (rberres)


Lesenswert?

branadic schrieb:
> wie wäre es mit einem logarithmischen Verstärker und

bei 25 VSS am Eingang?

Ralph Berres

von branadic (Gast)


Lesenswert?

Ralph, du musst auch alles lesen ;)
Ich sagte ja mit FET am Eingang, das schließt nicht aus, dass man noch 
einen Eingangsspannungsteiler einfügt.
Es könnte sogar, wie beim Oszi, eine Spannungsbereich-Umschaltung 
erfolgen. Man darf da ruhig etwas kreativer denken.

branadic

von Michael D. (mike0815)


Angehängte Dateien:

Lesenswert?

branadic sucht vielleicht ein Frequenzzählermodul für sein AD5930 
Projekt ?

Ich habe bei meinem jetzt mal die obere Messgrenze ermittelt bis jetzt 
ohne Vorschaltwerk.
Ich denke, das der 74HC590 auch nicht mehr macht. Reicht ja auch!
Die Anzeige bleibt bei der Frequenz auch über Dauer stabil.

Wie immer ein Bildchen von mir.

Gruß Michael

von W.S. (Gast)


Lesenswert?

Ralph Berres schrieb:
> Shottkydioden

Walter Schottky (* 23. Juli 1886 in Zürich; † 4. März 1976 in Forchheim 
(Oberfranken)) war ein deutscher Physiker und Elektrotechniker. Walter 
Schottky war der Sohn des Mathematikers Friedrich Schottky (1851–1935).

Nicht alles kommt aus USA.

W.S.

von Abdul K. (ehydra) Benutzerseite


Lesenswert?

Den Fehler machen die Amis gerne ;-)

Wei Wikipedia steht dann immer: 'Zeitgleich' haben der deutsche ... und 
der amerikanische ... das und das 'erfunden'. Zum Lachen wie die 
Wirklichkeit gebogen wird.


Bleiben wir beim logarithmischen Eingangsverstärker und einem schnöden 
Tastkopf-Anschluß. Das ist das was mich interessiert!

von Hans M. (Firma: mayer) (oe1smc) Benutzerseite


Lesenswert?

hallo Michael

danke fuers bild. das ist feine sache mit frequenzanzeige und perioden 
dauer in einem. bin noch nicht dazu gekommen, die neue software bei 
meinem modul zu installieren. allerdings scheints bei der 
kehrwertbildung ein winzig kleines problemchen zu geben.

wenn ich von 614613 den reziprok bilde, kann komme ich auf die 
zahlenfolge 16270401 ( ohne exp )
also der 3'er von 162703 ist schon sehr stark "abgerundet" :-)
vielleicht kann sich Axel das mal ansehen.

73 de hans
oe1smc

--

von Old P. (Gast)


Lesenswert?

Michael schrieb:
> Seit wann wird die Qualität von Meßgeräten primäer nach der Größe
> beurteilt und wieso "overkill". Mit dem Argument müßte man als erstes
> das Display verkleinern, wozu 6 Stellen bei einer einfachen
> Quarzzeitbasis, wenn man mehr als Relativmessungen machen möchte.

Nach der Größe natürlich nicht. Und wer hier aus diesem Modul einen 
Universalzähler basteln will, der kann das ja auch machen.
Wer aber das Modul "nur" als Anzeige für vorhandene Generatoren im 
Hobbybereich nutzt (das war die Ursprungsidee von Axel) wird schon auf 
die Größe achten (müssen) und einfache Generatoren sind eh nie so genau 
einstellbar um die Genauigkeit dieser Thermostate (OCXO) auszunutzen.
>
> Warum soll ein kleiner Frequenzzähler nicht genau sein. Je nach
> Einsatzzweck, ...

Eben, s. oben ;-)

> und wenn du das nicht brauchst, warum hast du die Teile dann rumliegen.

Ach was meinst Du, was ich alles so in den vergangenen 40 Jahren 
angesammelt habe... ;-) Die Frage nach dem "Gebrauchtwerden" stellt 
meine Frau 3x die Woche....

Old-Papa

von Michael D. (mike0815)


Angehängte Dateien:

Lesenswert?

Hallo Hans,

> wenn ich von 614613 den reziprok bilde, kann komme ich auf die
> zahlenfolge 16270401 ( ohne exp )
> also der 3'er von 162703 ist schon sehr stark "abgerundet" :-)
> vielleicht kann sich Axel das mal ansehen.

Ich habe jetzt noch mal ein paar Messungen mit verschiedenen glatten 
Frequenzen gemacht. Bei 1, 2 oder 16MHz, müsste normalerweise eine 
glatte Periodendauer angezeigt werden. Angezeigt wird aber z.B. 2MHz 
499.999ns statt 500.000ns.
Bei 1.99999MHz wird dann allerdings 500.000ns angezeigt.
Kann man das denn noch in der Software abgleichen und wenn ja, wo?

Gruß Michael

von Ralph B. (rberres)


Lesenswert?

Michael

das dürfte die Unsicherheit des letzten Bits sein, welche prinziepiell 
immer vorhanden ist.

Ralph Berres

von Uwe S. (de0508)


Angehängte Dateien:

Lesenswert?

Hallo !

ich habe die Firmware v1.4 auf den atMega48, m88, m168 und m328 
erweitert.

Das Makefile und main.c habe kleine Änderungen erfahren und avr_def.h 
ist neu !

Auch habe ich in config.h Testweise ein andere Ausgabefunktionen 
gewählt.

Ziel ist es für die "Frequenzerweiterung für den NWT (FE-NWT)" einen 
kleinen Frequenzzähler mit automatischer Verrechung eines Prescalers von 
128 zu haben.

In der unteren Zeile sollen noch eine Gleichspannung 0V -18V linear als 
Bargraph auf 14 erfolgen.

von Uwe S. (de0508)


Angehängte Dateien:

Lesenswert?

Hallo,

so hier ist nun der Prescaler 128 eingebaut und er sollte richtig 
verrechnet werden.

Siehe config.h und main.c.

Auf einem atMega48 werden nun noch benötigt:
1
   text     data      bss      dec      hex  filename
2
   1902       16       27     1945      799  main.elf

von Michael D. (mike0815)


Lesenswert?

Hallo Uwe,
Ich will das mit dem ATmega48 mal testen und habe den schon drinne!
Sehe ich das richtig, das du einen 16MHz Quarz angegeben hast?

Welche Fusebits-Einstellungen werden da vorgenommen?

Divide Clock by 8 Disabled?
Den Clock output Disabled ist klar.
Fullswing Crystal auch klar.
Watchdog-Timer an oder aus?
Brownout an oder aus, bzw. 2,7V ?

In der Main...quatsch Makefile stehen noch die Fuses vom Mega8!

Gruß Michael

von Uwe S. (de0508)


Lesenswert?

Servus Michael,

mir fehlt noch die Hardware für den Frequenzzähler.
Hast Du noch Platinen übrig ?

Einen 16MHz Quarz habe ich als Standart gewählt, da ich keinen 
14,31..MHz da habe und zur Festlegung der FuseBits nehme ich:

http://www.engbedded.com/fusecalc

Fur den atMega48 ergibt sich aus dem Makefile:

-U lfuse:w:0xd7:m -U hfuse:w:0xdd:m -U efuse:w:0xff:m

von Michael D. (mike0815)


Angehängte Dateien:

Lesenswert?

Uwe S. schrieb:
> Servus Michael,
>
auch Servus...

> mir fehlt noch die Hardware für den Frequenzzähler.
> Hast Du noch Platinen übrig ?
...du bist lustich, :-) nein habe ich nicht. Ich stelle die ja selber 
her!
Wahrscheinlich ätze ich diese Woche noch, da kann ich dir eine 
mitmachen, Löcher kannst du selber bohren?
Dann schick mir mal eine PN.
>
> Einen 16MHz Quarz habe ich als Standart gewählt, da ich keinen
> 14,31..MHz da habe und zur Festlegung der FuseBits nehme ich:
also funzt das auch mit dem 14,31MHz anständig, wenn ich den angebe?
>
> http://www.engbedded.com/fusecalc
> Fur den atMega48 ergibt sich aus dem Makefile:
> -U lfuse:w:0xd7:m -U hfuse:w:0xdd:m -U efuse:w:0xff:m
Dann habe ich ja die richtigen eingestellt, sind aber trotzdem lustige 
Zeichen auf dem Display, siehe Shot!

Gruß Michael

von Michael D. (mike0815)


Angehängte Dateien:

Lesenswert?

soo, ich habe jetzt mal deine 1. Version(src-v1.4) aufgespielt, das 
sieht schon etwas besser aus, hast aber irgendwie was verhauen!
Ich hänge mal einen Shot von der 1. Ver. an, vielleicht hilft dir das 
ja.
Den Crystal habe ich auf 14,31MHz angepasst. Das soll normalerweise 4MHz 
anzeigen, also nicht wundern, da fehlt noch das Finetuning!

Gruß Michael

von Uwe S. (de0508)


Lesenswert?

Hallo Michael,

danke, testen brauchst du nicht.
Das mache ich dann auf einem Steckbrett und einer hochohmigen 
Eingangsstufe.
Der VCO Output des "Frequenzerweiterung für den NWT (FE-NWT)" dient dann 
als Frequenzgenerator.
Dieser liefert die durch 128 geteilte Frequenz. die bei maximal ca. 
2.700GHz liegt.

von afu_frank (Gast)


Lesenswert?

Danke für Eure Vorschläge,

Ralph Berres schrieb:
> Man müste
> das in LTspice mal simulieren wie sich das benimmt.

Ja klingt gut, bis ich mich da eingearbeitet hab werden ein paar Tage 
vergehen. Wie gut sind den die Erfahren bei dem Unterschied Simulation 
und Praxis?

Lukas K. schrieb:
> Ich evaluiere geraden den TLV3502 Komparator als Eingangsstufe

Super, denke der TLV3501 wprde auch gehen, wo kann man die kaufen? Finde 
da keine Quelle...

Schöne Grüße!

von Ralph B. (rberres)


Lesenswert?

afu_frank schrieb:
> Wie gut sind den die Erfahren bei dem Unterschied Simulation
>
> und Praxis?

Die Simulation stimmt eigentlich sehr gut mit der Praxis überein.

In ihm ist das Psice implementiert.

Ralph Berres

von Lukas K. (carrotindustries)


Lesenswert?

afu_frank schrieb:
> Super, denke der TLV3501 wprde auch gehen, wo kann man die kaufen? Finde
> da keine Quelle...

Digikey hat welche, TI hat gratis-Samples, wenn man nur wenige braucht 
:)

von Uwe S. (de0508)


Angehängte Dateien:

Lesenswert?

Hallo Axel,

ich habe mich an die Umstellung auf 32, bzw. 64 Bit gemacht.

Es ist aber noch nicht endgültig, da ich noch die HW zum Testen aufbauen
muss und erst dann den Code testen könnte.

Angepasst wurde die aktuelle Version 1.4 und es sind auch die
Erweiterungen für die AVR µP atMega48 - 328 Serie drin !

Der 48 Bit Zähler ist nun 64 Bit und der 24 Bit Zähler kann nun 32 Bit.
Entsprechend wurde das Hauptprogramm |main()| angepasst.

Alle Änderungen könnt ihr dort als #define und #ifdef .. #endif wieder 
finden.

Vergessen habe ich ... |-

* die F_CPU Abfrage auf 24 Bit in der |main.c|, die nun raus könnte.

Neu hinzugekommen sind die 64Bit Funktionen von Matthias Hopf und eine 
Anpassung der bin2bcd Funktion auf 5 (6) Byte Argumenten.

In der |main.c| sind nun einige Funktionen als |static| deklariert, bzw. 
abhängig von den Einstellungen (#define) in der |config.h|.
Somit jetzt kann der Compiler - mit meinen Ergänzungen im Makefile - 
noch besser optimieren und der Linker wird, den nicht benötigten Code, 
weglassen.


Anregungen und Tests sind willkommen !

So nun es der Tag endlich zu Ende !

.

von m.n. (Gast)


Lesenswert?

Uwe S. schrieb:
> Anregungen und Tests sind willkommen !

Deine Software habe ich überflogen und frage mich, warum nicht die 
floating-point Routinen des Compilers verwendet werden. Das gesamte 
Programm wäre viel leichter zu handhaben und zu lesen.
Peter Dannegger hatte irgendwo berichtet, dass die GCC-Grundrechenarten 
für float ca. 1k benötigen; die Codegröße kann doch nicht das Problem 
sein. Und die Rechengeschwindigkeit ist (genauso) hoch, auch wenn es 
immer noch böse Zungen gibt, die Gegenteiliges behaupten.

Insbesondere zu später Nacht, sieht man ja manchmal den Wald vor lauter 
Bäumen nicht.

von Uwe S. (de0508)


Lesenswert?

Hallo,

Axel ist der Designer des Programms und hat seine Ideen sauber auf dem 
8-Bit AVR umgesetzt !

Aber dein Einwand ist eine kurze Betrachtung wert:

Wir rechnen, z.B. mit 16-Bit Software und 16-Bit Hardware (Timer1) 
Zähler, diese beiden Wörter werden als 32 Bit interpretiert durch die 
UNION Konstrukte.

Wir kommen also "anfänglich" nicht um diese Darstellung um her, die 
Mathematik ist auch klar:
1
      fx   fref                   fref * Nx
2
      -- = ----    <==>      fx = ---------
3
      Nx   Nref                     Nref


Wir betrachten nun noch die 64-Bit Arithmetik:

"fref * Nx": 32-Bit * 32-Bit liefert ein 64-Bit Ergebnis.

"fref" ist ~F_CPU

"Nx" setzt sich nun aus einen 16-Bit Software Zähler in Timer0 und den 
9-Bits aus HC590 und dem einen Bit HC7474 zusammen.

"Nref" setzt sich nun aus einen 16-Bit Software Zähler in Timer1 und aus 
16-Bit des Timer1 zusammen.

Die nachfolgende Division einer 64-Bit Zahl "fref * Nx" durch eine 
32-Bit Zahl "Nref" liefert als Ergebnis eine 32-Bit Zahl.
Den Rest betrachten wir nicht.

Ich rechne als Mathematiker lieber richtig, als mir Gedanken über Fehler 
mit dem Datentype 'float' unter avr-gcc zu machen.

.

von m.n. (Gast)


Lesenswert?

Uwe S. schrieb:
> Ich rechne als Mathematiker lieber richtig, als mir Gedanken über Fehler
> mit dem Datentype 'float' unter avr-gcc zu machen.

Ich rechne als Pragmatiker; Gedanken über den Datentype 'float' mache 
ich mir auch nicht (mehr) :-)

von Ulrich (Gast)


Lesenswert?

Die Float (double ist gleich) Zahlen von GCC sind nur mit 24 Bit 
Mantisse (oder sind es nur 23 Bits ?). Man kann also schon bei 7 Stellen 
die ersten Rundungsfehler bekommen - nicht immer, aber gelegentlich. In 
der Regel wird das reichen, es ist aber schon an der Grenze.

Die Rechengeschwindigkeit ist für den einfachen Reziprokzähler unwichtig 
- da kommt es nicht auf 1 ms an bis das Ergebnis erscheint. Das wird 
erst interessant, wenn man mehr Flanken auswerten will, aber dafür 
bräuchte man eine etwas andere Hardware.

von Axel (Gast)


Lesenswert?

Uwe S. schrieb:

> Ich rechne als Mathematiker lieber richtig, als mir Gedanken über Fehler
> mit dem Datentype 'float' unter avr-gcc zu machen.

Hehe. Dito :)

Die derzeit sichtbaren Rundungsfehler haben zwei Ursachen:

1. wird in der Divisionsroutine nicht gerundet. Da die Rechnung intern 
mit genuegend "Futter" in Form von Verzehnfachung gemacht wird, sollte 
das aber normal nicht auffallen.

2. gravierender: es wird nach der bin2bcd Umwandlung nicht auf die 
gewuenschte Zahl Stellen gerundet.

Sowohl Frequenz- als auch Periodendauer zeigen also ein "nach unten 
gerundetes" (bzw. "abgeschnittenes") Ergebnis.

Wer moechte, kann gern mal mit floats compilieren. Aber mich hatte schon 
abgeschreckt, wie fett der gcc 64-bit Integer-Arithmetik implementiert.

PS: Schade, dass der Thread gerade jetzt "explodiert" waehrend ich im 
Urlaub bin. Aber in einer Woche schaue ich mir das alles mal genauer an. 
Bis dahin viele Gruesse vom Gardasee ;-P


XL

von Stephan H. (stephan-)


Lesenswert?

Ralph Berres schrieb:
> Mein Vorschlag wäre das zu messende Signal über einen 1Kohm Widerstand
> und zwei dahinter angeordnete antiparallel geschaltete Shottkydioden als
> Begrenzer auf das Gate eines J310 als FETverstärker zu geben. Man müste
> das in LTspice mal simulieren wie sich das benimmt. Bis 30MHz könnte das
> eventuell sogar noch funktionieren.

Hallo Ralph,

das kommt mir doch aber sehr bekannt vor, lass mich raten.
Der fET ist ein KP303. Ich habe ja noch welche...

von m.n. (Gast)


Angehängte Dateien:

Lesenswert?

Axel schrieb:
> Wer moechte, kann gern mal mit floats compilieren.

Unter AVR-Studio 4.18 kommt mein Beispielprogramm mit 'float' auf ca. 
5,6kB. Die Rundung ist kein Problem. Anbei ein Bild der Anzeige.

von Ralph B. (rberres)


Lesenswert?

Stephan Henning schrieb:
> Ralph Berres schrieb:
>> Mein Vorschlag wäre das zu messende Signal über einen 1Kohm Widerstand
>> und zwei dahinter angeordnete antiparallel geschaltete Shottkydioden als
>> Begrenzer auf das Gate eines J310 als FETverstärker zu geben. Man müste
>> das in LTspice mal simulieren wie sich das benimmt. Bis 30MHz könnte das
>> eventuell sogar noch funktionieren.
>
> Hallo Ralph,
>
> das kommt mir doch aber sehr bekannt vor, lass mich raten.
> Der fET ist ein KP303. Ich habe ja noch welche...

Hallo Stephan

Den KP303 kenne ich nicht. Muss wohl ein Fet aus der ehemaligen DDR 
sein.

Ob der mit dem J310 kompatibel ist weis ich nicht.

Ralph Berres

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.