Moin, ich versuche zur Zeit mit einem ATMEGA328P Zeitintervalle im Bereich von 2s bis 100us zu messen. Platform waren Arduino NANO, Watterott 328PB und ein Pro-Mini. Alle Varianten verhielten sich identisch. Signalquelle ist ein Kalibrierter hochgenauer Timing generator. Dieser erzeugt die Test-Frequenzen im Bereich von 0.1Hz bis 10kHz. Das TTL (74S140 Ausgang) Signal ist über 4.7nF und 1kOHM Pull-Up am D8 Pin angeschlossen. Lauffähige Programm Quelle und LOG Datei sind im Anhang. Meine Frage ist, was hält ihr davon? Programmierfehler oder mysteriöses Verhalten. Ich verlange nicht nach Programmierfehlersuche. Nur Eure Meinung dazu. Ist das Problem die HW oder der Sesselokkupant vor dem PC;-) Ich machte etwas ähnliches vor über 10 Jahren mit einem 18F8722 PIC und da funktionierte es 100% einwandfrei mit ähnlichem Ansatz was Capture und Overflows betrifft. Mich interessiert nur, ob der AVR diesbezüglich über alle Zweifel erhaben ist und das Problem möglicherweise durch Arduino ISRs im Hintergrund irgendwie verursacht werden. Wenn das alles nichts nützt werde ich es später mit CVAVR oder GCCAVR ohne Arduino Hintergrund versuchen. Was ich auch nicht verstehe ist, warum bei Frequenzen unter 1kHz die ICP Werte nicht mehr zu 16MHZ passen: 10kHz: 1600 1kHZ: 16000 100Hz: 291076 10Hz: 3172903 1Hz: 31991176 0.1Hz: 311981903 (0.05Hz angezeigt) Ist es möglich, dass Arduino Hintergrund Services irgendwie damit kollidieren? Die sporadische Natur der Fehlmessungen macht die Fehlersuche schwer. Die Overflows scheinen nicht konsistent erfasst zu werden. Im Anhang ist ein Log File mit den Test Abläufen mit Frequenzen von 0.1Hz bis 10kHz. Gruesse, Gerhard
:
Bearbeitet durch User
Hallo Gerhard, mein Guter, was mir ins Auge fällt ist, dass 'T1OVF_Ctr' nicht volatile ist. Diese Art der Schreibweise alles hintereinander sollte man sich nicht angewöhnen. ;-) Vielleicht war es das schon oder noch nicht. Ich guck mir das noch genauer an ...
Veit D. schrieb: > Hallo Gerhard, mein Guter, > > was mir ins Auge fällt ist, dass 'T1OVF_Ctr' nicht volatile ist. > Diese Art der Schreibweise alles hintereinander sollte man sich nicht > angewöhnen. ;-) > Vielleicht war es das schon oder noch nicht. > Ich guck mir das noch genauer an ... Hallo Veit, wie geht es? volatile unsigned long ICP_val = 0, T1OVF_Ctr = 0; meinst Du das wird wie so gehandhabt: volatile unsigned long ICP_val = 0; unsigned long T1OVF_Ctr = 0; anstatt: volatile unsigned long ICP_val = 0; volatile unsigned long T1OVF_Ctr = 0; Gerhard
Gerhard O. schrieb: > Ist es möglich, dass Arduino Hintergrund Services irgendwie damit > kollidieren? Das glaube ich nicht. > Meine Frage ist, was hält ihr davon? Programmierfehler Jepp. Kleiner Tipp: Alles Wesentliche zur Lösung des Problems muss in der ISR des Capture-Interrupts passieren. Für die korrekte Lösung zu berücksichtigen sind Prioritäten der beiden relevanten Interrupts und die Tatsache, dass auch ISRs nicht in "Echtzeit" durchlaufen werden, sondern den realen Ereignissen immer hinterherhinken. Einfach mal gedanklich die möglichen Situationen der Auslösung der beiden Interrupts durchspielen. Dann kommst du erstmal hinter das Problem und weißt, wie man es in der Capture-ISR detektieren kann und auch, was dann zur Lösung zu unternehmen ist.
Hallo, mir gehts gut. :-) Zur Frage. Ja, da bin ich mir ziemlich sicher.
Ob S. schrieb: > Gerhard O. schrieb: > >> Ist es möglich, dass Arduino Hintergrund Services irgendwie damit >> kollidieren? > > Das glaube ich nicht. > >> Meine Frage ist, was hält ihr davon? Programmierfehler > > Jepp. > > Kleiner Tipp: Alles Wesentliche zur Lösung des Problems muss in der ISR > des Capture-Interrupts passieren. Für die korrekte Lösung zu > berücksichtigen sind Prioritäten der beiden relevanten Interrupts und > die Tatsache, dass auch ISRs nicht in "Echtzeit" durchlaufen werden, > sondern den realen Ereignissen immer hinterherhinken. > > Einfach mal gedanklich die möglichen Situationen der Auslösung der > beiden Interrupts durchspielen. Dann kommst du erstmal hinter das > Problem und weißt, wie man es in der Capture-ISR detektieren kann und > auch, was dann zur Lösung zu unternehmen ist. Dankeschön. Ich werde es diesbezüglich neu durchdenken. Gruss, Gerhard
Mach aus dem delay(1000) mal was anderes, was nicht so trefflich mit den zu messenden Frequenzen interferiert wie z.B. delay(777) und poste den Log nochmal. Und mach auch aus der Konstanten explizit einen long-Wert: ICP_val = T2 + (65536UL * T1OVF_Ctr) - T1; Siehe dazu https://stackoverflow.com/questions/13134956/what-is-the-reason-for-explicitly-declaring-l-or-ul-for-long-values
:
Bearbeitet durch Moderator
Hallo, wenn ich nichts übersehen habe wird das Overflow Flag nicht berücksichtigt. Dazu hat Peter hier niedergeschrieben: Beitrag "AVR Timer mit 32 Bit"
Veit D. schrieb: > Dazu hat Peter hier niedergeschrieben: > Beitrag "AVR Timer mit 32 Bit" Das ist ein durchaus verwandtes Problem, aber doch noch nicht exakt das Problem des TO. Da ist noch mehr zu berücksichtigen.
Deinen Code habe ich mit meinem verglichen und sehe, daß Du einen gesetzten Überlauf nicht beachtest.
1 | volatile uint16_t zeit_low, // Timer1-Anteil |
2 | zeit_high, // T1 Ueberlauf-Anteil |
3 | mess_dauer, // minimale Wartezeit |
4 | ueberlauf; |
5 | |
6 | |
7 | // Routinen zur Erfassung der Eingangsimpulse
|
8 | // Überläufe von T1
|
9 | ISR(TIMER1_OVF_vect) |
10 | {
|
11 | ueberlauf++; // Ueberlaeufe von T1 ergeben obere 16bit der Messzeit |
12 | }
|
13 | |
14 | // CAPT-Ereignisse an AIN1
|
15 | ISR(TIMER1_CAPT_vect) // Eingangsimpulse mit genauem Zeitpunkt erfassen |
16 | {
|
17 | static unsigned long count; // Impulse per Interrupt |
18 | count++; |
19 | if(mess_status == AUSLESEN) { // Ergebnisse synchron zum Eingangsimpuls auslesen+ablegen |
20 | end_ereignis = count; // Anzahl der Impulse lesen |
21 | zeit_low = ICR1; // capture-reg lesen: untere 16bit |
22 | zeit_high = ueberlauf; // dazu die oberen 16bit |
23 | |
24 | // siehe hier:
|
25 | |
26 | if((TIFR1 & BIT(TOV1)) && (zeit_low < 0x8000)) // evtl. Ueberlauf T1 noch offen? |
27 | zeit_high++; // nur, wenn capture-int + overflow-int gleichzeitig ! |
28 | mess_status = AUSWERTEN; // Daten fertig fuer Auswertung |
29 | }
|
30 | if(TIFR1 & BIT(ICF1)) { // falls neuer Eingangsimpuls gekommen ist |
31 | count++; // gleich hier auswerten |
32 | TIFR1 = BIT(ICF1); // und flag loeschen |
33 | }
|
34 | }
|
Vielleicht hilft es.
Moin, vielen Dank an Euch alle. Ich werde alles durchgehen. So einfach wie ich es am Anfang hatte, geht es also nicht. Der aktuelle Zustand der OVF-Flag muss also bei der Auswertung zeitnahe berücksichtigt werden. Ich werde mich später melden. Gerhard
Konnte das Verhalten sehr gut reproduzieren.
1 | ICP: 91392 OVF: 1 F: 175.0700 |
2 | ICP: 25856 OVF: 0 F: 618.8119 |
3 | ICP: 25856 OVF: 1 F: 618.8119 |
4 | ICP: 91392 OVF: 0 F: 175.0700 |
5 | ICP: 91392 OVF: 0 F: 175.0700 |
Denke es liegt daran, dass nur jede 2. Periode gemessen wird (von T1 bis T2), aber T1OVF_Ctr für jede (also auch zwischen T2 und T1) erhöht wird und beim nächsten T2 fälschlicherweise berücksichtigt wird.
1 | ---+ +---+ +---+ +---+ +---+ +---+ + |
2 | | | | | | | | | | | | | |
3 | +---+ +---+ +---+ +---+ +---+ +---+ |
4 | T1 T2 T1 T2 T1 T2 |
5 | toggle 111111110000000011111111000000001111111100000 |
6 | Mess |-------| |-------| |
7 | Problem O |
Daher den Overflow-Counter auch beim T1 setzen gelöscht und alles wird gut:
1 | if (!toggle) |
2 | { |
3 | T1 = ICR1; |
4 | toggle = 1; |
5 | T1OVF_Ctr = 0; //<------ |
6 | } |
7 | |
8 | ICP: 25856 OVF: 1 F: 618.8119 |
9 | ICP: 25856 OVF: 1 F: 618.8119 |
10 | ICP: 25856 OVF: 0 F: 618.8119 |
11 | ICP: 25856 OVF: 0 F: 618.8119 |
12 | ICP: 25856 OVF: 0 F: 618.8119 |
13 | ICP: 25856 OVF: 0 F: 618.8119 |
14 | ICP: 25856 OVF: 0 F: 618.8119 |
15 | ICP: 25856 OVF: 1 F: 618.8119 |
16 | ICP: 25856 OVF: 1 F: 618.8119 |
17 | ICP: 25856 OVF: 1 F: 618.8119 |
Helmut H. schrieb: > Daher den Overflow-Counter auch beim T1 setzen gelöscht und alles wird > gut: Du solltest schon etwas länger ausharren, um den Fehler als Zahlenwert zu sehen ;-) Alternativ folgende Überlegung: CAPT und OVL passieren gleichzeitig. Auf Grund der AVR Hardware hat TIMER1_CAPT höhere Priorität als TIMER1_OVL. Folglich wird TIMER1_CAP bedient und ICP = 0 gelesen. T1OVF_Ctr ist noch auf 0 und das Gesamtergebnis ist auch 0, müßte aber 65536 sein. Grundsätzlich ist es besser, die Variablen nur zu lesen und nie zu löschen. Den Messwert erhält man dann als: Endwert - Startwert.
:
Bearbeitet durch User
Mi N. schrieb: > Alternativ folgende Überlegung: > CAPT und OVL passieren gleichzeitig. > Auf Grund der AVR Hardware hat TIMER1_CAPT höhere Priorität als > TIMER1_OVL. > Folglich wird TIMER1_CAP bedient und ICP = 0 gelesen. T1OVF_Ctr ist noch > auf 0 und das Gesamtergebnis ist auch 0, müßte aber 65536 sein. Nein. Das läßt völlig die Tatsache außer Acht, das der Code in den ISRs NIEMALS zeitgleich mit den Ereignissen der Hardware ausgeführt wird, sondern mehr oder weniger deutlich danach. Das von dir beschriebene Szenario ist nicht das wirklich kritische, denn in deinem Szenario ist eben wegen dieser Interrupt-Latenz ganz sicher, dass der Code in der Capture-ISR das OVF-Flag bereits gesetzt sehen würde. Wirklich kritisch ist vielmehr folgendes Szenario: Capture triggert kurz vor dem Überlauf, Capture-ISR läuft irgendwann mehr oder weniger kurz danach (aber auf jeden Fall danach) an, fragt dann (wieder nach etwas weiterer Laufzeit) das OVF-Flag ab, sieht dieses gesetzt, weil in der der Überlauf halt dann zwischen den beiden Zeitpunkten Triggerung des Capture-IRQ und Abfrage des OVF-Flags in der Capture-ISR erfolgt ist. Diese Situation ist die eigentlich kritische und muss erkannt und anders behandelt werden, denn hier muß der Überlauf bezüglich des aktuellen Messwerts ignoriert werden. Bezüglich des Überlaufs hat man dann die freie Wahl, ob man die Behandlung des Überlaufs gleich mit in der Capture-ISR erledigt und das Flag löscht oder ob man es einfach ignoriert und die Arbeit der OVF-ISR überläßt. Da Interruptauslösung recht teuer ist, würde ich die erste Variante bevorzugen.
Ob S. schrieb: > Nein. Das läßt völlig die Tatsache außer Acht, das der Code in den ISRs > NIEMALS zeitgleich mit den Ereignissen der Hardware ausgeführt wird, > sondern mehr oder weniger deutlich danach. Du mußt schon alles von mir lesen. Ich hatte darauf hingewiesen, daß das OVF-Bit in der TIMER1_CAP-ISR beachtet und bewertet werden muß. Der genaue Zeitpunkt steht in ICR1. Ob S. schrieb: > Wirklich kritisch ist vielmehr folgendes Szenario: Capture triggert kurz > vor dem Überlauf, Gerade das ist wegen der Prioritäten der ISRs überhaupt nicht kritisch.
Mi N. schrieb: > Gerade das ist wegen der Prioritäten der ISRs überhaupt nicht kritisch. Du hast es trotz ausführlicher Erklärung nur nicht kapiert. Die Prioritäten bestimmen nur darüber, wo und wie die kritische Situation zu behandeln wäre, wären sie anders herum, könnte es gar keine sinnvolle Behandlung geben. Deswegen sind sie so, wie sie Atmel geschaffen hat. Die haben sich da durchaus was bei gedacht. Ansonsten helfen sie aber nicht weiter. Die Behandlung der kritischen Situation muss schon in Software erfolgen, konkret: in der Capture-ISR. Hast du ja auch ansatzweise versucht, alles Wesentliche ist drin. War aber wohl bloß ohne wirkliches Verständnis der Sache aus dem Code von Peda geklaut... Und ist (wohl deswegen) im Endeffekt falsch umgesetzt.
Moin, Ich habe momentan keine Gelegenheit zur Muße, um damit in Ruhe nachdenken zu können. Auf alle Fälle bin ich für Eure bisherigen Gedanken und Erörterungen dazu hier sehr dankbar. Die Zuordnung der zeitlichen Dynamik der Events und deren HW Konsequenzen ist eine richtige Herausforderung. Ich habe vor, alle möglichen Zustände erstmal auf Papier zu bringen, damit man nach Möglichkeit nichts übersieht. Mir ist bewußt, die Frage ist vielleicht unpassend oder auch blöd, aber anhand Eurer Erfahrungen und Probeläufe, ist da in der Praxis wirklich 100% Zuverlässigkeit in der Erfassung aller möglichen Zustände praktisch möglich und es kann eine fehlerhafte Zuordnung von OVF Events vollkommen ausgeschlossen werden? Oder wird es da immer eine Möglichkeit zu sporadischen bzw. sehr seltenen Fehlmessungen geben? Ist eine gültige Meßzyklus-Fehlerrate im ppm Bereich überhaupt realistisch bzw. möglich? Momentan habe ich überhaupt keine Erfahrungswerte auf die mich beim AVR stützen könnte. Das einig Gute ist, daß grobe Fehlmessungen in meiner Anwendung durch einen folgenden Plausibilitätstest erkannt werden können, weil die Eingangsfrequenz in der Praxis nur um einige tausend ppm abweichen kann. Grobe, seltene Fehler sind da also kein Problem und können ohne Beeinträchtigung der Anwendung übergangen werden. Trotzdem wäre es mir lieb wenn die Fehlmessrate im ppm Bereich liegen könnte. Falls jemand neugierig ist, diese Messung ist für ein spezielles Pendeluhrenprojekt beabsichtigt, das ich Euch später hier vorstellen würde. Ich möchte aber momentan nicht Weiteres darüber verlauten lassen, weil Vieles momentan noch in der Planungsphase ist und ich lieber ein funktionierendes Projekt vorstellen will, anstatt es hier totzureden. Ich möchte jetzt also nur bemerken, daß es ein altes Problem der Fehlerursachen von Pendeluhren auf eine besondere Art lösen will, die bisher scheinbar noch nicht versucht wurde. Abgesehen davon, muß der Fehler der momentan anscheinend zu Doppelperiodenmessungen führt, eliminiert werden, um gültige Resultate zu erhalten. "I will be back!" Gerhard
:
Bearbeitet durch User
Hallo, ca. 60min lang gemessen komme ich auf 2,8 ppm. ppm=100/1775614*5*10000 Takt 9 Hz, minimal gemessene Periode 1775614 Takte, größte Differenz 5 Takte. Arduino Mega2560, Taktgeber Timer 1, Frequenzmesser Timer 4 mit Prescaler 1. Dabei hängt alles am gleichen Taktgeber. Mit 100Hz gemessen sind es 143,7 ppm, größte Differenz 23 Takte. Hier macht sich der Interrupt für jede serielle Ausgabe bemerkbar. Halte ich die serielle Ausgabe kürzer komme ich auf 50 ppm, größte Differenz 8 Takte. Mit 1Hz gemessen sind es 0,43 ppm, größte Differenz 7 Takte. Wie man sieht ist es nur mit messen nicht getan. Wie man die Daten verarbeitet spielt auch eine Rolle. Müßte man ggf. einen Zwischenspeicher einbauen und erst weiter messen wenn andere störende Interrupts wie Serielle nicht mehr aktiv sind und der Zwischenspeicher verarbeitet ist.
Ob S. schrieb: > Hast du ja auch ansatzweise versucht, alles Wesentliche ist drin. War > aber wohl bloß ohne wirkliches Verständnis der Sache aus dem Code von > Peda geklaut... Ach Kindchen, was schreibst Du denn für ein dummes Zeug? Gerhard O. schrieb: > Mir ist bewußt, die Frage ist vielleicht unpassend oder auch blöd, aber > anhand Eurer Erfahrungen und Probeläufe, ist da in der Praxis wirklich > 100% Zuverlässigkeit in der Erfassung aller möglichen Zustände praktisch > möglich und es kann eine fehlerhafte Zuordnung von OVF Events vollkommen > ausgeschlossen werden? Ja. > Oder wird es da immer eine Möglichkeit zu > sporadischen bzw. sehr seltenen Fehlmessungen geben? Sicher: Stromausfall, µC kaputt, ... Als Anregung für Dich ein paar Beispiele: http://mino-elektronik.de/fmeter/fm_software.htm All diese Schaltungen/Programme basieren auf einer ursprünglichen Schaltung mit dem AT90S2313: http://mino-elektronik.de/fmeter/fmeter.htm Der lief noch mit 10 MHz und es war eine besondere Herausforderung, Messung und float-Berechnungen in 2 KB Flash unterzubringen. Für den nachträglichen Vorteiler /256 wurde die Skalierung durch Änderung des Exponenten erledigt. > Ist eine gültige > Meßzyklus-Fehlerrate im ppm Bereich überhaupt realistisch bzw. möglich? Ja. Es gibt auch ein Beispiel mit AVR+TCXO: http://mino-elektronik.de/fmeter/neue_versionen.htm#c2 Für besondere Ansprüche hätte ich noch eine Version mit STM32H750 und 2 x TDC-Kanälen vom AS6501. Das kann man dann für eine Stereo-Pendeluhr nehmen ;-) Zurück zu Deiner Geschichte: Erfasse jeden Zeitpunkt in der TIMER1_CAP-ISR und verwende die Ergebnisse, die benötigt werden. Dann geht nichts verloren. Der AVR ist schnell genug dafür!
Den AS6501 habe ich gerade am FPGA hängen. Funktioniert prima. Da stört die Uart Ausgabe überhaupt nicht, denn dafür werden andere LUTs verwendet. Wiese man alles mit einem ATMEGA328P erledigen will, verstehe ich nicht. Und dann noch mit dem Arduino-Überbau. Entweder man macht es richtig. Oder man braucht nur "über den Daumen"-Werte, dann reicht ein Arduino.
Peter schrieb: > Wiese man alles mit einem ATMEGA328P erledigen will, verstehe ich nicht. > Und dann noch mit dem Arduino-Überbau. > > Entweder man macht es richtig. > Oder man braucht nur "über den Daumen"-Werte, dann reicht ein Arduino. Na endlich jemand mit sinnvollen und untermauerten Argumenten.
Peter schrieb: > Wiese man alles mit einem ATMEGA328P erledigen will, verstehe ich nicht. Lass mal, das ist schon in Ordnung. Einfach zu handhaben, EEPROM schon mit auf dem Chip und eine einfache lineare Regression würde er auch noch schaffen. (Sollte ich noch machen ;-)) [OT] Peter schrieb: > Den AS6501 habe ich gerade am FPGA hängen. Funktioniert prima Verwendest Du LVDS? Kannst Du Ergebnisse zeigen? Hast Du ähnliche Effekte wie hier im 2. Bild? Beitrag "Re: RP2040 reziproker Frequenzzähler mit TDC" Das zu erfahren wäre interessant - sicher nicht nur für mich! [/OT]
:
Bearbeitet durch User
Mi N. schrieb: > [OT] > Peter schrieb: >> Den AS6501 habe ich gerade am FPGA hängen. Funktioniert prima > > Verwendest Du LVDS? Kannst Du Ergebnisse zeigen? Ich verwende LVDS, der FPGA stellt das bereit. 100MHz als Clock gehen raus, damit gibt mir der AS6501 eine Bitsequence (Frame/Data) zurück, die ich im FPGA dekodieren kann (44 Bit). SPI wird ignoriert. Zu den Messungen kann ich weniger sagen, das machen andere hier im Haus.
Moin, Wieder vielen Dank für Euer Engagement und Hinweise. Ich werde mich voraussichtlich heute wieder hineinknien können. Gestern gab es zu viele Störungen. Vielen Dank auch an Michael für seine HP Link. Vorerst möchte ich aber der Versuchung widerstehen, bei Dir abzuschreiben:-). Ich möchte zuerst selber versuchen, das Test Programm mit neuer Einsicht zum ordentlichen Funktionieren zu bringen. Da ist der Lernwert höher. Danach vergleiche ich gerne:-) Ich bin übrigens für meine Uhrenanwendung nur an hochauflösende Periodenzeitmessung interessiert. Frequenzumrechnung ist zur Funktion hier nicht wirklich ausser für Anzeigezwecke notwendig. Übrigens, bisherige Messungen am Teststand mit einem Philips Zähler (PM6666) haben ergeben, daß das Pendel einen Jitter im Bereich von +/-200us hat. Obwohl man das Mitteln könnte, fiel mir ein, daß man bei Dronen, Accelerator Sensor-Werte mit einem Kalman Filter Algorithm behandelt. Ob das auch hier Sinn hätte, um die Messungen zu beruhigen? Wahrscheinlich ist Mittelung ausreichend. Es wäre aber trotzdem interessant zu erfahren, was sich mit dem K-Filter in dieser Anwendung erreichen lässt. Aber das ist zur Zeit noch nicht aktuell. Abgesehen davon muß ich mich dort erst einlesen, weil ich noch nie etwas damit zu tun hatte. I will be back...
Gerhard O. schrieb: > Ich möchte zuerst selber versuchen, das Test Programm > mit neuer Einsicht zum ordentlichen Funktionieren zu bringen. Da ist der > Lernwert höher. Völlig richtig! > Obwohl man das Mitteln könnte, fiel mir ein, daß man bei > Dronen, Accelerator Sensor-Werte mit einem Kalman Filter Algorithm > behandelt. Ob das auch hier Sinn hätte, um die Messungen zu beruhigen? Das Problem bei einer Pendeluhr wird wohl sein, daß Du keine 1000 Messwerte/s zur Verfügung hast. Vielleicht zeigst Du Dir gleichzeitig den direkten Wert und den gleitenden Mittelwert über mehrere Sekunden an. Den aktuellen Wert würde ich immer aus den letzten beiden Perioden nehmen und keine davon auslassen. Probiere es aus und berichte.
Moin, hatte wegen vielen externen Ursachen erst heute Zeit zum Weitermachen. Ich habe mir eine Lösung anhand Eurer Gedanken erarbeitet (Und nein, ich habe noch nicht bei Michael nachgeschaut;-) ) Ob mein Ansatz tatsächlich korrekt und praktisch ist, da bin ich mir noch nicht sicher. Die beigelegte Version lauft bei mir jetzt ohne irgendwelche Fehler. Langzeit-getestet habe ich nur die 1Hz Eingangsfrequenz, obwohl alles im Bereich von 0.1Hz-100kHz funktioniert. Ihr könnt es ja ausprobieren. Das Test Signal hat eine tägliche Stabilität im 1e-10 Bereich und spielt hier keine Rolle was die Pro-Mini Zeitbasis Genauigkeit betrifft. Der verwendete Pro-Mini hier hat eine Frequenzablage bei 23DEGC von -392Hz (15.999608MHz). Ich habe das in FW normalisiert. Die ausgegebenen Werte sind kompensiert relativ zum Frequenzstandard. Das beiliegende Bild zeigt die Beobachtung über rund 15m. Der Ausgabe-Intervall ist 2s wegen der Tatsache, dass T1 Capture jedesmal neu gemessen wird und nicht der letzte T2 Punkt. Ich habe die Messungen als Frequenzfehler in ppm vom Nominalwert ausgedrückt. Da ich auch etwas mit Temperatur spielen wollte, fügte ich noch einen LM335 ein und ist mit-angezeigt im Plot. Der LM335 ist SW getrimmt. OK. Das wäre es für heute, Gruss, Gerhard
:
Bearbeitet durch User
Gerhard O. schrieb: > Ob mein Ansatz tatsächlich korrekt und praktisch ist, da bin ich mir > noch nicht sicher. Das ist schlecht. Allein mit Probieren wirst Du die Sicherheit Deines Codes nicht überprüfen können. Du wirst bestenfalls feststellen, ob die Fehler mehr oder weniger selten sind. Ich würde unbedingt dazu raten, diesen Code zu nehmen, denn der ist bulletproof: Beitrag "AVR Timer mit 32 Bit" Je nachdem, welcher Interrupt zuerst ausgelöst wird, ist die Ausführungsfolge nicht definiert. Da reicht bereits ein CPU-Zyklus Unterschied aus. Daher muß der Auslescode jede denkbare Reihenfolge berücksichtigen. Definiert ist beim AVR nur dann die Reihenfolge, wenn im Pollingzyklus beide Interruptflags gesetzt sind. Beim 8051 kann man durch verschiedene Interruptlevel eine eindeutige Reihenfolge erzwingen, beim AVR aber nicht.
Peter D. schrieb: > Gerhard O. schrieb: >> Ob mein Ansatz tatsächlich korrekt und praktisch ist, da bin ich mir >> noch nicht sicher. > > Das ist schlecht. > Allein mit Probieren wirst Du die Sicherheit Deines Codes nicht > überprüfen können. Du wirst bestenfalls feststellen, ob die Fehler mehr > oder weniger selten sind. > > Ich würde unbedingt dazu raten, diesen Code zu nehmen, denn der ist > bulletproof: > Beitrag "AVR Timer mit 32 Bit" > > Je nachdem, welcher Interrupt zuerst ausgelöst wird, ist die > Ausführungsfolge nicht definiert. Da reicht bereits ein CPU-Zyklus > Unterschied aus. Daher muß der Auslescode jede denkbare Reihenfolge > berücksichtigen. > > Definiert ist beim AVR nur dann die Reihenfolge, wenn im Pollingzyklus > beide Interruptflags gesetzt sind. > Beim 8051 kann man durch verschiedene Interruptlevel eine eindeutige > Reihenfolge erzwingen, beim AVR aber nicht. Hallo Peter, Es ist gut, daß Du noch Zweifel hast und danke für Deine Hinweise. Der grundsätzliche Unterschied bei Dir ist, daß nur der totale OVF cnt mittels ISR direkt ohne spätere Multiplikation der gesammelten OVF Events akkumuliert wird. Ferner geschieht bei Dir die Lesung des T2 Zählerstands, wann Du immer willst. Da aber bei mir, CAPTURE zum genauen Messen von externen Signalen im 1Hz Bereich gewünscht wird, muß das für ein ähnliches Konzept natürlich entsprechend angegangen werden. Eine Art Poll Verfahren wie bei Dir sollte grundsätzlich dann auch bei mir möglich sein. Entschuldige die Langatmigkeit meiner Gedanken hier. Also rekapitulieren wir: 1) T1 wird mit 16MHz getaktet. Diese hohe Taktrate ist für meine Anwendung notwendig, weil mein Interesse in Änderungen im ppm Bereich liegt. 2) Ferner wissen wir, dass der T1 Zähler bei 16Mhz alle 4.096ms einen Overflow erzeugt. Wenn ich also die eingehenden Captures im Poll Verfahren erfassen möchte, habe ich relativ viel Zeit fürs pollen, weil die Capture Flags nur alle 1-2s gesetzt werden. Folglich könnte ich jetzt Dein Konzept auf Capture Event Erfassung ändern bzw. ausdehnen. Das hätte definitiv den Vorteil die etwas unvoraussehbaren Timing Situationen zwischen OVF und CAP Interrupts zu vermeiden. Ich habe einiges vor dem letzten Ansatz ausprobiert um dem Herr zu werden. Nichts hat wirklich gefruchtet. Wenn auch sehr selten, über einen Zeitraum von 1Std gab es bis zu 2 bis 5 Fälle von OVF Fehlerfassungen. Also bestätigt das, daß die alleinige ISR Behandlung von OVF und CAP Interrupts scheinbar oder noch nicht auf ISR Basis wirklich beherrschbar ist. Zumindest fehlt mir die Magie hier:-) Ich werde mal einen Poll Versuch der Capture Flags ausprobieren, der Deinem Konzept folgt, um die Capture Events auf diese Weise zu erfassen. Zeit ist ja genügend da, um Pollen zu ermöglichen. Ich habe ja nicht vor im kHz Bereich zu messen. Solange die Main Loop nicht blockiert, könnte man Fehlmessungen ausschliessen. Man könnte also aus der Main loop periodisch eine State Machine Funktion aufrufen, die die erfolgte Capture Flag für erfolgte Captures prüft, um dann in der State machine den Start und das Ende der Perioden Erfassung zu verfolgen. Auf diese Weise genügt alleine die T1 OFV ISR um die Overflows zu erfassen und könnte direkt hochgezählt werden ohne spätere Multiplikation. Im Prinzip sollten dann keine sporadischen OVF Fehler mehr auftreten. OK, ich werde in ein paar Tagen wieder berichten. Bin gespannt, wie sich Dein Verfahren bewähren wird. Ich sehe eigentlich schon eine mögliche Realisation in meinem Kopf. Wie hört sich das also bei Dir an? Oder bin ich immer noch auf dem Holzweg? Gruß, Gerhard
Gerhard O. schrieb: > über einen Zeitraum von 1Std gab es bis zu 2 bis 5 Fälle von OVF > Fehlerfassungen. Ja, das ist der typische Wert, wenn man es falsch macht. Gerhard O. schrieb: > Oder bin ich immer noch auf dem Holzweg? Leider auch ja. Ich weiß jetzt nicht, ob Du Dir einen Spaß mit uns machen oder den Forumstrottel füttern willst oder Bill Gates bei Euch etwas ins Trinkwasser gegeben hat. So weit - so gut, hoffentlich kein Altersstarrsinn. Einen Link auf ein Arduino-Programm hatte ich Dir gegeben. Probiere das doch einfach einmal aus.
Mi N. schrieb: > Gerhard O. schrieb: >> über einen Zeitraum von 1Std gab es bis zu 2 bis 5 Fälle von OVF >> Fehlerfassungen. > > Ja, das ist der typische Wert, wenn man es falsch macht. Das bezog sich auf vorherige Versionen. Die letzte Version, hier im Anhang läuft 100% zuverlässig. Auch über eine Stunde, keine Anomalien. Aber dem Peter gefällt es auch noch nicht. Hallo Michael, > > Gerhard O. schrieb: >> Oder bin ich immer noch auf dem Holzweg? > > Leider auch ja. Bezieht sich das auch auf die letzte Version? W.G. Die laeuft von 0.1Hz-100kHz fehlerfrei. Keine einzigen Ausreisser konnte ich loggen. Ich habe einige Experimente, wie vorher erörtert gemacht und konnte in keinem Fall 100% Zuverlässigkeit erzielen. Erst als ich es so umschrieb, wie im letzten Beispiel, funktioniert es. Momentan ist das die einzige Version, die für mich absolut fehlerfrei arbeitet. Allerdings hatte auch ich einen Vorbehalt beim Testen der OVF Flag am Anfang der ISR. Da könnte es passieren, dass die Flag da nicht zurückgesetzt werden sollte, weil gerade dann ein OVF Event vorkommt. > Ich weiß jetzt nicht, ob Du Dir einen Spaß mit uns machen oder den > Forumstrottel füttern willst oder Bill Gates bei Euch etwas ins > Trinkwasser gegeben hat. So weit - so gut, hoffentlich kein > Altersstarrsinn. Nein. Nein. Nichts trifft zu. > > Einen Link auf ein Arduino-Programm hatte ich Dir gegeben. Probiere das > doch einfach einmal aus. Ich wollte erst mal nicht bei Dir abschauen. Allerdings denke ich, es wird Zeit, es mir endlich anzuschauen. Gruss, Gerhard
Gerhard O. schrieb: > Die letzte Version, hier im > Anhang läuft 100% zuverlässig. Auch über eine Stunde, keine Anomalien. Dann ist gut. Hier und an anderer Stelle wurde behauptet, man könne die Interrupts garnicht sicher verarbeiten. Bei solchen Verschwörungstheorien werde ich dann doch 'ungehalten' ;-) Wie Du schon geschrieben hattest, geht es bei den PeDa-Routinen allein um das korrekte Erweitern und Auslesen eines 8-Bit Timers. Diese Zugriffe zu beliebiger Zeit nützen Dir jedoch nichts, da Du exakte Zeitstempel brauchst. Insofern kommt 'polling' für Dich garnicht in Betracht: Holzweg. Deinen Anhang hatte ich übersehen und nur die Bilder beachtet. Die Routinen sind etwas unübersichtlich und das Löschen des Überlaufzählers ist hochriskant! Mi N. schrieb: > Grundsätzlich ist es besser, die Variablen nur zu lesen und nie zu > löschen. Den Messwert erhält man dann als: Endwert - Startwert.
Mi N. schrieb: > Gerhard O. schrieb: >> Die letzte Version, hier im >> Anhang läuft 100% zuverlässig. Auch über eine Stunde, keine Anomalien. > > Dann ist gut. > Hier und an anderer Stelle wurde behauptet, man könne die Interrupts > garnicht sicher verarbeiten. Bei solchen Verschwörungstheorien werde ich > dann doch 'ungehalten' ;-) > > Wie Du schon geschrieben hattest, geht es bei den PeDa-Routinen allein > um das korrekte Erweitern und Auslesen eines 8-Bit Timers. Diese > Zugriffe zu beliebiger Zeit nützen Dir jedoch nichts, da Du exakte > Zeitstempel brauchst. > Insofern kommt 'polling' für Dich garnicht in Betracht: Holzweg. Ja. > > Deinen Anhang hatte ich übersehen und nur die Bilder beachtet. > Die Routinen sind etwas unübersichtlich und das Löschen des > Überlaufzählers ist hochriskant! Ich werde es nochmal überarbeiten, um auch das zu vermeiden. > > Mi N. schrieb: >> Grundsätzlich ist es besser, die Variablen nur zu lesen und nie zu >> löschen. Den Messwert erhält man dann als: Endwert - Startwert. Ich vermute Du beziehst Dich auf den "T1OVF_Ctr = 0;" L186. Mein Grund dafür war: -OK, Capture ist passiert -Wir wissen aber nicht, ob es zur gleichen Zeit mit einem OVF passierte. Also kann ich ihn hier ohne Gefahr initialisieren, weil ja kein OVF fuer absehbare Zeit zu erwarten ist. Die OVF Flag lösche ich dann vorsichtshalber gleich für den Fall der Fälle. Das war mein Denken. Na ja. Bis jetzt lauft das Teil wie ein Uhrwerk. Ich habe es mittlerweile 4 Stunden ohne Fehler laufen lassen. Trotzdem möchte ich versuchen, es total risikofrei hinzukriegen. Werde mich wieder melden, wenn ich wegen Arbeit mehr Zeit dafür habe. Im Anhang eine Aufzeichnung des OCXO Aufwärmverhalten nach dem Einschalten über die ersten paar Minuten (~4m), den ich für die Messungen verwende. Man sieht, die Werte ändern sich bis zur Stabilisation sehr gleichmäßig. Die Samples sind 2s auseinander. Gruss, Gerhard
Gerhard O. schrieb: > Ich vermute Du beziehst Dich auf den "T1OVF_Ctr = 0;" L186. > Mein Grund dafür war: > -OK, Capture ist passiert > -Wir wissen aber nicht, ob es zur gleichen Zeit mit einem OVF passierte. > Also kann ich ihn hier ohne Gefahr initialisieren, weil ja kein OVF fuer > absehbare Zeit zu erwarten ist. Die OVF Flag lösche ich dann > vorsichtshalber gleich für den Fall der Fälle. Das war mein Denken. Am Capture-Wert (ICR1) kann man erkennen, wie es um den Überlauf steht. Ist der Wert im Bereich 0x8000 - 0xffff kann in der letzten Zeit kein Überlauf stattgefunden haben. Das OVF-Flag kann unbeachtet bleiben. Wird ICR1 als 0x0000 - 0x7fff gelesen und OVF_Flag ist gesetzt, dann ist die OVF-ISR zurückgestellt (pending) und wird erst nach der CAPT-ISR ausgeführt. In der CAPT-ISR wird daher der Zeitpunkt (korrigierend) um 0x10000 erhöht, obwohl T1OVF_ctr noch um 1 zu klein ist. Nach Verlassen der CAPT-ISR wird die OVF-ISR ausgeführt und T1OVF_ctr++ ausgeführt. Dann passt wieder alles zusammen. Damit das ungestört ablaufen kann, darf man weder das OVF-Flag noch T1OVF_ctr in der CAPT-ISR manipulieren oder löschen. Die Bereichsgrenze 0x8000 von ICR1 ist so gewählt, daß auch eine lange Interruptsperre nicht stört. Timer1 ist somit recht 'geduldig'. Bei einem 8-Bit Timer ist die Bereichsgrenze mit 0x80 deutlich kritischer, da bei einem 16 MHz Timer schon nach 8 µs ISR-Sperre ein gesetztes OVF-Flag nicht mehr eindeutig zugeordnet werden kann. Soviel wollte ich garnicht schreiben, aber ich hoffe, es ist verständlich geworden ;-)
Mi N. schrieb: > Gerhard O. schrieb: >> Ich vermute Du beziehst Dich auf den "T1OVF_Ctr = 0;" L186. >> Mein Grund dafür war: >> -OK, Capture ist passiert >> -Wir wissen aber nicht, ob es zur gleichen Zeit mit einem OVF passierte. >> Also kann ich ihn hier ohne Gefahr initialisieren, weil ja kein OVF fuer >> absehbare Zeit zu erwarten ist. Die OVF Flag lösche ich dann >> vorsichtshalber gleich für den Fall der Fälle. Das war mein Denken. > > Am Capture-Wert (ICR1) kann man erkennen, wie es um den Überlauf steht. > Ist der Wert im Bereich 0x8000 - 0xffff kann in der letzten Zeit kein > Überlauf stattgefunden haben. Das OVF-Flag kann unbeachtet bleiben. > > Wird ICR1 als 0x0000 - 0x7fff gelesen und OVF_Flag ist gesetzt, dann ist > die OVF-ISR zurückgestellt (pending) und wird erst nach der CAPT-ISR > ausgeführt. In der CAPT-ISR wird daher der Zeitpunkt (korrigierend) um > 0x10000 erhöht, obwohl T1OVF_ctr noch um 1 zu klein ist. > Nach Verlassen der CAPT-ISR wird die OVF-ISR ausgeführt und T1OVF_ctr++ > ausgeführt. Dann passt wieder alles zusammen. > Damit das ungestört ablaufen kann, darf man weder das OVF-Flag noch > T1OVF_ctr in der CAPT-ISR manipulieren oder löschen. > > Die Bereichsgrenze 0x8000 von ICR1 ist so gewählt, daß auch eine lange > Interruptsperre nicht stört. Timer1 ist somit recht 'geduldig'. > Bei einem 8-Bit Timer ist die Bereichsgrenze mit 0x80 deutlich > kritischer, da bei einem 16 MHz Timer schon nach 8 µs ISR-Sperre ein > gesetztes OVF-Flag nicht mehr eindeutig zugeordnet werden kann. > > Soviel wollte ich gar nicht schreiben, aber ich hoffe, es ist > verständlich geworden ;-) Hallo Michael, vielen Dank für Deine ausführliche Erläuterung und alles andere. Ich habe Deine Source umgesetzt und es funktioniert;-) Die neuesten Ergebnisse: 0.1 - 0.0999975 Hz 1 - 0.9999753 Hz 10 - 9.9997539 Hz 100 - 99.9975357 Hz 1K - 999.9754638 Hz 10K - 9999.7539062 Hz Die Frequenz wird schon richtig angezeigt. Der Quarz schwingt nämlich bei 16.000395 MHz. Die ausgegebenen Frequenzen waren zumindest für einige Minuten konsistent. Scheint "Rock Solid" zu sein! Ausreißer scheint es tatsächlich nicht zu geben. Ich ziehe vor Dir meinen (nicht vorhandenen) Hut;-) Das Bild zeigt meine vorherige Version. Ich zeige es nur, um zu demonstrieren wie leicht die Quarze auf Umgebungstemperaturen reagieren. Gerhard
:
Bearbeitet durch User
Gerhard O. schrieb: > Ich > habe Deine Source umgesetzt und es funktioniert;-) >
1 | if((TIFR1 & 1<<TOV1) && (zeit_low < 0x8000)) // evtl. Ueberlauf T1 noch offen? |
2 | zeit_high++; // nur, wenn capture-int + overflow-int gleichzeitig ! |
Ja, das sieht korrekt aus.
Moin, Ich habe das Printout Format auf den alten Stand zurück gebracht. Im Frequenzbereich von 0.1 bis 100kHz funktioniert Michaels Methode einwandfrei. Mein Test Generator geht nur bis 100kHz. Aber da wird es sowieso enger. Ich habe das Program hier angehängt wenn jemand damit spielen will. Nochmals vielen Dank an Euch. Das wirklich zu verstehen war anfänglich nicht leicht. Man merkt das zunehmende Alter der grauen Zellen;-) Gruss, Gerhard
Beitrag #7591978 wurde vom Autor gelöscht.
Hier ist ein Plot vom Pro-Mini der mit einer 25W Halogen Lampe in 10cm angestrahlt wurde. Das verwendete Modul hat einen HC-49 16MHz Quarz drauf. Das Logging Programm ist die letzte Version.
:
Bearbeitet durch User
Moin, ich testete das neueste Program gestern Abend noch für einige Stunden. Es läuft im Frequenzbereich von 0.1 bis 100000 Hz absolut fehlerfrei. Ich konnte keine einzige Anomalie in den Aufzeichnungen entdecken. Fuer meine Uhrenanwendung bestehen da keinerlei Bedenken. Das D13 LED am Arduino zeigt jetzt an, wenn gerade gemessen wird, wie früher die "GATE" Anzeige bei alten Zählern. Auch wird der Stellenwert automatisch der Eingangsfrequenz angepasst, so dass immer 7 Stellen richtig angezeigt werden können. Wenn man den Wert von F_CPU anpasst, wird die Frequenz exakt angezeigt. Das könnte man noch automatisieren. Bei mir muss ich 16000390 eingeben um eine exakte 1.0000000 Hz Ausgabe zu bekommen, sonst werden 0.9999758 angezeigt. Die Stabilität der Ergebnisse ist beeindruckend; man beobachtet sehr wenig LSD-Unruhe. Jedenfalls bin ich Dank Eurer Hilfe jetzt sehr zufrieden! Im Anhang das aktuelle Programm, wenn jemand noch damit spielen möchte. Wenn man in TeraTerm Logging einschaltet, kann man es auch als sehr einfachen Datenlogger verwenden. Ein LM335 an AN0 dient zur einfachen Temperaturerfassung. Nachtrag: Der Pro-Mini mit HC-49 16MHz Quarz drauf ist um Längen stabiler wie ein Nano mit Keramik Resonator. Ein Nano misst auch unruhiger. Beim PM war der RAW Wert praktisch sehr Langzeit-stabil. Der Nano tanzt andauernd um mindestens +/- 10 LSD-Werte herum. Keramik-Resonatoren sind hier definitiv für solche Anwendung weniger geeignet. Gerhard
:
Bearbeitet durch User
Gerhard O. schrieb: > Bei mir muss ich > 16000390 eingeben um eine exakte 1.0000000 Hz Ausgabe zu bekommen, sonst > werden 0.9999758 angezeigt. Nun wäre die Frage zu klären, wer genauer ist: der Generator oder der Quarz am AVR...
Gerhard O. schrieb: > Fuer meine Uhrenanwendung bestehen da keinerlei Bedenken. Schön zu lesen, daß Du Dich an den kleinen Dingen des Lebens noch so erfreuen kannst ;-) Wie willst Du denn die Pendelbewegung erfassen? Optisch mit Lichtschranke? Da wird sicherlich noch viel Jitter auftreten, der geglättet werden will.
Mi N. schrieb: > Gerhard O. schrieb: >> Fuer meine Uhrenanwendung bestehen da keinerlei Bedenken. > > Schön zu lesen, daß Du Dich an den kleinen Dingen des Lebens noch so > erfreuen kannst ;-) > Wie willst Du denn die Pendelbewegung erfassen? Optisch mit > Lichtschranke? > Da wird sicherlich noch viel Jitter auftreten, der geglättet werden > will. Rick schrieb: > Gerhard O. schrieb: >> Bei mir muss ich >> 16000390 eingeben um eine exakte 1.0000000 Hz Ausgabe zu bekommen, sonst >> werden 0.9999758 angezeigt. > Nun wäre die Frage zu klären, wer genauer ist: der Generator oder der > Quarz am AVR... Moin, in meinem Fall habe ich einen selbstgebauten Testgenerator mit einer Stratum III Zeitbasis mit täglicher Alterungsrate im 1e-10 Bereich der Ausgangssignale zwischen 0.1Hz bis 100kHz ausgibt. Der hat sich sehr bewährt. Mit hochwertigen Messgeräten sind die Messanzeigen extrem ruhig. Der Pro-Mini hatte eben von der Herstellung her einen Quarz eingebaut der ein bisschen daneben liegt und bei konstanter Temperatur auch ganz ordentlich stabil ist. Der China Nano hat einen der putze kleinen Keramikresonatoren drauf. Der ist definitiv für Zeitmessungen weniger geeignet. Aber das sit in Ordnung, weil ich den Nano dafür nicht verwenden werde. Alles cool;-) Gerhard
Mi N. schrieb: > Gerhard O. schrieb: >> Fuer meine Uhrenanwendung bestehen da keinerlei Bedenken. > > Schön zu lesen, daß Du Dich an den kleinen Dingen des Lebens noch so > erfreuen kannst ;-) Hmmm. Das hoert sich schon an ein Kompliment an. Aber, ist es das wirklich? ;-) > Wie willst Du denn die Pendelbewegung erfassen? Optisch mit > Lichtschranke? Ja. Die Pendelbewegung wird optoelektronisch mit OPL583 Doppelsensoren erfasst. Es sind drei Sensoren angeordnet. Einer erfasst BDC. Der linke Auessere die Pendelamplitude die auf 0.5mm stabil gehalten wird und einen Trigger-sensor for das Antriebssystem. Das Pendel ist auf 1 Grad Halbwinkel eingestellt. Totaler Ausschlag ist 2 Grad. Die Amplitude wird nach Hipp gesteuert und schlägt typisch alle 30s zu. Das Pendel hat die Autonomie sich selber zu versorgen wenn die Amplitude um 0.5mm abfällt. > Da wird sicherlich noch viel Jitter auftreten, der geglättet werden > will. Da habe ich schon Erfahrungswerte vom Pendelteststand. Mit einem PM6666 in Perioden Modus, ist der Bereich des Jitters im +/- 200us Bereich und statistisch ziemlich zufällig. Das wird sich mit einem Filter reduzieren lassen. Die 1.6s Nominal-Pendelschwingung wird in der Lotposition (BDC) des Pendels erfasst. Es geht hier um ein Testkonzept. Ich möchte die inhären Fehlereinflüsse auf die Pendelschwingung in SW kompensieren. Anstatt mechanisch aufwendig und teuer das Pendel so stabil wie möglich zu bringen, möchte ich es als Experiment anders anfassen. Das Ziel ist mit Hilfe des uC die bekannten Störquellen wie Temperaturänderungen und Druckänderungen die den Pendelauftrieb direkt beeinflussen, mit elektronischen Sensoren messen und dann den gemessenen Zeitwert (Dir Dank) entsprechend so kompensieren, dass der Pendelzeitwert in SW stabil gehalten wird. Das Ziel ist also, die natürlichen Abweichungen des Pendels als Eingabewert zu akzeptieren und dann anhand der Sensor-Messwerte mathematisch entsprechend zu skalieren und vom natürlichen Pendelzeitwert zu subtrahieren oder addieren. Die Hoffnung ist, dass das machbar ist und der Zweck meines Experiments. Dann nehme ich den aufbereiteten Zeitwert und lasse durch ihn mit Hilfe des T1 Compare Timer ein genau bemessenes Ausgangssignal zur Erzeugung des Schrittschalt-Impuls für die Anzeige im Sekundentakt. Da Capture und Compare von der selben Zeitbasis stammen, fällt dieser Faktor aus den Berechnungen. Da Eingabe und Ausgabe unabhängig voneinander operieren, ist es nur notwendig das T1 Compare System so zu konstruieren, dass die Timing von der AVR HW abhängt und FW nur die Überläufe zu überwachen hat. Da ist mir noch nicht alles klar. Ich habe zur Zeit vor, den Compare Wert des Timers mit N=64000 und 0.0625us Takt laufen zu lassen. Das ergibt 250 Überläufe für eine 1s Perioden Ausgabe. Der Plan ist nun eine Kombination von (249*64000) + 4000 Das ergibt 996000 + 4000 = 1000000 us. Durch einmalige Veränderung irgendeiner der Compare Wert Eingaben kann man jetzt den Sekundentakt in 0.0625us Schritten kalibrieren. Es ist aber kritisch für die Ausgabe, dass ohne irgendwelche Vorteilung gearbeitet wird. Bei 16MHz mit 0.0625us Auflösung, fällt jeder Schritt mit 1.97s per Jahr ins Gewicht. Also sind die Anforderungen ziemlich hoch. Jedenfalls, das ist der Grund warum ich nach einer zuverlässigen Zeitmessmethode gesucht hatte. Dank Dir kann man das jetzt abhaken. Sorry für die langatmige Erklärung. Aber es geht nicht anders. Gruss, Gerhard
:
Bearbeitet durch User
Hier ist ein Plot und Daten vom Nano (1std). Nicht gerade sehr erbaulich. Die Temperaturwerte sind im Vergleich zum Pro-Mini auch schlechter. Leider ist die AREF von VCC abgeleitet und ziemlich verseucht. Aber momentan habe ich keine Zeit das zu verbessern. Die beiden Ausreißer, vermute ich, haben nichts mit der Capture zu tun. Beim PM konnte man nichts dergleichen beobachten. Sie korrelieren auch mit der Temperaturerfassung.
:
Bearbeitet durch User
Gerhard O. schrieb: >> Schön zu lesen, daß Du Dich an den kleinen Dingen des Lebens noch so >> erfreuen kannst ;-) > Hmmm. Das hoert sich schon an ein Kompliment an. Aber, ist es das > wirklich? ;-) Mein Kompliment an Dich, daß Du Ratschlägen folgend zu einem für Dich guten Ergebnis gekommen bist. Wenn man die Feinheiten beachtet, liefert so ein ATmega zu kleinen Kosten eine richtig gute Lösung. Weiter oben waren ja auch Stimmen zu vernehmen, die jegliches Gelingen in Abrede gestellt haben. Einmal vorgeplappert, wird das dann immer unrefektiert wiederholt. Da gibt es von mir dann keine Komplimente ;-) Wenn man mit reziproken Zählern erst einmal richtig angetriggert ist und nach immer schneller - weiter - höher strebt, wird die Luft deutlich dünner. Nur 10 stabile Stellen sind dann plötzlich ganz schlecht und machen richtige Kopfschmerzen ;-)
Mi N. schrieb: > Nur 10 stabile Stellen sind dann plötzlich ganz schlecht Das könnte hier auch nochmal auffallen: Ein float hat 4 byte, double scheint es nicht zu geben (oder?)
1 | 1 tick dauert 0.062550 Mikrosekunden |
2 | 55555 also 3474.965250 |
3 | float rechnet 3474.965332 |
4 | Abweichung 0.000082 |
Mi N. schrieb: > Gerhard O. schrieb: >>> Schön zu lesen, daß Du Dich an den kleinen Dingen des Lebens noch so >>> erfreuen kannst ;-) >> Hmmm. Das hoert sich schon an ein Kompliment an. Aber, ist es das >> wirklich? ;-) > > Mein Kompliment an Dich, daß Du Ratschlägen folgend zu einem für Dich > guten Ergebnis gekommen bist. Wenn man die Feinheiten beachtet, liefert > so ein ATmega zu kleinen Kosten eine richtig gute Lösung. Ja finde ich auch. Ich freue mich auch, daß es mit Deiner Guidance geklappt hat. > > Weiter oben waren ja auch Stimmen zu vernehmen, die jegliches Gelingen > in Abrede gestellt haben. Einmal vorgeplappert, wird das dann immer > unrefektiert wiederholt. Da gibt es von mir dann keine Komplimente ;-) Verstehe ich. > > Wenn man mit reziproken Zählern erst einmal richtig angetriggert ist und > nach immer schneller - weiter - höher strebt, wird die Luft deutlich > dünner. Nur 10 stabile Stellen sind dann plötzlich ganz schlecht und > machen richtige Kopfschmerzen ;-) Wie viele Stellen kann jetzt die Industrie? Hallo Michael, Ich möchte noch einen zweiten ICP Kanal zum Zweck des Phasenvergleichs mit einem GPS 1PPS hinzufügen. Das wäre am Einfachsten mit einem uC der zwei oder mehr ICP Eingänge hat. Ich dachte zwecks Kompatibilität mit Arduino an den 328PB oder dem 1284P oder ähnliches Familienmitglied. Für den Phasenvergleich dachte ich an ein externes RS-FF, dessen Ausgang Impulsbreite dann vom zweiten ICP Kanal gemessen wird. Das RS-FF kriegt am Setzeingang das 1PPS Uhrwerk Ausgangssignal und am Rücksetzeingang das GPS 1PPS Signal. Dann kann ich die Phasenabhängigkeit der Uhr mit dem GPS als Referenz aufzeichnen und anzeigen. Ich vermute es spricht nichts dagegen zwei ICP Instanzen Deiner Methode gleichzeitig zu betreiben. Bitte lasse mich wissen ob Du irgendwelche Einwände dagegen hast. Was mehr Stellen betrifft, fürchte ich, daß es nur mit Interpolation oder höherer Taktfrequenz verwirklichbar ist. Ich vermute mit Interpolation lässt sich da möglicherweise etwas machen, ohne mit 10GHz takten zu müssen. Ich habe mich da noch nicht gescheit gemacht, was es da an kommerziellen Geräten gibt. Ist mir zu exotisch. Es gibt aber s.i.w., anscheinend Messgeräte mit bis zu 12-13 Stellen. Mein PM6666 kann da nur 7-8 Stellen, was aber oft völlig ausreichend ist. Ich möchte dieses W.E. Das Pendel mit dem P.M. Testprogramm aufzeichnen, um mir ein Bild über das Kurzzeitverhalten machen zu können. W.g. das Pendel hat ca. +/-200us an Jitter. Auch möchte ich untersuchen, welchen Effekt das 30s Pendel Anstossen auf die Schwingungsdauer hat. Am PM6666 merke ich schon einen ganz kleinen, kurzen Effekt gleich nach dem Anstoß. Der verschwindet gleich wieder nach der nächsten Schwingung. Ist eigentlich ein sehr interessantes Thema. Ich hätte übrigens Lust mir irgendwann ein Frequenzmessgerät anhand Deiner Vorschläge zu bauen. Aber momentan möchte ich mich nicht verzetteln, weil ich brennend gerne erfahren möchte, ob mein Uhrenkonzept Aussicht auf Erfolg haben wird. Gruß, Gerhard
Helmut H. schrieb: > Mi N. schrieb: >> Nur 10 stabile Stellen sind dann plötzlich ganz schlecht > > Das könnte hier auch nochmal auffallen: > Ein float hat 4 byte, double scheint es nicht zu geben (oder?) Das ist kein Problem, da hierfür µCs mit ARM-Kernen zum Beispiel STM32Fxxx besser geeignet sind. Da sind Fließkommawerte von Hause aus 'double', wenn man nicht explizit nur 'float' anfordert. Gerhard O. schrieb: > Ich möchte noch einen zweiten ICP Kanal zum Zweck des Phasenvergleichs > mit einem GPS 1PPS hinzufügen. Das wäre am Einfachsten mit einem uC der > zwei oder mehr ICP Eingänge hat. Ich dachte zwecks Kompatibilität mit > Arduino an den 328PB oder dem 1284P oder ähnliches Familienmitglied. Das kannst Du machen. ...1284 oder ...2560 würden passen. Einen GPS-stabilisierten Zähler hatte ich mit dem ATmega162 gemacht. Heutzutage bieten sich eher die erwähnten STM32 (o. ä.) oder auch der RP2040 auf einem Pico-Board an. Das muß aber nicht sein und inwieweit man das noch auf Arduino-Basis umsetzen kann, weiß ich nicht. Selber hätte ich ohne Debugging (ST-Link, J-Link) per SWD nichts davon auf die Reihe bekommen.
Mi N. schrieb: > Helmut H. schrieb: >> Mi N. schrieb: >>> Nur 10 stabile Stellen sind dann plötzlich ganz schlecht >> >> Das könnte hier auch nochmal auffallen: >> Ein float hat 4 byte, double scheint es nicht zu geben (oder?) > > Das ist kein Problem, da hierfür µCs mit ARM-Kernen zum Beispiel > STM32Fxxx besser geeignet sind. Da sind Fließkommawerte von Hause aus > 'double', wenn man nicht explizit nur 'float' anfordert. > > Gerhard O. schrieb: >> Ich möchte noch einen zweiten ICP Kanal zum Zweck des Phasenvergleichs >> mit einem GPS 1PPS hinzufügen. Das wäre am Einfachsten mit einem uC der >> zwei oder mehr ICP Eingänge hat. Ich dachte zwecks Kompatibilität mit >> Arduino an den 328PB oder dem 1284P oder ähnliches Familienmitglied. > > Das kannst Du machen. ...1284 oder ...2560 würden passen. Einen > GPS-stabilisierten Zähler hatte ich mit dem ATmega162 gemacht. > Heutzutage bieten sich eher die erwähnten STM32 (o. ä.) oder auch der > RP2040 auf einem Pico-Board an. > Das muß aber nicht sein und inwieweit man das noch auf Arduino-Basis > umsetzen kann, weiß ich nicht. Selber hätte ich ohne Debugging (ST-Link, > J-Link) per SWD nichts davon auf die Reihe bekommen. Danke Michael, Das ist gut zu wissen. Ich möchte aber lieber bei den 8-Bittern bleiben. Für so eine langsame Anwendung sind die AVRs insgesamt gerade richtig und auch gemütlicher zum Erstellen der Programme. Abgesehen davon, ziehe ich hier 5V Technologie vor. Ich werde bald versuchen, einen zweiten ICP auf dem 328PB von Watterott gleichzeitig zu betreiben und werde dann rückmelden, oder Dich, falls notwendig, frevelhaft und untertänigst, um Deinen Rat zu erbetteln:-))) Der Watterott P.M. wird wahrscheinlich, wie der Nano vorher wegen seines Keramik Resonators, ziemlich unstetige Werte liefern. Aber das macht zum Testen nichts. Die Chinesischen Pro-Minis mit HC-49 Quarz drauf, machen es ziemlich gut, wenn man von der Temperaturempfindlichkeit mal absieht. Gruß, Gerhard
Moin, falls es interessiert: ich habe jetzt das 1.6s Pendel mit dem ICP-Programm für ungefähr 15m aufgezeichnet. Man sieht deutlich die Pendel Energiezuführungs-Impulse. Das Pendel bestimmt selber wenn es neue Energie braucht, wenn die Pendelamplitude um 0.5mm abgefallen ist. Ich werde sie aber wahrscheinlich bei der Auswertung ausblenden müssen. Die ~30s Impulse sind übrigens messtechnisch verursacht. Ich messe das Pendel im Nulldurchgang (BDC). Wenn das Pendel aber angestoßen wird, schlägt es momentan etwas weiter aus und macht das Messsignal zeitmässig nach diesem Durchgang singular unsymmetrisch. Momentan schwingt das Pendel in freier Luft unter Raum Temperaturschwankungen. Die Pendelstange ist noch nicht in INVAR ausgeführt und besteht aus normalem Werkzeugstahl. Jedenfalls scheinen die Messungen realistisch zu funktionieren. Gerhard
Gerhard O. schrieb: > Das wäre am Einfachsten mit einem uC der > zwei oder mehr ICP Eingänge hat. Man kann den ICP auch über den ADC-MUX und den Komparator umschalten, dann hat man bis zu 8 (DIP) bzw. 10 (SMD) ICP-Eingänge nacheinander.
Gerhard O. schrieb: > Ich möchte aber lieber bei den 8-Bittern bleiben. Dann hättest Du aber wenigstens die neuen AVRs nehmen können. > Das Pendel hat nun eigentlich welche Funktion und Hintergrund?
Gerhard H. schrieb: > welche Funktion und Hintergrund? Gerhard O. schrieb: > Falls jemand neugierig ist, diese Messung ist für ein spezielles > Pendeluhrenprojekt beabsichtigt, das ich Euch später hier vorstellen > würde. Ich möchte aber momentan nicht Weiteres darüber verlauten lassen, > weil Vieles momentan noch in der Planungsphase ist und ich lieber ein > funktionierendes Projekt vorstellen will, anstatt es hier totzureden. > Ich möchte jetzt also nur bemerken, daß es ein altes Problem der > Fehlerursachen von Pendeluhren auf eine besondere Art lösen will, die > bisher scheinbar noch nicht versucht wurde.
Gerhard O. schrieb: > Ich möchte aber lieber bei den 8-Bittern bleiben. > Für so eine langsame Anwendung sind die AVRs insgesamt gerade richtig > und auch gemütlicher zum Erstellen der Programme. Volle Zustimmung! Vermutlich verwendest Du den 1 PPS Impuls eines GPS-Empfängers und die Phasenlage muß nur auf 1 s stabil sein. Dazu könnte man auch einen beliebigen anderen Interrupt (INT0, INT1, PCINTx) verwenden und ohne hochgenaues 'capture' den Wert von Timer1 in der betreffenden ISR lesen. Je nach Hintergrundbelastung wird der Jitter wohl 1 - 20 µs betragen, was aber bezogen auf 1 s völlig egal ist. Was auf jeden Fall erreicht wird, ist die Langzeitstabiltät ohne Abhängigkeit vom lokalen Taktgeber. Beispielsoftware findest Du (wie üblich) auf meiner Seite unter "4-Kanal Drehzahlmessung". Ich will Dich aber nicht davon abhalten, neue Erfahrungen mit anderen AVRs zu machen und Deine Knete zu verballern ;-) Gerhard H. schrieb: > Gerhard O. schrieb: >> Ich möchte aber lieber bei den 8-Bittern bleiben. > > Dann hättest Du aber wenigstens die neuen AVRs nehmen können. Wieso? Um alles auf Anfang und auf den Kopf zu stellen? Gibt es eine Arduino Unterstützung für diese Controller? Aber danke, daß Du mich erinnert hast, das hier zu liegende 'kuriose' ATmega4808-Board doch einmal anzuwerfen!
Mi N. schrieb: > Wieso? Zeitintervalle messen macht sich nämlich auch gut und sehr kräftesparend mit dem neuen Event-System. > Hintergrundbelastung interessiert da herzlich wenig. > Gibt es eine > Arduino Unterstützung für diese Controller? Gute Frage. Hab ich jetzt nicht dran gedacht, bin selber darauf (und damit verbundene "Hintergrundbelastung") nicht angewiesen.
:
Bearbeitet durch User
Gerhard H. schrieb: > Mi N. schrieb: >> Wieso? > > Zeitintervalle messen macht sich nämlich auch gut und sehr kräftesparend > mit dem neuen Event-System. > >> Hintergrundbelastung > > interessiert da herzlich wenig. Also noch mehr auf den Kopf stellen? Gerhard möchte gerne bei Arduino bleiben. Und da würde ich eher das RP2040 Pico-Board ins Spiel bringen, was die (doch recht lahmen) AVRs kalt im Regen stehen läßt. Aber auch die werden hier nicht benötigt. Wenn ein Fahrrad reicht, brauche ich kein Flugtaxi.
Gerhard O. schrieb: > Das Pendel bestimmt selber wenn es neue Energie braucht, wenn die > Pendelamplitude um 0.5mm abgefallen ist. Bei den alten Hauptpendeluhren wurde das Pendel mit einer konstanten Kraft durch ein Gewicht angetrieben. Die Amplitude blieb daher gleich, da sie ja die Frequenz beeinflußt. Das Gewicht wurde mit dem Minutenimpuls wieder hochgezogen. Bei Uhrenzentralen mit 2 Pendeluhren wurde durch den Magnet gerade nur soviel Energie zugeführt, damit die Synchronisation aufrecht erhalten wird. Beide Uhren mußten also erst unabhängig auf gleichen Gangfehler justiert werden. Die jeweils andere mußte dazu angehalten werden, da schon die Schwingungsübertragung auf das gemeinsame Gehäuse eine Synchronisation bewirken kann. Dann wurden sie angehalten, ausgelenkt und gleichzeitig losgelassen. Sieht die Auslenkung synchron aus, kann der Magnet zugeschaltet werden. Die Pendelgewichte sind so gelagert, daß sich eine Temperaturkompensation ergibt. Man sieht in der unteren Hälfte des Gewichts das dickere Rohr aus einem Material mit anderem TK. https://bawue.museum-digital.de/object/59714
Mi N. schrieb: > Gerhard H. schrieb: >> Dann hättest Du aber wenigstens die neuen AVRs nehmen können. > Gibt es eine Arduino Unterstützung für diese Controller? > Aber danke, daß Du mich erinnert hast, das hier zu liegende 'kuriose' > ATmega4808-Board doch einmal anzuwerfen! Hallo, die megaAVR0 Serie hat Arduino Unterstützung von MCUdude mittels MegaCoreX. Beachten sollte man das die TCBs bei der Serie kein OVF Flag haben. Wenn dann würde ich einen AVRxDB oder AVRxEA verwenden. Spence DxCore. Kann man gleich 2 TCB in Hardware zu 32-Bit kaskadieren. Und man hat 2 TCA zur Verfügung. Man muss umdenken, dafür misst TCB alles direkt in Hardware, der Zirkus mit Flags beachten entfällt.
Veit D. schrieb: > Mi N. schrieb: > >> Gerhard H. schrieb: >>> Dann hättest Du aber wenigstens die neuen AVRs nehmen können. >> Gibt es eine Arduino Unterstützung für diese Controller? >> Aber danke, daß Du mich erinnert hast, das hier zu liegende 'kuriose' >> ATmega4808-Board doch einmal anzuwerfen! > > Hallo, > > die megaAVR0 Serie hat Arduino Unterstützung von MCUdude mittels > MegaCoreX. > Beachten sollte man das die TCBs bei der Serie kein OVF Flag haben. > Wenn dann würde ich einen AVRxDB oder AVRxEA verwenden. Spence DxCore. > Kann man gleich 2 TCB in Hardware zu 32-Bit kaskadieren. > Und man hat 2 TCA zur Verfügung. > Man muss umdenken, dafür misst TCB alles direkt in Hardware, der Zirkus > mit Flags beachten entfällt. Hallo Veit, Ich gebe Dir ja in allen Punkten recht. Mit den neuen AVRs würde ich mir mein Leben leichter machen. Auch könnte ein Curiosity Modul als Einsteckmodul dienen. Du hast Dich ja mächtig in die DA/DB Technik reingekniet. Aber ich möchte vorläufig trotzdem lieber mit ihren Vorgängern arbeiten. Ist schwer zu begründen. Es spielt hier auch ein gewisser Nostalgiefaktor mit. Dein Argument trifft natürlich auch auf die STM32 zu. Die haben ja tonnenweise Timer und Zähler eingebaut. Aber die will ich aus anderen Gründen nicht verwenden. Für diese Anwendung wäre das aber für mich wirklich gleich, mit Kanonen auf Spatzen zu schiessen. Dir einen schönen Tag noch, Gerhard
Peter D. schrieb: > Gerhard O. schrieb: >> Das Pendel bestimmt selber wenn es neue Energie braucht, wenn die >> Pendelamplitude um 0.5mm abgefallen ist. > > Bei den alten Hauptpendeluhren wurde das Pendel mit einer konstanten > Kraft durch ein Gewicht angetrieben. Die Amplitude blieb daher gleich, > da sie ja die Frequenz beeinflußt. Das Gewicht wurde mit dem > Minutenimpuls wieder hochgezogen. > Bei Uhrenzentralen mit 2 Pendeluhren wurde durch den Magnet gerade nur > soviel Energie zugeführt, damit die Synchronisation aufrecht erhalten > wird. > Beide Uhren mußten also erst unabhängig auf gleichen Gangfehler justiert > werden. Die jeweils andere mußte dazu angehalten werden, da schon die > Schwingungsübertragung auf das gemeinsame Gehäuse eine Synchronisation > bewirken kann. Dann wurden sie angehalten, ausgelenkt und gleichzeitig > losgelassen. Sieht die Auslenkung synchron aus, kann der Magnet > zugeschaltet werden. Schon toll wie man das damals mit einfachen Mitteln, so perfekt hinkriegte. > Die Pendelgewichte sind so gelagert, daß sich eine > Temperaturkompensation ergibt. Man sieht in der unteren Hälfte des > Gewichts das dickere Rohr aus einem Material mit anderem TK. > > https://bawue.museum-digital.de/object/59714 Danke für den Link! Hallo Peter, Falls Du Erfahrungen mit solchen Pendelhauptuhranlagen gehabt hast, wäre ich Dir fast ein bisschen neidisch. Ich kenne so etwas nur aus Internet Unterlagen. Denen zu beobachten, muß wirklich toll gewesen sein. Was das Pendelenergiezufuhr Thema betrifft, kann man das in verschiedenster Weise sehen. Ich habe mir da schon Gedanken gemacht und mich am Schluß auf das selbstregulierende Hipp Verfahren entschieden, weil es meiner Auffassung entsprechend die freiest mögliche Pendelschwingung mit geringen Aufwand ermöglicht. Von PID Steuerung bis zu Gewichts kontinuierlichen Antrieb wurden ja früher die verschiedensten Möglichkeiten ausgenutzt. Ich beschränke mich aber jetzt nur auf elektrisch angetriebene Pendeluhren ohne Antrieb des Pendels über das Hemmungsrad. Einige Uhrentypen hatten ein Zählrad und typisch 30s Auslösung durch ein fallendenden Rollenhebel (Synchronom). Dieses Prinzip (Hope Jones, Shortt) hat sich durchaus sehr bewährt, wie die synchronisierten Uhrenpaare für Astronomieuhren, bewiesen und damals zu den genauesten Uhren der Welt gehörten. Ich könnte das ohne Weiters in meinem Design anwenden, und werde möglicherweise später, damit auch experimentieren. Lineare, proportionale PID Steuerung ist mir einerseits momentan zu aufwendig und leidet meiner Ansicht daran, das Pendel zu "vergewaltigen" wenn man es nicht optimal implementiert. Es widerspricht meinem Bestreben, das Pendel so frei wie technisch möglich, zwischen Energiezufuhr-Intervallen, ohne unnötige Störungen durch den Antrieb schwingen zu lassen. Das geniale Hipp Verfahren vereinbart zwei wichtige Faktoren. Es gibt dem Pendel die Autonomie sich nur, wenn notwendig, verbrauchte Energie zu ersetzen, um sich dann solange wie möglich selber zu überlassen. Ausser diesen, typisch alle 30s vorkommenden Energie-Impulsen, schwingt das Pendel vollkommen frei, was meiner Ansicht nach, ziemlich nahe an die Idealsituation herankommt. Deshalb habe ich mich für eine opto-elektronische Ausführung des Hipp'schen Verfahren entschlossen. Die Pendelamplitude wird mit dem OPL583 Dual Sensor erfasst. Ein Flip-Flop emuliert den gezogen, schwingenden Kontakthebel, das durch den OPL583 gesetzt und zurück gesetzt wird. Sobald die Amplitude um nur 0.5mm abfällt, wird das FF nicht mehr zurück gesetzt und leitet die Energiezuführung ein. Das Pendel hat also eine gewisse Autonomie seines Energiehaushalts. Bei den anderen Verfahren, wird dem Pendel blind Energie zugeführt, ob oder nicht, es nötig ist. Deshalb sehe ich im Hipp Verfahren einen gewissen Vorteil. Was den mechanischen Aufwand der Temperaturkompensation betrifft, soll ja gerade dieses Projekt beweisen oder widerlegen, ob es möglich ist, die störenden Pendeleinflüsse wie Temperaturexpansion der Metalle und dem Luftdruck abhängigen Einfluss des Luftauftriebs, in SW zu kompensieren, indem man im uC den erfassten Zeitwert mathematisch, anhand Sensordaten kompensiert und mit dem entsprechend programmierten Compare Timer Ausgang dann das Schrittschaltuhrwerk antreibt. Im Prinzip sollte das möglich sein und ist Zweck des Ganzen. Auch der Gang der Uhr, läßt sich dann in SW regulieren und man erspart sich die Regulierschraube und Gewichtsteller, die man früher dazu verwendet wird. Das Pendel braucht also nur beim Bau der Uhr ungefähr eingestellt werden und kann danach vergessen werden, solange diese Einstellung permanent und stabil bleibt. Im Prinzip spielt die genaue Frequenz der Pendelschwingung also keine akute Rolle mehr, solange man den Nominalwert kennt, die Differenz kann man als SW Justierwert eingeben um beste Genauigkeit der Uhr erzielen. VG, Gerhard
Mi N. schrieb: > Gerhard H. schrieb: >> Mi N. schrieb: >>> Wieso? >> >> Zeitintervalle messen macht sich nämlich auch gut und sehr kräftesparend >> mit dem neuen Event-System. >> >>> Hintergrundbelastung >> >> interessiert da herzlich wenig. > > Also noch mehr auf den Kopf stellen? > Gerhard möchte gerne bei Arduino bleiben. Und da würde ich eher das > RP2040 Pico-Board ins Spiel bringen, was die (doch recht lahmen) AVRs > kalt im Regen stehen läßt. > Aber auch die werden hier nicht benötigt. Wenn ein Fahrrad reicht, > brauche ich kein Flugtaxi. Guten Abend, Ausser STM32 habe ich ohnehin keine dieser schnellen uC. Da ich aber störrisch wie ein Maultier sein kann, begrenze ich meine Wahl auf 8-Bit Technik. Ist einfach gemütlicher dort. Ich befasse mich in der Arbeit den ganzen Tag mit STM32 und LPC Controller. Da ist AVR eine angenehme Abwechslung von den Komplexitäten und vergleichsweise viel anspruchsvolleren Anwendungen in der Firma. Abgesehen davon, finde ich die Welt der AVRs und auch PICS oder 8051er auch interessant und verlockend genug. Für Netzanbindung mache ich es über eine ESP WIFI Verbindung, um die Uhr überwachen zu können. Über die serielle Schnittstelle, lässt sich auch das bequem erledigen, ohne die Gesamt SW unnötig komplex zu machen. Ich ziehe auch eine logische Aufteilung der notwendigen Abläufe vor. Da meine Anwendung gute Anbindung an Realzeit Vorgänge notwendig macht, hat eine Aufteilung ohnehin mehr Sinn. Gerhard
Mi N. schrieb: > Gerhard O. schrieb: >> Ich möchte aber lieber bei den 8-Bittern bleiben. >> Für so eine langsame Anwendung sind die AVRs insgesamt gerade richtig >> und auch gemütlicher zum Erstellen der Programme. > > Volle Zustimmung! > Vermutlich verwendest Du den 1 PPS Impuls eines GPS-Empfängers und die > Phasenlage muß nur auf 1 s stabil sein. Dazu könnte man auch einen > beliebigen anderen Interrupt (INT0, INT1, PCINTx) verwenden und ohne > hochgenaues 'capture' den Wert von Timer1 in der betreffenden ISR lesen. > Je nach Hintergrundbelastung wird der Jitter wohl 1 - 20 µs betragen, > was aber bezogen auf 1 s völlig egal ist. Was auf jeden Fall erreicht > wird, ist die Langzeitstabiltät ohne Abhängigkeit vom lokalen Taktgeber. > Beispielsoftware findest Du (wie üblich) auf meiner Seite unter "4-Kanal > Drehzahlmessung". Dankeschön für den Hinweis. Ja. Das sollte ich mir durchdenken, weil diese Argumente stichhaltig sind. Es geht ja nur um Langzeitwerte um den Phasenfehler oder Abweichung sichtbar machen zu können. Da spielt der Jitter keine große Rolle und kann übersehen oder beruhigt werden. > Ich will Dich aber nicht davon abhalten, neue Erfahrungen mit anderen > AVRs zu machen und Deine Knete zu verballern ;-) Genau! Ich möchte mich nicht verzetteln. Genau wie ein Pilot, der sich einer Notlandung widmen muß, möchte ich das einmal gefasste Landeziel nun nicht mehr wesentlich ändern. > > Gerhard H. schrieb: >> Gerhard O. schrieb: >>> Ich möchte aber lieber bei den 8-Bittern bleiben. >> >> Dann hättest Du aber wenigstens die neuen AVRs nehmen können. > > Wieso? Um alles auf Anfang und auf den Kopf zu stellen? Gibt es eine > Arduino Unterstützung für diese Controller? > Aber danke, daß Du mich erinnert hast, das hier zu liegende 'kuriose' > ATmega4808-Board doch einmal anzuwerfen! ... ...
Gerhard, ich begrüße Deinen Ansatz, das Pendel nach seinem Gusto schwingen zu lassen und die gemessene Periode zu "normalisieren". Das mache ich mit Quarzen genau so. Statt Thermostat mache ich eine Temperaturkompensation. Aber alle 30 Sekunden die verlorene Energie zuzuführen, gefällt mir weniger. Ist es denn nicht möglich, stetig genau so viel Energie zuzuführen wie verloren geht, mit dem Ziel, eine stabile geregelte Amplitude zu erreichen? Für den geneigten Leser: Auf leapsecond.com beschreibt der Betreiber des genauesten privat betriebenen Zeitlabors Tom Van Baak aus Seatle (einer der Time-Nuts) seine Pendeluhr und deren Beeinflussung durch Gezeiten und Erdbeben: http://www.leapsecond.com/hsn2006/ http://www.leapsecond.com/pend/clockb/ http://www.leapsecond.com/pend/synchronome/quake.htm
Hallo Gerhard, das war eher als Antwort an Michael gedacht zu seiner Frage. Mach dir keinen Kopf, ich weiß das dir der 328P mehr liegt. :-) Das ist kein Problem. Man kann damit genauso gut messen. Falls wer wirklich dafür einen neueren AVR Controller verwenden möchte und man dafür nicht unbedingt einen großen 64 Pin AVRxDB benötigt, dann empfehle ich die AVRxEA Serie. Die hat unabhängig immer 2xTCA und 4xTCB zur Verfügung. Mehr wollte ich gar nicht reinquatschen und verfolge weiter ... Gerhard - weitermachen. :-)
Peter D. schrieb: > Gerhard O. schrieb: >> Das wäre am Einfachsten mit einem uC der >> zwei oder mehr ICP Eingänge hat. > > Man kann den ICP auch über den ADC-MUX und den Komparator umschalten, > dann hat man bis zu 8 (DIP) bzw. 10 (SMD) ICP-Eingänge nacheinander. Daran hätte ich nicht gedacht. Das muß ich mir im Datenblatt mal durchsehen. Diese Verbindungsmöglichkeit hätte ich nie erwartet und dass man an den MUX Ausgang herankommt. Danke!
Du könntest ja 2 AVRs nehmen und von einer Taktquelle (z.B. den zweiten vom Takt des ersten) versorgen.
Hallo Torsten, Torsten B. schrieb: > Gerhard, ich begrüße Deinen Ansatz, das Pendel nach seinem Gusto > schwingen zu lassen und die gemessene Periode zu "normalisieren". Das > mache ich mit Quarzen genau so. Statt Thermostat mache ich eine > Temperaturkompensation. Freut mich zu hören, dass ich deswegen noch nicht in die Klapsmühle gehöre:-) > > Aber alle 30 Sekunden die verlorene Energie zuzuführen, gefällt mir > weniger. > Ist es denn nicht möglich, stetig genau so viel Energie zuzuführen wie > verloren geht, mit dem Ziel, eine stabile geregelte Amplitude zu > erreichen? Na ja. Grundsätzlich schon. Nur fürchte ich, wenn man es nicht richtig macht, man es eher verschlimmbessern kann. Eine stetige Energiezufuhr wie bei einem elektronischen Oszillator mit Rückkopplung muß sehr sorgfältig realisiert werden, so daß die Pendelschwingung ohne Störungen durch den Antrieb erhalten wird. Das geht warscheinlich nur mit sehr sorgfältig bemessenem elektromagnetischen Antrieb und Erfassung der Pendelschwingung als Rückführgröße und korrekt eingestelltem Regelalgorithmus und vielleicht mit Forcefeedback. Aber das wäre eher ein eigenes Projekt, daß eine gänzlich andere Konstruktion bedingt, weil dann eine getrennte Antriebsspule und Positionserfassung notwendig wäre. In diesen Zusammenhang stellt sich dann die Frage ob man nicht das Voice Coil Driver Prinzip anwenden könnte, wie es zum Head positionieren bei Festplatten gebräuchlich ist. Damit könnte man bei geeigneter Ansteuerung die Kraft dynamisch sehr sanft gestalten. Möglichkeiten über Möglichkeiten. Ich könnte damit auch mit dieser Konstruktion experimentieren, weil der Erhaltungsintervall von der Energiezufuhr der Antriebsspulen abhängt. Durch Reduzierung der Spulenenergie kann ich praktisch eine 1:1 Erhaltung erzwingen. Der Spulenstrom verläuft zeitlich exponential abklingend, um das Pendel so wenig wie möglich zu stören. Ich werde es mal so einstellen und aufzeichnen. Phase und Dauer des Antriebs lässt sich einstellen. Der Antriebsimpuls geschieht zur Zeit ein wenig bevor BDC. Was mir übrigens an meinem Plot gestern aufgefallen ist, daß die 30s Impulse eine Reaktion suggerieren. Ich vermute deshalb, daß mein Pendelteststand nicht starr genug befestigt ist. Man kann nämlich mit dem geistigen Auge harmonische Unterschwingungen erkennen, die m.M.n. nur durch eine ungenügende Masse der Konstruktion oder Starrheit zu erklären wären. Aber das ist momentan nur eine Observation und muß untersucht werden. Aber das war gestern nicht Zweck der Sache, da ich nur das Pendel mit dem ICP aufzeichnen wollte. > > Für den geneigten Leser: Auf leapsecond.com beschreibt der Betreiber des > genauesten privat betriebenen Zeitlabors Tom Van Baak aus Seatle (einer > der Time-Nuts) seine Pendeluhr und deren Beeinflussung durch Gezeiten > und Erdbeben: > http://www.leapsecond.com/hsn2006/ > http://www.leapsecond.com/pend/clockb/ > http://www.leapsecond.com/pend/synchronome/quake.htm Vielen Dank für Deine hochinteressanten Links. Sind wirklich toll! Grüsse, Gerhard
:
Bearbeitet durch User
Torsten B. schrieb: > Du könntest ja 2 AVRs nehmen und von einer Taktquelle (z.B. den > zweiten > vom Takt des ersten) versorgen. Das müsste sich ergeben. Es sieht momentan schon so aus, als ob ein uC alle notwendigen Aufgaben alleine erfüllen kann. Der Takt der Timer HW wird ohnehin für gemeinsame Tätigkeiten gleichzeitig ausgenutzt. Capture, und Compare werden vom T1 geneinsam getaktet. Momentan bin ich schon der Meinung , daß der AVR es schaffen wird, mit allen Aufgaben zufriedenstellend zurechtzukommen. Im Vergleich zu den uC der 70-80er Jahre ist der AVR mit 16MHz ein Rennpferd. Da ist schon ziemlich viel möglich. Deshalb finde ich es auch ein wenig sportlich von mir motiviert, es mit bescheidenen Mitteln zu verwirklichen. Als zweiten uC kommt allenfalls der WIFI ESP8267/32 im Telnet Modus in Frage um mir eine (bequeme) drahtlose serielle Überwachungsmöglichkeit der Uhr zu ermöglichen. Das habe ich schon getestet. Eine Telnet Verbindung ist schon jetzt jederzeit möglich.
:
Bearbeitet durch User
Gerhard O. schrieb: > Deshalb finde ich es auch ein wenig sportlich von mir > motiviert, es mit bescheidenen Mitteln zu verwirklichen. Genau das ist der richtige Weg. :-) Ich würde noch, wenn ich du wäre, den Code so schnell wie möglich auf den 328PB umziehen, den hast du ja sowieso da. Dann hättest du zur Not noch einen weiteren 16 Bit Timer. Je mehr der Code wächst umso schwerer fällt einem das. Weil dann ggf. Pins umgelegt werden müssen usw. So als Hilfsgedanke.
:
Bearbeitet durch User
Veit D. schrieb: > Gerhard O. schrieb: >> Deshalb finde ich es auch ein wenig sportlich von mir >> motiviert, es mit bescheidenen Mitteln zu verwirklichen. > Genau das ist der richtige Weg. :-) > > Ich würde noch, wenn ich du wäre, den Code so schnell wie möglich auf > den 328PB umziehen, den hast du ja sowieso da. Dann hättest du zur Not > noch einen weiteren 16 Bit Timer. Je mehr der Code wächst umso schwerer > fällt einem das. Weil dann ggf. Pins umgelegt werden müssen usw. So als > Hilfsgedanke. Ja. Das werde ich tun. Ich fand gestern wieder ein paar Nanos mit dem 328PB und richtigen Quarz drauf. Der 328PB hat ja wesentlich mehr Timer Ressourcen. Aber momentan muß ich mich anderen Dingen widmen. Vielleicht gehts am Sonntag weiter. Schönes W.E. Gerhard
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.