Hallo Allerseits, ich habe hier mit dem AT90S2313 einen reziproken Frequenzzähler zur Messung der 50 Hz der Netzfrequenz aufgebaut und programmiert. Der Brumm wird vom Trafo über Kondensator und Schmitt-Trigger aus zwei Transistoren bereit gestellt und dem 16-Bit Timer1 gegeben. Die Überläufe werden in zwei weiteren Registern aufsummiert. Das vollständige Programm zeigt mir den Messwert, also die aufsummierten Zählpulse während einer Messung sowie den reziproken Wert an, also eine passende große Zahl dividiert durch den 4-Byte breiten Messwert ergibt ungefähr 50,000 Hz mit Nachkommastellen. Quarzfrequenz ist 5 MHz. Ich habe die Wahl, ob nur eine Periode, zehn Perioden oder 100 Perioden zur Messung heran gezogen werden, indem einfach die Flankenerkennung die Perioden mitzählt bis zur gewünschten Anzahl. Nun habe ich die Ausgabe verglichen mit den zwei, drei im Internet verfügbaren online-Anzeigen, die allesamt drei Nachkommastellen bieten und untereinander ziemlich genau überein stimmen. https://www.netzfrequenz.info/ (zwei Sekunden Intervall) https://www.netzfrequenzmessung.de/ (eine Sekunde Intervall) https://50hz.ewelt.net mit STM32 (tendentiell immer geringerer Wert als die anderen beiden, 4 Nachkommastellen) Es zeigt sich, daß mein Programm in etwa das gleiche anzeigt, jedoch immer etwas mehr, nämlich in der dritten Nachkommastelle etwa 3 zu viel, gestern 5 zu viel . Das bedeutet, daß der Messwert zu klein sein muß. Wo könnte ich denn beim Zählen der vorbei kommenden Flanken einen Fehler gemacht haben? Klar ist, die Befehle für Sprung und Abfrage brauchen immer ein, zwei Takte, um zu reagieren. Könnte es sein, daß bei 100 Perioden 100 Flanken zu wenig unter kommen? Anbei ein Minimalprogramm mit Flankenerkennung und Timer1. Vielleicht blickt diesbezüglich jemand durch und kann behilflich sein. Danke im Voraus. mit freundlichem Gruß
:
Bearbeitet durch User
Wie genau ist denn dein Quarz am uC?
Ich kann nur mit dem Rigol-DSO vergleichen, das noch nicht warm gelaufen ist: 4,99962 MHz zeigt es an, direkt am Pin4. Das belastet zusätzlich. Ja, man müßte ein Programm verwenden, das den Takt an einem Pin ausgibt,habe ich gerade nicht parat. Kommt noch. An den Quarz denke ich natürlich zuletzt. mfg
Also für mich ist das in Ordnung: > in der dritten Nachkommastelle etwa 3 zu viel, gestern 5 zu viel Das sind also, bei Sollwert 50.000, 60 resp. 100 ppm. > 4,99962 MHz zeigt es an Das entspricht 76 ppm.
Das Programm selbst ist wohl in Ordnung. Zwar ein gewöhnungsbedürftiger Stil, besonders die '20 warnings', aber okay.
Danke fürs Drüberschauen. Habe es mit wavrasm assembliert, da läuft es ohne Fehler durch. MfG
Ich habe das mal laufen lassen (mit aktiviertem 'ldi temp2, 0'), auf einem ATtiny2313: Takt von einem 5 MHz-Quarz, dahinter eine Teilerkette auf 50 Hz, diese auf Pin D5 gelegt, führt zu zwei wechselnden Zählerständen: 10000002 und 10000005.
Wie sieht denn die Aufbereitung des 50Hz-Analogsignals aus? Insbesondere sollte man einen guten Blick auf die Bandbreite des Vorfilter haben, damit Transienten auf dem Netz die Flankenerkennung nicht stören (Jitter). Wie sieht die statistische Verteilung der Einzelmesswerte aus?
Ein Problem besteht darin, dass ohne Input-Capture gearbeitet wird: tritt die Flanke an D5 zu Beginn der Timer1-Overflow-ISR auf, dauert es über 30 Takte bis zur Reaktion. Bei den derzeitigen 100 Durchläufen mag das okay sein, bei 10, die ja auch, alternativ, im Programm stehen, wären es über 30 ppm Fehler.
Wolfgang schrieb: > Wie sieht denn die Aufbereitung des 50Hz-Analogsignals aus? Nur mittels Schmitt-Trigger aus zwei Transistoren und Hysterese. > > Insbesondere sollte man einen guten Blick auf die Bandbreite des > Vorfilter haben, damit Transienten auf dem Netz die Flankenerkennung > nicht stören (Jitter). Vorfilter ist keines drinnen, wenn der Trafo noch was durch läßt. Also müßte noch ein Resonanzkreis oder mehrstufiger TP für 50 Hz dazu? > > Wie sieht die statistische Verteilung der Einzelmesswerte aus? Über sie kann ich gar keine Aussage treffen. Das ginge nur, wenn sie sofort per UART schnell genug ausgegeben würden oder erst im SRAM landen zur späteren Ausgabe. mfg
Christian S. schrieb: > Das ginge nur, wenn sie > sofort per UART schnell genug ausgegeben würden oder erst im SRAM landen > zur späteren Ausgabe. Bei 50Hz hast du dafür 20ms Zeit. Bei gemütlichen 9600Bd kannst du also pro Periode 10 Zeichen mit großer Pause übertragen. Selbst in ASCII würde das für eine Auflösung von 0.0001ppm reichen ;-)
Eine gewisse Verbesserung, falls Sie nicht auf Input-Capture umsteigen wollen, brächte die Beschleunigung der ISR:
1 | ;Interrupttabelle: |
2 | |
3 | rjmp Initial ; nach RESET zum Hauptprogramm |
4 | |
5 | .org OVF1addr |
6 | push temp1 |
7 | in temp1,SREG |
8 | inc over_low |
9 | brne hopp |
10 | inc over_high |
11 | hopp: |
12 | out SREG,temp1 |
13 | pop temp1 |
14 | reti |
15 | |
16 | Initial: |
Die 'over_low/high' in den oberen Arbeitsregisterbereich zu legen, sparte einen weiteren Takt (subi sbci). Was mich betrifft, so würde mir die damit erreichte Genauigkeit genügen, z.B. bei 100 Durchläufen, d.h. 2 s-Messintervall.
gibt es auch ein aktuelles Projekt in "C" ? Oder auch Arduino? Zum Nachbauen.
... Ein Arbeitsregister für das Sichern von SREG zu reservieren, brächte vier weitere Takte (kein push pop).
Wolfgang schrieb: > Insbesondere sollte man einen guten Blick auf die Bandbreite des > Vorfilter haben, damit Transienten auf dem Netz die Flankenerkennung > nicht stören (Jitter). Das würde auch prima in Software gehen... Nicht "mögliche Frequenzen" rauswerfen und Mittelwert über 50 oder 100 Messungen bilden. Flankenjitter wäre damit eliminiert.
S. Landolt schrieb: > Ich habe das mal laufen lassen (mit aktiviertem 'ldi temp2, 0'), auf > einem ATtiny2313: Takt von einem 5 MHz-Quarz, dahinter eine Teilerkette > auf 50 Hz, diese auf Pin D5 gelegt, führt zu zwei wechselnden > Zählerständen: 10000002 und 10000005. Das ldi temp2, 0 muß dazu wieder im Queltext sein. Verstehe ich das richtig, daß der Tiny2313 die 5 MHz Quarztakt bekommt und extern dieser Takt auf 50 Hz herunter geteilt wird, um phasenstarr verkoppelt in den PD5 zu gelangen? Dann ergeben sich also die um 2 oder 5 erhöhten Zählerstände, die tendentiell zu einem kleineren Ergebnis nach der Division führen müßten. Das Projekt hier sollte mich nach 15 Jahren wieder mit Assembler vertraut machen und ich wollte einige Feinheiten der Timer nacheinander ausprobieren. Ich hatte von früher noch etliche Code-Bausteine und Übungsprojekte in der Hinterhand. Input capture wäre dann meine nächste Baustelle. mfG
> Verstehe ich das richtig ...
Ja.
Ich hatte dann noch, da es ja bei mir ein ATtiny2313 ist, mit dem Timer0
ein niederfrequentes Signal auf/für D5 erzeugt, und da gab es dann eine
Erhöhung um 34.
Hallo, ein interessantes Thema. Es gibt Konzepte, bei denen als Zeitbasis/ Referenz eine Dallas RTC oder auch gleich ein GPS Empfänger genutzt wird. Kann jemand die Messgenauigkeit im Vergleich zu der hier vorgestellten Lösung beurteilen oder gar “vorrechnen”? Danke
Warum in assembler? Das schränkt doch nur den potentiellen Nutzerkreis unnötig ein. Kopfschüttel...
Udo schrieb: > Warum in assembler? Das schränkt doch nur den potentiellen Nutzerkreis > unnötig ein. > > Kopfschüttel... Aha, Kopfschüttel
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.