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.
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
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.
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.
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
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.
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
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 :)
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.
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
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.
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
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
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
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
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"
.
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.
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
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.
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
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
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
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
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
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.
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 .......
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.
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 :-)
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.
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!
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.
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.
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).
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.
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!
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.
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!
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
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
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
@ 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.
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.
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.
@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
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
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.
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
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
@ 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
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
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.
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.
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.
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
--
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
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
--
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
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
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
--
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.
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.
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
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.
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.
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
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.
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
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
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!
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
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?
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....
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.
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
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
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.
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?
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
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
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
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.
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
--
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
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.
@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
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
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
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
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
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:
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
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?
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
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
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. :-/
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
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?
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.
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...
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
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.
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!!!
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
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
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
> 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
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
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
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
EEMEMuint32_tee_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
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.
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
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
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)
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!
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:
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
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
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
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
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
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
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.
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
>> 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?
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
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
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
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
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
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
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?
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
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
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
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:
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
voidshow_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:
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
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
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
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
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
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
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
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...
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.
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.
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
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.
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.
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.
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...
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
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
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
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.
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
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
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
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
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.
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!
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
--
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
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
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.
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:
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
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
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
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
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.
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!
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
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
:)
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 !
.
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.
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
fxfreffref*Nx
2
--=----<==>fx=---------
3
NxNrefNref
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.
.
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) :-)
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.
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
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...
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.
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