AVR T1 Capture Problem - Meinung erbeten

[Gerhard O. (gerhard_)]

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

[Veit D. (devil-elec)]

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 ...

[Gerhard O. (gerhard_)]

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

[Ob S. (Firma: 1984now) (observer)]

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.

[Veit D. (devil-elec)]

Hallo,

mir gehts gut.  :-)

Zur Frage. Ja, da bin ich mir ziemlich sicher.

[Gerhard O. (gerhard_)]

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

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

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

[Veit D. (devil-elec)]

Hallo,

wenn ich nichts übersehen habe wird das Overflow Flag nicht 
berücksichtigt.
Dazu hat Peter hier niedergeschrieben:
Beitrag "AVR Timer mit 32 Bit"

[Ob S. (Firma: 1984now) (observer)]

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.

[Mi N. (msx)]

Deinen Code habe ich mit meinem verglichen und sehe, daß Du einen 
gesetzten Überlauf nicht beachtest.

volatile uint16_t zeit_low, // Timer1-Anteil
        zeit_high,          // T1 Ueberlauf-Anteil
        mess_dauer,         // minimale Wartezeit
        ueberlauf;


// Routinen zur Erfassung der Eingangsimpulse
// Überläufe von T1
ISR(TIMER1_OVF_vect)            
{
  ueberlauf++;                  // Ueberlaeufe von T1 ergeben obere 16bit der Messzeit
}

// CAPT-Ereignisse an AIN1
ISR(TIMER1_CAPT_vect)           // Eingangsimpulse mit genauem Zeitpunkt erfassen
{
static unsigned long count;     // Impulse per Interrupt                
  count++;
  if(mess_status == AUSLESEN) { // Ergebnisse synchron zum Eingangsimpuls auslesen+ablegen
    end_ereignis = count;       // Anzahl der Impulse lesen
    zeit_low = ICR1;            // capture-reg lesen: untere 16bit
    zeit_high = ueberlauf;      // dazu die oberen 16bit

// siehe hier:

    if((TIFR1 & BIT(TOV1)) && (zeit_low < 0x8000))    // evtl. Ueberlauf T1 noch offen?
      zeit_high++;              // nur, wenn capture-int + overflow-int gleichzeitig !
    mess_status = AUSWERTEN;    // Daten fertig fuer Auswertung
  }
  if(TIFR1 & BIT(ICF1)) {       // falls neuer Eingangsimpuls gekommen ist
    count++;                    // gleich hier auswerten
    TIFR1 = BIT(ICF1);          // und flag loeschen
  }
}

Vielleicht hilft es.

[Gerhard O. (gerhard_)]

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

[Helmut H. (helmuth)]

Konnte das Verhalten sehr gut reproduzieren.

ICP: 91392 OVF: 1 F: 175.0700
ICP: 25856 OVF: 0 F: 618.8119
ICP: 25856 OVF: 1 F: 618.8119
ICP: 91392 OVF: 0 F: 175.0700
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.

    ---+   +---+   +---+   +---+   +---+   +---+   +
       |   |   |   |   |   |   |   |   |   |   |   |
       +---+   +---+   +---+   +---+   +---+   +---+
       T1      T2      T1      T2      T1      T2
toggle 111111110000000011111111000000001111111100000
Mess   |-------|       |-------| 
Problem           O

Daher den Overflow-Counter auch beim T1 setzen gelöscht und alles wird 
gut:

 if (!toggle)
  {
    T1 = ICR1;
    toggle = 1;
    T1OVF_Ctr = 0;  //<------
  }
  
ICP: 25856 OVF: 1 F: 618.8119
ICP: 25856 OVF: 1 F: 618.8119
ICP: 25856 OVF: 0 F: 618.8119
ICP: 25856 OVF: 0 F: 618.8119
ICP: 25856 OVF: 0 F: 618.8119
ICP: 25856 OVF: 0 F: 618.8119
ICP: 25856 OVF: 0 F: 618.8119
ICP: 25856 OVF: 1 F: 618.8119
ICP: 25856 OVF: 1 F: 618.8119
ICP: 25856 OVF: 1 F: 618.8119

[Mi N. (msx)]

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.

[Ob S. (Firma: 1984now) (observer)]

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.

[Mi N. (msx)]

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.

[Ob S. (Firma: 1984now) (observer)]

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.

[Gerhard O. (gerhard_)]

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

[Veit D. (devil-elec)]

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.

[Mi N. (msx)]

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!

[Peter (pittyj)]

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.

[Veit D. (devil-elec)]

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.

[Mi N. (msx)]

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]

[Peter (pittyj)]

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.

[Gerhard O. (gerhard_)]

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...

[Mi N. (msx)]

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.

[Gerhard O. (gerhard_)]

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

[Peter D. (peda)]

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.

[Gerhard O. (gerhard_)]

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

[Mi N. (msx)]

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.

[Gerhard O. (gerhard_)]

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

[Mi N. (msx)]

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.

[Gerhard O. (gerhard_)]

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

[Mi N. (msx)]

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 ;-)

[Gerhard O. (gerhard_)]

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

[Peter D. (peda)]

Gerhard O. schrieb:
> Ich
> habe Deine Source umgesetzt und es funktioniert;-)

>

if((TIFR1 & 1<<TOV1) && (zeit_low < 0x8000))    // evtl. Ueberlauf T1 noch offen?
      zeit_high++;              // nur, wenn capture-int + overflow-int gleichzeitig !

Ja, das sieht korrekt aus.

[Gerhard O. (gerhard_)]

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

[Gerhard O. (gerhard_)]

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.

[Gerhard O. (gerhard_)]

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

[Rick (rick)]

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...

[Mi N. (msx)]

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.

[Gerhard O. (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 ;-)
> 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

[Gerhard O. (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

[Gerhard O. (gerhard_)]

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.

[Mi N. (msx)]

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 ;-)

[Helmut H. (helmuth)]

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 tick dauert      0.062550  Mikrosekunden
 55555 also     3474.965250
float rechnet   3474.965332
Abweichung         0.000082

[Gerhard O. (gerhard_)]

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

[Mi N. (msx)]

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.

[Gerhard O. (gerhard_)]

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

[Gerhard O. (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

[Peter D. (peda)]

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 H. (hauptmann)]

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?

[Martin H. (horo)]

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.

[Mi N. (msx)]

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!

[Gerhard H. (hauptmann)]

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.

[Mi N. (msx)]

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.

[Peter D. (peda)]

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

[Veit D. (devil-elec)]

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.

[Gerhard O. (gerhard_)]

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

[Gerhard O. (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

[Gerhard O. (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

[Gerhard O. (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!
...
...

[Torsten B. (butterbrotstern)]

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

[Veit D. (devil-elec)]

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.  :-)

[Gerhard O. (gerhard_)]

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!

[Torsten B. (butterbrotstern)]

Du könntest ja 2 AVRs nehmen und von einer Taktquelle (z.B. den zweiten 
vom Takt des ersten) versorgen.

[Gerhard O. (gerhard_)]

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

[Gerhard O. (gerhard_)]

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.

[Veit D. (devil-elec)]

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.

[Gerhard O. (gerhard_)]

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