Announcement: there is an English version of this forum on 
Hallo Welt, hier kommt ein Spielprojekt von mir: ein Frequenzzähler, der im Bereich 1Hz bis ~40MHz mit durchgängig 6 Stellen Genauigkeit arbeitet. An Hardware steckt drin: 1xATmega8, 1x74HC74, 1x74HC590, LCD 10x1. Das Meßprinzip ist eine Kombination von Frequenz- und Periodendauermessung. Details finden sich im angehängten tar.gz. Die Firmware ist ein Mix aus C und Assembler. Rein C ging leider nicht, weil die Arithmetikroutinen aus der avr-libc den Code auf ca. 20kB aufgeblasen hätten. Also habe ich ein bisschen Arithmetik in Assembler gehackt :) Das Projekt geht zurück auf eine Veröffentlichung aus der DDR: "Schaltungssammlung für den Amateur", 5. Lieferung, 1989, Blatt 5-1 ff. Zu finden bei http://www.raupenhaus.de/down/load.php. Damals war es ein größeres TTL-Grab rund um einen U882. Der Code paßte damals in 1/2KB, heute sind es etwas über 2K :-O Kommentare sind erwünscht! lg, XL
Angehängte Dateien:
-
schematic.png
28 KB
Dick!!! Werde ich bestimmt mal nachbauen an einem kalten Winterabend... Aber die Codesammlung wäre ein besseres Unterforum, auch wenn es sich um ein Komplettgerät handelt.
Wie genau ist das von dir gebaute denn? Schonmal eine Vergleichsmöglichkeit gehabt?
ich schrieb: > Wie genau ist das von dir gebaute denn? So genau wie du ihn kalibrieren kannst. Es sind zwei Kalibrierungsmöglichkeiten vorgesehen: 1. die verwendete Referenzfrequenz steht im EEPROM und kann unabhängig von der Firmware verändert werden. 2. das Poti an PC5 erlaubt eine Justierung um +/-511 Hz. > Schonmal eine Vergleichsmöglichkeit gehabt? Nein. Ein Frequenznormal steht aber auf meiner Projekte-Liste. Bislang habe ich eine Handvoll XOs aus der Bastelkiste (von 1.8MHz bis 40MHz) drangehängt und ca. den Mittelwert eingestellt :) Mit einem nackten Quarz (wie der Prototyp hat) läuft dir das Dingens sowohl mit der Zeit als auch mit der Umgebungtemperatur weg. Ein TCXO oder OCXO behebt zumindest das Temperaturproblem. Mehr als die 6 Stellen sind aber ohne ein gutes Frequenznormal nicht sinnvoll, obwohl eine 7. Stelle von der Auflösung her drin wäre. XL
Für 80€ bekommst du ein Rubidumnormal: http://cgi.ebay.de/10MHz-Rubidium-Frequenzstandard-Atom-frequenznormal-/290301954333?pt=DE_TV_Video_Elektronik_Funkger%C3%A4te&hash=item439758491d
@ Axel hast du den Frequenzzähler aus der Schaltungssammlung damals aufgebaut? Ich hatte den mal zur Wendezeit angefangen und letztes Jahr wiedergefunden und vollendet, aber leider zeigt er nur Mist an.
Axel Schwenke schrieb: > Ein TCXO > > oder OCXO behebt zumindest das Temperaturproblem. Falls Dir ein OCXO genehm ist: Einen 10 MHz OCXO habe ich noch abzugeben, für 35 Euro. Schick mir bei Interesse einfach eine PN.
Moin, gururom schrieb: > hast du den Frequenzzähler aus der Schaltungssammlung damals aufgebaut? Ja. > Ich hatte den mal zur Wendezeit angefangen und letztes Jahr > wiedergefunden und vollendet, aber leider zeigt er nur Mist an. Meiner lag bis vor ca. 2 Jahren mit ganz ähnlichen Symptomen auf Eis. Seitdem läuft er aber. Und zwar ganz hervorragend. Die abgedruckte Firmware hat einen Fehler. Details habe ich verdrängt :) Ich habe etliche Varianten der Firmware hier als Quellcode. Das Original, ein minimal angepaßtes Original, eine schöne Variante mit den Original-Algorithmen, eine neue Variante. Der Assembler ist ein Eigenbau :) Meine Änderungen: Polarität der Treiber geändert (Segmente pnp, Digits npn). Die Einheit wird mit 4 Einzel-LEDs angezeigt: Hz, kHz, MHz und Unterlauf. Wenn du mir deine Quarzfrequenz sagst und ob/welche anderen Modifikationen du hast, kann dir ein Firmware-Image bauen. Schick mir ne Mail. XL
Mit einem zusätzlichen Temperatursensor (falls man dafür noch einen PIN freimachen kann) könnte man die Temperaturdrift in erster Näherung kompensieren. Das braucht dann nur zusätzlichen Abgleich bei hohen und tiefen Temperaturen. Wozu eigentlich die Umschaltung im Messverfahren ? Für hohe Frequenzen kann man auch weiter die Periodenmessung über den ICP Pin machen, nur dann halt mit Vorteiler (z.B. 256). In der Minimalversion könnte man so mit nur dem µC und einem Teiler IC auskommen - die Umschaltung kann man über den MUX und Komperator intern erledigen. Ein anderer Test für die Qualität wäre die Auflösung bzw. das Frequenzrauschen das man für die 50 Hz Netzfrequenz erhält.
Moin, ulrich schrieb: > Mit einem zusätzlichen Temperatursensor (falls man dafür noch einen PIN > freimachen kann) könnte man die Temperaturdrift in erster Näherung > kompensieren. Das braucht dann nur zusätzlichen Abgleich bei hohen und > tiefen Temperaturen. Gefrickel. Ein TCXO bietet genau das (Temperaturkompensation) und kostet nicht die Welt. Tatsächlich habe ich hier noch 2 TCXO 12.8MHz von Elektronik-Fundgrube liegen. Die haben mal EUR 0.87 gekostet. Da werde ich sicher keinen Quarz für vermessen (mit welchem Normal eigentlich?) > Wozu eigentlich die Umschaltung im Messverfahren ? > Für hohe Frequenzen kann man auch weiter die Periodenmessung über den > ICP Pin machen, nur dann halt mit Vorteiler (z.B. 256). In der > Minimalversion könnte man so mit nur dem µC und einem Teiler IC > auskommen - die Umschaltung kann man über den MUX und Komperator intern > erledigen. Da wird gar nix umgeschaltet. Das ist ja gerade das geniale an diesem Meßverfahren. Ein fester Vorteiler hat den Nachteil, daß er den Meßbereich nach unten einschränkt. Bzw. dann für kleine Frequenzen überbrückt werden müßte. Ich sehe schon, ich muß das Meßverfahren hier nochmal erläutern. Siehe unten. > Ein anderer Test für die Qualität wäre die Auflösung bzw. das > Frequenzrauschen das man für die 50 Hz Netzfrequenz erhält. Nicht wirklich. Zum einen hast du da jede Menge Schmutz auf dem Netz, den du erst mal entfernen mußt, damit es keine Fehltriggerung gibt. Zum weiteren ist die Kurzzeitstabilität der 50Hz nicht berauschend. Hier also eine Beschreibung des Meßverfahrens. Das gibts auch nochmal im tar.gz in RATIOMETRIC.txt (allerdings auf Englisch). Der Zähler benutzt ein gemeinsames Tor, das zwei Zählerketten steuert. Der eine Zähler zählt Impulse der unbekannten Meßfrequenz fx, der andere Zähler zählt Impulse der Referenzfrequenz fref. Sei nun Nx der Zählerstand des Fx-Zählers und Nref der Zählerstand des fref-Zählers. Für geeignete Tor-Öffnungszeiten gilt dann:
bzw. umgestellt nach fx:
Was wäre nun eine geeignete Tor-Öffnungszeit? Zum einen sollte das Tor synchron zur Meßfrequenz fx öffnen. Dadurch zählen wir immer ganze Perioden von fx und vermeiden so den +/- 1 Fehler, den wir bei unsynchronisierter Torzeit sonst bekommen. Da wir das Tor nur entweder auf fx oder auf fref sychronisieren können, müssen wir andererseits eine genügend lange Torzeit wählen, um genügend Impulse von fref zu bekommen. Wenn wir z.B. mindestens 1'000'000 fref-Impulse haben, dann beträgt der systematische Fehler höchstens 1ppm. Soweit zur Theorie. In der Praxis ist da nur 1 Zähler - der für fx. Die ersten 8 Bit macht der 74HC590, die eine (rechte) Hälfte des 74HC74 macht ein weiteres Bit (vor allem, weil der Impuls an RCO des HC590 evtl. zu schmal ist, um den ATmega8 sicher zu triggern). Die restlichen Bits machen Timer0 und ein weiteres Byte per Software. Wenn fx sicher unter 1/2 F_CPU liegt, dann kann man den 74HC590 einsparen (braucht aber ein Gatter als Tor - nix gewonnen) Der Zähler für fref nutzt die Capture-Einheit und Timer1. Dazu muß man erst die Tor-Logik verstehen. Die zweite (linke) Hälfte des 74HC74 ist das Tor-Flipflop. An D liegt das Signal "Start" - im Prinzip das unsynchronisierte Tor-Signal. Über CLK wird das Tor mit fx synchronisiert und über /Q wird der 74HC590 freigegeben. Gleichzeitig werden die fallende Flanke (Tor öffnet) und die steigende Flanke (Tor schließt) von der Capture-Einheit festgehalten. Dazu noch die Anzahl der Timer1-Überläufe dazwischen und fertig ist der Zähler für fref. Die Firmware hält das Tor nun mindestens so lange auf, bis ca. 4'000'000 Impulse im fref-Zähler sind (bei 14.31MHz dauert das ca. 0.28 sec). Dann schließt die nächste steigende Flanke von fx das Tor. D.h. bis ca. 10Hz ist die Torzeit ca. 0.3 sec, maximal 1 sec beim Minimum von 1Hz. Aber immer ein ganzes Vielfaches der Periodendauer von fx. Das absolute Minimum für fx ist fref/(16*1024*1024) = 0.853Hz. Das deswegen, weil der fref-Zähler 24 Bit lang ist (maximal 16*1024*1024-1). Die obere Grenze ergibt sich analog: der fx-Zähler ist auch 24 Bit lang. Während der 4 Mio fref-Impulse dürfen max. 16 Mio fx-Impulse auflaufen bevor der fx-Zähler überläuft. Damit darf fx nicht größer werden als 4*fref. In der Praxis macht die 74HC-Logik vorher dicht. Wenn das Tor wieder geschlossen ist, werden die Zähler ausgelesen und fx nach obiger Formel berechnet. Der systematische Meßfehler ist dabei kleiner als +/- 0.25ppm. Dazu kommt der Fehler von fref. Wenn man die Meßzeit auf 10'000'000 fref-Impulse verlängert (Torzeit 0.7 sec), dann liegt der systematische Fehler unter 0.1ppm und man kann 7 Stellen anzeigen. Vorausgesetzt natürlich, man kennt fref genau genug und fref driftet signifikant weniger über Zeit und Temperatur. Ich habe fertig :) OK. Eins noch: man kann das mit einem Trigger (und evtl. einem Gigahertz-Vorteiler) als standalone-Frequenzzähler betreiben. Meine Intention war allerdings eher, eine Art no-brainz Frequenzanzeige zu bauen, die man z.B. in einen Funktionsgenerator so selbstverständlich reinbaut, wie ein Panelmeter-Modul in ein Netzteil. Genausogut kann man mit wenig Aufwand kann man da noch eine ZF-Subtraktion reinbauen und das in einem Funkempfänger verwenden. Etc. pp. XL
Nachtrag: es sind noch ein paar Fehler im Schaltplan: 1. der Pullup an Reset fehlt 2. dito ein Pullup an fx (Connector "Signal", Pin 1) 3. Pins 4 und 10 (/PRE) des 74HC74 liegen an Vcc, offen lassen geht zwar bei TTL, aber nicht bei 74HC 4. die Abblock-Cs für '74 und '590 sind nicht eingezeichnet (5. ich hab auch PC5 des ATmega und Vee des LCD noch 100n gegen GND spendiert. Und es gibt ein paar "Angst-Pullups" - siehe Fotos) PS: Ich habe mehrere Anläufe gestartet, den Schaltplan mit Eagle (Freeware) oder gschem zu zeichnen. Ohne Erfolg. Schließlich bin ich zum Altbewährten (xfig) zurückgekehrt. Liegt das an mir, oder sind besagte Programme einfach nur schlecht? XL
Hallo habe heute Nacht mal den Schaltplan mit Eagle gezeichnet. Ich hoffe es sind keine Fehler drin :-) Wenn Interesse besteht werde morgen Nacht mal Layout fertig machen. Schrotti
Mit ein wenig Suchen findet man u. a. so etwas im Netz; http://www.mino-elektronik.de/fmeter/fmeter.htm Ist nichts Neues, sondern schon 10 Jahre alt. Die Eingangsfrequenz kann noch deutlich tiefer erfaßt werden.
Moin! Gockel schrieb: > Mit ein wenig Suchen findet man u. a. so etwas im Netz; > http://www.mino-elektronik.de/fmeter/fmeter.htm Ha! Ich hatte etliche Male mit Google gesucht, aber nix in der Richtung gefunden. Wahrscheinlich nicht die richtigen Suchbegriffe verwendet... > Ist nichts Neues, sondern schon 10 Jahre alt. Sogar noch älter. Die erste mir bekannte Variante ist >21 Jahre alt. Heh - das ist älter als das WWW! > Die Eingangsfrequenz kann noch deutlich tiefer erfaßt werden. Klar. Muß man nur die Zähler weiter aufbohren. Mit 32 Bit kommt man auf besagte 3mHz. Nur wer will schon 5 Minuten auf jedes Meßergebnis warten? XL
Christian Scharrer schrieb: > Wenn Interesse besteht werde morgen Nacht mal Layout fertig machen. Ja. Und wenn dann weiter Interesse besteht, könnte ich Platinen bestellen..? Peter
Danke für die Erklärung des Messverfahrens. Schon eine gar nicht so schlechte Lösung, und wirklich ohne Umschalten des Verfahrens. Gerade wenn die angezeigte Frequenz wegen eines schlechten Signals schon schwankt ist die Frage wie viel es denn schwankt schon interessant. Da interessiert dann nicht mehr die theoretische Auflösung, sondern die praktische, durch die Empfindlichkeit auf Störungen. Gerade bei eher gestörten Signalen wie den 50 Hz aus dem Netz, hat die Messung der Zeiten für die erste und letzte Flanke in der Torzeit aber ihre Grenzen. Es wird relativ empfindlich auf Fehler bei den beiden ausgewählten Flanken für Start und Stop. Wenn man wollte, könnte man z.B. mehr als nur die 2 Flanken messen und so weniger Empfindlich auf gestörte Signale werden. Nur mit der gegeben Hardware dürfte das aber kaum gehen. Das Verfahren und der Plan sind schon gut, mit das beste was ich bisher im Netz als Frequenzzähler (bzw. den Teil davon) gefunden habe. Abgesehen natürlich von der Referenz.
Hallo, sollte das nicht besser in die Codesammlung verschoben werden? In ein paar Tage ist es weg und die, die nicht jeden Tag hier 'reinschauen, erfahren das nie.
Dieter S. schrieb: > Hallo, sollte das nicht besser in die Codesammlung verschoben werden? In > ein paar Tage ist es weg und die, die nicht jeden Tag hier 'reinschauen, > erfahren das nie. Ich hab den Fred im AVR Softwarepool verlinkt. Reicht das nicht? XL
ulrich schrieb: > ... wenn die angezeigte Frequenz wegen eines schlechten Signals schon > schwankt ist die Frage wie viel es denn schwankt schon interessant. Da > interessiert dann nicht mehr die theoretische Auflösung, sondern die > praktische, durch die Empfindlichkeit auf Störungen. Ich verstehe nicht, was du sagen willst. Wenn die Frequenz des Signals schwankt (oder die Flanken jittern) dann kriegst du mit keinem Frequenzmeßverfahren der Welt eine stabile Anzeige. Das beste, was du dann machen kannst, ist das Meßintervall recht lang zu machen und so über viele Perioden zu mitteln. Oder du machst es recht kurz und wertest Minimum, Maximum, Mittelwert etc. aus. Oder du fütterst es in eine FFT und läßt ein Spektrogramm raus. Je nachdem, was du denn eigentlich messen willst. > Gerade bei eher gestörten Signalen wie den 50 Hz aus dem Netz, hat die > Messung der Zeiten für die erste und letzte Flanke in der Torzeit aber > ihre Grenzen. Es wird relativ empfindlich auf Fehler bei den beiden > ausgewählten Flanken für Start und Stop. Wenn man wollte, könnte man > z.B. mehr als nur die 2 Flanken messen und so weniger Empfindlich auf > gestörte Signale werden. Nur mit der gegeben Hardware dürfte das aber > kaum gehen. Alle Frequenzmesser müssen irgendwie definieren, wo eine Periode des Eingangssignals anfängt. Im digitalen Bereich ist es üblich, dafür eine Impulsflanke zu nehmen. So wie die Schaltung jetzt ist, ist es die steigende. Mach einen Inverter davor, dann ist es die fallende. Die Aufbereitung eines verrauschten, verbrummten Signals ist eine separate Aufgabenstellung. > Das Verfahren und der Plan sind schon gut, mit das beste was ich bisher > im Netz als Frequenzzähler (bzw. den Teil davon) gefunden habe. Danke für die Blumen. Ich stehe auf den Schultern von Giganten. > Abgesehen natürlich von der Referenz. Die Referenz darfst du so genau machen wie du willst. Kauf das o.g. Rubidium-Normal bei ebay und füttere dem ATmega8 die 10MHz daraus. Schon mußt du dir um Kalibrierung keine Gedanken mehr machen. Und im Bastelkeller ist es immer schön warm (wenn der Frequenzzähler läuft :) XL
Bei einer nicht so stabilen Frequenz sind die Schwankungen in der angzeigten Frequenz abhängig vom Messverfahren. Ganz schwankungsfrei kreigt man die Anzeige nicht, aber es kann mehr oder weniger stark schwanken. Hier wird bei z.B. 50 Hz und 1 s Tor-zeit nur ein kleiner Teil (die 2 besten) der Flanken ausgewertet. Man könnte es noch schlechter machen wenn man einen Teil der Torzeit verschenkt, oder halt besser wenn man die Zeit aller Flanken misst und nutzt. Bei dem Beispiele wäre etwa ein Faktor 2-4 drin - wie viel hängt auch vom Signal ab. Bei der hier gezeigten Hardware ist es aber kaum möglich mehr als 2 Flanken zu vermessen - das war auch nur so ein Hinweis wie man es eventuell noch etwas besser machen könnte. Wenn es wirklich drauf ankommt bei einen Signal wie der Netzfrequenz eine genaue rauscharme Frequenzmessung zu bekommen, dann ist die Methode der Wahl das Signal per AD Wandler zu digitalisieren und an die Daten eine passenden Kurve (z.B. Sinus) anzupassen. Mein Frequenzzähler hat auch keine bessere Referenz, und mir reicht es. Oft kommt es auch nicht auf den Absolutwert der Frequenz an, sondern eher auf Änderungen.
Guten Morgen habe jetzt das Layout fertig gemacht.Für meine erste Arbeit mit Eagle schaut es gar nicht so schlecht aus. Warscheinlich mit lauter Anfängerfehler voll. Deswegen Kritik sehr erwünscht.
Christian Scharrer schrieb: > Deswegen Kritik sehr erwünscht. Dann stell' bitte ein PNG für den Schaltplan und eins für das Board mit ein. Dann schau' ich mir das auch an.
Christian Scharrer schrieb: > Danke für den Hinweis :-) C6 ist seltsam und im Originalplan nicht vorhanden? Eventuell Vorwiderstand und Beschaltung für LCD-Hintergrundbeleuchtung einplanen? (Pin 15+16) Wenn du mit dieser Platine wirklich bis zu 40 MHz Rechteck messen willst, würde ich die Signalführung des Eingangssignals nochmal deutlich überarbeiten. D.h. vor allem kürzer machen. Ob hier eine normale Pin-Header Verbindung noch sinnvoll ist, wage ich auch zu bezweifeln. Zumindest über eine BNC-Buchse sollte man nachdenken. Im Layout sind einige 90°-Knicke, die man zumindest als "unschön" bezeichnen kann. Auch wenn man es sich einfach macht und keinerlei GND-Leitungen im Layout einfügt und es nach "die Massefläche wird's richten"-Mentalität routet, sollte man doch im Hinterkopf behalten, dass man so keine optimalen Stromschleifen hinbekommt. Speziell IC2 ist katastrophal, da die Massefläche unter dem IC durch Signalleitungen komplett durchtrennt ist. Ok, links herum geht es, da ich aber nicht weiß, die deine Massefläche ausehen wird (isolate Wert?), kann man das nicht abschließend beurteilen. Vllt. einfach mal die GND-Leitungen reinmalen und schauen. C4 ist zu weit von AVCC weg, der sollte sich rechts vom AtMega aufhalten, nahe am Pin. Willst du die Platine selbst fertigen? Dann sind die Vias unter den ICs evtl. unpraktisch. Wenn du die Platine fertigen lassen willst, könnte man über SMD nachdenken. Dann passt die ganze Schaltung locker unter das Display... Da R5 (Poti) dem Abgleich dient und die das Signal über das halbe Board routest, wäre ein Kondensator am Ausgang des Potis auch nicht verkehrt. Aber: Im Großen und Ganzen für die erste Arbeit mit Eagle nicht schlecht, an den VCC-Leitung sieht man schon, dass du mit etwas Planung an die Sache herangegangen bist.
ulrich schrieb: > Danke für die Erklärung des Messverfahrens. Schon eine gar nicht so > > schlechte Lösung, und wirklich ohne Umschalten des Verfahrens. > > > > Gerade wenn die angezeigte Frequenz wegen eines schlechten Signals schon > > schwankt ist die Frage wie viel es denn schwankt schon interessant. Da > > interessiert dann nicht mehr die theoretische Auflösung, sondern die > > praktische, durch die Empfindlichkeit auf Störungen. Das von Axel benutzte Messverfahren ist ein hochmodernes von mittlerweilen sämtliche renomierten Messgerätefirmen benutzte Messverfahren. Wieviel Stellen / Sekunde Auflösung man bekommt, hängt von der maximalen Geschwindigkeit ab, welche die Hardware ohne einen Vorteiler noch verarbeiten kann. Das Problem mit dem Jitter des zu messenden Signals kann man dem Frequenzzähler nicht anlasten. Da streikt dann jedes Messgerät, sofern er nicht viele Messungen mittelt, was letztendlich wieder Zeit kostet. Ich finde das das Messprinziep von Axel gerade im NF Bereich ein hochinteressantes Verfahren ist, welche auch bei niedriger Messfrequenz noch eine vernünftige Auflösung erlaubt. Bisher ist mir unter den Selbstbauprojekten noch keines begegnet, welches dieses Verfahren anwendet. Maximal wurde mal ein Reziprokmessverfahren angewendet, welches dann die Auflösung bei hohen Frequenzen alt aussehen läßt. Axel meine Hochachtung. Ralph Berres
>Bisher ist mir unter den Selbstbauprojekten noch keines begegnet, Mit dem Suchbegriff 'reziproker Frequenzzähler' bei google findet man obigen Link. Aber allein schon hier in der Codesammlung ist der letzte Beitrag vom Nomvember 2010: Beitrag "Reziproker Frequenzzähler+ Optimierte 64bit uint Routinen" Eagle-Leiterplatte und Programm findet man auch, wenn man weitersucht: http://www.mino-elektronik.de/download/progs_sheets.htm Irgendwo müßte auch noch eine Schaltung von PeDa zu finden sein, die auch schon ein Jahrzehnt alt sein dürfte. Allesamt sind Selbstbauprojekte.
Gockel schrieb: > Mit dem Suchbegriff 'reziproker Frequenzzähler' bei google findet man > > obigen Link. Axels Messverfahren ist aber eben kein rein reziprokes Zählverfahren. Das Zählverfahren von Axel umgeht die Nachteile sowohl der klassischen direkten Zählverfahren ( Torzeit ist die runtergeteilte Zeitbasis und Frequenz ist proportional der gezählten Impulse ) als auch der reziproken Zählverfahren ( Periodendauermessung mit anschliesender Umrechnung in Frequenz ). Axel misst sowohl die Anzahl der Impulse des Frequenzzähltores, als auch die Impulse der Zeitbasis, welches auch ein Tor besitzt. Beide Tore also Frequenzzähltor als auch Zeitbasistor werden gemeinsam mit der ersten Periode des zu messenden Signals geöffnet und nach einer ( fast ) beliebigen Zeit mit der selben Flanke der zu messende Frequenz wieder geschlossen. Die beiden Ergebnisse werden miteinander verrechnet. Die Zeit wie lange die beiden Tore geöffnet sind bestimmt, wieviel Stellen angezeigt werden können. Und zwar unabhängig von der Frequenz. Die Geschwindigkeit wie schnell der Zähler ist bestimmt , wieviel Stellen pro Sekunde Toröffnungszeit angezeigt werden können. Diese Tatsache ist der Unterschied zum reinen Reziprokmessverfahren. Es muss lediglich gewährleistet sein, das innerhalb der Toröffnungszeit mindestens eine Periode der zu messende Frequenz reinpasst. Ralph Berres
@Christian: Danke daß du dir die Mühe mit Eagle gemacht hast. Zum Schaltplan: C6 gehört da nicht hin. Zur Platine: zu groß :) - aber im Ernst, die sollte möglichst genau so groß sein wie das LCD, damit man da ein hübsches Sandwich bauen kann. Es wäre zu überlegen, die Platine und das Display "Rücken an Rücken" zu montieren, dann dürften sich auch die 8 Datenleitungen zum Display leichter legen lassen. Das 40MHz Signal ist nicht ganz so kritisch, wie Maik meint - immerhin hat es HC Pegel. Beim Testen habe ich auch problemlos 40MHz aus einem XO mit 1m Meßstrippen über den Tisch geführt. Trotzdem kann es natürlich nicht schaden, die folgenden Leitungen kurz zu machen: - fx - alles am Quarz - das analoge Kalibrierungssignal. Dem könnte man übrigens einen Jumper spendieren, mit dem man PC5 wahlweise an GND legen kann. XL
Ralph Berres schrieb: > Axel misst sowohl die Anzahl der Impulse des Frequenzzähltores, als auch > die Impulse der Zeitbasis, welches auch ein Tor besitzt. Beide Tore > also Frequenzzähltor als auch Zeitbasistor werden gemeinsam mit der > ersten Periode des zu messenden Signals geöffnet und nach einer ( fast ) > beliebigen Zeit mit der selben Flanke der zu messende Frequenz wieder > geschlossen. Die beiden Ergebnisse werden miteinander verrechnet. Mein Gott, das ist doch Stand der Technik seit Mitte der den 70iger.
Gockel schrieb: > Irgendwo müßte auch noch eine Schaltung von PeDa zu finden sein, die > auch schon ein Jahrzehnt alt sein dürfte. Siehe z.B. hier Beitrag "Re: Frequenzzähler eigenbau" und hier: Beitrag "Re: Frequenzzähler eigenbau" Christian.
Freies Elektron schrieb: > Mein Gott, das ist doch Stand der Technik seit Mitte der den 70iger. Richtig.
@Christian
Danke, ich dachte der Beitrag wäre noch älter und nicht mehr verfügbar.
@Ralph Berres
Ließ Dir den Artikel zum 1. Link doch einmal durch und dann korrigiere
Deine Aussage ;-) Da kann man abhängig von der Meßzeit die Anzahl der
gültigen Stellen wählen: 5-7 mit stets optimaler Auflösung und
lückenloser Erfassung.
>Mein Gott, das ist doch Stand der Technik seit Mitte der den 70iger.
Aber nur für Leute, die da schon geboren waren ;-)
Gockel schrieb: > >>Mein Gott, das ist doch Stand der Technik seit Mitte der den 70iger. > Aber nur für Leute, die da schon geboren waren ;-) Bzw. für die stets weniger Werdenden die danach geboren wurden UND in der Lage sind Fachliteratur zu lesen und zu verstehen ,-)
Gockel schrieb: >>Mein Gott, das ist doch Stand der Technik seit Mitte der den 70iger. > Aber nur für Leute, die da schon geboren waren ;-) Jau, aber die später geborenen(;-) könnten auch wissen, dass Hameg in seinen 8000er-Modul-Frequenzzähler die parallele Fx- und Frefzählung durchführt. Selbst ELV benutzt dieses Verfahren in seinem Bausatz FC7008. Schaltbild kann man dort laden. Beide, Hameg und ELV haben zusätzlich die Messfunktionen pos.Pulsbreite, neg.Pulsbreite und Total. Und wer was Gutes tun will der baut noch eine Tastverhältniss-Messung ein.
Von Philips gab es in den 70ern solch ein Meßgerät PM.... zu rund DM 1000. Mit viel Zeit könnte ich das Datenblatt wieder ausgraben. Das hatte auch bestimmt noch einen Datenausgang: BCD parallel, wie man das damals so machte ;-)
Andrew Taylor schrieb: > Gockel schrieb: >> >>>Mein Gott, das ist doch Stand der Technik seit Mitte der den 70iger. >> Aber nur für Leute, die da schon geboren waren ;-) > > Bzw. für die stets weniger Werdenden die danach geboren wurden UND in > der Lage sind Fachliteratur zu lesen und zu verstehen ,-) Haha. Übrigens: beide o.g. Threads waren nicht vom AVR Softwarepool verlinkt. Ich habe zumindest den einen jetzt mal da rein getan. Womöglich erspart das ja jemand anderem, das Rad nochmal neu zu erfinden. Was mich persönlich angeht: ich wollte so ein Projekt allein angehen. Zum einen, weil ich mich in AVR-C und insbesondere die Kopplung C/ASM einarbeiten wollte. Zum zweiten habe ich bereits ein Gerät, das nach diesem Prinzip arbeitet. Das braucht ca. 1x Europlatine und frißt 450mA bei 5V. Ich wollte einfach mal sehen, wie klein und stromsparend das aufzubauen geht. Was ich dabei gelernt habe: 1. mit den AVRs bekommt man keine schnellen (kurzen) ISRs hin. U.a. deswegen, weil man SREG manuell sichern muß. Schon gar nicht in C (man schaue sich mal den Code an, den gcc/avr-libc für eine ISR erzeugen, die nur ein Byte inkrementieren muß). In Z8 ASM sieht das so aus:
1 | ISR: INC foo |
2 | RETI |
(ja, mit 128 Registern im Z8 haben alle Variablen ihr eigenes Register) 2. wegen 1. ist eine reine Software-Lösung (also ohne externes Gate) entweder vom Meßbereich oder von der Auflösung limitiert. 6 Stellen wollte ich aber schon haben. Und 10MHz (besser 20) auch. 3. entwickeln mit der gcc Toolchain macht Spaß und geht schnell - viel schneller als reiner Assembler anno 1990. Der Code wird aber größer. Bei diesem Beispiel sind es 0.5KB vs. 2KB (Z8 vs. Mega8). Das ist natürlich doppelt unfair verglichen - zum einen ASM vs. C und dann auch CISC vs. RISC. Trotzdem interessant. Ich habe das Projekt hier rein gestellt in der Hoffnung daß es jemandem was nützt. Wenn nicht - auch gut. Wie ich mich kenne, werde ich das ganze vermutlich nochmal in reinem ASM neu schreiben. Einfach um zu sehen, wieviel kleiner (ich tippe <1KB) und schicker das wird. XL
>1. mit den AVRs bekommt man keine schnellen (kurzen) ISRs hin. U.a. >deswegen, weil man SREG manuell sichern muß. Das stimmt so nicht. Nur weil ein anderer CISC-Prozessor wenig Tipperei bei der Eingabe braucht, muß die Verarbeitungszeit noch lange nicht kurz sein. ein "INC byte_var; RETI;" mag ja schön aussehen findet sich aber in der Realität kaum wieder. Zeige den Code, wie zum Beispiel eine long_var inkrementiert wird und dabei gepusht und gepoppt werden muß (wie unanständig) und ermittle die effektiven Ausführungszeiten. Diese kann man dann vergleichen.
Ich finde es gut, sehr gut sogar, von Axel, hier seine Arbeit reinzustellen. Man lernt was und spart auch noch Zeit, wenn man es benutzen möchte. Die Arbeit selbst als "veraltet" einzustufen - naja, wer richtig konsequent ist, sollte nicht in dieses Forum reinschauen. Ein Hinweis auf die anderen Links für den Autor dieser Arbeit hätte schon gereicht. So ein Z8-Zähler-Ding habe ich auch, aus der selben Quelle nachgebaut. Schön zu sehen, wie es auch anders geht. Blackbird
Freies Elektron schrieb: > Mein Gott, das ist doch Stand der Technik seit Mitte der den 70iger. Das ist wohl richtig das die Technik schon relativ alt ist. Trotzdem wird sie nach wie vor auch heute so wie sie ist, selbst von Firmen wie Agilent, angewendet, deswegen bezeichne ich sie trotzdem als hochmodern. Freies Elektron schrieb: > Jau, aber die später geborenen(;-) könnten auch wissen, dass Hameg in > > seinen 8000er-Modul-Frequenzzähler die parallele Fx- und Frefzählung > > durchführt. Stimmt, habe ich gerade auch festgestellt. Was ich aber heute noch vermisse, sind fertige kleine Module, die finanziell erschwinglich sind und genau dieses Messverfahren anwenden. Es gabe von Intersil früher mal ein fertiges IC , welches einen kompletten 8 stelligen Frequenzzähler beinhaltete. Das konnte aber auch nicht das aktuelle Messverfahren. Es ist schön das es vermehrt fertige Konzepte gibt auf Basis eines Amtel oder Pic Prozessor. Vor ein paar Jahren ist mir sowas jedenfalls noch nicht über den Weg gelaufen. Da gab es allenfalls die reinen Reziprokmessverfahren, bei welcher die Periodendauer des Messsignals das Zähltor für die Referenzfrequenz gesteuert hat. Das war bei niedrigen Frequenzen gut aber nicht bei hohen Frequenzen. Nichts für ungut und Sorry wenn ich übersehen habe das solche Konzepte es schon im Netz gab. Nichts desto Trotz finde ich es trotzdem gut wenn Usewr wie Axel seine Projekte ins Netz stellen. Schon alleine um sich Anregungen holen zu können. Ralph Berres
>Was ich aber heute noch vermisse, sind fertige kleine Module, die >finanziell erschwinglich sind und genau dieses Messverfahren anwenden. So etwas? http://www.mino-elektronik.de/bilder/fmeter/fmeter_brd.jpg Wenn es was Fertiges sein soll: http://www.reichelt.de/?;ACTION=3;LA=444;GROUP=D113;GROUPID=4041;ARTICLE=81696;START=0;SORT=artnr;OFFSET=16;SID=30@TNBPVX8AAAIAAHukQdcdf7a6c0b7ae9e8efa4b3c0dd04d357f
Gockel schrieb: > Wenn es was Fertiges sein soll: > > http://www.reichelt.de/?;ACTION=3;LA=444;GROUP=D11... Ist zwar nicht ganz billig, aber genau das was ich suchte. Besten Dank für den Tip. Ralph Berres
HP /Agilent verwendet seit den 80er Jahre bei denn meisten Counter das sogenannte Analoginterpolationsverfahren. Dabei wird der bei der Periodendauermessung enstehende +-1 Fehlerdurch eine Analoginterpolationsschaltung so gedehnt das sie wieder Messbar werden. So kann man auch mit Refernzclocks von z.B. 10MHz Aufloesungen des Counter von 1nS erzielen. Angewandt zB. im HP5334B
>Ist zwar nicht ganz billig, aber genau das was ich suchte. Billig geht doch auch: nimm einen ATtiny2313 (2€), einen 10MHz Quarz sowie Kleinteile (<1€) und programmiere das Programm FM.HEX darauf. Damit kannst Du den Bereich von 0,0025Hz - 140kHz abdecken. Mit einem zusätzlichen 74HC393 (0,28€) geht es dann bis knapp 40MHz. Preislich liegst Du dann bei ca. 3,5€. Eine Programmänderung (Skalierung) und ein 20MHz Quarz könnten die obere Grenzfrequenz verdoppeln. Entweder gibt es ein Display 16x2 dazu (6,80€) oder per RS232 Pegelwandler an einen PC o.ä.. Also für rund 10€ (Preise von Angelika) bis Du dabei ;-) @Helmut Lenzen Das war damals ein Notbehelf, der wohl eher nichts für Bastler ist. Heute kann man feiner auflösen, wenn man als Fref etwas zwischen 100MHz und 1GHz verwendet oder einen µC nimmt, der bei dieser Taktfrequenz arbeitet.
Hallo Axel!
Großartig das ganze kleine Projekt.
Das ist mal etwas, was von der Theorie zwar schon etwas älter ist,
aber in der Praxis wohl nur von wenigen bisher genutzt wurde.
Ich kann das Ganze vielen anderen ans Herz legen und empfehlen, sich
mehr damit zu beschäftigen.
Die Idee mit dem ATMEGA8 und dem Portsplitting war die Idee,
die mir noch fehlte. DANKE!
Ich habe dieses Meßverfahren hier schon seit 8 Jahren auf einem
betagten AVR8515 so ähnlich laufen.
So jetzt kommt aber eine wichtige mich interessierende Frage.
Funktioniert dein Hardwareverfahren auch wirklich???
Als ich vor vielen Jahren das mit dem 74590 als VorTeiler/Zähler
ausprobiert hatte, entstand ein Problem:
Der Übertragstakt RCO kam immer zu früh, so das bei bestimmten
Meßfrequenzen falsche Anzeigen erfolgten. Der 74590 zeigte noch
255 an, während der Softwarezähler schon um 1 weitergeschaltet hatte.
(Problem: Flankenrichtung und Kopplung Synchronzähler-Asynchronzähler).
Ich hatte es damals (und so auch noch heute) mit einem MonoFlop 74123
gelöst (200µs Verzögerung o.ä.).
Deine Version mit dem 7474 als "9.Bit" habe ich so aber nie hin-
bekommen?
Meine Frage: Kennst Du dieses Problem? Wie hast Du es gelöst?
PS: Ich kann im Moment deine ZIP-Datei nicht öffnen, weil mein
Rechner hier einen schlechten Stand hat und hoffe das der noch
ein paar Stunden durchhält, bis vielleicht eine Antwort kommt.
Axel mach bitte weiter an diesem schönen Projekt.
mfg Padex
Ralph Berres schrieb: >Das Problem mit dem Jitter des zu messenden Signals kann man dem >Frequenzzähler nicht anlasten. Da streikt dann jedes Messgerät, sofern >er nicht viele Messungen mittelt, was letztendlich wieder Zeit kostet. Jitter kann man dem Messgerät nicht anlasten, aber die Empfindlichkeit auf Jitter ist abhängig vom Verfahren. Beim gleichen schlechten Signal kann ein Gerät mehr Schwanken als ein anderes. Ein Möglichkeit zur Verbesserung ist es z.B. mehrere Messungen zu mitteln, ohne das es mehr Zeit kostet: Das geht wenn man für die erste Messung wie hier die Flanken Nr 1 und N nutzt, für die 2. Messung die Flanken Nr. 2 und N-1 usw. Die weiteren Messungen sind durch die kürzere Messzeit nicht ganz so gut, aber auch nicht ganz schlecht. Im Idealfall bildet man dann das gewichtetes Mittel. Ein andere Möglichkeit ist es die Zeiten zu allen Flanken in der Torzeit zu messen, und dann eine lineare Interpolation der Zeiten vs. laufender Nummer zu machen. Im Endeffekt kommt da übrigens die gleiche Formel raus, wie beim gewichteten Mittel der Teilmessungen. Es ist also nur eine andere Interpretation, kein wirklich anderes Verfahren. Den Nachteil den man so hat, ist dass man wohl einen zuschaltbaren Vorteiler braucht, denn je nach µC schaft man das halt nur bis vielleicht 10-500 kHz.
Angehängte Dateien:
-
Schalt02.png
24 KB -
board02.png
29 KB
Hallo habe den Fehler in meinen Schaltplan beseitigt. Einen BNC Stecker, Jumper und Beleuchtung eingefügt. Sowie die Platine passend verkleinert. Bitte um weitere Kritik :-) Schrotti
Christian Scharrer schrieb: > Bitte um weitere Kritik :-) Das Platinenformat gefällt so besser ;) Das einzige, was mir beim schnellen Drüberschaun noch aufgefallen ist: Die Leitung unter dem Quarz kannst du auch rechts von der rechten Lastkapazität des Quarzes verlegen, das muss nicht unter dem Quarz durch. Und wenn du das machst, kannst du auch gleich noch den rechten Quarz-Kondensator 90° im UZS drehen und den linken 90° gegen den UZS, damit deren Massepins näher an den uC rankommen. Ein PNG vom Board mit der Massefläche wäre auch interessant, ich bin nach wie vor etwas skeptisch, was die Anbindung diverser GND-Pins angeht... Mehr habe ich gerade nicht zu meckern.
Gockel (Gast) schrieb am Datum: 09.12.2010 16:16 >Billig geht doch auch: nimm einen ATtiny2313 (2€), einen 10MHz Quarz >sowie Kleinteile (<1€) und programmiere das Programm FM.HEX darauf. >Damit kannst Du den Bereich von 0,0025Hz - 140kHz abdecken. Mit einem >zusätzlichen 74HC393 (0,28€) geht es dann bis knapp 40MHz. >Preislich liegst Du dann bei ca. 3,5€. > >Eine Programmänderung (Skalierung) und ein 20MHz Quarz könnten die obere >Grenzfrequenz verdoppeln. Entweder gibt es ein Display 16x2 dazu (6,80€) >oder per RS232 Pegelwandler an einen PC o.ä.. Wo bekommt man den Sourcecode der mino-elektronik-Lösung her? Blackbird
Bei der Platine kann man auf die Induktivität für AVCC verzichten - so kritisch ist das AD-wandler da nicht. Die Abblockkondensatoren an den ICs sind da wichtiger. So sind die Masseleitungen einfach zu lang, und die Störungen werden stark in die zerfranste Massefläche eingekoppelt. Vor allem beim µC sollten die Kondesatoren wirklich so dicht wie möglich an die Pins - nicht mehr als ein paar mm weg. Der Kondensator unter dem µC ist ok, der drüber ist schon zu weit weg. Ggf. auch die Kondesatoren als SMD, wenn der Platz knapp wird.
>Wo bekommt man den Sourcecode der mino-elektronik-Lösung her? Einmal nach rechts und links geklickt: http://www.mino-elektronik.de/fmeter/fm_software.htm
Moin Padex, Padex schrieb: > Funktioniert dein Hardwareverfahren auch wirklich??? > Als ich vor vielen Jahren das mit dem 74590 als VorTeiler/Zähler > ausprobiert hatte, entstand ein Problem: > > Der Übertragstakt RCO kam immer zu früh, so das bei bestimmten > Meßfrequenzen falsche Anzeigen erfolgten. Der 74590 zeigte noch > 255 an, während der Softwarezähler schon um 1 weitergeschaltet hatte. > (Problem: Flankenrichtung und Kopplung Synchronzähler-Asynchronzähler). Klingt so, als hättest du auf die fallende Flanke von RCO getriggert. Das ist falsch. Schau in das Datenblatt des '590 (das von TI ist IMHO besser). RCO geht auf L wenn der '590 von 0xFE auf 0xFF schaltet und zurück auf H wenn er von 0xFF auf 0x00 springt. Ein asynchroner Zähler dahinter muß also mit der steigenden Flanke von RCO weiterschalten. Wenn man mehrere '590 kaskadiert, wird übrigens CCLK aller Stufen verbunden und von RCO nach CCKEN kaskadiert. > Ich hatte es damals (und so auch noch heute) mit einem MonoFlop 74123 > gelöst (200µs Verzögerung o.ä.). Das ist ein böser Würgaround... > Deine Version mit dem 7474 als "9.Bit" habe ich so aber nie hin- > bekommen? Eigentlich war der Plan, den ATmega mit QH des Vorteilers zu triggern. Das geht aber aus 2 Gründen nicht: 1. das Latch im '590 ist flankengetriggert. Selbst wenn man CCLK und RCLK verbinden würde, würde QH einen Takt zu spät updated. 2. wenn man während der laufenden Messung auf das Display schreiben will (das ist in der Entwicklungs/Debugphase extrem hilfreich), dann muß man die Ausgänge des '590 inaktiv schalten. RCO direkt an den ATmega geht aber auch nicht, weil der Impuls an RCO nur eine Periode von fx lang ist. Um den ATmega damit sicher zu triggern, dürfte fx nicht größer als der MCU-Takt sein. Da kam das zweite FF im '74 gerade recht. Freundlicherweise schaltet es auch mit der richtigen Flanke (der steigenden). Etwaige Verzögerungen durch die asynchrone Stufe (und viel mehr durch die Synchronisierung/Flankenerkennung im ATmega) sind solange unkritisch, wie man nach dem Schließen des Tors noch genügend Zeit verstreichen läßt, etwaige Interruptanforderungen reinkommen zu lassen. Die ISR für ICP1 allein ist schon lang genug, um das zu gewährleisten. Da der '590 in Hardware gesperrt wird, kann für fx kein überzähliger Interrupt kommen. Für fref hingegen schon. Wenn zwischen "Tor schließt" und dem folgenden CLI noch ein Timer1-Überlauf passiert, dann zählt fref (viel) zu weit. Deswegen macht die Capture-ISR diese Interrupt-Quelle auch zu. . .. ... und jetzt sehe ich doch eine Fehlerquelle. Wenn ICP1 genau beim Überlauf von Timer1 triggert, dann wird der Timerüberlauf übersehen (die ISR disabled & cleared das entsprechende Bit - irgendwie war ich die ganze Zeit der Meinung, der Überlauf-Interrupt wäre höher priorisiert als der Capture-Interrupt). Aber das ist leicht zu reparieren. Aus
1 | /* rising edge = gate closes */
|
2 | register uint16_t tmp= ICR1; |
3 | if (tmp < nref.w[0]) { |
4 | --nref.b[2]; |
5 | }
|
wird
1 | /* rising edge = gate closes */
|
2 | register uint16_t tmp= ICR1; |
3 | if (tmp == 0) { |
4 | ++nref.b[2]; |
5 | }
|
6 | if (tmp < nref.w[0]) { |
7 | --nref.b[2]; |
8 | }
|
also gut daß wir darüber gesprochen haben ;) XL
Ich fürchte so ist der Fehler noch nicht behoben. Es reicht wenn Überlauf und ICP fast gleichzeitig kommen, z.B. gerade bei einem RET Befehl. Damit kann ICP auch einen Wert von 1 bis etwa 4 haben, mit anderen Interrupts ggf. auch mehr. Die Prioritäten helfen einem da nicht. Es wird immer die erste ausstehende ISR aufgerufen, egal welcher Interrupt tatsächlich zu erst da war. Die Lösung die man sonst bei ICP mit Zählen der Überläufe nimmt ist es in der ICP ISR zu testen ob der ICP Wert klein ist (z.B. < 256) und gleichzeitig noch ein Overflow Interrupt aussteht (über das Interrupt Flag). Der unscharfe Begriff "klein" ist hier kein Problem: wenn der Interrupt aussteht, kann man beim ICP Register nur Werte kurz vor oder kurz nach dem Überlauf bekommen - man kann also auch 32000 als Grenze wählen.
Angehängte Dateien:
-
schematic.png
21 KB
Hallo, hier ein Update des tar.gz mit ein paar Korrekturen: 1. Software-Fix für ICP1/TOV1 Interrupts 2. Schaltplan-Fixes - pullups hinzugefügt - /pre des '74 beschaltet - Abblock-Cs hinzugefügt - an ISP waren Reset und MISO vertauscht XL
Kannst Du bitte auch die fertig kompilierte .hex-Datei in das Verzeichnis einfuegen? Das waer eine feine Sache fuer Leute, die das Geraet nachbauen wollen, aber keine C-Kenntnisse besitzen. MfG Paul
ulrich schrieb: > Ich fürchte so ist der Fehler noch nicht behoben. Es reicht wenn > Überlauf und ICP fast gleichzeitig kommen, z.B. gerade bei einem RET > Befehl. Damit kann ICP auch einen Wert von 1 bis etwa 4 haben, mit > anderen Interrupts ggf. auch mehr. Die Prioritäten helfen einem da > nicht. Es wird immer die erste ausstehende ISR aufgerufen, egal welcher > Interrupt tatsächlich zu erst da war. Oh. Du meinst, die Interrupts in den AVRs locken sich nicht gegenseitig, sondern werden nur registriert und erst wenn die CPU die aktuelle Instruktion fertig hat, wird über die Liste geschaut und der höchstpriorisierte genommen? Irgendwie geht das Manual (zumindest des mega8) nicht so weit ins Detail. Dann hast du natürlich recht. Und die Interrupt-Priorisierung in den AVRs verdient dann diesen Namen auch nicht :( > Die Lösung die man sonst bei ICP mit Zählen der Überläufe nimmt ist es > in der ICP ISR zu testen ob der ICP Wert klein ist (z.B. < 256) und > gleichzeitig noch ein Overflow Interrupt aussteht (über das Interrupt > Flag). Ja. Man würde zu allererst das Interrupt-Enable für den Überlauf zurücksetzen. Dann schauen, ob ICP1 klein ist und ein Überlauf Interrupt pending. Und in diesem Fall eine Kollision annehmen. Korrekt? ICH WILL 32-BIT TIMER! Ersatzweise eine richtige Interrupt-Priorisierung. Und am besten mit konfigurierbaren Prioritäten. Das hatte der Z8 schon! XL
und für Leute, die was anderes suchen werfe mal den Burschen rein: sn74lv8154 Gruss Klaus
Der Datenblatt ist da wirklich nicht so detailliert mit den Interrupts. Die Tücke ist dabei noch das der alte Simulator von AVRStudio die Simulation so macht das der Fehler nicht auftritt - das ist aber leider ein Fehler der Simulation. In der Hardware geht es nur nach den Flags - die Reihenfolge wird nicht gespeichert. Das ist ja auch am einfachsten zu realisieren. Bei einer früheren Version meines Zähler hatte ich ohne die Berücksichtigung diese Spezialfall einige Ausreißer. Durch das messen mehrerer (bis 255) Flanken kommt der Fehler dabei aber auch etwa 100 mal so oft vor. Mit Berüksichtigen der fast gleichzeitigen Interrupts sind die Ausreißer weg. Schon richtig verstanden: der Overflow kommt zu spät, wenn im ICP Interrupt das Flag vom Overflow Interrupt gesetzt ist, und der ICP wert klein ist. Bei dem C Programm "fm.c" für den kleinen Zähler ist das auch schon so gemacht. Wenn einem der 8 bit AVR nicht gut genug ist, könnte man z.B. auf einen dsPIC33 ausweichen. Da hat man gleich noch einen Puffer für die letzten Capture Ereignisse und verpasst so schnell keinen Wert.
Noch ne Korrektur. Jetzt mit der Interrupt-Kollisionserkennung a'la Ulrich. Und auf Wunsch eines einzelnen Herren auch die HEX-Files für Flash und EEPROM. XL
2 Kleinigkeiten sind mir bei dem Code aufgefallen: 1) Die Grenze vom 20 für den verpassten Overflow dürfte etwas knapp sein. Es macht aber nichts die Grenze auf 256 oder 32000 zu setzen - damit ist man dann auf der sicheren Seite. Bei einem Pending Overflow können Werte bis etwa 100, vielleicht auch mal 200, oder dann ganz große Werte über 65000 vorkommen. Da hat man eigentlich genug Spielraum. Die 20 werden vermutlich nicht ganz reichen, denn es kann auch der Overflow von timer0 noch dazwischen kommen. 2) Um ein Interrupt Flag zu löschen schreibt man in das Flag eine 1 schreibt, ohne verknüpfung. also statt TIFR |= _BV(TOV1); /* clear overflow interrupt */ besser TIFR = _BV(TOV1); /* clear overflow interrupt */ Ob das hier einen wirklichen Einfluss hat weiß ich nicht. Mit dem |= löscht man alle ausstehenden Timer-Interrupts. Wenn der Compiler den SBI Befehl nutzt kann es bei einigen neueren AVRs gehen - ist aber nicht schön weil vom Compiler abhängig.
Hi, ulrich schrieb: > 2 Kleinigkeiten sind mir bei dem Code aufgefallen: > > 1) > Die Grenze vom 20 für den verpassten Overflow dürfte etwas knapp sein. Hmm. Meine anderen beiden ISRs sind so kurz, wie es nur geht. Aber du hast recht, eine höhere Grenze schadet hier nicht. > 2) Um ein Interrupt Flag zu löschen schreibt man in das Flag eine 1 > schreibt, ohne verknüpfung. also statt > TIFR |= _BV(TOV1); /* clear overflow interrupt */ > besser > TIFR = _BV(TOV1); /* clear overflow interrupt */ > > Ob das hier einen wirklichen Einfluss hat weiß ich nicht. Oh doch. Das ist richtig böse. Der ICP-Interrupt kann ganz gut mit dem TOV0 Interrupt gleichzeitig kommen - das ist die selbe fx-Flanke, mit 1:512 Chance. Also nochmal geändert. Diesmal wieder als .tar.gz. Mit dem .hex XL
@ Axel
Danke für Deine Erklärungen zum 74590. Habe mir das Datenblatt
bei TI nochmal angesehen. Damals muß ich wohl doch etwas falsch
interpretiert haben. Das Monoflop fliegt jetzt bei mir raus. War
ja sowieso nur eine "halbe Sache".
Also Entwarnung auch für die anderen. Dein Konzept geht so auf.
Nochmals Gratulation!!!
Es macht schon Spaß, wenn man einen 27,1234 MHz-Quarz-Oszillator
mit 6 Dezimalteilern dahinter messen kann und immer die gleiche
Zahlenfolge auf dem Display erscheint.
27,1234 MHz
2,71234 MHz
0,271234 MHz
.
.
27,1234 Hz
Das war für mich ein wichtiges Testkriterium.
@Christian
Falls Du auf die besonders ausgefallene Idee kommen solltest,
die Leiterplatte auch fertigen zu lassen, würde ich schon mal
vorab 3 Stck. bestellen wollen.
Frage doch mal hier im Forum, wer denn da noch Interesse hätte.
@ Die Anderen
Die Diskussion um den ICP-Service ist vielleicht morgen schon
Geschichte. Ich glaube man braucht den eigentlich gar nicht.
Bin da optimistisch (ich verwende ihn zwar auch noch).
Aber man kann ja das ICR1-Register gleich nach der Toröffnung
lesen und zwischenspeichern (Polling). Danach braucht man den
ICP ja nicht mehr, weil zum Ende der Torzeit der T1-Zähler durch
die Hardware sowieso stehen bleibt und damit die echte Torzeit
berechnet werden kann.
Das wollte ich noch los werden, bevor ich jetzt diesen Rechner
hier platt mache (Betriebssystem XP spinnt fürchterlich).
Wünsche allen einen schönen 3. Advent.
Tschüß.
@Padex Die ICP-funktion nimmt einem bei der Lösung hier schon einen recht großen Teil der Hardware ab. Klar kann man das auch von Hand reallisieren (2 oder 3 weitere 74HC590),aber wozu. Die Sache mit der Interrupt-kollision kann man lösen, wenn man weiß wie der Timer genau funktioniert. Die Lösung ist vielleicht nicht so elegant wie man es auf den ersten Blick hofft, aber es funktioniert zuverlässig, ohne irgendwelche zeitkritischen Flanken. Mit dem Ende der Torzeit bleibt der Timer 0 stehen, nicht Timer 1 - der läuft weiter mit den µC Takt. Man könnt beim Start mit einem Externen Interrupt arbeiten und erst dann den Timer Starten - mit einer definierten Antwortzeit aus dem Sleep Mode geht da auch auf den Zyklus genau, wenn auch umständlich. Für das Ende der Messung wird das aber schwer bis unmöglich es so abzupassen, das einem da nicht gerade ein Interrupt dazwischen kommt. Wozu auch der Umstand, wenn der µC die passende ICP Hardware hat. Es gibt sogar die Alternative noch mehr Funktionen in den µC zu verlagern, mit nur einem einfachen Vorteiler extern - das Ergebnis ist im wesentlichen das selbe, nur halt mit mehr Aufwand für die Software und weniger Hardware. Für Frequenzen bis etwa 140 kHz kann das der Mega8 auch ganz ohne externe Logic. Halt die Lösung von http://www.mino-elektronik.de/fmeter/fm_software.htm In ASM geht es dann ggf. noch etwas schneller (ca. 300 kHz).
Hi wollte schon welche fertigen lassen von den Platinen. Werde noch ein paar Fehler im Schaltplan und Platine korrigieren. Und mich mal um die böse Massefläche kümmern :-) Heute Nacht geht's weiter. Falls jemand noch die Eagle Dateien braucht nur sagen. Ich selber werde so 10Stück brauchen, eigenen sich ja fast für alles. (Drehzahlmesser, HF Gedöns, usw.) Wenn also jemand auch welche will nur Bescheid geben. Schrotti
Hi Schrotti, danke f. das Angebot der Eagle Datein, poste sie doch mal, i werde das teil bei gelegenheit auch mal bauen aber in SMD vlG Charly
Hallo, und noch eine Korrektur. Beim Testen mit sehr niedrigen Frequenzen (<1.5Hz, da hörte mein Test-Generator gerade auf) habe ich noch einen Bug in der Divisionsroutine gefunden. Wenn der Divisor sehr groß wurde, konnte es einen unbemerkten Überlauf geben. Außerdem habe ich noch die Anzeige in mHz dazugebaut. Unterhalb von 1Hz wird jetzt 987.654mHz angezeigt (vorher 0.98765Hz - also eine Stelle verschenkt für die führende 0). Die letzte Änderung rechtfertigt IMO einen Versionssprung auf 1.3 :) Das .tar.gz enthält wie üblich alle Files, inclusive .hex und .eep XL
Angehängte Dateien:
-
Masse.PNG
8,5 KB
So bitte schön. Wobei ich gemerkt habe das meine Massefläche doch recht zerstückelt ist ... Doch mal in SMD machen, habe ja noch Zeit bis Morgen. Schrotti
Als SMD wird das mit der Massefläche nicht unbedingt besser. Man hat sogar eher weniger Platz zur Verfügung um die Leitungen zu sortieren. So schlimm sieht das doch noch nicht mal aus - die paar wirklich schlimmen stellen sollten sich beheben lassen ( z.B. der Kondensator an GND/VCC des µC). Was etwas helfen würde, wäre einiger der Ablockkondensatoren in SMD, auf der Unterseite zu haben. Die Mischung SMD und bedrahtet ist im Hobby-bereich kein Problem - lässt sich nur nicht gut maschinell löten. Der einzig kristische Teil ist der Quarz mit den Verbindungen. Der Rest ist Digital.
@Ralph Berres (rberres) Auf der mino-Seite mit dem Beispielprogramm befindet sich eine Datei fmeter20.zip. Wenn Deu einen tiny2313 programmieren kannst, hast Du gewonnen. Mehr kann man für kein Geld nicht erwarten ;-)
m.n. schrieb: > Wenn Deu einen tiny2313 programmieren kannst, hast Du > > gewonnen. Leider habe ich für keines der Singlechip Prozessoren weder eine Möglichkeit vorhandene Firmware in den Prozessor zu laden, noch Programme zu erstellen, da das erstellen von Programme nicht meine Welt ist. Ralph Berres
@Christian Scharrer: Bei Platinen (DK + Lötstoplack) bin ich gerne mit 1-2 je nach Preis dabei. Ich könnte die alternativ auch anfertigen lassen.. Ca. 6-7€/Stück bei 20 Stück. Danke, Peter
>Leider habe ich für keines ...
Gut, nur falls Du einen single-chip Frequenzzähler brauchen solltest,
weißt du jetzt wo ;-)
40 MHz sind schon relativ optimistisch für einen 74HC590. Für eine hohe Frequenz müsste man da ggf. eher nach der AHC, VHC Version suchen. Wenn das Layout bei den Abblockkondensatoren Probleme macht, notfalls einen bedrahteten Kondensator direkt zwischen die Pins, auf die Unterseite löten. Nicht schön, aber dafür der direkte Weg. Es gibt sonst auch spezielle Sockel wo der Kondensator schon drin ist.
Ok werde noch mal das Layout überarbeiten. Wenn keiner was dagegen hat wegs SMD bestücken werde ich mal die Kondensatoren auf die Rückseite legen. @Peter Sieg: Hört sich gut an. So 30 Stück werdens schon werden :-) mh brauch ich dann ne andere Eagle Lizenz ? Schrotti
ulrich schrieb: > 40 MHz sind schon relativ optimistisch für einen 74HC590. Ja. Sowohl für den HC74 als auch für den HC590 gibt das Datenblatt fmax mit ca. 35MHz an (je nach Hersteller leicht verschieden). Im Test haben beide 40MHz Oszillatoren, die ich gerade da hatte, sofort funktioniert. Und das mit fliegendem Anschluß (1m Meßstrippe quer über den Tisch). Mit 64MHz passierte dann nix mehr. Zumindest der HC74 scheint das dann nicht mehr zu mögen. > Für eine hohe Frequenz müsste man da ggf. eher nach der AHC, VHC Version suchen. Scheint es nicht zu geben. Noch nicht mal als 74AC :( Man könnte das ja umdesignen. Wenn man das LCD im 4-Bit-Modus anspricht, bekommt man 4 Pins für den Direktanschluß des Vorteilers. OE braucht man dann nicht. Macht Pin #5. Mit fx hätte man dann 6 Pins für den Vorteiler. Bräuchte man einen schnellen Zähler >=6 Bits mit Clock-Enable und Reset. Gibts das? XL
danke Scrotti f. die files, f. meinen Geschmack fehlt da noch ein HF-Vorverstaeker um auch kleine Signale messen zu koennen (event. dahinter ein 74F74, geht bis ueber 100Mhz) viel spass & erfolg beim layouten vlg Charly
Es fehlt ein Vorverstärker und vor allem noch so etwas wie ein Schmidt-trigger für die Wandlung von einem potentiell analogem Signal auf einen sauberes Rechtecksignal. Für einen einfachen Zähler reicht das so ja auch. Man sollte nur wissen das die 40 MHz nicht sicher sind und sich nicht wundern wenn es da nicht mehr geht. Für die wirklich hohen Frequenzen könnte man einen Teiler ggf. auch einfach vor die ganze Schaltung schleifen. Man verliert ja nichts an Auflösung, nur die ganz niedrigen Frequenzen gehen dann nicht mehr. Das einzige wäre, das der µC weiß ob der Vorteiler drin ist oder nicht - ggf. könnte der µC den Teiler auch bei Bedarf abschalten kann (erst mit Teiler messen, wenn nach etwa 1/100 s noch keine Pulse ankommen, kann der Teiler sicher raus). Wenn man akzeptiert das der µC je nach Frequenz den Vorteiler an oder abschaltet, kann man eigentlich auch auf den externen Auslesbaren Zähler und die Flipflops verzichten - bis etwa 100 kHz (in ASM ggf. auch etwa 400 kHz) kriegt der µC die Messung auch ohne externe Logic genauso gut hin. Wenn man will sogar etwas besser.
War in der gleichen Schaltungssammlung nicht auch ein Eingangsverstärker drin? Mit einstellbarem Triggerpegel, schaltbaren 10:1-Vorteiler und 2 LEDs zur Pegelanzeige? Eingangsstufe KP303, alternativ BF245. Den Triggerpegel (war per Poti reine Gleichspannung) könnte man ja gleich noch auf dem Display anzeigen. Wenn dann noch ein (auch ungenaues) NF-/HF-"Millivoltmeter" per Diodengleichrichtung dabei wäre, inclusive Anzeige auf dem Display, wäre das Modul perfekt. Ein (automatisch) schaltbarer 2:1- oder 4:1-Teiler mit 74F74 reicht doch schon bis 70MHz oder weit über 100MHz. Blackbird
Advent Advent ein Lichtlein brennt! Mir ist gestern noch ein Licht aufgegangen und hoffe, daß es nicht gleich wieder ausgeht. Habe mir das MINO-Teil mal näher angesehen. http://www.mino-elektronik.de/fmeter/fmeter.htm Scheint auch ein sehr schönes Projekt zu sein. Ich favorisiere aber doch die Lösung von Axel. Thema: Auflösung und Genauigkeit. Wenn man mal den metrologischen Fehler (nicht meteorologisch) der Zeitbasis außen vor läßt, verhalten sich beide Konzepte bis Meßfrequenz < 1/Zeitbasis wahrscheinlich gleich. Oberhalb der "ZeitbasisFrequenz" kommt der Vorteiler ins Spiel. Das heißt die Inkremente des Vorteilers gehen bei der Meßfrequenz- berechnung mit in das Ergebnis ein. Bei dem MINO-Konzept kann der Stand des Vorteilers keinen Beitrag zur Erhöhung der Auflösung leisten. Anders bei Axels Lösung. Würde man in beiden Fällen von einer Taktfrequenz (Zeitbasis) von 10 MHz ausgehen, so wäre Axels Lösung um den Faktor 4 (bei Grenzfrequenz des 74590 von 40 MHz) besser. Vielleicht sogar um den Faktor 8, wenn man alle sytema- tischen Fehler in Betracht zieht (IMHO). Das "Ankratzen" der 7.Stelle (mehr schafft man mit "float" nicht), ist realistischer. So! Aber wofür braucht man schon solch einen "genauen" Zähler? Nennt mal Beispiele! 1. Filterquarze genau ausmessen 2. Oszillatordrift (Temparaturabhängigkeit, Kurzzeitstabilität) bestimmen. 3. LOL Rhubidium-Normal nachmessen ulrich schrieb: > Mit dem Ende der Torzeit bleibt der Timer 0 stehen, nicht Timer 1 - der > > läuft weiter mit den µC Takt. Da hast Du völlig Recht. Axel mach bitte weiter. Der Fred ist noch heiß. mfg Padex.
@Padex: >Bei dem MINO-Konzept kann der Stand des Vorteilers keinen Beitrag zur >Erhöhung der Auflösung leisten. Wozu auch? Zum Zeitpunkt der Auswertung hat er immer den gleichen Wert ;-) >Würde man in beiden Fällen von >einer Taktfrequenz (Zeitbasis) von 10 MHz ausgehen, so wäre Axels >Lösung um den Faktor 4 (bei Grenzfrequenz des 74590 von 40 MHz) >besser. Vielleicht sogar um den Faktor 8, wenn man alle sytema- >tischen Fehler in Betracht zieht (IMHO). Irrtum! Selbst, wenn man den Vorteiler auf 1GHz (Traum-Chip:74GAS590) auslegen und verrechen würde, würde die Messung nie genauer oder "aufgelöster", als durch Fref 10MHz vorgegeben ;-) Mit den Lichtern nimm Dir noch mehr Zeit, dann brennen bald noch mehr. Aber pass gut auf den Baum auf ;-)
Padex schrieb: > 3. LOL Rhubidium-Normal nachmessen Mit einen 6 oder bestenfalls 7stelligen Counter? Also ein Rubidiumnormal ist wenigstens mal auf 10 Stellen genau und stabil. Selbst wenn er total daneben liegt ist er immer noch auf 9 Stellen genau. Schon ein Abgleich eines schnöden 70cm SSB/CW Transceiver ist schon mindestens 7 Stellen Genauigkeit erforderlich. Ralph Berres
Von der Auflösung nehmen sich die beiden Verfahren so nichts. Der eventuelle Vorteiler legt nur fest das man als "Torzeit" vielfache von z.B. 256 Perioden des Signlas nutzt. Eine wesentliche Einschränkung ist das nicht. Eher hat man da bei der Lösung mit dem HC590 eine minimale Gefahr den Start genau zur falschen Zeit zu machen und so einen Metastabilen Zustand beim 74HC74 zu treffen. Der Synchronisation im µC würde ich da eher mehr trauen. Bei der Hardwarelösung von Mino (erweitert um einen zuschaltbaren Vorteiler) hat man aber die Möglichkeit eine etwa höhere Auflösung zu erreichen indem man auch die Zeit der Flanken während der Torzeit nutzt. Neben der höheren Auflösung, die eher theoretischer Natur ist, hat man da vor allem den Vorteil dass man weniger empfindlich auf Jitter ist. Ich habe einen Zähler nach dem Verfahren, und könnte auch den Code (ASM auf Tiny2313) dazu zur Verfügung stellen. Es sind aber noch ein paar Macken in der Bedienung drin und die Anzeige läuft über 7-seg. LEDs mit externem Decoder. Ein LCD wäre aber deutlich besser, schon um anzuzeigen was man eigentlich misst, und ein Mega88 wäre auch besser geeigent als der doch etwas kleine Tiny2313.
>Aber wofür braucht man schon solch einen "genauen" Zähler? In der "Bastelpraxis" ist es damit, wie mit einem Multimeter mit automatischer Bereichsumschaltung: Meßspitze anlegen - Ergebnis mit bester Auflösung ablesen. Alle Meßgrößen, die sich als Frequenz darstellen, können optimal erfaßt werden. Zum Beispiel Drehzahl (magn. oder opt. Sensor), (Wind-, Wasser-)Geschwindigkeit über Drehsensor, Ticken (Optosensor) einer mechanischen Uhr. Sofern ein entfernter Sensor kostengünstig ausgelesen werden soll, kann man sein Signal in eine (Nieder-)Frequenz wandeln, über lange Strecken "transportieren" und erfassen. Oder man baut mit einem NTC einen Oszillator auf, dessen Frequenz die Temperatur wiederspiegelt; oder ein LC-Kreis wird durch Abstandsänderung verstimmt. Oder man schaltet seinem Funktionsgenerator eine Frequenzmesser dazu: die Frequenz wird immer optimal angezeigt. Drehzahlen von langsamen Motoren z.B. 10U/min: alle 6 Sekunden ein Ergebnis. Geräte dieser Art baue ich seit Jahrzehnten. Seinerzeit ging es darum, Tonruffrequenzgeber schnell abzugleichen. Oder Kraftwerke brauchten die genaue Frequenz ihrer Funktionsgeneratoren (50Hz), um damit ihre Frequenzrelais zu überprüfen. Mein rezipr. Zähler mit 13MHz TCXO wurde für physikalische Exp. verwendet. Gerne habe ich immer Uhrenbausteine PCF8563/PCF8583 am Sekundenausgang gemessen, um die genaue Frequenz einzustellen (Trimmkondensator). Wenn 1.000000Hz und 1.000000s angezeigt wurden, war alles in Ordnung: jede Sekunde ein neues Ergebnis. Mit der mino-Schaltung lassen sich 200 Messungen/s machen (5-stellig) und an einen übergeordenten µC übertragen (38400Bd). Damit lassen sich Frequenzänderungen in kurzer Zeit erfassen und auswerten. Tonfrequenzsignale, die nur als Burst (10ms) auftauchen, können detektiert werden. Wer will, kann sich die Kurzzeitdrift der Netzfrequenz protokollieren: jede einzelne Schwingung. Und was braucht man für all das minimal? 1 x Tiny2313, 2 x Cs 18pF, 1 x Quarz 20MHz und 1 x C 100nF zum Abblocken der Versorgungsspannung. Billiger und einfacher kann man Sensoren meines Erachtens nicht auswerten. Eigentlich wollte ich mich zurückhalten und bin jetzt doch gechwätzig geworden.
Blackbird schrieb: > War in der gleichen Schaltungssammlung nicht auch ein Eingangsverstärker > drin? Mit einstellbarem Triggerpegel, schaltbaren 10:1-Vorteiler und 2 > LEDs zur Pegelanzeige? Eingangsstufe KP303, alternativ BF245. Danke für den Denkanstoß! In meinem vor 20 Jahren gebauten Zähler steckt genau dieser Vorverstärker drin. Ich habe den Schaltplan nicht mehr in meinen Unterlagen gefunden, aber dank Raupenhaus isser wieder da!! Nicht in der gleichen Sammlung, sondern in der vierten von 1986, Kapitel 3-1 "Vorverstärker für digitale Zähler".
Angehängte Dateien:
-
board-smd.png
35 KB
So habe nun die Platinen auf einen Teil SMD und Bohrlöcher umgestellt. Sowie die Designrules von Bilex benutzt. Wenn keiner mehr einen Schnitzer findet, werde ich mal einen Prototypen ätzen. Schrotti
Hi Schrotti, sorry, i konnts nicht lassen ;) hab a bissel geaendert, meiste bahnen nach unten (besser f. den 'selbstaetzer') auf beide seiten ein Polygon, weniger aetmittelverbrauch und gleichmaessigeres aetzen (und weniger Abfall) ein paar DK's zum festloeten des Quarzes, ach was, schaus dir einfach mal an vlg Charly
Hi Charly schaut gut aus :-) Auf die 2 Layer wäre ich net gekommen. Werde mal morgen ein bischen Ätzen. Ähm und Teile bestellen... Schrotti
So Prototype wird noch ein bischen dauern :-( Habe keine Platinen mehr daheim. Heute erst bestellt. Schrotti
Hab heut grad mal rein geschaut: Ist es Absicht, das AREF mit AVCC verknotet ist??
Jörn Paschedag schrieb: > Hab heut grad mal rein geschaut: Ist es Absicht, das AREF mit AVCC > verknotet ist?? Ja
m.n. schrieb: > Auf der mino-Seite mit dem Beispielprogramm befindet sich eine Datei > fmeter20.zip. Wenn Deu einen tiny2313 programmieren kannst, hast Du > gewonnen. 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. > Mehr kann man für kein Geld nicht erwarten ;-) Genau, bleibt nur noch ein Eingangsverstärker für den jeweiligen Anwendungsbereich als Pflichtübung. Wahrscheinlich werde ich folgende Eingangsstufen aufbauen: http://liebl-net.dtdns.net/hard/frequ_counter/frequ_counter.gif Im Service Manual zum PM6685 ist eine Eingangsstufe mit einstellbaren Trigger-Leveln beschrieben: http://assets.fluke.com/manuals/PM6685__smeng0000.pdf Christian.
Hallo Christian, ich habe mich gerade auch in das Projekt eingelesen und es gefällt mir besser als meine bisherige Baustelle: Beitrag "Re: Reziproker Frequenzzähler+ Optimierte 64bit uint Routinen" Ich hab verschieden Vorteiler und HF-Verstärker im Einsatz - MB510 (2,7GHz) und einem - U6064BS bis 1.2GHz. Ein Fet dient als hochohmige Pufferstuffe und alle HF-Signale laufen über einen 74HC132, der als Schmitttrigger und Eingangsselektor geschaltet ist. Mit einem Johnson-Counter 74HC74 forme ich ein 50:50 Signal mit einem /4 Vorteiler. http://www.qrpforum.de/index.php?page=Thread&postID=46013#post46013 http://www.multiforum.se/afu/viewtopic.php?p=3625&mforum=afu#3625 Zum 20-MHz-TCXO, leider gibt die aktuelle Firmware einen Fehler aus, das liegt an diesem Code
1 | #if F_CPU > (16*1024*1024-512) |
2 | #error "F_CPU is too big! Must fit in 24 bits" |
3 | #endif |
Wobei natürlich eine Änderung auf 20UL*1024*1024 dann funktioniert. Ein Problem macht auch noch in lcd.c diese Zeile,
1 | int long __count |
in der Funktion _delayFourCycles. Meine Änderung:
1 | # neu 2011-01-03 |
2 | static inline void _delayFourCycles(unsigned long __count) |
Für mich stellt sich noch die Frage, ob wir den Code noch auf den atMega48 portieren, da die atMega8PU-16 Preise stark ansteigen. Meine letzten kommen aus Polen. 73, Uwe
Habe mal über das smd Layout geschaut und da ist mir aufgefallen, dass die smd Kondensatoren C8, C10 und C11 unter dem Mega8 nur einseitig angeschlossen sind. Ich denke mal da fehlt noch der GND Anschluß. Günter
Hallo Uwe, Uwe S. schrieb: > ich habe mich gerade auch in das Projekt eingelesen und es gefällt mir > besser als meine bisherige Baustelle: > Zum 20-MHz-TCXO, leider gibt die aktuelle Firmware einen Fehler aus, das > liegt an diesem Code >
1 | > #if F_CPU > (16*1024*1024-512) |
2 | > #error "F_CPU is too big! Must fit in 24 bits" |
3 | > #endif |
4 | > |
> > Wobei natürlich eine Änderung auf 20UL*1024*1024 dann funktioniert. > > Ein Problem macht auch noch in lcd.c diese Zeile, >
1 | int long __count |
in der Funktion _delayFourCycles. > > Meine Änderung: >
1 | > # neu 2011-01-03 |
2 | > static inline void _delayFourCycles(unsigned long __count) |
3 | > |
> > Für mich stellt sich noch die Frage, ob wir den Code noch auf den > atMega48 portieren, da die atMega8PU-16 Preise stark ansteigen. Ich bezog mich eigentlich auf den hier zwischendrin genannten Zähler von MiNo: Beitrag "Re: Frequenzzähler 1Hz - 40MHz" http://www.mino-elektronik.de/fmeter/fmeter.htm http://www.mino-elektronik.de/download/fmeter20.zip Für diesen Zähler gibt es keinen Quellcode, nur eine fertige HEX-Datei für den ATtiny2313. Lediglich von einem rudimentären Beispiel gibt es den Quellcode. Aber irgendwie muß MiNo ja seine Brötchen verdienen ;-) In Bezug auf die Quelloffenheit und Erweiterbarkeit ist Axels Projekt vorzuziehen. Allein die zusätzliche äußere Zählerlogik mit dem 74HC590 hat mich bisher von einem kurzfristigen Nachbau abgehalten. Christian.
Auch bei den anderen smd Kondensatoren C1-C5 fehlt ein Anschluß ... ist das so richtig???? Günter
Hallo, ja da haben wir uns missverstanden. Ich benötige ja auch noch dein 2-Kanal Modus der u.a. auch die ZF-Messung und die automatische Verrechnung zulässt. darüber hinaus werde ich noch die verschiedene Vorteilerfaktoren meiner Vorteiler einbauen. .
Hallo Uwe, Uwe S. schrieb: > > ich habe mich gerade auch in das Projekt eingelesen und es gefällt mir > besser als meine bisherige Baustelle: Danke :) > Zum 20-MHz-TCXO, leider gibt die aktuelle Firmware einen Fehler aus, das > liegt an diesem Code
1 | > #if F_CPU > (16*1024*1024-512) |
2 | > #error "F_CPU is too big! Must fit in 24 bits" |
3 | > #endif |
> Wobei natürlich eine Änderung auf 20UL*1024*1024 dann funktioniert. Naja. Obiger Code steht da nicht ohne Grund. Die Arithmetik-Routinen sind so weit zusammengestrichen, daß f_ref, n_ref und n_x jeweils maximal 24 bit lang sein dürfen. Wenn du da größere Zahlen reinfüllst, kommt nach der Rechnung Müll raus. Konkret rechnet die Firmware dann statt f_ref*n_x/n_ref mit (f_ref % 2^24)*n_x/n_ref. Es wäre wohl sinnvoller, das TCXO-Signal durch einen 2:1 Teiler zu schicken. Der Genauigkeit tut das keinen Abbruch, und ob du nun 2.5 Messungen pro Sekunde oder 5 Messungen pro Sekunde bekommst, dürfte für mit den Augen abgelesene Werte auch egal sein. Zumal da ohnehin noch ein Sicherheitsfaktor von 4 drin ist. > Für mich stellt sich noch die Frage, ob wir den Code noch auf den > atMega48 portieren, da die atMega8PU-16 Preise stark ansteigen. Das sollte wiederum kein Problem sein. Obs viel bringt? Bei Reichelt derzeit EUR 2,45 : 2,95 (Mega48-20 vs. Mega8-16, DIP) bzw. EUR 2,20 : 2,40. Wenn ich die Tage mal Zeit habe (wird aber wohl eher erst im Feb) dann stricke ich mal die Erweiterung für ein 2x16 Display. Das kann dann Frequenz und Periodendauer gleichzeitig anzeigen. XL
Günter N. schrieb: > Auch bei den anderen smd Kondensatoren C1-C5 fehlt ein Anschluß ... > ist das so richtig???? moin moin Günter tipp mal in der Commandozeile nach dem laden des Boards: rats <enter> vlG Charly
> moin moin Günter > tipp mal in der Commandozeile nach dem laden des Boards: > > rats <enter> OK das wars ..... alles in Ordnung
@alle: Auf Basis smd2.brd (37,5 x 86,6 mm) würden 2-lagige Platinen mit Lötstoplack, verzinnt, durchkontaktiert und elektrisch geprüft in etwa kosten: Stück Einzelpreis € 20 7 40 4 Falls das dann mal interessant werden sollte.. bitte Mail. Und dann sollten wir auch mind. einen Artikel zusammen stellen, in dem Schaltplan, Board, Teileliste etc. zusammen gefasst sind. Gruß, Peter
@Peter & @alle ;) meine Meinung : zum mal bissel Spielen ok aber f. meine Vorstellung fehlt da ein Vorverstaerker und ein Vorteiler f. min. 1.3Ghz oder besser 2.5Ghz & sonst noch paar kleinigkeiten. Leider hab i im moment nicht die Zeit daran weiterzumachen, lese hier aber immer gerne mit vlG Charly
Moin, Charly B. schrieb: > @Peter & @alle ;) > > meine Meinung : zum mal bissel Spielen ok aber > f. meine Vorstellung fehlt da ein Vorverstaerker > und ein Vorteiler f. min. 1.3Ghz oder besser > 2.5Ghz & sonst noch paar kleinigkeiten. Was Vorverstärker/Trigger und Vorteiler angeht: ja, für einen vollständigen Frequenzzähler fehlt das sicher noch. Wobei man den Vorteiler dann sicher auch umschaltbar haben wöllte (bzw. gleich mehrere Eingänge umschaltbar, einen davon mit GHz-Vorteiler). Beides geht jedoch über den geplanten Umfang des Projekts hinaus. Was ich haben wollte, ist ein Modul ähnlich wie ein LCD-Panelmeter, das man an Versorgung und Signal anschließt und ansonsten als eigenständiges Modul ansieht. Ähnlich wie bei einem Panelmeter muß man das Signal passend konditionieren. Auf meinem Prototypen gibts es dafür die Lochrasterfelder, um noch ein paar Kleinigkeiten auf dem Modul unterbringen zu können. Ursprünglich angedachte Einsatzgebiete sind Funktionsgeneratoren oder Grid-Dipper, wo man ohnehin bereits anständig Pegel hat und bestenfalls noch von Sinus auf Rechteck aufpusten muß. Ein guter Vorverstärker/Trigger braucht allein vermutlich etwa soviel Platz wie das ganze Modul. Immerhin wird man schaltbare Abschwächung, schaltbare AC/DC Kopplung, zuschaltbaren Hoch-/Tiefpaß (ersteren z.B. gegen Netzbrumm), einstellbare Triggerschwelle, Pegelanzeige etc. haben wollen. Ansonsten hatte ich letztens noch ein paar Ideen für Erweiterungen. Insbesondere braucht die Schaltung noch ein paar Hardware-Konfigurations-Optionen. Sei es als Jumper oder als Anschluß für externe Schalter (etwa, um einen Vorteiler 64:1 anzukündigen). Wie es aussieht, werde ich die 8 Leitungen "Datenbus" über 4.7k Widerlinge an eine 8x2 Stiftleiste führen für Jumper und/oder externe Schalter. Zumindest das sollte auf eine Platine noch drauf. Als schaltbare Optionen sind mir eingefallen: - Anzeige umschalten zwischen Frequenz und Periodendauer (bei einzeiligem Display). - Berücksichtigung eines festen Vorteilers; evtl. mehrere Jumper für feste Faktoren. Alternativ nur ein Jumper und den Vorteiler-Faktor im EEPROM. - Berücksichtigung eines Offsets (etwa ZF in einem Funkempfänger). Hier würde der Wert wohl am besten im EEPROM stehen. Weitere Ideen/Wünsche? XL
Angehängte Dateien:
-
preamplifier.png
7,5 KB
Hallo Axel und Mitleser, ich habe mich als Frequenzanzeige für eine 8-stellige 7 Segment LED Anzeige entschieden. Dafür habe ich heute die Platine fertig layoutet. Das kann extern an den Frequenzzähler angeschlossen werden ! Warum? ich stehe auch auf 'oldstyle' und großen Displays, die von weitem gut lesbar sind. Menüfunktionen etc. werden weiter über das LCD Display angezeigt. atMega*8, kann mit internem oder externen Quarz betrieben werden. Die 8-stellige LED-Anzeige wird im Multiplex betrieben und alle 1ms eine neue Stelle angezeigt. Zur Ansteuerung werde ich eine Schnittstelle über i2c und RS232 programmieren. Die eigentliche Frequenzmessung erfolgt dann mit dem atMega8, die Schaltung wurde hier vorgestellt. Er erhält noch einen Eingangsumschalter über einen 74HC132, als Vorteiler (prescaler) verwende ich den U6064BS 1,1GHz(1:64), den MB510 2,7GHz (1:128/256) und eine hochohmige Eingangsschaltung nach "preamplifier.png". Erwähnt werden sollte auch der U813BS (FA). Mit zwei Kanälen kann man die ZF dirkt messen und per +/- mit der gemessenen Frequenz verrechnen. Bei mir kommen die Vorteiler und Anpassverstärker (FET BF245/ J310, HF-Transistor BF199) alle in ein Weisblechgehäuse, so HF-gerecht 'verpackt' werden sie über den Eingangsumschalter (74HC132) per Software ausgewählt.
Der Schaltplan aus der ELV ist eher ein Beispiel wie man es besser nicht macht: - Ein kleines TTL-Grab für Funktionen die viele der µCs auch intern übernehmen können. - direkter Abgriff des Taktsignals vom Oszillator zur Gate Schaltung
Hallo Ulrich, ja eher als Übersicht über verschiedene Eingangsbeschaltungen.
Ulirch schrieb: > Der Schaltplan aus der ELV ist eher ein Beispiel wie man es besser nicht > macht: > - Ein kleines TTL-Grab für Funktionen die viele der µCs auch intern > übernehmen können. Welche MCU kann bis zu 50MHz an den Ports verarbeiten? Das TTL-Grab ist schon in Ordnung. Als Alternative steckt man das Ganze in eine CPLD.
Nachtrag: Bemängeln möchte ich die Vorverstäker, man wird jede Menge Ersatzdioden benötigen, weil man durch zu hohen Signalpegel wieder welche zerschossen hat.
Axel Schwenke schrieb: > Moin, > > > Beides geht jedoch über den geplanten Umfang des Projekts hinaus. Was > ich haben wollte, ist ein Modul ähnlich wie ein LCD-Panelmeter, das man > an Versorgung und Signal anschließt und ansonsten als eigenständiges > Modul ansieht. Ähnlich wie bei einem Panelmeter muß man das Signal > passend konditionieren. Auf meinem Prototypen gibts es dafür die > Lochrasterfelder, um noch ein paar Kleinigkeiten auf dem Modul > unterbringen zu können. > Hallo Axel, das ist genau das was ich suche und auch genau für diesen Einsatzzweck. Ein einfaches Zählermodul bis ca. 50MHz! Echte (industrielle) Frequenzzähler habe ich im Dutzend hier stehen, sowas bau ich schon lange nicht mehr selber (der letzte war zu DDR-Zeiten bis 150MHz und der tuts auch noch). Doch für einfache Dinge nehme ich gerne kleine einfache Handgeräte, z.B. einfacher HF-Generator mit LTC1799 (nach Nussbaum). Der reicht für vieles aus, da brauche ich nicht den alten Marconi-Messender (2017) auf den Tisch zu wuchten ;-) Also, herzlichen Dank und bitte genau so weiter machen! Gruß Old-Papa
@all Sorry das es längergedauert hat mit Prototypen bauen. (kaltes Wetter, Rohrbruch, Bastelkeller überschwemmt, grrr) So ab nächste Woche werde ich wieder weiter machen können. Schrotti
Falls die Platinen noch nicht geätzt sind: Es hat schon seinen Grund, warum die Hersteller von Controllern mit eingebautem Oszillator direkt neben den Resonator-Pins immer auch einen Masseanschluss hinsetzen (schon mal jemandem aufgefallen?), denn genau dahin sollen dann auf möglichst kurzem Weg die Masseanschlüsse der Lastkapazitäten des Resonators angeschlossen werden. Gründe und Vorschläge wie man's machen kann findet man z.B. hier: http://www.lothar-miller.de/s9y/categories/33-Quarz
Freies Elektron schrieb: > Welche MCU kann bis zu 50MHz an den Ports verarbeiten? Das ist (zumindest bei den PICs) kein Problem, das schafft sogar der uralte PIC16F84 ohne externen Vorteiler. Siehe http://sprut.de/electronic/pic/projekte/frequenz/freq.htm
Uwe S. schrieb: > Warum? ich stehe auch auf 'oldstyle' und großen Displays, die von weitem > gut lesbar sind. Echt "oldstyle" nenn ich DAS: http://www.pambor.de/Pics/Resize%20of%20DCFCNT_Total.JPG
Dirk W. schrieb: > Freies Elektron schrieb: >> Welche MCU kann bis zu 50MHz an den Ports verarbeiten? > > Das ist (zumindest bei den PICs) kein Problem, das schafft sogar der > uralte PIC16F84 ohne externen Vorteiler. Siehe > http://sprut.de/electronic/pic/projekte/frequenz/freq.htm Da schmeisst du was durcheinander. Die 50MHz Messfrequenz werden im sprut-Zähler in den Timer0 eingezählt. Bastlerweise soll das funktionieren, ich nehme aber an, dass das ausserhalb der Specs ist. Das von dir kritisierte TTL-Grab im E.L.V.-Zähler lässt sich jedoch nicht über die Portpins einer MCU realisieren. Denn, welcher Portpin kann schon 50MHz toggeln?
Nur mal so als kleine Frage: Der Datenbus im Datenblatt, bedeutet das das LCD und der 590 am den gleichen Portpins hängt?
Ganz lässt sich das TTL grab vielleicht nicht so einfach durch einen µC ersetzen - mit einem Vorteiler (z.B. : 256) ist es dann aber kein Problem mehr. Ein DsPic33 wäre zumindest dich dran an den 50 MHz: da sind mindestens je 10 ns für die High und low Phase vorgeschrieben für den ICP Pin mit internem Vorteiler. Für 40-45 MHz sollte das dann schon reichen. Ähnlich ist das wohl auch bei einigen PIC16. Die 50 MHz sind schon etwa die Grenze der Spezifikation. Das erste was damit gemacht wird ist ja das Teilen, und das geht noch asynchron.
Moin, Rene K. schrieb: > Der Datenbus im Datenblatt, bedeutet das > das LCD und der 590 am den gleichen Portpins hängt? Ja. 8 Pins des Mega8 bilden einen Datenbus für die Peripherie. [PC0-PC4,PD5-PD7] = [D0-D7] = [QA-QH] XL
Angehängte Dateien:
-
05-7-seg-led-anzeige.jpg
260 KB
Hallo Axel und Mitleser, meine LED Anzeige ist nun fertig aufgebaut und die Ansteuerung per RS232 läuft. Die I2C Schnittstelle ist belegt, nun folgt nur noch das kleine Programm zur Ansteuerung. Für die Erstellung verschiedener Tasks verwende ich cocoOS 2.1.0 mit einigen kleinen Anpassungen, die die codegröße verringern. Link: http://www.cocoos.net/ Ein Watch-Doc-Timer mit max. 60ms sorgt für einen reibungslosen Betrieb, wenn doch mal ein Task hängen sollte.
Nachtrag, Im Anhang findet ihr noch die "main.c" Datei, um sich einen Vorstellung für das cocoOS machen zu können.
Moin Uwe, Uwe S. schrieb: > meine LED Anzeige ist nun fertig aufgebaut und die Ansteuerung per RS232 > läuft. Schicke Platine. Aber irgendwie scheinen deine Displays keinen Dezimalpunkt zu haben. Bzw. nicht in jeder Stelle. Zur Anzeige einer Dezimalzahl sind sie also eher nicht zu gebrauchen. XL
Guten morgen Axel, doch einige sind da, aber die LED-Anzeige kann man ja wechseln. Für meine Anwendungen reicht diese Darstellung aus: "99.765.431" Hz oder so etwas: "2.700123,0" GHz. Ok?
Hallo, ich habe das Ganze mal in Hardware aufgebaut und leider massive Probleme. Zunächst startet das Ganze andauernd neu, ein Muster ist dabei nicht wirklich erkennbar. Mal erfolgt der Neustart, wenn ich die Eingangsfrequenz (also die zu messende) verändere, mal einfach so (weil in China nen Sack Reis...). Ich verwende die Platine "smd2.brd", die ich nachgezeichnet habe. Alle Leitungen sind mehrfach durchgeklingelt, alle Verbindungen genau so wie im Schaltplan (smd2.sch) beschrieben. Je nach angestöpseltem Display werden mal die meisten Zeichen richtig dargestellt, bei einem anderen Modell erscheinen schonmal ulkige Buchstaben-Ziffern-Kombinationen ohne jeden Sinn. Das aber auch nicht immer, manchmal gehen die wieder richtig. Verwendet habe ich mehrere Modelle 1x16 (alle mit dem HD-44780), aber zum Test auch mit 2x16 Zeichen. Das von Axel verwendete Modul ist ja nicht mehr lieferbar, sollte aber mit den anderen auch gehen. Der Quarz schwingt sehr sauber auf seiner Frequenz, an die Resetleitung habe ich zum Test noch einen 100nF für sauberen Reset gelötet, die Betriebsspannung ist von meinem Labornetzteil und sehr sauber, alle Abblock-Cs sind natürlich auch drauf. Eingangsspannung kommt von einem DDS-Generator mit hochstabiler Frequenz (zum Test 50-100kHz TTL). Mein Hauptproblem ist meine mangelnde Kenntnis in C, deshalb habe ich ja was halbwegs Ausgereiftes gesucht (und glaube noch immer, dieses hier auch gefunden zu haben). Den AtMega habe ich mit der Version 1.2 gebrannt, die eep natürlich auch. Zum Test habe ich jetzt noch die neueste Version (V1.3) gebrannt, keine Änderung! Gebrannt habe ich mit AVR-OSP-II und die Fuses so eingestellt wie im Makefile beschrieben. Die HEX und die EEP stehen auch exakt wie sie müssen in ihren Speichern, alles mehrfach verifiziert. Wo kann dabei was klemmen, hat irgendwer ähnliche Erfahrungen gemacht? Bei der mitunter vergurkten Darstellung tippe ich ja noch auf ein Timingproblem der Initialisierungsroutine, doch der andauernde Neustart muss andere Ursachen haben. Ein ratloser Old-Papa
Papi, mach mal gute bilder von den Platinen-seiten und poste sie mal, aber keine 'icons' vlG Charly
Angehängte Dateien:
-
Foto-Top-1.jpg
50 KB -
Foto-Bottom-1.jpg
41 KB
Ja mein Sohn, mach ich doch gerne ;-) Hier die Dateien, generiert als "Foto" aus Sprintlayout. Gruß Old-papa PS: Ich habe festgestellt, das dieser Dauer-Reset frequenzabhängig ist. Bis etwa 30kHz Messfrequenz steht das Teil gut, darüber wirds dann wacklig um bei etwa 1,5 bis 2MHz wieder halbwegs stabil zu stehen. Zumindest war dann selbst nach einigen Minuten kein Neustart zu verzeichnen, sonst im schlimmen Fall etwa alle 3-5 Sekunden. Das ist aber auch vom angestöpselten Displaymodell abhängig. Bei einigen geht fast nichts, bei anderen steht das wie gesagt bei hohen und tiefen Frequenzen.
So, konnte mal wieder nicht schlafen.... Wenn ich die beiden Teiler rausnehme, wird jedes Display exakt initialisiert und nix wird resettet. Klar, nun zählt auch nichts mehr. Irgendwo klemmt das wohl im Datenbus. Heute abend mach ich weiter. Testweise hänge ich dann mal einige kOhm nach Plus an jede Datenleitung. Wenn ich noch Nerven habe, mach ich auch Fotos des echten Aufbaus. ;-) Old-Papa PS: Auf einem Platinenfoto hier drüber ist noch ein Bug (nö, zwei, aber einer ist nur ein Schönheitsfehler). Mal sehen wers als erster merkt ;-) Der ist auf der Prototypplatine aber nicht, dafür zwei andere....
moin moin Papi, so sind die alten, hoeren einfach nicht zu, ich wollte bilder von deiner Platine, nitt irgendwas ausm rechner generiert, unn ich hab doch gesagt: KEINE ICONS !!! vlG dein Sohn
Hallo Papi, Old -papa schrieb: > ich habe das Ganze mal in Hardware aufgebaut Damit bist du anscheinend der erste hier! OK, nach mir natürlich :) > und leider massive Probleme. > Zunächst startet das Ganze andauernd neu, ein Muster ist dabei nicht > wirklich erkennbar. Das dürfte der Watchdog sein. Steht auf 2 Sekunden (länger kann der Mega8 nicht). Und sollte eigentlich nicht triggern, es sei denn ist ist noch ein Bug in Software (oder Hardware). Du kannst den Watchdog in der Firmware deaktivieren. In Version 1.3 sollte bei 0x2F6 im Flash diese Bytefolge stehen: 0x2F 0xE0 0x88 0xE1. Wenn du 0x2F in 0x27 änderst, wird der Watchdog nicht aktiviert. XL
Angehängte Dateien:
-
Top-Komparator-1.jpg
75 KB -
Bottom-Komparator-1.jpg
61 KB
Hallo Kinders ;-))) Ich sitze nun doch etwas früher wieder in meiner Rumpelbude am Rechner. @Axel, das mit dem Watchdog habe ich schon vermutet, aber das "Wo" war mir nen Rätsel ;-) Ok, mach ich nachher mal einen Versuch. Inzwischen habe ich noch eine Platine mit einem Komparator als Pegelwandler/Vorverstärker gezeichnet. Laut Datenblatt könnte ein TLV3501 passen, der kostet so um 6-7Euro, habe aber keinen zum Testen da. Wird das nächste mal testweise mitbestellt. Hier also die Platine, wieder "nur" als PC-Foto, in Hardware mach ich die erst, wenn der Komparatortest erfolgreich ist. @Charly, klick doch einfach mal auf die Icons, dann wird das.... Gruß Old-Papa
Angehängte Dateien:
-
Kpl-Display.jpg
90 KB -
Kpl-oben.jpg
110 KB -
Kpl-unten.jpg
140 KB -
Detail-unten.jpg
130 KB -
Detail-oben.jpg
70 KB
So, hier die versprochenen Fotos. Die Platine ist wie nach dem Löten, also vollkommen ungewaschen. Eine Leiterbahn war falsch geroutet, ist durch Draht ersetzt. Die Leiterbahn zum Pin15 des Displays (+LED) fehlt (und der Vorwiderstand), ist aber noch wurscht, kommt eh kein beleuchtetes Display rein. Die HEX habe ich noch nicht gefixt, mach ich nachher. Ich habe aber noch einen 10µF SMD verbaut, hätte ja helfen können. Schaden wird er natürlich nicht. Angezeigt werden die 10,00000000MHz meines GPS-Frequenznormals, allerdings habe ich die Kalibrierung im EEprom noch nicht gemacht. Bei diesen 10MHz läuft das alles stabil, wenn ich die am Normal auf 1MHz geteilt abnehme, habe ich wieder Dauerreset. Ebenso natürlich mit meinem DDS-Generator (0-10MHz) Den Kontrast am Display habe ich für das Foto absichtlich so stark gemacht, so sieht man die Zeichen pro Zeile besser. Gruß Old-Papa
Die metallene Bodenplatte des Quarzes könnte einen Kurzschluss zwischen den Quarzanschlüssen bilden. Daher immer ein Glimmerplättchen unter den Quarz legen. Oder - die zweitbeste Lösung - den Durchmesser der Quartzlötaugen kleiner wählen wie der Durchmesser der Drahtausgänge am Quarz ist.
Kurfürst schrieb: > Die metallene Bodenplatte des Quarzes könnte einen Kurzschluss zwischen > den Quarzanschlüssen bilden. Daher immer ein Glimmerplättchen unter den > Quarz legen. Oder - die zweitbeste Lösung - den Durchmesser der > Quartzlötaugen kleiner wählen wie der Durchmesser der Drahtausgänge am > Quarz ist. oder einfach den Quarz nicht aufliegen lassen. Stück Draht drunter und nach dem Löten wieder raus. Ist zu Hause so schwer nicht. :-) @old - papa Lass mich raten....Du bist Belichter! oder Toneraufbügler ?
Hallo Stephan, nein weder Belichter, noch Tonerbügler, sondern Methode "fauler Hund" ;-) Ich habe einen guten Bastelfreund, der macht mir immer die Platinen. Er hat inzwischen einige Routine mit Belichten und Ätzen, ich sitze dafür immer stundenlang und entwerfe Platinen (oder wie hier nach Methode "abkupfern und verändern"). Eigentlich habe ich das ganze Ätz- und Belichtergeraffel auch hier, doch immer wenig Zeit. Mein Kumpel geht dabei natürlich nicht leer aus, wir kommen schon klar. @Kurfürst, Also ich habe schon hunderte kleiner Platinen mit Quarz gefummelt, einen Kurzschluss habe ich da noch nie gebaut. Ein wenig Fingerfertigkeit sollte man in dem Geschäft schon haben. @alle, ich habe jetzt mal Axels Würgaround versucht, der Dauerreset ist weg! Aaaaber... Dafür bleibt das Teil jetzt genau an der Stelle einfach stehen, wo es vorher neu gebootet hat. Also ooch nich besser.... Wenn ich nicht mit TTL-Pegel reingehe, sondern diesen etwas vermindere, ist der Absturzbereich etwas schmaler (so von 450kHz bis 1MHz), nutz also auch nichts. Wie gesagt, die gesamte Hardware ist (zumindest nach Schaltplan) fehlerfrei. Außerhalb der kritischen Frequenzen läuft es ja 1A. Es muss also irgendeine Kollision in der Firmware geben. Da können also nur die C-Gurus weiterhelfen. Gruß Old-Papa
Respekt Papi!, und das mit den Icons ist jetzt aach besser :P wenn du jetzt die letzten paar kleinigkeiten noch verbesserst gib i dich auch nicht ins altersheim :)) vlG dein Sohn
Hallo Charly, schwafel nich rum, sag was nach Deiner Meinung besser zu machen geht. Ist ja immerhin zu 90% nicht mein Layout.... Mir gefällts, ausreichend Masse, nix im Kreis geroutet, Leiterbahnen so, dass sie mein Kumpel noch arbeiten kann (der kann noch viel filigraner), alles so, dass man noch händisch löten kann... Also was hast Du noch anzumerken? Interessanter wäre ja schon, den wahrscheinlichen Fehler in der Firmware zu finden. Gruß Old-Papa
Old -papa schrieb: > Hallo Charly, > > schwafel nich rum, sag was nach Deiner Meinung besser zu machen geht. > Ist ja immerhin zu 90% nicht mein Layout.... > Mir gefällts, ausreichend Masse, nix im Kreis geroutet, Leiterbahnen so, > dass sie mein Kumpel noch arbeiten kann (der kann noch viel filigraner), > alles so, dass man noch händisch löten kann... Also was hast Du noch > anzumerken? jaja, i kenn den Kerl ganz gut der die 90% deines Layouts gemacht hat, und f. Firmware binn i nitt zustaendig da in C 'gecoded' und echte programmierer meiden C , und jetzt bitte keine diskusion darueber, i kann und i mag kein C punkt. vlG Charly
Charly B. schrieb: > und jetzt bitte keine diskusion > darueber, i kann und i mag kein C punkt. 100% ACK Aber mit :-)))
Charly B. schrieb: > echte programmierer meiden C , und jetzt bitte keine diskusion > darueber, i kann und i mag kein C punkt. Naja, das mit den "echten Programmierern" würde ich so nicht unterschreiben, doch auch ich habe damit extreme Bauchschmerzen. Vor gut 25 Jahren habe ich mit Kumpels mal einiges in Asembler für Z80 gemacht, das ist aber alles längst vergessenes Wissen. Derzeit stolpere ich etwas in Bascom für AVRs rum, ist aber bisher wirklich nur stolpern. Also ich ziehe immer meinen virtuellen Hut für jeden Programmierer, egal ob in Assembler, C, Basic, Forth, Agol und was es noch alles gab und gibt. Old-Papa PS: Zum Thema sollte man ja auch noch was sagen.... Also, Axel hat mir in der Nacht noch eine Version zum testen geschickt, die läuft zumindest bisher ohne diesen komischen Reset-Fehler.
>Angezeigt werden die 10,00000000MHz meines GPS-Frequenznormals, >allerdings habe ich die Kalibrierung im EEprom noch nicht gemacht na dann bin ich ja mal gespannt wie der Messewert nach dem Kilibrieren aussieht und steht.
Klar, das Teil ist auch nicht dazu da das über längere Zeit supergenau anzuzeigen. Zumindest stärkere Temperaturänderungen werden da wohl was in der letzten Stelle verändern. Testen werde ich das ganz sicher, muss aber erstmal kalibrieren. Zur genauen Messung habe ich andere Zähler, bis zu 10-Stellig und mit Doppelofen bzw. ans GPS gehäckelt. Dieses Modul soll nur als Ersatz für Frequenzskalen einfacher Generatoren dienen, und das wird es machen. Old-papa
Angehängte Dateien:
-
Platinen-nackt.jpg
190 KB
Hallo, ich habe das Dingens jetzt mal einige Zeit am GPS-Frequenznormal arbeiten lassen. Die Kalibrierung ging absolut sauber, im Ergebnis standen die angezeigten 10.0000MHz wie eine Eins. Selbst wenn ich die Betriebsspannung von 4,5 bis 5,2 Volt verändere, bewegt sich die letzte Stelle um max. ein Digit. Die siebente Stelle ist also durchaus machbar! Nur wenn ich die vorgesehenen 1x16-Zeichen Displays ranhänge gibt es noch Macken. Mal wird ab dem 9. Zeichen überhaupt nichts angezeigt oder bei anderen Displays springt die 6. Stelle (also auf dem Display das 9.Zeichen) mal zu umd mal weg. Der Messwert (z.B. MHz) rückt dann eins vor oderzurück. Gaaanz merkwürdig. Wenn ich testweise ein 2x16er Display nehme, werden 8 Zeichen auf der ersten Zeile angezeigt (ist ja klar) und die 2. Zeile zeigt den Rest. Aber auch dann springt das mal nach oben auf die erste Zeile (oups!) und wieder zurück. Ich habe als letzten Test die LCD.h angepasst und ein 2x20er Display genommen, hier steht alles astrein in der ersten Zeile, nix springt. Dabei ist das wurscht, ob ich dieses nun als 1x20 oder 2x20 eintrage. Ja auch ein 2x16 geht gut, auch hier egal ob das als 2x16 oder 1x16 in die LCD.h eingetragen ist. Irgendwas mit dem Timing könnte das sein, ist auch nicht bei allen Displays gleich, manche springen seltener, andere dauernd. Wie gesagt, mit dem 2x20 habe ich das dann länger laufen gelassen, der Messwert steht absolut stabil und genau. Für die Fotofreaks hier noch die Platinen nackich. Für die beiden Einstellregler habe ich Nieten eingesetzt, da kann man ja nicht von oben löten. Und ja, die sind unverkäuflich (eine bekommt Axel für seine Arbeit, die andere bleibt mir ;-)) Wenn alles hinhaut, lass ich nochmal welche bei meinem Kumpel machen, dann aber mit dem Komparator drauf. Gruß Old-Papa
Old -papa schrieb: > Und ja, die sind unverkäuflich (eine bekommt Axel für seine Arbeit, die > andere bleibt mir ;-)) unn was iss mit deinem Sohn ? ;(
Hallo, ich bin auch am layouten, aber mehr in Richtung SMD und mit 74HC132 als Eingangsschmittrigger und 2 Kanalumschalter. Dann kommen auch noch zwei hochohmige Eingangsstufen mit J310 und BF199 drauf. Sowie weitere ADC Eingänge die mit Trimmer Parameter an die Software übergeben. Wie z.B. die Vorteilerverhältnisse 1:n der beiden Eingänge. Auch werde ich die Einheiten GHz, MHz, kHz festlegen und außen einstellbar machen. Zeit.. Ich baue aber gerade noch den Kennlinienschreiber von Andreas, DL4JAL und die Frequenzerweiterung für den FA-NWT von Rainer, DM2CMB auf. Das wir noch etwas dauern. .
Angehängte Dateien:
-
46.0000-MHz.jpg
100 KB -
1.5-Hz.jpg
120 KB -
1-Hz.jpg
130 KB
So, da das ja mit einem 2-Zeiligen Display ohne Macken geht, habe ich jetzt mal einige Tests gemacht. Obere Kotzgrenze ist bei ca. 46.000MHz, untere bei 1 Hz. Der 46.0000MHz-Wert steht ganz sauber, (im Bildhintergrund mein schnell zusammengehäkelter HF-Generator), unten bei 1,5Hz spinnt mein DDS-Generator etwas, am "GPS-Zähler" werden auch 1,40074Hz ausgegeben. Die 1Hz (931.506Hz) werden zumindest vor dem Komma noch richtig angezeigt, ab der 2. Stelle hinterm Komma ist nur noch Hausnummer. Doch insgesamt schon beeindruckend und für meinen Einsatzzweck völlig ausreichend. Müsste nur noch die Springerei bei einzeiligen Display aufhören. Obwohl, die 1x16er Displays sind ja eigentlich auch 2-Zeilige, doch nach 8 Zeichen wird umgeswitcht auf die "2. Zeile". Genau hier gibbet wohl noch ein Problem Old-Papa
Hallo, was ist bis hier an der Software angepasst worden, dass die nun so gut bei Dir läuft ? .
Angehängte Dateien:
-
52.0000-MHz.jpg
100 KB
Hallo Uwe, da muss ich passen. Axel hatte mir eine Version zum Testen geschickt und die läuft bis auf die Macke mit der Springerei. Wenn ich in die ganzen h und c-Dateien reinschaue, kann auch das berüchtigte Schwein ins Uhrwerk.... ;-) So, und einen lege ich noch drauf: Dat Dingens geht bis jetzt rauf bis 52.0000MHz! Ist wahrscheinlich Temperaturabhängig und natürlich auch von sauberen Eingangsimpulsen. (vorhin hatte ich noch einen 2. Zähler parallel zum Generatorausgang) Mal sehen, wie weit ich das noch kitzeln kann.... Old-Papa
Danke ! Wie sieht nun deine Eingangsbeschaltung vor dem HC590 aus ? .
Hallo Uwe, so wie im Schaltplan von Axel, also nur einen R 10k nach Plus. Mein Generator macht 5V-CMOS-Pegel am Ausgang, das ist der FA-Synth nebst Steuerplatine vom Funkamateur (box73.de). Der geht von 3,5MHz bis 269,9MHz und ist nach Kalibrierung (via USB) sehr genau. Ist ein Si570 drin. Old-Papa Ach ja: Bri 52.3000MHz ist definitiv Schluss, zumindest mit diesem Generator. Leider muss ich meinen 150MHz-Oszi immer erst auf den Tisch wuchten, kann also die Impulse mit dem einfachen Oszi nur bs etwa 20MHz ansehen. Ich vermute das die Flanken bei über 50MHz schon nicht mehr sehr sauber sind. Wenn Segor den weiter oben genannten Komparator liefert, bau ich den mal testweise davor.
>Ich vermute das die Flanken bei über 50MHz schon nicht mehr >sehr sauber sind. Und was soll ein Komparator da noch bewirken? Bei den Frequenzen reicht ein 74AC04 als "Verstärker" um kleinere Signale zu verbessern. Ob Deine 50MHz Impulse jetzt 8,1ns oder 5,3ns Anstiegszeit haben, ist doch völlig Wurst. Einen Komparator braucht man für niedrige Frequenzen, die man zuvor noch per Tiefpaß (ggf. auch Hochpaß) filtert, um höherfrequente Störungen auszuschließen. Und dann muß noch ein Spannungsteiler, ein Impedanzwandler und ein DC-Offset-Regler vorgesehen werden, falls man Signale mit extremen Tastverhältnis erfassen will. Am Ausgang des Komparators sollte noch eine LED anzeigen, ob statisch '0' oder '1' erzeugt wird, oder mit halber Helligkeit ein sinnvolles Ausgangssignal vorliegt. Das nur am Rande.
Hallo, zum Thema Komparator: Such mal nach: "ne592 frequenzzähler" Bild: http://www.sprut.de/electronic/pic/projekte/frequenz/frequen1.gif Oder ich verwende am Eingang gerne 74HC mit "Schmitt trigger" Eingängen: - 74HC132 - 74HC14
Soll der Suchbegriff vielleicht "ne529 frequenzzähler" sein? Der ne529 ist ein schneller Komparator, braucht aber V+ und V-.
Moin, Uwe S. schrieb: > > was ist bis hier an der Software angepasst worden, dass die nun so gut > bei Dir läuft ? Da ist noch eine race-Condition in main() die man bei "mittleren" Frequenzen zwischen ~500kHz und ~1.5MHz recht zuverlässig trifft. Freundlicherweise hatte unser Papi gerade in diesem Bereich getestet. Mein Testgenerator hier hört bei ~100kHz auf und die Quarzgeneratoren, die ich testweise mal rangehängt habe, hatten alle >= 10MHz. Hier ist der relevante diff:
1 | start_low(); |
2 | while (nref.b[2] && gate_is_open()) { |
3 | wdt_reset(); |
4 | - sleep_cpu(); |
5 | }
|
(im Klartext: das sleep_cpu() muß da weg) [falls das jemand im Flash patchen will: ab 0x344 steht die Bytefolge 0xA8 0x95 0x88 0x95. Das müßte geändert werden in 0xA8 0x95 0x00 0x00. Das gilt für die Version, die ich hier am 10.12. hochgeladen habe] Was die Display-Probleme angeht: meine Displays funktionieren alle. Und von Papi habe ich noch nicht genug Details, um das Problem eingrenzen zu können. Es gibt ein bekanntes Problem, das ich auch mit meinem 10x1 von Pollin sehe. Intern ist das ein 5x2 und das automatische Umschalten auf die 2. Zeile, das Peter Fleurys lcd-lib macht, funktioniert nicht korrekt. Konkret wird 1 Zeichen zu spät umgeschaltet, so daß ein Zeichen (das an die 6.Position gehört) dann fe lt. Bei 16x1 würde das ein verschlucktes Zeichen zwischen Position 8 und 9 bedeuten. Ich vermute(!) daß die Ursache ein falscher Rückgabewert für den LCD-Adreßzähler ist, den die lcd-lib zusammen mit dem Busy-Flag abfragt um daraus die aktuelle Zeile/Spalte auszurechnen. Als Abhilfe kann man in lcd.h die Zeilenlänge um eins vermindern (das 16x1 also z.B. als 7x2 deklarieren). Was ich auf Papis Fotos noch sehe, ist das fe lende "=" nach dem "F". Das könnte natürlich an einem komischen Zeicensatz in seinem LCD liegen, wäre aber ziemlich abnormal. Zumindest den ASCII-Bereich von 0x20 bis 0x7F sollten alle Displays korrekt darstellen. Wenn jemand Display-Fehler sieht, bitte den genauen Display-Typ notieren, nach Möglichkeit ein Datenblatt dazu finden und bei mir Bescheid sagen. Wenn sich eine Systematik abzeichnet, kann ich da gerne noch etwas am Code basteln. XL
Old -papa schrieb: > So, und einen lege ich noch drauf: Dat Dingens geht bis jetzt rauf bis > 52.0000MHz! > Ist wahrscheinlich Temperaturabhängig und natürlich auch von sauberen > Eingangsimpulsen. (vorhin hatte ich noch einen 2. Zähler parallel zum > Generatorausgang) > Mal sehen, wie weit ich das noch kitzeln kann.... Vermutlich nicht sehr weit. Je nach Hersteller werden für den 74HC590 nur 36MHz garantiert (bei 5V und über den erlaubten Temperaturbereich). Typische Werte in den Datenblättern sind um die 50MHz. Beim 74HC74 sieht es nicht viel anders aus. Und während es den 74HC74 auch noch schneller gibt (z.B. als F74 oder AC74), ist beim 74HC590 Ende der Fahnenstange. Im Zweifelsfall gibt eine höhere Betriebsspannung auch mehr Speed. Die Software stellt dir erst bei 99.999999MHz ein Bein. Da läuft der Akku bei der Binär-BCD-Umwandlung über. Wenn man regelmäßig Frequenzen über 40MHz messen muß, dürfte es besser sein, einen Vorteiler (z.B. 74F74 als 4:1 bis 100MHz) davor zu schalten. Allerdings verliert man dann halt am unteren Ende. Die Software-Anpassung für einen Vorteiler ist in der Mache, also bitte abwarten. Eine Erweiterung nach unten habe ich mittlerweile verworfen. Die <1Hz, die derzeit erreichbar sind, reichen IMHO vollkommen aus. Zumal man bei niedrigeren Frequenzen ja auch entsprechend lange auf jeden neuen Meßwert warten müßte. XL
Hallo Axel, nein, kein komischer Zeichensatz, ich habe das "=" einfach in der Main.c gekillt (durch " " erstetzt). So finde ich das übersichtlicher. Habe zwar nix Ahnung von C, doch dafür reicht es noch ;-))) Mehr habe ich aber nicht geändert, großes Pionier-Ehrenwort! Diese Springerei kann ich nur so beschreiben: 1. Deine völlig unveränderte HEX geflasht 2. ein 1x16er Display angestöpselt und Power-On Der Messwert wird nach der Initialisierung (also das Begrüßungsgedöhns) mal als "F=12.3456MHz" angezeigt oder je nach Lust und Laune plötzlich als "F=12.345MHz" Die 6. Stelle wird einfach verschluckt. Das passiert mit mehreren Displaymodellen und ist offenbar von nichts abhängig (also Spannungsänderung oder Frequenzänderung). Ein Display ist dabei, da erscheinten nur die ersten 8 Zeichen (also "F=12.345" und dann nix mehr). Das Display selbst ist aber in Ordnung, funktioniert in anderen Schaltungen bestens. Wenn ich mit der gleichen HEX ein 2x16er Display anstecke (oder ein 2x20er), wird in der ersten Zeile "F=12.345" angezeigt und in der 2. dann "6MHz". Das ist ja auch völlig korrekt so, doch wenn das Ding plötzlich wieder springt, swapt die "6MHz" auch auf die erste Zeile, aber weiter hinten. Oder in seltenen Fällen werden die Zeileninhalte plötzlich vertauscht. Dann habe ich die LCD.h auf 2 Zeilen und 16 Zeichen angepasst und in der Main.c das = gekillt (also durch ein Leerzeichen ersetzt). Jetzt erscheint auf zweizeiligen Displays alles wie es soll auf der ersten Zeile, da springt nichts mehr. Ich hoffe, ich habe mich halbwegs ausgedrückt... ;-) @Frank-Gast, klar kann man mit den ST-Gattern die Flanken steiler bekommen, doch nur wenns halbwegs Spannung hat. Mit dem o. genannten Komparator kann man langsame Frequenzen oder eben lansame Flanken versteilern. Wo siehst Du da ein Problem (ok, der Preis...) @Uwe, der ne592 ist ein Videoverstärker bis 40(90)MHz und braucht mehr Außenbeschaltung. Der ne529 dazu noch Dualspannung. Ich habe mir den TLV3501 mal bestellt, mal sehen wie das geht. (Ein KLick hier auf den Bezeichner öffnet das Datenblatt, dort auf Seite 5 findet sich obige Grafik) Old-Papa
Angehängte Dateien:
-
TLV3501-Grafik.jpg
40 KB
Hmm, die Grafik hat "er" nicht angenommen, hier 2. Versuch
Axel Schwenke schrieb: > Was ich dabei gelernt habe: > 1. mit den AVRs bekommt man keine schnellen (kurzen) ISRs hin. U.a. > deswegen, weil man SREG manuell sichern muß. eZ8: Interrupt Latency ist >= 16 Takte (!), plus 7 (2+5) für den Code = 23 Takte insgesamt. AVR: Interrupt Latency ist >= 4+3 Takte, plus 7 (1+1+1+4) für den Code = 14 Takte insgesamt, wenn für SREG und den Zähler Register reserviert werden können. Mit SREG und Zähler im RAM sind es 28 Takte. Der Z8 muss das Statusregister genauso sichern wie der AVR, nur macht er das automatisch. Schneller wird es dadurch nicht notwendigerweise.
Old -papa schrieb : > Mit dem o. genannten Komparator kann man > langsame Frequenzen oder eben lansame Flanken versteilern. Ich hatte Dich so verstanden, dass Du mit einem Komparator die obere Grenzfrequenz bei digitalen Signalen verbessern wolltest. Der LT1016 wäre eine preiswerte Alternative bei Angelika. Die Grafik mit 20mVpp nach HCMOS-Signal bei 50MHz ist ja nett, allerdings ist die Beschaltung dafür nicht dargestellt. Ohne nennenswerte Hysterese >=50mV wird das gezeigte Ausgangssignal auch ohne Eingangssignal vorhanden sein oder bei NF sporadisch hinzugefügt ;-)
Hallo Frank-Gast, ja, den LT1016 kenne ich auch, doch den TLV3501 will ich vielleicht noch in einem anderen Projekt einsetzen und deshalb teste ich den schonmal. Klar ist der etwas teuerer, doch was ist schon Geld beim Hobbay... ;-) Mein längst verstorbenenr Meister hat immer gesagt "Geld ist am besten angelegt, wenn es ausgegeben ist", da ist wohl was dran ;-) (ich füge gern hinzu "sinnvoll ausgegeben ist") Ansonsten habe ich heute erstmal meinen oben im Bildhintergrund zu sehenden Generator in ein Gehäuse gebaut und nachher bau ich noch einen Rechteck-Generator 10kHz bis ca. 50MHz. Dafür unter anderem soll dieser Frequenzzähler sein. Ich habe einiges an Generatoren hier, doch die richtig guten sind auch richtig groß und schwer und sind deshalb immer irgendwo abgestellt, die hole ich nur wenns unbedingt nötig ist auf den (meist verkramten) Tisch. Deshalb hatte ich mir aus einem Modul, was aus einem Experiment über war (FA-Synth), vorgestern noch schnell dieses HF-Dingens gebaut, die Teile lagen schon länger rum. Damit konnte ich den Zähler im oberen Bereich testen. Mein DDS geht von 0,1Hz bis 10Mz, der aus dem FA-Synth-Modul von 4MHz bis ca. 269MHz. Damit ist eigentlich vieles abgedeckt, doch der DDS ist etwas umständlich zu bedienen. Daher die dusslige Idee nochwas für "dazwischen" zu basteln. Ich habe es lieber, wenn ich fix am Regler drehe und einen großen Bereich überstreichen kann. Diese Knöppchentasterei am DDS ist eigentlich nervig. Naja, jeder spinnt auf seine Weise... ;-) Gruß Old-Papa
So, ich habe mal mein HTC bemüht und ein Wackelvideo gedreht. Das liegt natürlich beim "Jutube", ich hoffe der Link klappt: http://youtu.be/wvsA4Q4XOeo Allerdings muss ich mich etwas korrigieren. Mit der ganz originalen Hex von Axel gingen am 1x16er nur die ersten (?)Zeiche und es springt nix. Da Axel ja ein 1x10er Display hat (also intern als 2x5 orgenisiert), habe ich via "Programmers-Notepad" aus der aktuellen Version von WinAVR, wie von ihm geraten die LCD.h angepasst. Dann in diesem "Programmers..." über "Tools-Make All" compiliert. Es gab keinerlei Fehlermeldungen, sollte also doch alles klappen. Tuts aber nicht...... :-( Irgendwas geht in die Büsche, wenn das Display auf die 2. Zeile schreiben will. Bei einem 2x16er Display ist eine Zeile ja echte 16 Zeichen lang und da braucht nicht gewrapt zu werden. Old-Papa
Moin, Old -papa schrieb: > So, ich habe mal mein HTC bemüht und ein Wackelvideo gedreht. Dieses erratische Gespringe sieht so aus, als wäre dein LCD einfach nur langsam. Da du anscheinend damit klarkommst, den Code zu ändern und neu zu compilieren, probier doch mal diese Änderung: in lcd.c diese Zeile (ziemlich am Anfang)
1 | #define lcd_e_delay() __asm__ __volatile__( "rjmp 1f\n 1:" );
|
ändern in
1 | #define lcd_e_delay() delay(4);
|
Statt 4 kannst du auch noch größere Werte ausprobieren. XL
Hallo Axel, werd ich heute abend mal machen. Doch wie schon geschrieben, das passiert mit allen ca. 10 getesteten Displays unterschiedlicher Bauart und Hersteller, wenn ich diese als 2x8 eintrage. Ein Typ ist dabei (2 Stück) da geht nach den ersten 8 Zeichen überhaupt nichts, egal ob ich da nun 2x8 oder wie von Dir als Tipp gegeben, auch mal 2x7 in die LCD.h eintrage. Ich werde dann mal Fotos der Displays machen (Rückseiten) und die Fehler dazu schreiben. Gruß Od-Papa
Old -papa schrieb: > wie schon geschrieben, das > passiert mit allen ca. 10 getesteten Displays unterschiedlicher Bauart > und Hersteller, wenn ich diese als 2x8 eintrage. Ich habe mir ehrlich gesagt den Code in lcd.c nicht allen angesehen (vor allem nicht das low level inline ASM Geraffel). In der Tat erscheint mir die Verzögerung, die die Länge des E-Impulses für das Display definiert, als recht kurz. Es würde mich daher nicht wundern, wenn ältere Displays damit nicht klar kommen. <seufz> "Wenn man nicht alles selber macht" > Ein Typ ist dabei (2 > Stück) da geht nach den ersten 8 Zeichen überhaupt nichts, egal ob ich > da nun 2x8 oder wie von Dir als Tipp gegeben, auch mal 2x7 in die LCD.h > eintrage. Es gibt 16x1 LCD, die auch intern als 16x1 aufgebaut sind. Kann man anhand der Anzahl der verbauten Chips erkennen. Guckstu: http://www.sprut.de/electronic/lcd/ Wenn du ein solches echtes 16x1 als 8x2 zu betreiben versuchst, würde genau das passieren was du siehst: nur die ersten 8 Zeichen werden angezeigt. XL
Hallo Axel, als 1x16 habe ich es bei dem Ding auch versucht, nichts! Dei beiden Dinger haben auch nur je einen vergossenen Chip drauf. Mal sehen, vielleicht haben die ja auch nur ein Timingproblem. Die Seite vom Sprut kenne ich gut, vor allem seine Ausführungen zu LCD-Displays. Die sollte jedem angehenden Elektroniker zur Pflichtlektüre werden! Old-Papa
Hallo, voller Erfolg! Ich habe das jetzt mal verändert, jetzt switcht da nix mehr. Zumindest bei fast allen Displays, die beiden, die bisher nur die ersten 8 Zeichen darstellten, machen nun garnichts mehr. Testweise habe ich dann in der LCD.h in der Zeile:
1 | #define LCD_CONTROLLER_KS0073 1 /**< Use 0 for HD44780 controller, 1 for KS0073 controller */ |
auf einen KS0073 umgestellt, da ich ja nicht weis, welcher Controller da unter dem Klecks steckt. Hilft auch nichts. Was mich allerdings irretiert, wenn ich die damit erzeugte HEX mit der für den HD44780 vergleiche, sind beide absolut identisch. Da ich ja in der Zeile die "1" für den KS0073 gesetzt hatte, sollte doch irgendwo in der HEX irgendwas anderes stehen. Eigentlich schade, denn genau dieses Modul wollte ich eigentlich verwenden, da es mechanisch am besten passt und guten Kontrast hat. Was bedeutet eingentlich die Daten in der "falschen" Befehlszeile:
1 | #define lcd_e_delay() __asm__ __volatile__( "rjmp 1f\n 1:" );
|
? Kann man das mal in "deutsch" übersetzen? Ich möchte ja immer was lernen. Gruß Old-Papa
Hallo Old Pappa
1 | #define lcd_e_delay() __asm__ __volatile__( "rjmp 1f\n 1:" ); |
Ja ist einfach. ein
1 | #define |
ist eine Definition für eine Ersetzung aller Stellen mit "lcd_e_delay()" durch den "rjmp ..".
1 | __asm__ |
sagt dem c-compiler, jetzt kommt Assembler !
1 | rjmp |
ist ein relativer Sprung zur Marke "1:", also direkt auf die nächste vom c-compiler erzeugte Anweisung. Somit ist das eine kurze, 2 Takte lange, Verzögerung. .
Moin, Old -papa schrieb: > > voller Erfolg! > Ich habe das jetzt mal verändert, jetzt switcht da nix mehr. \o/ > Zumindest bei fast allen Displays, die beiden, die bisher nur die ersten > 8 Zeichen darstellten, machen nun garnichts mehr. Merkwürdig. Auch mal mit delay(20) versucht? Die Zahl gibt ca. die Breite des E-Impulses (H-Zeit) in Mikrosekunden. Laut Datenblatt möchte der HD44780 mindestens 500ns. > ... Was mich allerdings > irretiert, wenn ich die damit erzeugte HEX mit der für den HD44780 > vergleiche, sind beide absolut identisch. Da ich ja in der Zeile die "1" > für den KS0073 gesetzt hatte, sollte doch irgendwo in der HEX irgendwas > anderes stehen. Nö. Der KS0073 ist nur bei 4-zeiligen Displays subtil anders zu initialisieren, wird sonst aber genau gleich angesteuert. Wenn du dein Display mit 4 Zeilen angegeben hättest, dann wäre da auch anderer Hex-Code. > Eigentlich schade, denn genau dieses Modul wollte ich eigentlich > verwenden, da es mechanisch am besten passt und guten Kontrast hat. Keine Sorge, das bekommen wir sicher noch hin. Ich muß nochmal über lcd.c schauen. Vermutlich hat Peter F. da noch ein paar Ostereier versteckt... > Was bedeutet eingentlich die Daten in der "falschen" Befehlszeile: >
1 | #define lcd_e_delay() __asm__ __volatile__( "rjmp 1f\n 1:" );
|
? > Kann man das mal in "deutsch" übersetzen? Ich möchte ja immer was > lernen. das ist Inline-Assembler und würde schön hingeschrieben so aussehen:
1 | rjmp dummy ;springe zur Marke "dummy" |
2 | dummy: ;das ist genau da, wo es auch ohne Sprung weiter geht |
hat also keine Funktion, außer den AVR für 2 Zyklen zu beschäftigen. Man hätte genauso gut schreiben können:
1 | nop |
2 | nop |
aber das würde zwei Byte mehr Flash kosten ;) HTH, XL
Angehängte Dateien:
-
Sharp-Display.jpg
170 KB -
51.0000-MHz.jpg
87 KB
Hallo Uwe, hallo Axel, danke für die Erklärung, wieder was gelernt... ;-) Bis auf die beiden bekloppten Displays geht es jetzt ganz gut. Allerdings komme ich jetzt nicht mehr über 51.0000MHz. ist aber vielleicht auch vom Geraffel auf dem Werktisch abhängig. ;-) Übermorgen werde ich mal die bestellten (bösen ;-)) Komparatoren abholen, ich verspreche mir davon schon was. Hier noch ein Foto der bekloppten Displays, Tante Google hat mir da nichts rechtes ausgespuckt. Das 2. Foto zeigt das Dingens jetzt mit 1-zeiligem Display. Als Delay-Wert habe ich da jetzt 2 drin stehen, 3 oder 4 geht auch, doch selbst mit 20 gingen die beiden bösen Displays nicht. Die Darstellungsgeschwindigkeit kann zwar nicht ganz mit der tatsächlichen Änderung beim Abstimmen mithalten, ist aber brauchbar. Gruß Old-papa
Angehängte Dateien:
-
Bottom-Komparator-11.jpg
84 KB -
Top-Komparator-11.jpg
98 KB
Hallo die Herren, ich hatte "die Tage" doch etwas Stress im Job, zum WE kann ich also weiter machen. Heute habe ich die Platine nochmal überarbeitet. 1. Ich habe die +5V-Leiterbahn für die beiden Einstellregler auch unten verlegt, so sind keine Durchkontaktiernieten nötig. Be industrieller Platine eh wurscht. 2. Ich habe einige Leiterbahnen begradigt und die Massekreuze an Bauteilpins dicker gemacht. 3. Die deutlichste Überarbeitung: Ich habe auf die Unterseite noch einen HC132 gebaut. So kann man als Eingangstrigger halt auswählen, ob man oben einen TLV3501 oder auf die Unterseite einen 74HC132 verbaut. Man kann auch beides weglassen und eine kleine Brücke von der Eingangsbuchse (Durchkontaktierung) zur Durchkontaktierung am Eingang 74HC74 legen. Der 51-R unter der Eingangsbuchse (übrigens eine SMB) ist genauso optional wie die Rs oben beim TLC3501. Damit kann man halt etwas experimentieren. Einmal um 50Ohm sicher zu stellen und oben am Eingang zum TLV3501 noch ein Vorwiderstand (ca. 100-330Ohm) zum Schutz gegen zu hohe Eingangsspannungen. Und dann ein ca. 10K vom +-Eingang zum Ausgang um eine Hysterse zu erreichen. Näheres dazu im Datenblatt. Wenn Interesse besteht, kann mein Kumpel ja nochmal Handmade-Platinen machen. Morgen werde ich den TLV3501 testen. Zunächst muss ich erstmal meine Lupenleuchte zurück ins Leben bringen (s. Thread bei Analogtechnik). Ohne Lupe wird das nix mehr :-( Gruß Old-Papa
Moin, Old -papa schrieb: > Heute habe ich die Platine nochmal überarbeitet. Wenn das wirklich eine universell einsetzbare Platine werden soll, hätte ich da noch ein paar Änderungsvorschläge: 1. die drei bedrahteten Widerstände (Pullup f_x, Pullup Reset, Vorwiderstand Backlight) und die 10µH Drossel sind alle mit 300mil Länge vorgesehen, obwohl da Platz für längere Typen ist. Da man zwar kleine Bauformen mit größeren Lochabständen verwenden kann, aber nicht anders herum, wäre es sinnvoll da wenigstens 400mil vorzusehen. Oder auch mehrere Lötaugen für verschiedene Größen. 2. Spindeltrimmer haben die Pins auch gern mal in einer Reihe statt im Dreieck. Für die Trimmer sollte also auch noch ein 4. Lötauge vorgesehen werden. 3. die Kondensatoren unter dem Mega8 sind ungünstig angeordnet. Da ist ein GND-Pin genau zwischen dem Vcc-Pin und the XTAL-Pins. Genau da sollten die Kerkos hin. 4. das SMD-Hühnerfutter ist alles in 1206 vorgesehen. Wer verbaut denn noch solch riesiges Zeug? 0805 ist eher angemessen. Da wo das geht, gerne auch Pads für variable Bestückung. Was ich an 0805 praktisch finde: auf Lochraster passen die prima zwischen zwei Pins in 100mil Abstand. 5. mir sind da zuviele Stütz-Elkos an Vcc. Die vorgesehenen 100n (kann man auch 1µ bestücken) reichen vollkommen. Insbesondere der fette 100µ-Elko ist angesichts der doch sehr überschaubaren Stromaufnahme eher überflüssig. 6. ich hatte das glaub ich, schon mal erwähnt. Ich plane noch, bis zu acht Jumper/Schalter-Anschlüsse vorzusehen. Dazu würde jede der 8 Datenbusleitungen über einen 4.7K Widerling an einen Jumper (nach GND) gehen. Vielleicht braucht man auch nicht alle 8, sondern 4 reichen. Mindestens 2 würde ich vorsehen um a) bei einzeiligen Displays zwischen Frequenz- und Periodendaueranzeige wählen zu können und b) einen (zuschaltbaren) Vorteiler zu berücksichtigen. Der konkrete Teilerfaktor könnte ja im EEPROM stehen. Oder man sieht mehrere Jumper vor, um feste Vorteiler-Faktoren zu konfigurieren. XL
Hallo Axel, bei den Rs hats Du recht, mach ich morgen (quatsch, heute) mal. Die L natürlich auch. Die 1206 habe ich extra genommen, nicht jeder kann das kleine Hünerfutter löten. Man kann an den Stellen fast überalle auch 0805 einbauen. Da werde ich auch noch etwas fummeln. Andererseits sollte dann wirklich eine Platine mit durchgängig SMD gebaut werden, dann meinet wegen auch 0805, wers mag..... Freiwillige vor! Die SMDs der Eingangsschaltung hatte ich nur genommen, weil es den TLV3501 nur in SMD gibt. Die Cs am Quarz liegen schon gut an Masse, die ist ja auch auf der Oberseite großflächig vorhanden. Zumindest habe ich mit einer ähnlichen Anordnung in anderen Schaltungen nie Probleme gehabt. Die Stützelkos resultierten noch aus meinen Versuchen zur Fehlerermittlung, der SMD kann wirklich weg. Am Eingang würde ich die 100µF schon belassen, das Modul soll ja in vielen Situationen verwendbar sein. Ok, 10µF reichen wohl auch. Die Kerkos am TLV3501 sind aber so gewollt, auch der 100nF und der 1nF parallel. Auch SMDs haben eine Eigenresonanz und so wird das breiter aufgestellt. Die Jumper könnten sicher auch Lötbrücken sein, denn man wird das ja nur einmal konfigurieren. Ok, Frequenz und Periode später auch im Betrieb... Mal sehen was ich da machen kann. Jetzt geh ich erstmal die Frequenz meiner Atemzüge messen Gute Nacht Old-Papa
>Jetzt geh ich erstmal die Frequenz meiner Atemzüge messen
Mit welchen Frequenzmeßgerät machst Du das? Deine Atemfrequenz liegt
doch hoffentlich unter 1Hz ;-)
Angehängte Dateien:
-
Bottom-Komparator-11a.jpg
110 KB -
Top-Komparator-11a.jpg
120 KB
Frank-Gast, das Zählgerät liegt gewöhnlich neben mir und nimmt die Frequenzen akustisch auf. (wenns nicht gerade selber Geräusche erzeugt ;-))) So, heute die finale Version, ich habe fast alles eingebaut, was Axel vorgeschlagen hatte. 1. Die bedrahteten Rs und Ls haben jetzt einen größeren Lochabstand. 2. Den SMD-Elko habe ich rausgeworfen 3. Einen 100nF auf die Lötseite gelegt 4. Damit hatte ich Platz, einen zusätzlichen "SIP-R" mit 4x4,7K unter zu bringen. Damit können nun die Datenleitungen 0 bis 3 zur Programmierung von max. 16 Zusatzfunktionen genutzt werden. Dabei ist aber nur eine Datenleitung auf einen Jumper gelegt (D3), die übrigen drei gehen auf Lötbrücken. So sollte das durchaus reichen. Sollten noch Fehler drin sein, fummel ich daran nochmal rum, ansonsten lass ich das so. Wer Böcke hat, kann das Ganze ja in SMD routen, damit hatte ich schonmal angefangen. Habe es aber bleiben lassen, da man nämlich nur recht fummlig Leiterbahnen zwischen den Pins durchrouten kann. Also werden wahrscheinlich viel mehr Durchkontaktierungen nötig sein. Das ist für eine Handmade-Platine eher ungünstig. Aber wers gut hinbekommt, da nehme ich gerne Anregungen auf ;-) Gruß Old-Papa Ach ja, herzlichen Dank auch an Christian und Charly, die hatten ja den Grundstein für mein Layout gelegt.
Angehängte Dateien:
-
Bottom-Komparator-1a.gif
130 KB -
Top-Komparator-1a.gif
150 KB
Kaum online und schon Änderungen..... Naja, zum Einen habe ich die 4. Pins unter den Einstellreglern noch hingefummelt und zum Anderen ein paar Leiterbahnen begradigt. Dann noch (damit hier Friede herscht) auch die beiden "Quarzkondensatoren" direkt an den richtigen GND-Pin vom µC gehäkelt. So, das wars dann aber wirklich ;-) Gruß Old-Papa
Old -papa schrieb: > Naja, zum Einen habe ich die 4. Pins unter den Einstellreglern noch > hingefummelt Danke. Das fehlte mir doch gleich. > Dann noch (damit hier Friede herscht) auch die beiden > "Quarzkondensatoren" direkt an den richtigen GND-Pin vom µC gehäkelt. Warum hast du den Abblock-C von 100n nicht auch gleich direkt zwischen Pin 7 und 8 des Mega8 gelegt? Auf der L-Seite direkt oberhalb ist da massig Platz zwischen dem Mega8 und dem Via. XL
Hallo Axel, das mit dem "massig Platz" ist ja relativ. Ich müsste den Quarz etwas verschieben. Doch wie schon geschrieben, die Masse beider Platinenseiten ist ja auf kürzestem Weg über Durchkontaktierungen und die µC-Pins verbunden. Da kann weder nennenswerte Induktivität noch Widerstand entstehen. Ich hatte ja in den letzten Tagen (als diese komischen Fehler auftraten) extra mein 150MHz-DSO angeschlossen und nach Störimpulsen gesucht. Zumindest mit meinen Tastköpfen war da absolut nichts nachzuweisen. Nur allgemeines Rauschen. So, aber damit alles "den Vorschriften entspricht", habe ich das jetzt auch noch gemacht ;-) Fotos gibts aber erst, wenn sich nicht noch andere Macken zeigen. Gruß Old-Papa
Angehängte Dateien:
-
Vierfach-Bottom-1.gif
270 KB -
Vierfach-Top-1.gif
300 KB
So, hier die letzten Fotos... Mal sehen, wann mein Kumpel mir die ätzen kann. Gruß Old-Papa
Hallo Charly, ist doch hier mehrfach gepostet worden. Klar, ein paar kleine Änderungen (eher Zusätze) gibt es jetzt, doch das ist alles ganz simpel und nachvollziehbar. Mal sehen was heute noch so ist, vielleicht pinsel ich ja noch einen. Old-Papa
Old -papa schrieb: > ist alles ganz simpel und nachvollziehbar. ja wenn mans weis schon, also ich hab keine Lust mich durch die ganzen Post's zu kaempfen um deine gedankengaenge zu verfolgen um dann doch festzustellen das du doch was nicht erwaehnt hast..... also Axel hat sein Schaltbild gepostet, Christian und ich auch, also i finde es nicht grad die feine Art nachdem dir hier doch wirklich viel geholfen wurde, oder ? vlG Charly
Hallo Charly, bleib doch mal ganz entspannt. Ich hatte nachts um einse nun wirklich keine Lust mehr einen Schaltplan zu pinseln. Aber Du kannst davon ausgehen, das ich das ganz sicher noch machen werde. Andererseits ist das doch genau der Plan, den Du, Christian und Axel schon gezeichnet haben. Wie ein 74HC132 mit seinen Gattern beschaltet wird, ist erstes 1x1 der Digitaltechnik (und nun wirklich mit einem Blick aus dem Layout zu entnehmen). Bleibt der Komparator. Der ist nach Standardschaltung aus dem Datenblatt aufgebaut, besteht aber im einfachsten Fall auch nur aus sich selbst und einem Widerstand. Die Jumperei, die Axel sich noch gewünscht hat, habe ich ja auch nur so eingezeichnet, dazu existiert nichtmal ein Plan (doch, bei Axel und mir im Kopf). Also, heute am Tage mach ich was anderes, und wenn der Tatort vorbei ist, kann ich ja noch einen kompletten Schaltplan zeichnen. Ganz entspannte Grüße Old-Papa
Hallo ! ich möchte mich auch ganz herzlich für die Fortführung des Projekts bedanken. Bald werde ich auch eine Testschaltung aufgebaut haben und euch darüber berichten können. Im Augenblick arbeite ich noch an einer neuen Firmware für das "HF - mW-Meter bis 2,7 GHz". .
Hallo, nun habe ich mich doch früher an den Schaltplan usw. gemacht. In der PDF ist soweit alles Stand heute enthalten. Firmware gibbet beim Axel ;-) bzw. hier im Thread die aktuelle Version. Als Schaltplan habe ich nur den von Axel gezeichneten um die Änderungen, Eingangsschaltungen und Anmerkungen ergänzt. Gruß Old-Papa
Uwe S. schrieb: > Hallo ! > > ich möchte mich auch ganz herzlich für die Fortführung des Projekts > bedanken. > > Bald werde ich auch eine Testschaltung aufgebaut haben und euch darüber > berichten können. > > Im Augenblick arbeite ich noch an einer neuen Firmware für das "HF - > mW-Meter bis 2,7 GHz". > > . Hallo Uwe, das ist doch das Projekt von Helmut (DL1ALT) oder? Ich habe vor zwei-drei Wochen den NWT502m von ihm fertiggestellt. Besonders das Auflöten des DDS mit 0,5mm Pinabstand war kitzlig, der Rest gut machbar. Das mW-Meter interessiert mich auch, derzeit habe ich aber noch andere Baustellen. Was hast Du an der Firmware verändert? Gruß Old-Papa
Angehängte Dateien:
-
00-bargraph.png
268 Bytes -
01-bargraph.png
266 Bytes -
02-bargraph.png
256 Bytes -
04-bargraph.png
274 Bytes
Hallo Old-Papa, ja richtig ist von DL1ALT. Die Version 1 des mW Meter hatte ich von 2 Jahren auch schon mal aufgebaut, nur wurde da ein µP mit Core 8051 zum Einsatz. Die aktuelle Version 2.0 basiert auf einem atMega Design und so habe ich die Firmware auf die Hardware von DL1ALT komplett neu in "C" geschrieben, den Speicherbedarf verringert, 4 (3 neu) Bargraph-Zeichensätze eingebaut. Und Betreibe den atMega88 nun auch mit einem 1-Wire Bootloader (peda) an PD7. Die Bargraphzeichensätze lassen sich per Dip-Schalter auswählen und werden beim booten eingelesen. Die dBm, Leistung P in den Einheiten pW,nW,µW,mW,W und kW und Spannung U an 50R werden in den Einheiten pV,nV,µV,mV,V und kV berechnet, automatisch auf 4 Ziffern mit Punkt skaliert. z.B. a) 1mW ==> 1,000mW b) 890µW ==> 890,0µW usw. Ziel ist es auch externe Dämpfungsglieder, bzw. Leistungsdämpfungsglieder mit ein zu beziehen und die Eingangsleistung richtig an zu zeigen. Auch wäre eine Kalibierrung mit verschiedene Frequenzen und Stützstellen denkbar, aber das liegt nicht auf meiner Linie, da wir die Frequenz direkt nicht messen können. Auch denke ich darüber nach ein 4x 20 Zeichen Display zu verwenden, fehlt mir aber noch in meinem Bestand. Dafür habe ich genügend 2x 24 Zeichen Displays. Im Anhang die Vertreter für die Bargraph-Zeichensätze. .
hallo old-papa wird man die prints bei dir auch kaufen koennen ? schoene gruesse hans --
Hallo Hans, ein paar aus Handarbeit für Hobbykollegen habe ich seit heute hier, wenns kommerziell sein soll, ganz bestimmt nicht. Schick mir mal eine PN oder Mail. Gruß Old-Papa
@old-papa ich habe dir eine PN zukommen lassen. @uwe ja, so trifft man sich wieder. schoene gruesse hans
Hallo, heute habe ich mal eine der neuen Platinen aufgebaut. Ums mal gleich zu sagen, das mit dem Komparator überzeugt mich noch nicht ganz. Im Bereich oberhalb 10MHz ist alles ok, darunter wird das immer unstabiler, je tiefer man kommt. Mit meinem 40MHz-Oszi kann ich kein Schwingen erkennen, ich weder mal den 150MHz auf den Werktisch stellen. Morgen werde ich mal den HC132 installieren. Nach oben hat der Komparator was gebracht, 57.0000MHZ waren erreichbar. Dabei konnte die Eingangsspannung irgendwas von Sinus bis Rechteck sein. Die Fotos zeigen einer Version mit 2x16er Display, wobei in der oberen Zeile der Inhalt der beiden Zähler Hexadezimal (wenn ich Axel richtig verstanden habe) für die Testphase und die untere den berechneten Messwert darstellt. Oben ganz rechts dann noch der Hex-Wert der vier Jumper (nicht gesetzt, also FF) das Foto mit dem 1x16er hat hinter dem Messwert (MHz) noch eine "Irrläuferziffer" und wieder den Wert der Jumper. Die Irrläuferziffer habe ich wohl durch irgendeinen falschen Eintrag in der Config.h (die ist neu) verbockt. 57MHz schafft mein Generator, in den diese Anzeige ja mal rein soll, zwar nicht, doch schön zu wissen, dass es geht. Old-Papa
Angehängte Dateien:
-
66.0000MHz.jpg
110 KB
Wenn man denkt es geht nicht mehr, kommt....... So auch hier ;-) Siehe Foto. Die Zweifler vom Anfang dieses Threads können also aufatmen ;-) Das ist noch immer die gleiche Schaltung mit HC590 und HC74 sowie den TLV3501 im Eingang. Gespeist allerdings mit TTL (oder eher CMOS) Gruß Old-Papa
Hola, Old -papa schrieb: > das mit dem Komparator überzeugt mich noch nicht ganz. Ich hatte ehrlich gesagt von Anfang an Bauchschmerzen bei der Schaltung. Auch wenn der TLV3501 am Eingang rail-to-rail sein soll, meist hat man doch Einbußen, wenn man die Eingänge beide auf V- legt. > Nach oben hat der Komparator was gebracht, 57.0000MHZ waren erreichbar. > Dabei konnte die Eingangsspannung irgendwas von Sinus bis Rechteck sein. Ich sehe gerade, daß der Zähler für F_x kurz vor dem Überlauf steht. In der Tat wirst du mit der derzeitigen Software so nicht über 4*fref kommen. Also knapp über 57.2MHz. Läßt sich aber per Software-Änderung leicht beheben:
1 | PHASE2(); /* wait for MINCYCLES fref pulses */ |
2 | |
3 | - while (nref.b[2] < (MINCYCLES/65536)+1) { |
4 | + while ((nref.b[2] < (MINCYCLES/65536)+1) && (nx.b[2] < 0x7c)) { |
5 | wdt_reset(); |
6 | sleep_cpu(); |
7 | }
|
Dieser Fix kann später wieder raus, wenn ich die Zähler auf 32 Bit aufgebohrt habe. > das Foto mit dem 1x16er hat hinter dem Messwert (MHz) noch eine > "Irrläuferziffer" und wieder den Wert der Jumper. Die Irrläuferziffer > habe ich wohl durch irgendeinen falschen Eintrag in der Config.h (die > ist neu) verbockt. Das ist einfach der Rest dessen, was bei einem 2x16 Dispaly in der ersten Zeile stehen würde. > 57MHz schafft mein Generator, in den diese Anzeige ja mal rein soll, > zwar nicht, doch schön zu wissen, dass es geht. Wenn du einen Speed-Rekord willst, mach die Versorgungsspannung größer. Bis 6V sollte gerade noch gehen (keine Gewähr ;) XL
Stimmt, hatte ich garnicht mehr dran gedacht. #define MINCYCLES (1*1024*1024L) /* min number of fref cycles */ Die hatte ich aber vorhin beim 57MHz-Ende auch so. Ich versuch jetzt mal etwas höher (2* oder 3*xxx) Old-Papa
Old -papa schrieb: >> Wie hast du das gemacht? MINCYCLES verringert? > Stimmt, hatte ich garnicht mehr dran gedacht. > #define MINCYCLES (1*1024*1024L) /* min number of fref cycles */ OK. Dann geht das auch. Das Limit, das der Zählerüberlauf setzt ist fref * 0xFFFFFF / MINCYCLES XL
Aha! Ich habe jetzt den Komparator runter geschmissen und einen HC132 drauf. Ergebnis: Im unteren Hz-Bereich zappelt die Anzeige genau so wie mit dem Komparator. Ab ca. 250kHz wird das ruhiger, nach oben ging das dann nur noch bis 65.0000MHz. Allerdings ist mit Sinus am Eingang ziemlich Essig, muss schon halbwegs Rechteck sein. Mal sehen was es bringt, den Eingang des HC132 auf knapp halbe Betriebsspannung zu legen und zum Eingang einen Kondensator davor zu schalten. Für heute ist aber Schluss, muss noch etwas "regenerieren" um dem Arbeitgeber zum Ausbeuten zu Willen zu sein ;-) Gruß Old-Papa
Frank schrieb > Die Grafik mit 20mVpp nach HCMOS-Signal bei 50MHz ist ja nett, > allerdings ist die Beschaltung dafür nicht dargestellt. Ohne > nennenswerte Hysterese >=50mV wird das gezeigte Ausgangssignal auch ohne > Eingangssignal vorhanden sein oder bei NF sporadisch hinzugefügt ;-) Ich wiederhole es noch einmal; vielleicht bist Du jetzt einsichtiger ;-) Kritisch ist der Bereich 0,xHz - 1MHz, um die Signale sauber aufzuarbeiten. Dazu hatte ich auch etwas geschrieben: Hysterese, Dämpfung, Tiefpass, DC-Offset. Verbeiß Dich nicht an der oberen Grenzfrequenz, die kann man per Vorteiler nahezu beliebig erhöhen.
Hallo Frank, natürlich verbeiße ich mich nicht an der oberen Grenzfrequenz. Ich habe hier kommerzielle Zähler bis über 2GHz, darum geht es ja nicht. Ich wollte halt mal sehen, wie weit man gerade ohne Vorteiler und Gedöhns kommt. Das ein Komparator um unteren Frequenzbereich schneller unstabil als im oberen wird, ist mir auch klar. Dämpfung und LP fallen allerdings aus, bleibt noch etwas mit der Hysterse zu experimentieren. Wenn nicht, bleibt der halt weg. Mit gleichem Pinnig gibt es auch "HF-OPVs". Wer mit sehr schwachen Signalen arbeiten muss, könnte damit auch experimentieren. Die Variante mit dem HC132 setzt halt höhere Eingansspannung und am besten Rechteck voraus. Gehen tut das aber, ohne Frage. Was kann vereinfacht werden? 1. Eine spezielle HF-Buchse am Eingang (ich habe eine SMB gezeichnet) ist nicht unbedingt nötig, man kann das HF-Kabel (Koax) auch direkt anlöten. Ja sogar HF-Kabel ist entbehrlich, verdrillte Schaltdrähte gehen bei kurzen Verbindungen auch. 2. Der 4x4,7k-SIP nebst Jumper muss auch nur bestückt werden, wenn man die zukünftig vorgesehenen Zusatzfunktionen nutzen will. 3. Es ist unnötig und bei einer selbst geätzen Platine sogar hinderlich, dass für alle ICs Fassungen verwandt werden. Höchstens für den µC. 4. Der ISP-Header muss ja eigentlich auch nicht, ich habe den bisher nicht genutzt, programmiere immer im externen Programmer. 5. Der Jumper zur Umschaltung der Kalibrierspannung kann durch Brücke zum Mittelanschluss vom 22k ersetzt werden, notfalls kann man den ja nach Masse kurbeln. 6. Die Drossel (10µ, Wert unkritisch) kann durch eine Brücke ersetzt werden. 7. Der 100R kann entfallen, wenn ohne Hintergrundbeleuchtung gearbeitet wird. 100ohm sind aber auch nicht für jedes beleuchtete Display richtig, hier muss man halt fummeln ;-) Was muss unbedingt beachtet werden? 1. Das Display! Da gibt es selbst bei diesen Standardabmessungen deutliche Unterschiede, weil die Kontaktreihe häufig etwas versetzt ist. Ich habe welche, die passen gut und andere sitzen 1-3mm daneben. 2. Der 22k zur Kalibrierung muss ein Mehrgangtrimmer sein, sonst ist eine Kalibrierung fast unmöglich. 3. Die 22p-Kondensatoren am Quarz sollten ausgemessen werden. Die Doofköppe beim Reichelt hatten mir mal statt 22p 1n eingetütet. Die anderen Cs sind völlig unkritisch. 4. Bei der selbstgeätzten Platine am besten als erstes die Fassung für den µC einlöten und auch die wenigen Leiterbahnen oben anschließen. Später kommt man da nur mühsam heran. Old-Papa
Niedrige Frequenzen mit hoher Auflösung zu zählen ist immer eine Herausforderung. 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. Zum Schluss ist noch die Stabilität des Mutterquarzes limitierend. Wie weit das Programm des Mikroprozessors darauf Einwirkung hat vermag ich nicht zu beurteilen , das ist sicherlich eine Sache der intelligenten Programmierung des Prozessors. In professionellen Zähler verwendet man den Mikroprozessor aber nur zur Auswertung. Gezählt wird mit Asics , die rein statisch aufgebaut sind, also feste Zählerarrays haben. Diese übergeben das Zählergebnis an den Mikroprozessoer. 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. Ralph Berres
>Mehr als 7 Stellen bei 1KHz Messfrequenz sind einfach nicht drin. Damit wäre Opa ja schon überglücklich ;-) >Dämpfung und LP fallen allerdings aus, bleibt noch etwas, ... Warum? Soll es funktionieren oder nur schön aussehen? Schnelle Komparatoren (und OPV) lieben es zu schwingen. Daher ist eine nicht zu kleine Hysterese Voraussetzung für stabiles Arbeiten. OPVs sind für höhere Frequenzen als Komparator nicht gut geeignet.
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
Verstehe ich das richtig: wenn man Statistik anwendet, braucht man keinen Komparator mehr am Eingang? ;-)
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
Angehängte Dateien:
-
10k-an-HC132.jpg
130 KB
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
Angehängte Dateien:
-
eingangsstufe.png
9 KB
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.
Angehängte Dateien:
-
breadboard.jpg
560 KB
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
Angehängte Dateien:
-
Web-Bild.GIF
11 KB
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 zusammen, geht's hier noch weiter ??? Ich suche immer noch einen Frequenzzähler als Bausatz, 1Mhz reicht. mfg steiner
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: > Immer diese Drängler :-) ja genau, i kann die auch nicht leiden :) unn wo kann man das Teil f. kleines Geld kaufen ?
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.
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?"
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.
Angehängte Dateien:
-
schematic.png
24 KB
Hallo, hier endlich mal das Schaltbild und nochmal die Firmware für die Variante mit LED-Display. XL
@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
Angehängte Dateien:
-
Anzeige_aussen.JPG
15 KB -
Oberseite.JPG
28 KB -
Unterseite.JPG
40 KB
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 --
Angehängte Dateien:
-
PIC-Handzaehler.jpg
250 KB
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.
150MHz mit 5 Stellen ist doch langweilig. Wieviel Stellen Zeigt das Gerät denn bei 150Hz?
Willi schrieb: > Wieviel Stellen Zeigt das Gerät denn bei 150Hz? Hast du das Meßprinzip verstanden? Dann erübrigt sich die Frage.
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.
Angehängte Dateien:
-
LCD-2x16-01.gif
28 KB
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
Angehängte Dateien:
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
Angehängte Dateien:
-
LCD-1x16__geht.gif
52 KB -
LCD-2x16__geht-auch.gif
50 KB
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
Angehängte Dateien:
-
FreqZaehler-Kupfer02.jpg
130 KB -
FrequZaehler-1x16-16_6kHz.jpg
130 KB -
FrequZaehler-1x16-32MHz.jpg
130 KB -
FrequZaehler-2x16-222kHz.jpg
120 KB -
FrequZaehler-2x16-228kHz.jpg
110 KB
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:
1 | HFUSE = 0xC9 |
2 | LFUSE = 0x9F |
3 | |
4 | # Fuse high byte: |
5 | # 0xc9 = 1 1 0 0 1 0 0 1 <-- BOOTRST (boot reset vector at 0x0000) |
6 | # ^ ^ ^ ^ ^ ^ ^------ BOOTSZ0 |
7 | # | | | | | +-------- BOOTSZ1 |
8 | # | | | | + --------- EESAVE (don't preserve EEPROM over chip erase) |
9 | # | | | +-------------- CKOPT (full output swing) |
10 | # | | +---------------- SPIEN (allow serial programming) |
11 | # | +------------------ WDTON (WDT not always on) |
12 | # +-------------------- RSTDISBL (reset pin is enabled) |
13 | # Fuse low byte: |
14 | # 0x9f = 1 0 0 1 1 1 1 1 |
15 | # ^ ^ \ / \--+--/ |
16 | # | | | +------- CKSEL 3..0 (external >8M crystal) |
17 | # | | +--------------- SUT 1..0 (crystal osc, BOD enabled) |
18 | # | +------------------ BODEN (BrownOut Detector enabled) |
19 | # +-------------------- BODLEVEL (2.7V) |
XL
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?
Angehängte Dateien:
Hier noch mal einen Shot von den Fuses.
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
Angehängte Dateien:
-
FreqZaehler-1x16-36MHz.jpg
120 KB -
FreqZaehler-1x16-40MHz.jpg
120 KB -
FreqZaehler-1x16-50MHz.jpg
120 KB
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. :-/
Angehängte Dateien:
-
10Hz.jpg
84 KB -
500kHz.jpg
63 KB -
2MHz.jpg
83 KB -
8MHz.jpg
64 KB
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?
Angehängte Dateien:
-
1x16_10Hz.jpg
77 KB -
1x16_8MHz.jpg
87 KB
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.
Angehängte Dateien:
-
FreqZaehler-Best01.jpg
96 KB -
FreqZaehler-Platine-Best-ob.jpg
270 KB -
FreqZaehler-Platine-unten.jpg
310 KB
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 | EEMEM uint32_t ee_fref = F_CPU; |
Der Rest des EEPROM ist egal, wird aber beim Löschen des Controllers typischerweise mit gelöscht - also auf FF gesetzt. In meinem steht in den letzten 4 Bytes des EEPROM noch die Zahl, wie oft ich den Controller schon geflasht habe. XL
Angehängte Dateien:
-
1kHz.jpg
92 KB -
8MHz_2_.jpg
87 KB -
500Hz_LED.jpg
89 KB
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:
1 | > ... 3A3034303030303030313437414441303039340D0A ... |
2 | : 0 4 0 0 0 0 0 0 1 4 7 A D A 0 0 9 4\r\n |
Das heißt dein Brenner hat das .eep File nicht als .hex erkannt, sondern als rohes Binärfile interpretiert und einfach stur Zeichen für Zeichen ins EEPROM geschrieben. Vielleicht gibts ja irgendwo eine Option, um das einzustellen... XL
Angehängte Dateien:
-
Bascom-eep.gif
21 KB -
Bascom-eep-Dump.gif
19 KB
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
Angehängte Dateien:
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
Ach.. ihr seid ja immer noch nicht weiter gekommen. Noch immer keine Eingangsstufe, keine Stromversorgung, kein Gehäuse... W.S.
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
Angehängte Dateien:
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:
1 | #elif CUSTOMIZATION == michael_2x16
|
2 | |
3 | #define SHOW_GREETING show_greeting_michael_2x16
|
4 | #define SHOW_RESULT show_result_michael_2x16
|
5 | #define PHASE1()
|
6 | #define PHASE2()
|
7 | #define PHASE3()
|
8 | #define UNDERFLOW() lcd_gotoxy(15,1); lcd_putc('U')
|
9 | #define IS_VALID() lcd_gotoxy(15,1); lcd_putc(' ');
|
10 | #define LCD_LINES 2
|
11 | #define LCD_DISP_LEN 16
|
12 | #define DEBUG 0
|
Eigentlich ganz simpel: SHOW_GREETING und SHOW_RESULT verweisen auf neue (noch zu schreibende) Funktionen. Die PHASE Makros tun nix. Und UNDERFLOW und IS_VALID setzen bzw. löschen die Underflow-Anzeige. Und schon sind wir halb fertig. Der zweite Teil ist auch nicht schwerer. Da müssen wir die neuen Funktionen show_greeting_michael_2x16() und show_result_michael_2x16() in main.c einfügen. Die Funktionen kopiert man am besten von einer existierenden Anpassung, benennt sie um und paßt sie dann schrittweise an. Die neue SHOW_GREETING FUnktion könnte z.B. so aussehen:
1 | void show_greeting_michael_2x16(void) |
2 | {
|
3 | lcd_puts(VERSION"\nHallo Michael!"); |
4 | _delay_ms(2000); |
5 | }
|
Hier machen wir uns zu Nutze, daß der C-Compiler aufeinanderfolgende Stringliterale zusammenfaßt. Die SHOW_RESULT Funktion ist eine Abwandlung der normalen 2x16 Variante:
1 | void show_result_michael_2x16(void) |
2 | {
|
3 | unsigned char len= calculate_frequency(); |
4 | char* bufptr= buffer; |
5 | |
6 | lcd_clrscr(); |
7 | lcd_putc('F'); |
8 | lcd_putc(' '); |
9 | |
10 | /* nur die Zahl ausgeben */
|
11 | while ((*bufptr == '.' || (*bufptr >= '0' && *bufptr <= '9')) && len--) { |
12 | lcd_putc(*bufptr++); |
13 | }
|
14 | |
15 | /* Trennzeichen nach Geschmack */
|
16 | lcd_putc(' '); |
17 | |
18 | /* und jetzt noch die Einheit */
|
19 | while (len--) { |
20 | lcd_putc(*bufptr++); |
21 | }
|
22 | |
23 | IS_VALID(); |
24 | }
|
Im Prinzip hätte man das einfacher haben können, wenn man sich darauf verläßt, daß immer die ersten 7 Zeichen im Buffer die Zahl und die letzten 3 die Einheit sind. Aber wir wollen uns ja nicht den Weg verbauen, wenn mal jemand eine Änderung auf 7 Stellen schreiben sollte. Also erkennen wir die Zahl lieber am Inhalt. Angehängt sind die neue config.h, main.c und ein diff (basierend auf Version 1.4), um die oben besprochenen Änderungen auf eine eigene Version des Quellcodes anwenden zu können. XL
Angehängte Dateien:
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
Hallo Eric und Ralph, und vergesst nicht den AD8310 damit habe ich für den fa-nwt weitere Tastköpfe entwickelt. - http://www.qrpforum.de/index.php?page=Thread&threadID=4591 Bei mir laufen die nun in SMA und BNC Bestückung sehr gut. Technische Daten AD8310: Fast, Voltage-Out, DC to 440 MHz, 95 dB Logarithmic Amplifier Datenblatt: http://www.analog.com/static/imported-files/data_sheets/AD8310.pdf
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
Das wird ja noch richtig interessant hier ;) Ich selbst bin erst wieder in den dunkleren Monaten oben im "Elektroniklabor"... Gruß Old-Papa
Für dieses Projekt gibt es jetzt auch einen eigenen Artikel im Wiki: http://www.mikrocontroller.net/articles/Frequenzz%C3%A4hlermodul XL
Angehängte Dateien:
-
FreqZ-Periode-01.jpg
82 KB -
FreqZ-Periode-02.jpg
89 KB -
FreqZ-Periode-03.jpg
95 KB
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äre das nicht was für den Frequenzzähler? http://cgi.ebay.de/10MHZ-ISOTEMP-131-OCXO-OSCILLATOR-square-wave-VCC-small-/170558942064?pt=LH_DefaultDomain_0&hash=item27b61aeb70 MFG
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.
Timo schrieb: > Wäre das nicht was für den Frequenzzähler? > > http://cgi.ebay.de/10MHZ-ISOTEMP-131-OCXO-OSCILLATOR-square-wave-VCC-small-/170558942064?pt=LH_DefaultDomain_0&hash=item27b61aeb70 > > MFG Radio Eriwan würde sagen: Im Prinzip ja, aber.... Die Dinger sind nicht schlecht, habe irgendwo auch noch 2-3 Stück, doch für dieses Modul der blanke Overkill. Schon die Größe spricht dagegen, die sind ja fast so groß wie das ganze Modul. Old-Papa
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...
Den SF245 habe ich gegen den BF199 ersetzt. Ist halt ein NPN HF Transistor, ft=1,1GHz und sollte auch etwas Verstärkung beta haben. Über Vorverstärker habe ich mir hier ausgelassen: http://www.qrpforum.de/index.php?page=Thread&postID=46013#post46013
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
branadic schrieb: > wie wäre es mit einem logarithmischen Verstärker und bei 25 VSS am Eingang? Ralph Berres
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
Angehängte Dateien:
-
FreqZ-Periode-61MHz-04.jpg
100 KB
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
Angehängte Dateien:
-
FreqZ-Periode-4MHz-01.jpg
110 KB
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
Michael das dürfte die Unsicherheit des letzten Bits sein, welche prinziepiell immer vorhanden ist. Ralph Berres
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:
1 | text data bss dec hex filename |
2 | 1902 16 27 1945 799 main.elf |
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
Angehängte Dateien:
-
FreqZ-ATmega-48-01.jpg
81 KB
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
Angehängte Dateien:
-
FreqZ-ATmega-48-02.jpg
98 KB
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 | fx fref fref * Nx |
2 | -- = ---- <==> fx = --------- |
3 | Nx Nref Nref |
Wir betrachten nun noch die 64-Bit Arithmetik: "fref * Nx": 32-Bit * 32-Bit liefert ein 64-Bit Ergebnis. "fref" ist ~F_CPU "Nx" setzt sich nun aus einen 16-Bit Software Zähler in Timer0 und den 9-Bits aus HC590 und dem einen Bit HC7474 zusammen. "Nref" setzt sich nun aus einen 16-Bit Software Zähler in Timer1 und aus 16-Bit des Timer1 zusammen. Die nachfolgende Division einer 64-Bit Zahl "fref * Nx" durch eine 32-Bit Zahl "Nref" liefert als Ergebnis eine 32-Bit Zahl. Den Rest betrachten wir nicht. Ich rechne als Mathematiker lieber richtig, als mir Gedanken über Fehler mit dem Datentype 'float' unter avr-gcc zu machen. .
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...
Angehängte Dateien:
-
Anzeige.png
120 KB
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
Ralph Berres schrieb: > Den KP303 kenne ich nicht. Muss wohl ein Fet aus der ehemaligen DDR > sein. Ist russisch. Hilft vllt. bei der Ersatzsuche. Belegung (auf Beinchen schauen): Nase -D -S -G -Masse- Nase in Uhrzeigerrichtung.
Ein Vorschlag für eine passende Eingangsstufe findet sich hier: Beitrag "Eingangsstufe für Frequenzzähler DC-50MHz, +5V"
da isser ja! Ich bin begeistert von deinem Projekt! Willst du das nicht mal hier vorstellen? Gruß Michael
Guten Tag, habe mir den kompletten Thread durchgelesen, und bin begeistert. Nachdem eine version fuer die ATmega48..328 vorhanden war, dachte ich mir, bau mal nach. Problem : Entweder zu dumm beim kompilieren ( mit winavr 2009, da die version 2010 wohl probleme bereitet ), oder zu dumm beim kompilieren. Das ganze basiert auf ATMEGA88 ( warum BOD auf 2,7V wenn das diggen auf 5 V läuft ? ) Quarz hatt ich nen PAL 17.734475 MHz, habe aber dann auf 16Mhz umgelötet, mit gleichem erfolg-=> geht nicht ( latürnich neu kompiliert mit 16Mhz) Entweder mein LCd hat arge Timingprobleme mit der library oder ich weiss nicht. Dachte mir, brenne das ganze mit der HEX vom Uwe S. für den Atmega48 und angepassten fuses für den Atmega88. Immer nocht nix. Und zwar passiert folgendes: es sollte anzeigen : "V1.4 (c)XL" zeigt aber an : "########XL" kompiliere ich anders: "XLV1.4 (c)" zeigt das gute stueck: "XL########" die rauten zeigen wirres zeug, bin grad nicht daheim um die korrecten zeichen anzugeben. Das interessante ist aber das XL immer korrekt angezeigt wird. Meine bitte nun: hat jemand mal ne kompilierte ATmega88 version die ich testen kann ?! Danke.
hallo ich bin nicht der guru in diesen belangen. habe das nette teil nur nachgebaut. und bin auch begeistert davon. aber soweit ich weiss, darf der quarz nicht mehr als ein viertel von 50 MHz sein. vielleicht liegts daran. gruss hans
Hi, die Antwort kommt etwas spät, aber besser als nie... > Problem : Entweder zu dumm beim kompilieren ( mit winavr 2009, da die > version 2010 wohl probleme bereitet ), oder zu dumm beim kompilieren. benutzt du für's Kompilieren "Programmers Notepad" ? Tip: Du mußt vor jedem Kompilieren "cleanen" > Das ganze basiert auf ATMEGA88 > ( warum BOD auf 2,7V wenn das diggen auf 5 V läuft ? ) Im Makefile ist der Mega48 angegeben muß also auf den Mega88 angepasst werden! BOD ist, glaube ich, wurscht. > Quarz hatt ich nen PAL 17.734475 MHz, habe aber dann auf 16Mhz > umgelötet, mit gleichem erfolg-=> geht nicht ( latürnich neu kompiliert > mit 16Mhz) Da gehört ein 14,31MHz quarz rein! > Entweder mein LCd hat arge Timingprobleme mit der library oder ich weiss > nicht. > Dachte mir, brenne das ganze mit der HEX vom Uwe S. für den Atmega48 und > angepassten fuses für den Atmega88. Immer nocht nix. > Und zwar passiert folgendes: > es sollte anzeigen : "V1.4 (c)XL" zeigt aber an : "########XL" > kompiliere ich anders: "XLV1.4 (c)" zeigt das gute stueck: "XL########" > die rauten zeigen wirres zeug, bin grad nicht daheim um die korrecten > zeichen anzugeben. > Das interessante ist aber das XL immer korrekt angezeigt wird. Ich glaube du hast das falsche Kompilat von Uwe erwischt, das wollte noch nicht so richtig, das letzte geht aber. Was hast du denn für ein Display? > Meine bitte nun: hat jemand mal ne kompilierte ATmega88 version die ich > testen kann ?! Ich hänge mal Uwe's angepasstes File an, ich habe es jetzt extra noch mal getestet. Ist auf den Mega48 angepasst, weil der bei mir verbaut ist. Also im Makefile noch den Mega88 eintragen, dann muß das gehen. Es wird noch die Ver.1.4 angezeigt, ist aber schon mit Periodendauer für die 2. Displayzeile. Viel Spass damit und gib mal Feeback! Gruß Michael
Angehängte Dateien:
-
total.JPG
180 KB -
P1207078.JPG
170 KB -
P1207070.JPG
170 KB -
P1207068.JPG
150 KB -
P1207069.JPG
160 KB
Erfolg, erfolg, Danke an Michael D. Hab die kompilierte version benutzt und hat auch nicht geklappt. Denk mir, kann ja nicht sein... Platine in die Tonne gekloppt. Alles auf Steckbrett gepappt, und siehe da es funktioniert. mit ATmega88, 16 Mhz Michaels layout war ja arg eng ( wie macht ihr das mit dem bohren und löten ? 0,6 bohrer und lötstation ?!).Meine Tonertransfer-methode schaft 10 mil. Also das ganze neu gemacht basierend auf Michael's layout ( denke ich mal ) Poti weggelassen, wird digital abgeglichen ( PC5 auf GND). Mein ISP stecker ist ein-reihig ( MISO MOSI CLK RESET GND ) Alle Bohrlöcher auf 0,8, kein Hühnerfutter ( SMD ) Weniger brücken. 16Mhz abgeglichen, Kalibrieren ist ja nicht ;) Firmware drauf, und erfolg.. Muss nur noch das ganze ändern , so das nicht mehr "HALLO MICHAEL" erscheint.... Ihr dürft also vermerken das das ganze auf ATMEGA88 funktioniert. Beizeiten wird mit 17734475 MHz probiert, mit Uwe's version. Mein Display ist irgendwas kompatibles, Fotos oben... P.S. woran lags ?! natürlich dummheit. Microlötbrücken an der R/W leitung.Durch rumgefrickle Leitung mal da, dan mal nicht... Die sollte schon festen pegel haben. Nuno
Hi, Nuno Faria schrieb: > Erfolg, erfolg, > Danke an Michael D. Bitte! > Hab die kompilierte version benutzt und hat auch nicht geklappt. > Denk mir, kann ja nicht sein... > Platine in die Tonne gekloppt. > Alles auf Steckbrett gepappt, und siehe da es funktioniert. > mit ATmega88, 16 Mhz Wird mit der 16MHz Frequenz denn alles richtig angezeigt? > Michaels layout war ja arg eng ( wie macht ihr das mit dem bohren und > löten ? 0,6 bohrer und lötstation ?!).Meine Tonertransfer-methode schaft > 10 mil. 0,6er Bohrer und meine Lötstation hat den Geist aufgegeben, ging auch mit dem Ersa Multitip und 1mm Lötspitze. > Also das ganze neu gemacht basierend auf Michael's layout ( denke ich > mal ) Ich mache es wie du mit der Tonertransfererei! Hättest du was gesagt, dann hätte ich noch mal ein modifiziertes Layout posten können mit weniger Brücken u.s.w. > Poti weggelassen, wird digital abgeglichen ( PC5 auf GND). > Mein ISP stecker ist ein-reihig ( MISO MOSI CLK RESET GND ) > Alle Bohrlöcher auf 0,8, kein Hühnerfutter ( SMD ) > Weniger brücken. > 16Mhz abgeglichen, Kalibrieren ist ja nicht ;) > Firmware drauf, und erfolg.. Muss nur noch das ganze ändern , so das > nicht mehr "HALLO MICHAEL" erscheint.... Och... :-) Das war der Axel, mit der FW hat er ganze Arbeit geleistet... > Ihr dürft also vermerken das das ganze auf ATMEGA88 funktioniert. > Beizeiten wird mit 17734475 MHz probiert, mit Uwe's version. Uwe hat hier 2 Versionen gepostet, wobei bei einer nur gezappel auf dem Display erscheint. Berichte mal, wie es da bei dir aussieht. > > Mein Display ist irgendwas kompatibles, Fotos oben... > > P.S. woran lags ?! natürlich dummheit. Microlötbrücken an der R/W > leitung.Durch rumgefrickle Leitung mal da, dan mal nicht... > Die sollte schon festen pegel haben. Das Problem hatte ich bei meinem 2. Aufbau mit der LED-Version. Man sollte die nackige Platine vorher prüfen, gibt weniger Ärger. > > Nuno Gruß Michael
ich habe das eben noch mal verglichen, hier ist mein Layout. Beitrag "Re: Frequenzzähler 1Hz - 40MHz" Nur wie gesagt, ich habe das noch mal überarbeitet...
> Wird mit der 16MHz Frequenz denn alles richtig angezeigt? > Mit der version die du ( Michael) gepostet hast -> JA. Mit 16Mhz klappt es ja noch in 24bit. Mit dem Pal Quarzen die ich hier rumliegen hatte aber nicht, die sind ja halt 17734475 Hz Der atmega88 kann ja bis 20MHz. Dumm nur mit den 24bit, da passen halt nur 16Mio rein. > Das war der Axel, mit der FW hat er ganze Arbeit geleistet... Suuper dingen, endlich mal etwas das auch funktioniert. > >> Ihr dürft also vermerken das das ganze auf ATMEGA88 funktioniert. >> Beizeiten wird mit 17734475 MHz probiert, mit Uwe's version. > Uwe hat hier 2 Versionen gepostet, wobei bei einer nur gezappel auf dem > Display erscheint. Berichte mal, wie es da bei dir aussieht. >> Uwe hat ja eingentlich drei Versionen gepostet einmal v1.4 ohne prescaler: gleiches resultat wie bei dir, letzte zeichen im Display murks. einmal v1.4 mit prescaler: gezappel ohne ende. Ich hab ja auch kein prescaler dran( wo kommt der dran ?!). Kompiliere ich mit "default_2x16" in der config.h erscheint schon was vernünftiges, bei dieser version. und eine version mit 64bit routinen mit prescaler die bei mir auch nicht funktioniert. Der Wert wird in KHz angezeigt, und zappelt andauern hin un her. Das ganze mit 16Mhz getestet. Nuno
Hi Nuno, > Mit der version die du ( Michael) gepostet hast -> JA. > Mit 16Mhz klappt es ja noch in 24bit. An der ATMega48-88er Ver. von Uwe (das müsste die letzte gewesen sein), habe ich nur noch den die Periodendauer von Axel und die Displayanpassung rein gesetzt, das hat Stunden gedauert bis das funzte! > Suuper dingen, endlich mal etwas das auch funktioniert. Jup, das tut es. ;-) > Uwe hat ja eingentlich drei Versionen gepostet > einmal v1.4 ohne prescaler: gleiches resultat wie bei dir, letzte > zeichen im Display murks. Also irgendwie hatte er da noch so eine Art Bargraf mit eingebaut, soweit ich mich erinnern kann, scheint aber nicht so richtig zu funktionieren. > einmal v1.4 mit prescaler: gezappel ohne ende. Ich hab ja auch kein > prescaler dran( wo kommt der dran ?!). Ich bin der Meinung, das der Vorteiler in der Software auf 128 gesetzt ist, näheres weiß da nur der Uwe! >Der Wert wird in KHz angezeigt, und zappelt andauern hin > un her. eben! Gruß Michael
Angehängte Dateien:
Michael D. schrieb: > 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 Hallo. Sorry for my bad Brief, verwende ich einen elektronischen Übersetzer. Ich interessiere mich für dieses rf-Generator verwendet, um diese Frequenz-Zähler zu testen. Wo finde ich das Design dieser HF-Generator? Ich habe das Forum versucht und nicht gefunden. Ich schätze die Hilfe. Luciano. PY2BBS aus Brasilien.
Hallo Luciano, Hier der Thread vom Frequenzgenerator: Beitrag "Einstellbarer Frequenzgenerator für 0.12 Hz - 8 MHz mit Atmega 8 und Bascom" Achtung, es gibt einige Modifikationen mit verschiedenen Mikrocontrollern. Die Grundschaltung ist mit dem ATmega8 und wird mit einem 16MHz Quarz oder Oszillator betrieben. Die modifizierte Schaltung basiert auf einem ATmega48/88 und wird normalerweise mit 20MHz getaktet(innerhalb der Specifikation)und liefert ein 10MHz Rechteck-Signal. Auf den Fotos läuft der ATmegega48/88 übertaktet(ausserhalb der Specifikation) mit 32MHz und liefert 16MHz Rechteck-Signal. Bis jetzt läuft die Schaltung ohne Probleme, ist aber ohne Gewähr! Gruß Michael
Danke Michael. Dieser Generator ist besonders interessant für Overclocking-Test in höheren Frequenzen. Möchten Sie eine Test-Version zu bauen und sehen, wie weit ich gehen kann (Grenzfrequenz). Eine letzte Frage könnte Layout für Frequenzzähler bieten in LED-Ausführung, einseitig Bord? Kann in EAGLE-Format oder PDF oder was auch immer, nur sicher sein, um anzuzeigen, welches Programm Sie verwenden.
Hi >Auf den Fotos läuft der ATmegega48/88 übertaktet(ausserhalb der >Specifikation) mit 32MHz und liefert 16MHz Rechteck-Signal. >Bis jetzt läuft die Schaltung ohne Probleme, ist aber ohne Gewähr! Mit einem ATTiny25/45/85 oder ATTiny261/461/861 kommt man ohne Übertakten auf über 20 MHz. MfG Spess
Luciano - PY2BBS schrieb: > Danke Michael. Bitteschön! > > Möchten Sie eine Test-Version zu bauen und sehen, wie weit ich gehen > kann (Grenzfrequenz). Könnte interessant werden. ;-) > > Eine letzte Frage könnte Layout für Frequenzzähler bieten in > LED-Ausführung, einseitig Bord? Das Mainboard für die LED-Version hat dasselbe Layout wie die LCD-Version! Ich hänge aber noch mal eine REV.2 im EagleCad mit an. > Kann in EAGLE-Format oder PDF oder was auch immer, nur sicher sein, um > anzuzeigen, welches Programm Sie verwenden. Das "Sandwich-Board" für die 7-Segmentanzeige ist auch im EaglCad-Format und mit einseitigen Layer. Es sind aber sehr viele Drahtbrücken auf dem Top-Layer, also vorsicht bei der Bestückung, es wird sehr eng!!! Das Board ist aufgebaut und erprobt. Beim verschrauben mit dem Mainboard unbedingt Isolierscheiben unter die Abstandshülsen(Metall)legen, sonst gibt es Kurzschlüsse!!! Anbei packe ich den Code von Axel für die LED-Ausführung mit bei. Ich habe viele Stunden daran gesessen, also Feedback ist erwünscht,! ;-) Gruß Michael
spess53 schrieb: > Hi auch Hi > >>Auf den Fotos läuft der ATmegega48/88 übertaktet(ausserhalb der >>Specifikation) mit 32MHz und liefert 16MHz Rechteck-Signal. >>Bis jetzt läuft die Schaltung ohne Probleme, ist aber ohne Gewähr! > > Mit einem ATTiny25/45/85 oder ATTiny261/461/861 kommt man ohne > Übertakten auf über 20 MHz. mit einem generierten, regelbaren Signal??? Das will ich sehen! > > MfG Spess
Hallo Michael, Michael D. schrieb: > Das Mainboard für die LED-Version hat dasselbe Layout wie die > LCD-Version! > Ich hänge aber noch mal eine REV.2 im EagleCad mit an. Ich habe dein Layout mal auf der Wiki-Seite zu "unserem" Modul verlinkt: http://www.mikrocontroller.net/articles/Frequenzz%C3%A4hlermodul dort finden sich auch Links auf die Firmware, es ist also nicht nötig, Kopien in Form von Attachments anzulegen. Prinzipiell bitte ich darum, etwaige Änderungen auch im Wiki nachzutragen. XL
Hallo Axel, Axel Schwenke schrieb: > > Ich habe dein Layout mal auf der Wiki-Seite zu "unserem" Modul verlinkt: fein, freut mich! :-) > dort finden sich auch Links auf die Firmware, es ist also nicht nötig, > Kopien in Form von Attachments anzulegen. Ok, dann wird das in Zukunft so geschehen. > > Prinzipiell bitte ich darum, etwaige Änderungen auch im Wiki > nachzutragen. wird auch gemacht und nur mit vorheriger Absprache! Kleiner Nachtrag zum Mainboard REV2.0 : Das Layout wurde von mir nochmal überarbeitet. 1. Einige Leiterbahnen habe ich abgerundet damit sich die Elektronen nicht den Kopp anstossen. :-) 2. Der 74HC74 wurde um 180 Grad gedreht. 3. Auf dem Top-Layer wurden nochmal 4 Brücken eingespart. 4. Das Eingangs-Signal läuft jetzt ohne Unterbrechung an die Eingangspins des 74HC74 u. 74HC590 5. Die Pinleiste zum Displaymodul hat statt 16 jetzt 17 Pins (für 34er Floppykabel) LCD-Displays für Huckepack-Montage passen trotzdem. Ich hoffe, das passt so, und wünsche noch einen schönen Sonntagabend Gruß Michael @Axel EDIT: Welche 64bit Version ist online? War das die letzte von dir?
Hi >mit einem generierten, regelbaren Signal??? >Das will ich sehen! Die haben 64MHz PWM-Takt. Denk mal nach. MfG Spess
Michael D. schrieb: > EDIT: Welche 64bit Version ist online? War das die letzte von dir? Die ist von Uwe. Ich hab den Code nur mal kurz überflogen und es sah erst mal ganz gut aus. Im Detail will ich das schon länger mal ansehen und evtl. übernehmen(?) Allerdings habe ich dann später hier gelesen, daß der eine oder andere damit Probleme hat (z.B. Nuno am 21.11.2011). So wird das nix. Wenn es Probleme gibt, sprecht den Autor der Software direkt an. Im Zweifelsfall mit einem Post in diesem Thread. Darin dann genaue(!) Beschreibung des Problems. Details sind wichtig! Ach ja. Wikis haben eine Edit-Historie. Linkes Seitenmenu "Dieser Artikel" -> "Versionen/Autoren". Da kannst du auch jederzeit nachsehen wer wann was geändert hat. XL
Hallo Axel, ich habe die nächsten Monate keine Zeit an diesem Projekt weiter zu arbeiten. Die Quellen sind ja da und offen und jeder kann die Änderungen per Diff nachvollziehen. ok? .
Hallo zusammen, dies ist zwar mein erster Beitrag hier, ich lese aber in diesem Forum bereits seit einiger Zeit mit und verfolge insbesondere dieses Thema mit besonderem Interesse. Meine letzten "Abenteuer" mit Mikroprozessoren liegen allerdings fast 30 Jahre zurück und mit Mikrocontrollern habe ich bisher noch keine Erfahrung. Also bitte nicht schlagen, wenn meine Fragen etwas "dumm" erscheinen. Eigentlich komme ich nämlich aus der Mainframe-Ecke... Ich habe versucht, den in diesem Thread beschriebenen Frequenzzähler in etwas abgewandelter Form für einen ATmega32 auf meinem STK500 zu implementieren. Das Teil funktioniert auch, nur bekomme ich je nach zu messender Frequenz mehr oder weniger große Abweichungen von der tatsächlichen Frequenz. Der ATmega32 läuft mit 14 MHz, da dieser Quarz gerade greifbar war. Das Problem scheint von dem Zähler der Referenzfrequenz zu kommen. Die gezählten Perioden von nx sind stabil, während die für nref sich ändern und damit auch die angezeigte Frequenz. Addiere ich einen Korrekturfaktor, damit z.B. die Frequenz eines Quarzoszillators von 5,76 MHz korrekt angezeigt wird (mit einem anderen Frequenzzähler überprüft), so liegt sie bei einem anderen Oszillator mit 18 MHz Frequenz 3000 Hz zu tief. Ist also nix mit 6 Stellen... Irgendetwas stimmt hier nicht. Gibt es vielleicht einen wesentlichen Unterschied zwischen dem ATmega8 und dem von mir verwendeten ATmega32, der für das Problem verantwortlich sein könnte? Ich hatte auch schon die Originalversion von Axel Schwenke ausprobiert (nach Anpassung der Ports), aber auch damit hatte ich Probleme. Vielleicht hat ja jemand von Euch ein ähnliches Phänomen beobachtet und schon gelöst? Natürlich könnte ich beide Zähler mit 74HC590 realisieren, aber das sollte eigentlich nicht nötig sein, oder doch? Vielen Dank für Eure Hilfe, Ralf
Hallo Uwe, Uwe S. schrieb: > ich habe die nächsten Monate keine Zeit an diesem Projekt weiter zu > arbeiten. Das ist gar kein Problem. Im Gegenteil möchte ich dir für deinen Beitrag danken! > Die Quellen sind ja da und offen und jeder kann die Änderungen > per Diff nachvollziehen. genau XL
Hallo Ralf, Ralf G. schrieb: > Ich habe versucht, den in diesem Thread beschriebenen Frequenzzähler in > etwas abgewandelter Form für einen ATmega32 auf meinem STK500 zu > implementieren. Das Teil funktioniert auch, nur bekomme ich je nach zu > messender Frequenz mehr oder weniger große Abweichungen von der > tatsächlichen Frequenz. Der ATmega32 läuft mit 14 MHz, da dieser Quarz > gerade greifbar war. OK. Die Quarzfrequenz ist sicher nicht das Problem. Zumindest solange du sie im Makefile korrekt einträgst. > Das Problem scheint von dem Zähler der Referenzfrequenz zu kommen. Die > gezählten Perioden von nx sind stabil, während die für nref sich ändern > und damit auch die angezeigte Frequenz. Das ist nicht normal. Es ist zwar normal, daß sowohl nx als auch nref sich bei konstanter Meßfrequenz ändern. Sie müssen sich aber immer beide ändern. Der Grund für die Abweichung liegt darin, daß das if() zur Prüfung ob genug nref-Impulse gezählt wurden, nur die oberen 8 Bit anschaut. Der Wert der unteren 16 Bit hängt davon ab, bei welchem Stand von Timer1 die Startflanke reinkam. > Addiere ich einen > Korrekturfaktor, damit z.B. die Frequenz eines Quarzoszillators von 5,76 > MHz korrekt angezeigt wird (mit einem anderen Frequenzzähler überprüft), > so liegt sie bei einem anderen Oszillator mit 18 MHz Frequenz 3000 Hz zu > tief. Ist also nix mit 6 Stellen... Irgendetwas stimmt hier nicht. Mir ist nicht ganz klar, was das Problem ist. Ein konstanter Offset? Oder springt das angezeigte Ergebnis auch bei konstanter Eingangsfrequenz? Im letztere Fall überprüfe bitte mal, welche Version von avr-libc du installiert hast. Mit avr-libc 1.6.7 haben auch andere schon merkwürdige Probleme gehabt, während avr-libc 1.6.6 funktioniert. > Gibt es vielleicht einen wesentlichen Unterschied zwischen dem ATmega8 > und dem von mir verwendeten ATmega32, der für das Problem verantwortlich > sein könnte? Nein. Ein paar Ports und Bits haben andere Namen. Aber das wars dann schon. XL
Axel Schwenke schrieb: > Ein paar Ports und Bits haben andere Namen. Aber das wars dann > schon. Gerade beim Einstellen von Hardware mit unterschiedlichen Registernamen und/oder Aufteilung der Bits passieren gerne mal Fehler, da genau die Datenblätter vergleichen.
Hallo zusammen und vielen Dank für die schnellen Antworten. Heute habe ich noch einmal bei Null angefangen, Eure Implementierung mit den nötigsten Änderungen für den ATmega32 und mein LCD versehen und in den µC programmiert. Damit war die Anzeige stabil, aber falsch. Bei der anschließenden Überprüfung meines Aufbaus fiel mir dann auf, dass ich bei dem vielen Herumprobieren vergessen hatte, eine provisorisch gesetzte Drahtbrücke wieder zu entfernen und außerdem den T0-Pin falsch benannt hatte (schäm...) Kurzum, der Zähler funktioniert jetzt und das bis 50 MHz. Somit kann ich mich jetzt an einen anständigen Aufbau und die Ansteuerung von LEDs (mit einem MAX7221 über SPI) machen. Wozu ich das Teil eigentlich brauche? Es soll mir die Frequenz meines alten KW-Transceivers mit Analogskala digital auf 100 Hz genau anzeigen und damit das automatisch funktioniert, müssen drei Frequenzen im Transceiver gemessen und ausgewertet werden. Es gibt (oder gab) dafür zwar einen Bausatz, aber damit hätte ich nicht soviel gelernt :-) Nochmals vielen Dank an alle die geholfen haben und besonders an die, die diesen Zähler entwickelt haben! 73 de Ralf / DL5EU
Hallo Ralf, Ralf G. schrieb: <schnipp> > Kurzum, der Zähler funktioniert jetzt und das bis 50 MHz. Somit kann ich > mich jetzt an einen anständigen Aufbau und die Ansteuerung von LEDs (mit > einem MAX7221 über SPI) machen. Du hast die Wiki-Seite hier: Frequenzzählermodul gesehen? Da gibts auch ne LED-Version. > Wozu ich das Teil eigentlich brauche? Es soll mir die Frequenz meines > alten KW-Transceivers mit Analogskala digital auf 100 Hz genau anzeigen Super. Genau für solche Anwendungen ist es gedacht. > und damit das automatisch funktioniert, müssen drei Frequenzen im > Transceiver gemessen und ausgewertet werden. Es gibt (oder gab) dafür > zwar einen Bausatz, aber damit hätte ich nicht soviel gelernt :-) Bitte gib doch noch ein paar Details zum Besten, was du alles zusätzlich anflickst. Ich habe noch ein paar Punkte auf der ToDo-Liste, u.a. die Berücksichtigung eines Offsets (ZF). Vielleicht ergeben sich so Anregungen für weitere Features. > Nochmals vielen Dank an alle die geholfen haben und besonders an die, > die diesen Zähler entwickelt haben! Das wäre dann ich. Danke :) XL
Hallo Axel, was ich machen will/muss ist folgendes: Vor den Zähler muss ein Multiplexer mit drei HF-Verstärkerstufen. Dann muss ich die Frequenz des VFO (immer gleicher Bereich, egal in welchem Band), die des Quarzoszillators zum Mischen in ein bestimmtes Amateurfunkband und die des Oszillators in der Signalaufbereitung (SSB USB/LSB, CW und AM) auswerten und aus diesen drei Werten die tatsächliche Sende- bzw. Empfangsfrequenz berechnen. Damit erhalte ich eine Anzeige, die jederzeit die korrekte Frequenz anzeigt, ohne dass ich etwas umschalten muss. Der einzige Nachteil ist, dass ich die drei Oszilatoren in meinem (noch in Analogtechnik gebauten und teilweise mit Röhren bestückten) Transceiver anzapfen muss. Ich habe gestern gesehen, dass es auch eine LED-Version des Zählers gibt. Meine eigene Anzeigeplatine ist allerdings schon fertig und den MAX7221 habe ich auch schon seit einigen Wochen hier liegen. Der MAX7221 hat den Vorteil, das Multiplexing der Anzeige selbst zu machen ohne dass der µC aktiv wird. Der 7221 hat gegenüber dem 7219 noch den Vorteil, mit weniger steilen Flanken zu arbeiten und dürfte daher weniger Störungen produzieren. Das Ganze kommt aber sowieso in ein abgeschirmtes Gehäuse. 73 de Ralf / DL5EU
Ralf G. schrieb: > und dürfte daher > weniger Störungen produzieren. Falls es doch Probleme geben sollte, hier ein Vorschlag, ohne Multiplexen auszukommen. Beitrag "Re: 36 Sieben-Segment-Anzeigen Multiplexen" Irgendwann mache ich vielleicht auch mal ein Programm dafür; eine Leerplatine habe ich schon lange zu liegen.
hallo Axel
> Ich habe noch ein paar Punkte auf der ToDo-Liste, u.a. die ...
ich habe mir ein SDR ( software defined radio ) gebaut. da braucht man
als taktquelle das 4-fache, von dem, was man empfangen moechte. waere
schoen, wenn der zaehler einen software-maessigen teiler durch 4 haette.
z.b. mit dem einen jumper, wenn beim einschalten gesteckt, dann durch 4,
sonst normale anzeige.
im prinzip wuerde mir auch eine #ifdef anweisung reichen, da ich den
zaehler nicht so oft in unterschiedlichem environment betreibe.
schoene gruesse
hans
oe1smc
--
Hallo Axel Das mit dem Offset interessiert mich auch brennend. Ich moechte auch einen alten Transceiver mit Digitalanzeige ausruesten. Heute habe ich mir mal die Leiterplatte vorgenommen gehabt. Einige Loetpads waren ja so mickrig das ich sie kaum auf dem Papier erkennen konnte, geschweige, das ich das spaeter loeten kann. Auch hab ich ein wenig "rum-geroutet" um ein wenig mit Eagle klarzukommen. Herausgekommen ist eine Leiterplatte, komplett mit bedrahteten Bauelementen, bei der nur noch drei einzelne Durchkontaktierungen zu machen sind. Der Quarz (Low-Profile) ist jetzt under dem mega8. Benutzt man Praezisionssockel passt der genau dazwischen, wenn man den Mittelsteg heraustrennt. Das naechste ist jetzt den 2-Transistor Vorverstaerker noch mit auf die Platine zu packen, dafuer muss sicher die BNC-Buchse weichen. Aber das sollte kein Problem sein, weil das Teil ja eh mit in ein Geraet eingebaut wird, und man gut und gerne die Eingangsleitung anloeten kann. Fuer diejenigen, bei denen Interesse besteht, das gezipte Board im Anhang. Gruss Asko.
Hallo Asko, Deine Files lassen sich bei mir nicht öffnen mit Eagle-Ver.5.11 ! Hast du eine höhere Version? Gruß Michael
Hallo Michael Auwei, das ist ja doof. Ich hatte mir gestern erst Eagle heruntergeladen und das ist Version 6.01 Das iss ja schade, da bin ich als 1-tages-benutzer jetzt erst mal ueberfragt ob man das wandeln kann. Aber ich hab da was von Importieren/Exportieren gelesen. Das muss ich mal ergruenden. Ich war gerade so froh, den Quarz nun so hingebastelt zu haben, das man den auch von der Leiterseite aus anloeten kann ;-) Vielleicht weiss ja auch ein anderer Nutzer noch was dazu. Gruss Asko.
Hi Michael Importieren/exportieren, das waren nur Netlist und Parts etc. In der Beschreibung steht auch nur, das jede Version von Eagle alle Dateien lesen kann, sofern sie mit den kaeuflichen Versionen gemacht sind. Von meiner Light-Version steht da leider nix. Gruss Asko.
Also das ist mir das erste Mal passiert, das ich ein Eaglefile nicht öffnen kann! Umgekehrt genauso. Jedes Layout, welches ich hier reinstelle, z.B. die LED-Version ist von mir, kann Jederman öffnen. Und stimmt, Export ist nicht für ein anderes Format gedacht, das ist mal wieder typisch Eagle! Ich arbeite mit einigen Vektor u. Cad-Programmen für die Werbetechnik, mit allen kann ich mehrere Versionen abwärts exportieren, nur bei Eagle-Cad geht das nicht. Was soll ich davon halten? Gruß Michael
Angehängte Dateien:
-
Versuch_7.JPG
270 KB -
Versuch_8_aufgebaut.JPG
220 KB
Hi Auch wenn es hier im Tread ganz schoen "ruhig" geworden ist, wir basteln immernoch dran.... Ich weiss zwar immernoch nicht, wo ich besagte ZF subtrahieren kann/muss. Aber erst mal war mir der Aufbau wichtiger. @ Michael Ich habe zwar ein Layout mit der VV-Stufe gemacht, weiss aber noch nicht ob sie funktioniert. Reichelt lieferte leider nicht das was ich wollte. zB. liegende statt stehende Einstellregler.... Gruss Asko.
Michael D. schrieb: > Was soll ich davon halten? Das ist bei Eagle so. Eine neue Hauptversion gibt es bei Eagle nur dann, wenn sich was wesentliches in den inneren Strukturen der Leiterplatten-Dateien geändert hat. Daten von älteren Versionen können importiert werden, aber eben nicht umgekehrt. Innerhalb einer Hauptversion geht der Austausch allerdings problemlos. Mein Ratschlag: nicht immer die allerneueste Version haben wollen. Mit einer älteren Version läßt es sich in 90% aller Fälle genausogut arbeiten und die Lesbarkeit durch Andere ist gegeben. Ach ja.. herrje - ihr bastelt ja immer noch. Mein PIC-Zähler hingegen ist schon seit Monaten komplett fertig incl. Gehäuse. So verschieden kann das sein. Das Layout ein bissel weiter oben finde ich schlecht: Die Massefläche ist nicht wirklich durchgehend, was aber sein sollte, wenn man nicht im Megahertzbereich Probleme bekommen will. Und müssen denn die IC's im DIL Gehäuse bei euch immer noch sein? Ich verstehe nicht, wie man sich die Arbeit derart schwer machen kann. Bei SMD spart man sich Mengen an Bohrungen - gerade wichtig beim Selberätzen. Wenn ich dran denke, was ich früher an Löchern gebohrt habe - igitt. Das spart man sich fast komplett mit SMD und man hat auf der Rückseite viel Platz für eine ordentliche Massefläche. W.S.
W.S. schrieb: > Ach ja.. herrje - ihr bastelt ja immer noch. Mein PIC-Zähler hingegen > ist schon seit Monaten komplett fertig incl. Gehäuse. So verschieden > kann das sein. Meine habe ich inzwischen einige Stück fertig an Bekannte gegeben, so verschieden ist das garnicht ;-) Andererseits scheint gerade hier das Interesse groß, wenn dieser Thread noch immer so qieklebendig ist ;-) Wo ist dein Thread (mit fertigem Gerät) eigentlich abgeblieben? > Das Layout ein bissel weiter oben finde ich schlecht: Die Massefläche > ist nicht wirklich durchgehend, was aber sein sollte, wenn man nicht im > Megahertzbereich Probleme bekommen will. Und müssen denn die IC's im DIL > Gehäuse bei euch immer noch sein? Ich verstehe nicht, wie man sich die > Arbeit derart schwer machen kann. Man man, was haben die Inschenjöre bloß früher gemacht, gab noch kein SMD und die mussten weit in den GHz-Bereich rein. Wie doof müssen die wohl gewesen sein? Old-Papa
W.S. schrieb: > Mein Ratschlag: nicht immer die allerneueste Version haben wollen. Mit > einer älteren Version läßt es sich in 90% aller Fälle genausogut > arbeiten und die Lesbarkeit durch Andere ist gegeben. Ich hab mir zum ersten mal Eagle heruntergeladen. Also hab ich die Version geladen, die dort angeboten wurde. Von Inkompatibilitaeten stand da leider nichts. Das hat sich ja erst jetzt herausgestellt. > Ach ja.. herrje - ihr bastelt ja immer noch. Mein PIC-Zähler hingegen > ist schon seit Monaten komplett fertig incl. Gehäuse. So verschieden > kann das sein. Immernoch oder schon wieder, oder gar (wie bei mir) erst jetzt. Das Platinchen kann man sicher auch nach Jahren nochmal aufbauen, sofern man solch ein Geraetchen benoetigt. Ich selber habe noch ein Zaehler bis 1,3GHz. Wuerde also das Geraet nicht unbedingt benoetigen (als stand-alone). Das soll ja als Anzeige in ein bestehendes Geraet mit eingebaut werden. Deswegen hat das auch keine Stromversorgung, keine vernuenftigen Buchsen und kein Gehaeuse. > Das Layout ein bissel weiter oben finde ich schlecht: Die Massefläche > ist nicht wirklich durchgehend, was aber sein sollte, wenn man nicht im > Megahertzbereich Probleme bekommen will. Und müssen denn die IC's im DIL > Gehäuse bei euch immer noch sein? Ich verstehe nicht, wie man sich die > Arbeit derart schwer machen kann. Bei SMD spart man sich Mengen an > Bohrungen - gerade wichtig beim Selberätzen. Wenn ich dran denke, was > ich früher an Löchern gebohrt habe - igitt. Das spart man sich fast > komplett mit SMD und man hat auf der Rückseite viel Platz für eine > ordentliche Massefläche. Wenn man die Masseanschluesse der Bauelemente beidseitig anloetet, (geht bei SMD aber nicht) erhaelt man auch wieder eine "fast" durchgehende Masseflaeche. SMD´s sehen zwar huebsch aus, und sind schoen klein, aber das hat auch einen entscheidenden Nachteil fuer mich. Mit zunehmenden Alter laesst nicht nur die Sehkraft nach, sondern und vor allem bekommen die Haende/Finger ein ungewolltes "Eigenleben". Da sind bedrahtete Bauelemente weit aus gutmuetiger. Und ... sooo viele Bohrungen hat diese kleine Platine nun wirklich nicht. Gruss Asko.
Hallo Axel Ich habe meinen Zaehler jetzt erst mal am laufen. Ich habe ganz schoen "gekaempft" um mit der programmierbaren Frequenzkorrektur klar zu kommen. Man muss ja auch noch die CRC richtig in die main.eep eintragen. Damit hatte ich mich ganz schoen schwer getan. Aber jetzt laeuft er erstmal. Ich habe das uebrigens mit WinAVR-20100110 und der avr-libc 1.6.7 kompiliert. Also es funktioniert, weiter oben im Tread hatte ich ja was anderes gelesen. (Deine Version V_1.5 (c)XL) Jetzt wuerde ich eigentlich gerne die Jumperabfrage fuer die Entscheidung USB oder LSB verwenden. Und dann ebend 5,25 MHz vom Ergebnis abziehen oder dazurechnen. Bloss wenn ich in den Code schaue, das ist so, als wenn ein Schwein in´s Uhrwerk glotzt. Da bin ich noch nicht weit genug um das sofort zu verstehen. Koenntest Du mir da ein paar hilfreiche Tips geben ?? Uebrigens...prima Sache, dank an Dich fuer bisherige Arbeit ! Als Anfaenger in sachen AVR kann ich das nicht laut genug loben. ;-) Dank Michael, der hier (mir) die Vorlage fuer die Leiterplatte gegeben hat, konnte ich die auch meinen Beduerfnisssen prima anpassen. Es war schon ein "erhebenes" Gefuehl nach ca. 10-15 Jahren mal wieder eine Leiterplatte zu aetzen. Und das Ding funktioniert auch noch !!! Es waere schoen, wenn Du mir da weiterhelfen koenntest. Wie ich gelesen habe, moechten ja auch noch andere User einen Offset programmieren koennen. Du hattest es ja selber auf Deiner ToDo-Liste. Gruss Asko.
Angehängte Dateien:
-
FqM-start.JPG
140 KB -
FrM-10MHz.JPG
140 KB -
Generator.JPG
130 KB
Hi Ich wollte vorhin schon Bilder befuegen, aber ich musste erst mal "Licht in´s Dunkel" bringen, sprich die Back-LED anschliessen. Mit Hintergrundbeleuchtung hab ich jetzt 270mA gemessen. Das sollte die vorhandene Stromversorgung bequem noch mit versorgen koennen. 2,2V sinus, direkt am TTL-Eingang macht er noch mit. Unter 100 kHz streikt da der Zaehler, aber er soll ja nur zw. 3 und 30 MHz anzeigen koennen. Und als "Injektor" diehnte ein HF-Tastkopf "rueckwaerts". Zwar nich ganz Gentleman-Like, aber es funktionierte. Gruss Asko.
Angehängte Dateien:
-
LED-board-top.png
8,6 KB -
LED-board-bottom.png
8,9 KB
Moin, moin! Es gibt mal wieder etwas Neues von der Front. Und zwar habe ich die Tage mal eine Anzeigeplatine für die LED-Version des Zählermoduls gebaut. Bei der Gelegenheit sind gleich ein paar Änderungen in die Firmware eingeflossen: - die LED-Version kann jetzt wahlweise die Frequenz oder die Periodendauer anzeigen. Die Auswahl erfolgt über Jumper J1 (J1 gesetzt = Periodendauer). - passend dazu gibt es jetzt nicht mehr nur 3, sondern 6 LED für die Maßeinheit: Hz, kHz, MHz (Frequenzanzeige) und ns, µs, ms (Periodendaueranzeige). - das Meßergebnis wird jetzt gerundet; vorher wurde einfach nur abgeschnitten, was zu Diskrepanzen zwischen angezeigter Frequenz und Periodendauer führte. - die Zuordnung von Portleitungen zu LED-Segmenten ist jetzt angepaßt an mein Platinenlayout. Ich habe die strenge Zuordnung [0..7] -> [a..g, dp] aufgegeben und die Signale so gelegt, daß sie sich leichter routen ließen. Diese Änderung in ports.h sollte trivial zu erkennen sein. Anbei sind das aktuelle Firmware-Archiv, aktualisierter Schaltplan und das gerenderte Layout. Den Wiki-Artikel "Frequenzzählermodul" aktualisiere ich in Kürze. PS: die LCD-Version rundet jetzt auch. Nach ein paar Tests wird es auch da demnächst eine Version 1.6 geben. XL
Axel Schwenke schrieb: > ... habe ich die Tage > mal eine Anzeigeplatine für die LED-Version des Zählermoduls gebaut. Nachtrag: - die Display-Platine ist gegenüber einem LCD um 180 Grad gedreht - die Anzeigen sind TOT-4301FG (gab es mal bei Pollin) - als LED sind quadratische 5x5mm² Typen vorgesehen (Reichelt V 530, V 532), die die auf Folie gedruckte Einheit hinterleuchten sollen. - die Anordnung der LED: linke Reihe von oben nach unten MHz, kHz, Hz, rechte Reihe von oben nach unten ns, µs, ms. Darunter mittig "Überlauf/kein Signal" - alle Widerstände sind 0805 SMD - unter dem 74HC138 ist ein 100nF Abblock-C in 0805 vorgesehen - Das Layout kann auch einseitig mit Drahtbrücken gebaut werden XL
Rudi M. schrieb: > Old Papa schrieb: >> Feine Sache! > > Ja, wenn man die TOT-4301FG noch hat... unn wenn ma nitt zu dumm zum lesen ist kauft man sie hier: http://www.pollin.de/shop/dt/NTM4OTc4OTk-/Bauelemente_Bauteile/Aktive_Bauelemente/Displays/LED_Anzeige_TOT_4301FG_1.html kopfschuettel vlG Charly
Rudi M. schrieb: > > Ja, wenn man die TOT-4301FG noch hat... Nun, die Displayplatine ist ja nun kein Hexenwerk, zur Not geht sogar Lochraster und Fädeldraht. Ich selbst habe diese Module auch nicht, dafür hunderte an Einzelanzeigen. Wenns pressiert route ich eine neue Platine, pressiert aber noch nicht ;) Old-Papa
"Charly B. unn wenn ma nitt zu dumm zum lesen ist kauft man sie hier: http://www.pollin.de/shop/dt/NTM4OTc4OTk-/Baueleme... kopfschuettel" Du kannst es auch nicht. Hast du den roten Punkt unter Verfügbarkeit nicht gesehen? kopfschüttel***
> Du kannst es auch nicht. Hast du den roten Punkt unter Verfügbarkeit > nicht gesehen? hm, das war ja wieder klar :-( auch Kopfschüttel... Ich habe die Teile in 4facher Ausführung(10mm u. 14.2mm) mit CA, evtl. könnte man die letzten beiden Digits anstelle der eckigen LED's misbrauchen? Die gibt es übrigens recht günstig und ohne roten Punkt beim Chinesen! Hier der link für die 4Digit 14,2mm http://www.ebay.de/itm/280735607444?ssPageName=STRK:MEWAX:IT&_trksid=p3984.m1423.l2648 für die 10mm Exemplare muß ich erst kramen... Gruß Michael
Old Papa schrieb: > Nun, die Displayplatine ist ja nun kein Hexenwerk, zur Not geht sogar Klar ist sie das nicht. Trotzdem ist es nett wenn jemand seine Arbeit anderen zur Verfügung stellt nur Schade wenn dann die entscheidenden Bauteile schon zum Zeitpunkt der Veröffentlichung gar nicht mehr zur Verfügung stehen und doch die meisten die Arbeit selbst machen müssen. > Wenns pressiert route ich eine neue Platine, pressiert aber noch nicht > ;) > Na hoffentlich pressierts bei Dir früher als bei mir ;-) Grüße, Rudi
Michael D. schrieb: > Ich habe die Teile in 4facher Ausführung(10mm u. 14.2mm) mit CA, evtl. > könnte man die letzten beiden Digits anstelle der eckigen LED's > misbrauchen? Können kann man viel. Ich persönlich finde 7 Segmente für die Einheit aber unpassend. Mit 16 Segmenten könnte man was anfangen, aber so finde ich Einzel-LED gelungener. YMMV. > Die gibt es übrigens recht günstig und ohne roten Punkt beim Chinesen! > Hier der link für die 4Digit 14,2mm > http://www.ebay.de/itm/280735607444?ssPageName=STRK:MEWAX:IT&_trksid=p3984.m1423.l2648 Die passen aus mehreren Gründen nicht. Zum einen sind sie zu groß (2 Stück nebeneinander brauchen mehr als 80mm). Zum anderen können sie mit 12 Pins nur entweder Dezimalpunkte oder den Doppelpunkt herausgeführt haben. Murphy ist da klar gegen dich. Hingegen sieht eBay 290607390518 halbwegs passend aus. Ist zwar rot und auch etwas kleiner. Aber 11 Pins stimmen vermutlich sogar beim Pinning überein. XL
Angehängte Dateien:
-
4Digit-Rot-Dezimal-Punkt.jpg
130 KB
Hallo Axel, > Können kann man viel. Ich persönlich finde 7 Segmente für die Einheit > aber unpassend. Mit 16 Segmenten könnte man was anfangen, aber so finde > ich Einzel-LED gelungener. YMMV. Mit den 16 Segmenten gebe ich dir Recht, da wäre aber der Schaltungsaufwand etwas erheblicher... > Die passen aus mehreren Gründen nicht. Zum einen sind sie zu groß (2 > Stück nebeneinander brauchen mehr als 80mm). Zum anderen können sie mit > 12 Pins nur entweder Dezimalpunkte oder den Doppelpunkt herausgeführt > haben. Murphy ist da klar gegen dich. Nö, die Butterseite ist diesmal oben gelandet...die Dinger sind so geschaltet, das der Doppelpunkt immer mit leuchtet, wenn der Dot in der Mitte angesteuert wird. Ich habe die 14,2mm für Spannungsmodule verwendet und den Doppelpunkt mit mattschwarzer Folie überklebt. Dadurch ist der mittlere Dot etwas dunkler als die Anderen, ist aber noch akzeptabel. Diese gibt es aber auch in 10mm Ausführung, allerdings ohne Doppelpunkt, soweit ich mich erinnern kann. Die grünen Anzeigen daneben sind je 2 Duo-Module und erzeugen eine gewaltige Helligkeit, wie schon auf dem Pic zu sehen ist. > Hingegen sieht eBay* 290607390518* halbwegs passend aus. Ist zwar rot > und auch etwas kleiner. Aber 11 Pins stimmen vermutlich sogar beim > Pinning überein. Die werden bestimmt passen und Rot ist auch ok. Danke für den Link, werde von denen mal welche ordern. Für diesen Preis sind die in Deutschland auf keinen Fall erhältlich. Bis jetzt hatte nur gute Erfahrungen mit den Chinateilen gemacht. Übrigens hast du da wieder eine schöne Arbeit präsentiert, ein Lob von mir an dieser Stelle. Gruß Michael
Angehängte Dateien:
-
led-anzeige.jpg
12 KB
Hallo Michael, ich verwende gerne kompakte LED-Module mit gem. Anode. Mit den LED LTC-5653HR ist mal ein Anzeigeprojekt auf Basis eines atTiny2313 mit RS232 Ansteuerung entstanden. Pratisch ist dabei, das LED-Modul wird direkt über den atTiny2313 in ein Steckbrett stecken. So wird das Routing sehr einfach und die Schaltung sehr kompakt.
Hinweis: dieser Thread ist mittlerweile sehr groß und enthält am Anfang auch ziemlich viel mittlerweile überholte Information. Außerdem hätte er wahrscheinlich von Anfang an besser ins Nachbarforum "Codesammlung" gepaßt. Ich habe jetzt eben da einen neuen Thread Beitrag "AVR-Frequenzzählermodul 1Hz - 40MHz" eröffnet. Hinweisen möchte ich auch auf den zugehörigen Artikel Frequenzzählermodul im Wiki, wo ich immer die aktuellste Information vorhalte. BR, XL
Axel S. schrieb: > > Meiner lag bis vor ca. 2 Jahren mit ganz ähnlichen Symptomen auf Eis. > Seitdem läuft er aber. Und zwar ganz hervorragend. Die abgedruckte > Firmware hat einen Fehler. Details habe ich verdrängt :) > > Ich habe etliche Varianten der Firmware hier als Quellcode. Das > Original, ein minimal angepaßtes Original, eine schöne Variante mit den > Original-Algorithmen, eine neue Variante. Der Assembler ist ein Eigenbau > :) > > Meine Änderungen: Polarität der Treiber geändert (Segmente pnp, Digits > npn). Die Einheit wird mit 4 Einzel-LEDs angezeigt: Hz, kHz, MHz und > Unterlauf. > > Wenn du mir deine Quarzfrequenz sagst und ob/welche anderen > Modifikationen du hast, kann dir ein Firmware-Image bauen. Schick mir ne > Mail. > > XL Hallo , hat jemand noch füt den U882-Frequenzzähler eine bin-Datei für den Eprom? Möchte die Schaltung nachbauen (Nostalgiker), die Hex-Datei in dem Buch "Schaltungssammlung ,Schlenzig,5.Lieferung" ist allerdings kaum lesbar. mfg Ralf
Ralf schrieb: > ... > Hallo , hat jemand noch füt den U882-Frequenzzähler eine bin-Datei für > den Eprom? Möchte die Schaltung nachbauen (Nostalgiker), die Hex-Datei > in dem Buch "Schaltungssammlung ,Schlenzig,5.Lieferung" ist allerdings > kaum lesbar. > mfg Ralf Ist hier zwar völlig OT, aber ich müsste noch ein aufgebautes Exemplar in einem FG haben. Ich hoffe, wir reden vom gleichen Zähler ;-) Schick mir mal eine Mail. Old-Papa
Ralf schrieb: > Hallo , hat jemand noch füt den U882-Frequenzzähler eine bin-Datei für > den Eprom? Möchte die Schaltung nachbauen (Nostalgiker), die Hex-Datei > in dem Buch "Schaltungssammlung ,Schlenzig,5.Lieferung" ist allerdings > kaum lesbar. Mach dir einen Account hier im Forum, dann kannst du anderen auch direkt Nachrichten schicken. Dann frag mich direkt und ich schick es dir per Email.
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.