Berndt, ich geh mal davon aus, das Du die einfach verfügbaren
Soundkarten basierten Zeitwaagen schon gesichtet hast.
Mich wundert, das es da keine Lösung gibt, die auch den Sekungenimpuls
eines GPS nutzen (und Absolutzeit über USB, seriell) und ein 2s Pendel
lesen können.
Eine Zeitwaage benutzt der Uhrmacher, um eine Uhr schnell einzuregulieren.
Der Datenlogger soll die Langzeitbeobachtung ermöglichen, dafür sind
Zeitwaagen nicht gebaut.
(Der Datenlogger ist nebenbei natürlich auch eine Zeitwaage).
Noch mal zu meiner Messung mit diesen auffälligen Wellen: ich muss nicht unbedingt wissen warum das so ist, ich habe nicht vor meine Uhr zu optimieren (ich habe geantwortet weil jemand gefragt hat).
Allerdings würde ich erwarten dass der TO sich dazu äußert wenn er hier schon schreibt was man alles aus der Aufzeichnung eines professionellen Datenloggers erkennen kann. Und eventuell auch die Messung an einer vergleichbaren einfachen Pendeluhr mit eben so einem professionellen Datenlogger zeigt damit man vergleichen kann.
Aber ehrlich gesagt frage ich mich schon was der TO eigentlich möchte: zum einem geht es um Glaskeramik versus Invar, auf der anderen Seite schreibt der TO hier
dass die Lichtschranken schon ganz gut seien weil die LED nur kurz aufblitzt ohne das näher zu quantifizieren bzw. genaue Angaben zu der Lichtschranke zu machen. Und auch der dort erwähnte Schlitz mit 0.5 mm ist nichts besonderes, die von mir erwähnte Gabellichtschranke von Optek gibt es z.B. mit einer Apertur von 0.08 mm auf der Sensorseite.
So eine "einfache" Pendeluhr wird man auch kaum mit einem Datenlogger
optimieren können.
Das gesamte Räderwerk ist von der Präzision sehr weit von dem Uhrwerk
einer Präzisionsuhr entfernt. Dazu kommt noch das Schlagwerk,hier wird
mechanisch Kraft vom Gehwerk abgenommen, um Hebel zu bewegen.
(Das müsste man komplett entfernen).
Die Hemmung ist bei solch einer Uhr meist ein gebogenes Stahlteil.
Eine Präzisionsuhr hat hier einen massiven Anker mit Rubinpaletten.
Sie läuft auch mit viel weniger Kraft (weniger als ein Zehntel, dass
eine Gebrauchsuhr hat).
Das entscheidende Teil ist das Pendel als Taktgeber, deswegen wird da ja
so ein Aufwand getrieben.
Dann kommen noch 1000 Feinheiten dazu, die eine Gebrauchsuhr von einer
PPU unterscheiden. Eine gute PPU hatte fast den Wert eines kleinen Hauses.
Fehler im Räderwerk lassen sich durchaus lokalisieren. Dazu braucht man
die genauen Zähnezahlen jedes Zahnrades. Interessant wird es, wenn Fehler
nur in bestimmten Kombinationen auftreten.
Deswegen habe ich bei meiner "Uhr" auf ein mechanisches Uhrwerk
verzichtet. Ich könnte keine Zahnräder mit der nötigen Genauigkeit
herstellen.
Zu den drei Lichtschranken: Die sind für den Antrieb nötig. Die mittlere
kann ich auch für den Datenlogger nutzen. Der Schaltpunkt ist der Eintritt
der Schaltfahne in den Lichtstrahl, das ist genau genug.
Aber ehrlich gesagt frage ich mich schon was der TO eigentlich möchte:
Der TE möchte mit seinen Mitteln eine möglichst genaue Uhr bauen und er möchte den Einfluss von Temperatur und Luftdruck auf die Genauigkeit seiner Uhr erfassen.
Was er dazu braucht ist ein System, das ihm erlaubt die Abweichung von der echten Zeit (GPS) in einem angemessenen Zeitraum zu erfassen. Ich bin der Meinung, dass ein Zeitraum im Bereich von 1-3 Stunden erreichbar ist.
Was er dazu braucht ist ein System, das ihm erlaubt die Abweichung von
der echten Zeit (GPS) in einem angemessenen Zeitraum zu erfassen. Ich
bin der Meinung, dass ein Zeitraum im Bereich von 1-3 Stunden erreichbar
ist.
Dann sollte dem TO klar sein dass die Lichtschranke dafür entscheidend ist (u.a. deren Apertur), diese Erkenntnis hat er aber offensichtlich nicht.
Wenn er nur nach 100 Tagen feststellen will ob seine Uhr auf 1 Sekunde genau geht (davon schrieb er in diesem Thread auch mal) reicht eine DCF77 Uhr und visuelle Kontrolle der angezeigten Zeit. Und nur für das Loggen der Umweltdaten braucht es keine GPS Uhrzeit.
Wenn er nur nach 100 Tagen feststellen will ob seine Uhr auf 1 Sekunde
genau geht (davon schrieb er in diesem Thread auch mal) reicht eine
DCF77 Uhr und visuelle Kontrolle der angezeigten Zeit
Er will das natürlich früher wissen, damit er seine mechanischen Werte (v.a. Länge des Pendels) nachregulieren kann. Das geht in 1 h (= 3600000 Millisekunden) mit GPS und einfacher µC-Programmierung auf 1 ppm genau. Der Streit hier geht jetzt darum, wie.
Einfluss von Temperatur und Luftdruck auf die Genauigkeit seiner Uhr
erfassen.
Den größten Einfluss wird die Temperatur haben, weil sich durch
Ausdehnung
die Pendellänge ändert.
Da gibt es Kompensationsmethoden, siehe hier:
https://de.wikipedia.org/wiki/Kompensation_(Uhr)
Das habe wir schon längst durch, seine Uhr hat ein Pendel aus Glaskeramik.
Und ein Messfenster von 3 Stunden ist m.E. auch doof, weil die Umgebung der Uhr längere Phasen hat (vulgo Tag/Nacht bzw. deren z.B. Temperaturänderung).
Oder vertu' ich mich da?
Ich nehme an, wenn man in 3 Stunden feststellt, das die Uhr zu langsam läuft, die Messung aber von 11:00 bis 14:00 "in der Sonne" stattfand, dann reguliert man die Uhr schneller (bzw. das Pendel, eine Uhr isses ja noch nicht) und nachts wenn's kalt wird holt sie wieder derbe auf.
Erst Recht dann, wenn es Winter wird.
Genau das will er ja erfassen, das ist das Kernthema des Threads. Mit welchen Mitteln mache ich das.
Der TE ist Anfäger in Programmierung, also kann man Assembler, aufwendige µC etc vergessen. Micropython oder Arduino-ähnliche Srache ist angesagt. Und er braucht für längere Phasen (wenn es um Bruchteile von ppm geht) auch viel Speicher für die werte.
Einfluss der Apertur der Lichtschranke: Siehe Anhang, aus dem Datenblatt der OPB830 und OPB840 gegenübergestellt damit man es sofort sieht, das gilt so ähnlich natürlich auch für Lichtschranken von anderen Herstellern. Welche von beiden würde man nehmen wenn man mit möglichst kleiner Streuung der Messwerte eine möglichst genaue Zeitmessung des Durchgangs eines Objekts durch die Lichtschranke machen will?
Was mich an dem Datenblatt stört, ist die fehlenede Angabe zur genutzten Wellenlänge von Sender und Empfänger. Fremdlicht könnte ein entscheidnedes Kriterium sein, also sollte man den Empfänger so wählen, dass nur IR länger als 800 nm detektiert wird.
Eine Apertur von 0,3 / 0,5 / 1,0 mm bei Sender und Empfänger herzustellen ist easy, Kappe aus schwarzem POM davor und passendes Loch bohren. Das Ausrichten ist dann Feinarbeit, geht aber.
Was mich an dem Datenblatt stört, ist die fehlenede Angabe zur genutzten
Wellenlänge von Sender und Empfänger. Fremdlicht könnte ein
entscheidnedes Kriterium sein, also sollte man den Empfänger so wählen,
dass nur IR länger als 800 nm detektiert wird.
Eine Apertur von 0,3 / 0,5 / 1,0 mm bei Sender und Empfänger
herzustellen ist easy, Kappe aus schwarzem POM davor und passendes Loch
bohren. Das Ausrichten ist dann Feinarbeit, geht aber.
Was mich an dem Datenblatt stört, ist die fehlenede Angabe zur genutzten
Wellenlänge von Sender und Empfänger.
Die Angabe "Input Diode LED (See OP240 for additional information—for reference only)" ist im Datenblatt ja auch schwer zu finden, und dann muss man noch die Angabe "890 nm" im Datenblatt der OP240 finden...
Und für den "Output Transistor (See OP550 for additional information—for reference only)" findet sich ebenfalls das Datenblatt mit mehr Details.
Eine Apertur von 0,3 / 0,5 / 1,0 mm bei Sender und Empfänger
herzustellen ist easy, Kappe aus schwarzem POM davor und passendes Loch
bohren.
Genauso einfach wie ein 0.08 mm Loch, mit dieser Apertur gibt es ebenfalls Gablelichschranken (vermutlich auch noch kleiner).
Ich bin jetzt raus, der TO hat bereits geschrieben dass seine Lichtschranken gut genug sind (nach wie vor ohne weitere Angaben zum genauen Typ) und er bekommt hier sicher weiter genügend praxistaugliche Vorschläge...
Die schnurgerade Linie gibt es halt in der Natur nicht. Da ist alles
mehr oder weniger dynamisch und pendelt halt um einen Mittelwert. Der
Mittelwert einer vollen Sinusschwingung ist nun mal 0. Insofern wäre ein
sinusförmiger Verlauf ideal.
Was soll da eine Sinusschwingung?
Dann schau Dir einfach mal in der vom TO geposteten Grafik, https://www.mikrocontroller.net/attachment/preview/703777.jpg, den Verlauf von Temperatur (rot), Druck (gelb) und die Gangabweichung (braun) an. Das sind sinusförmige Verläufe und das ist für solche Prozesse auch normal. Auch ein eingeschwungener Regelkreis pendelt um einen Mittelwert. Je gleichmäßiger er das tut um so besser ist die Regelcharakterristik eingegestellt. Eine "schurgerade" Linie wäre zwar wünschenswert aber dann würde der Regelkreis nicht mehr funktionieren, der braucht nämlich die Regelabweichung, um den gewünschten Regelwert einstellen zu können. Das Ganze soll natürlich möglichst gleichmäßig ablaufen und das funktioniert am Besten wenn die Abweichungen einen sinusförmigen zeitlichen Verlauf haben.
Glaskeramik von Schott ist schon auf dem Datenblatt deutlich besser,
deswegen habe ich das genommen.
Welchen Typ Glaskeramik von Schott benutzt Du denn? Da gibt es zum einen mehrere Sorten mit jeweils verschiedenen Klassen bezüglich des Ausdehnungkoeffizienten.
Mit der Briefmarke kann ich nichts anfangen. Warum zitierst du nicht den TO?
Wenn ein Regler sinusförmig schwingt, ist die Verstärkung zu hoch eingestellt.
Eine "schurgerade" Linie wäre zwar wünschenswert aber dann würde der
Regelkreis nicht mehr funktionieren, der braucht nämlich die
Regelabweichung, um den gewünschten Regelwert einstellen zu können.
Um so eine Restregelabweichung zu vermeiden, wurde der Integralanteil erfunden.
Bohren ergibt meist eine rund Öffnung, falls man sich nicht zu dusselig anstellt. Und für die OPB830 bzw. OPB840 steht's im Datenblatt, dass sie rechteckig ist.
Falls es hier jemand interessiert:
Invar und Glaskeramik.
Jetzt gerade gelesen, Du verwendest Robax. Das ist eigentlich bezüglich Ausdehnungskoeffizient das Schlechteste was Schott da anbietet, auch wenn es besser als Invar ist. Das Zeug ist eigentlich für die Glastüren von Kaminöfen gedacht. Da geht es halt darum Spannungsrisse wegen der großen Temperaturdifferenzen zu vermeiden, was mit einem geringen Ausdehnungskoeffizienten am besten gelingt. Die Frage ist halt wie genau der Ausdehnungskoeffizient da eingehalten wird.
Wie von Hinz schon angemerkt wäre Zerodur die bessere Wahl, dürfte aber auch deutlich teurer sein. Ein Maßstab aus Zerodur (ca. 1,5cm breit, 1,5mm dick und 1m lang) kostet dann aber auch um die 3000-4000€. Klar bezüglich des Ausdehnungskoeffizienten ist der natürlich excellent.
Eine andere Frage ist, ob Zerodur sich auf Grund seiner mechanischen
Eigenschaften überhaupt dafür nutzen lässt.
Doch das geht schon. Das ist ausreichend stabil. Wir hatten z.B. auch Stufenendmaße aus Zerodur. Stöße gegen das Material sollte man halt vermeiden, das gibt nämlich unschöne Ausplatzungen etwa so wie bei einer Glasplatte, wenn mit einem harten Gegenstand an die Kante schlägt. Zerodur steckt bis zu einem gewissen Grad Biegelasten weg, aber wenn es zuviel wird bricht es einfach. Zug- bzw. Druckbelastungen, wie sie bei einem Pendel auftreten, sind kein Problem. Man muß sich halt was überlegen wie man das Pendel mechanisch einspannt. Bei uns wurden die Maßstäbe mit einem speziellen Öl auf die Unterlage aufgeklebt.
Auf dem Arduino Nano Board wird der ATmega328 verwendet. Wenn du in das
Datenblatt dieses µC guckst, siehst du, dass der genau drei Ports
besitzt, bezeichnet als "Port B" (8 Bit), "Port C" (7 Bit) und "Port D"
(8 Bit).
Beim Arduino Nano sind einige der Port-Pins fest belegt, z.B. für ext.
Takt (2), serielle Kommunikation (2).
Richtig, macht am Ende, nach Deiner Rechnung, 23 nutzbare Portpins,die alle einzeln ansprechbar sind, d.h. jeder Portpin kann für eine spezielle Aufgabe genutzt werden.
Allerdings gibt es einen Unterschied zwischen dem Dabla des Atmega und dem realen Nanoboard, auf Letzterem sind es genau 2 Portpin weniger, aber es reicht trotzdem locker. Auf dem Nanobrettel sind vom Port B nur 6 Pins (PB0 -PB5), Port C 7Pins (PC0-PC6) und bei Port D 8 Pins herhaus geführt. Und ja einige der Portpins PC6, PD0, PD1, PD4 und PD5 sind für spezielle Augaben vorgesehen und die sollte man natürlich möglichst nicht benutzen. Man kann die natürlich auch andereitig verwenden,, wenn mann die speziellen Anwendungszwecke nicht braucht. Trotz dieser Sonderpins sind immer noch 16 Portpins frei verfügbar und das ist für das was der TO vor hat bei weitem ausreichend.
Mit der Briefmarke kann ich nichts anfangen. Warum zitierst du nicht den
TO?
Dann putz einfach mal die Brille. Falls Du das Putztuch nicht findest hier noch der Link Beitrag "Re: Datenlogger Pendeluhr". Scheint ja ja wirklich schwierig zu sein das selbst hinzubekommen
Wenn ein Regler sinusförmig schwingt, ist die Verstärkung zu hoch
eingestellt.
Eine "schurgerade" Linie wäre zwar wünschenswert aber dann würde der
Regelkreis nicht mehr funktionieren, der braucht nämlich die
Regelabweichung, um den gewünschten Regelwert einstellen zu können.
Um so eine Restregelabweichung zu vermeiden, wurde der Integralanteil
erfunden.
Ein Regelkreis braucht immer eine Regeldifferenz. Der Integralanteil verschiebt die Regeldifferenz nur in Richtung 0, sie ist aber niemals konstant 0, dann wäre es keine Regelung mehr.
Wenn Schott für Robax für den Ausdehnungskoeffizient zwischen 20°C und
700°C eine mögliche Abweichung von ±0,5 x 10−⁶/K angibt, hält sich
Schott doch wohl möglicherweise auch daran, oder?
Natürlich werden die das einhalten. Die Angabe bedeutet halt, daß der reale Ausdehnungskoeffizient +0,5 x 10−⁶/K oder auch -0,5 x 10−⁶/K betragen kann, je nachdem was für ein Charge man erwischt. Der Focus liegt bei Robax halt nicht auf Messtechnik. Für den vorliegenden Fall natürlich nicht relevant.
Gleich diese Wellen einmal mit den Drehzahlen der einzelnen Zahnräder
ab.
Um periodische Fehler durch nicht exakt zentrisch gebohrt Zahnräder
aufzuspüren, ist es vielleicht einfacher, direkt das Spektrum zu
analysieren und nicht irgendwelche Überlagerungen von Wellen in der
Zeitserie versuchen zu interpretieren.
Der TE ist Anfäger in Programmierung, also kann man Assembler,
aufwendige µC etc vergessen. Micropython oder Arduino-ähnliche Srache
ist angesagt. Und er braucht für längere Phasen (wenn es um Bruchteile
von ppm geht) auch viel Speicher für die werte.
Wie wär's, wenn man das aufteilt: Ein Nicht-Anfänger baut und programmiert die Hardware und Bernd macht die Auswertung auf einem normalen PC, pauschal gesagt mit Excel? Damit entfallen alle künstlichen Einschränkungen wie Pin-Anzahl oder Programmiersprache.
Die Hardware müsste alle denkbaren Daten mindestens im Sekundentakt erfassen, aber keine Vorverarbeitung machen. Wegwerfen kann man hinterher immer noch. So sollten später weniger Änderungen nötig werden. Der Mehraufwand für mehr Sensoren ist minimal, wenn man's gleich vorsieht.
Anscheinend gibt es ja nichts passendes fertig. Ja, GPS-Empfänger, RPi oder Schaltnetzteile gibt's fertig, aber für den ganzen Rest wird eine eigene Platine wohl am einfachsten. Zum Beispiel kann man einen fetten STM32 spendieren und mehrere 32-Bit Input Captures nutzen usw.
Man sollte auch einen Analogteil für die Lichtschranke vorsehen. Der LED-Strom muss geregelt werden und Empfänger und Komparator brauchen eine gemeinsame stabile Spannungsversorgung. Dafür wäre ein Schaltbild vom Antrieb nützlich.
Als Taktquelle würde ich einen TCXO mit analoger Temperaturkompensation nehmen: T100F-020.0M. "Natürlich" liefert der ohne Umweg über eine PLL den CPU-Takt. Ja, das gibt nur 50 ns Auflösung, die aber ohne unerwartete Fehlerquellen. Das ist das mindeste, wenn man nach Minuten statt nach Tagen erste Ergebnisse möchte. Der GPS-PPS ist nur für lange Zeiten besser, 30 ns RMS Jitter sind leicht zu schlagen. Außerdem fällt der manchmal ganz aus.
Ein OCXO wäre natürlich besser, der braucht aber über 1 Watt und das Ganze muss aus dem Akku laufen können. Es gibt doch einen Akku für den Antrieb? Bernd?
das geht aber völlig am Thema vorbei.
Um so ein Pendel zu optimieren, bedarf es einer Langzeitbeobachtung
über Wochen und Monate.
Ein Monat sind 2,6 Millionen Sekunden, da muss nur die Referenzuhr
stimmen. Eine Wertaufnahme pro Stunde wäre völlig ausreichend.
Warum ist das so? Die Umweltbedingungen ändern sich halt langsam.
Am einfachsten? sind Temperatureinflüsse zu kompensieren.
Dummerweise ist die Luftdichte (nicht nur der Luftdruck) eine
entscheidende Störgröße.
Diese Luftdichte ist schwer zu erfassen, weil sie sich aus vielen
Faktoren zusammensetzt. Größere Luftdichte bremst das Pendel, andere-
seits bekommt das Pendel mehr Auftrieb und wird leichter.
Messen, interpretieren, Konstruktion ändern, von Vorn beginnen.
Darum geht es.
keiner versteht mich :( Die entscheidende Frage war doch: "Könnte jemand ein so Gerät bauen?"
Das muss möglichst einfach werden und trotzdem alle interessanten Daten liefern. Und die fallen eben zweimal pro Pendelperiode an. Wenn man bei der Gelegenheit Luftdruck usw. mit aufzeichnet, wird das Programm einfacher. Wenn man versucht, weniger oft aufzuzeichnen, muss man sich eine Art Kompression ausdenken (schlecht) und später feststellen, dass man anders komprimieren muss (ganz schlecht). Je einfacher, umso funktioniert es!
Es ist einfacher, alle Sekunde zu messen, die Daten auf den PC oder Raspi zu schicken und dann hinterher auszuwerten als irgendeine Auswertung auf dem µC zu machen. Ausserdem kann man damit die Monotonität der Daten besser beurteilen.
Angenommen alle 3 Minuten wird ein Datensatz geschrieben, dann sind dies 31gb im Monat. Die Annahme bezieht sich auf zwei Lichtschranken, 24bit Datensatz und zwei Durchgänge je Sekunde, sowie weiteren 3minuten Datensätzen. Mit zusätzlichem i2c EEPROM und einer zweiten SD Karte sollte die Daten einfach alle 10tage abgeholt werden. Dies sehe ich schon als einfach machbar, wobei ich wirklich einen ocxo empfehle, kostet nicht viel,
Und nein, ich würde keine Akku Lösung verwenden.
keiner versteht mich :( Die entscheidende Frage war doch: "Könnte jemand
ein so Gerät bauen?"
Klar geht das! Hat man im ESP32 erst mal das richtige Grundgerüst für OTA per WiFi und Webseite, kann man die Schaltung nach Absprache mit dem OP aufbauen und auf dem Tisch soweit testen, dass es grundsätzlich passt. Dann sendet man das ganze, oder besser eine Kopie des ganzen, an den OP und der fängt an zu Messen. Bedarf es weiterer Anpassungen, kann man das im Code korrigieren, das OTA Image backen und dem Op bescheid geben, wenn er auf Update drücken soll. Ob dabei Messreihen verloren gehen, wird am Anfang sicher egal sein, da Entwicklungsphase. Später sollte der Code so aktualisiert werden, dass da nichts verloren geht, oder man baut einen Download mit ein.
Es gibt eine ganze Reihe Varianten, die es erlauben ESP32 mit OTA zu aktualisieren.
Das Thema Datenlogger hat mich jetzt fasziniert.
Ich werde erstmal selbst versuchen, was funktionsfähiges hinzustellen.
Mehr als Scheitern kann ich nicht.
Nun warte ich auf DPD, oder so.
Für die Zwischenzeit gibt es genug Baustellen. Eigentlich sammel
ich ja alte Stoppuhren. Vor ein paar Wochen konnte ich eine
exotische Auburndale finden.
Die Uhr hat mir Schmerzen bereitet beim Überholen. Jede Schraube war so
fest, dass ich immer Angst hatte, was zuerst bricht. (Schraubenkopf oder
Schraubendreher).
Die Hardware müsste alle denkbaren Daten mindestens im Sekundentakt
erfassen, aber keine Vorverarbeitung machen.
Warum willst du dem System einen künstlichen zweiten Takt aufdrücken. Die Zeitquantisierung erfolgt doch bereits durch das Pendel.
Alles andere ist langsam dagegen.
Das Thema Datenlogger hat mich jetzt fasziniert.
Ich werde erstmal selbst versuchen, was funktionsfähiges hinzustellen.
...
Endlich
Für die Zwischenzeit gibt es genug Baustellen. Eigentlich sammel
ich ja alte Stoppuhren. Vor ein paar Wochen konnte ich eine
exotische Auburndale finden.
https://uhrforum.de/threads/seltene-hemmungen.622990/
Runterscrollen, kommt irgendwann.
Ganz ohne Elektronik.
...
Nicht nur das, ohne Computer, ohne Software, ohne KI, ohne komplizierte Maschinen. Echte Kunstwerke!
Angenommen alle 3 Minuten wird ein Datensatz geschrieben, dann sind dies
31gb im Monat.
Bitte rechne das vor.
Datensatz:
Was ich gerechnet habe, aber irgendwie bin ich von Mb auf Gb gekommen,
2 Lichtschranken * (24bit) timing * 2 durchgaenge * 180 Sekunde = 2160 byte.
Dazu kommt noch ein 32bit Wert fuer die Unix Time, ein 16bit incremental counter fuer den Datensatz,
ein length byte und CRC, egal ob 8bit oder 16bit, rechne mal mit 8bit, weil is besser passt.
Dies macht 8 bytes, + angenommen Feuchtigkeitssensor mit Temperatur, RTC mit Temperatur,
Temperatursensor, Drucksensor mit Temperatur, macht 6x 2byte = 12byte, angenommene 3x 32bit timing oder flag register
ergeben dann insgesamt 2193 bytes alle 3 Minuten.
2193*20 (Stunden) * 24 (Tag) * 31 (Monat) = 32140800 bytes oder aufgerundet 31 Mb. je Monat.
Wenn man jetzt vor dem SD_KARTEN Schreiben eine Led blinken laesst, und
beim SD-Karten Schreiben die Led an bleibt, kann man die SD Karte mit einer anderen einfach nach dem Schreiben wechsel Es wurde damit gerechnet, entweder einen Sensor anzuschliessen und Eintritt sowie Austrittsmoment des Pendels zu erfassen, oder eben zwei IR Sensoren welche nur den Eintrittswert erfassen. Je Page passen 40 Sekunden, sowie 24byte andere Sensordaten rein. Demnach muesste man in einem Interwall von 80 Sekunden jeweils zwei Pages schreiben, waehrend die Dritte befuellt wird. Ein Austausch der SD Karten ist in dieser Zeit leicht machbar. Anstelle der 3 Pages koennte man auch nur einen buffer nehmen, z.B. 48byte fuer 4 Sekunden, und anstelle dessen nur 2 Pages verwenden, sowie z.B. die Sensordaten jede Minute messen und abspeichern. Mfg Chris
Die Hardware müsste alle denkbaren Daten mindestens im Sekundentakt
erfassen, aber keine Vorverarbeitung machen.
Warum willst du dem System einen künstlichen zweiten Takt aufdrücken.
Die Zeitquantisierung erfolgt doch bereits durch das Pendel.
Alles andere ist langsam dagegen.
Das will ich garnicht, deswegen "mindestens". Man könnte sogar sagen, dass es garkeinen solchen Takt gibt, nur Ereignisse (zweimal Lichtschranke, GPS-PPS und Erschütterungen). Aufgezeichnet wird jeweils der Zählerstand des Timers. Die Unix Time braucht man genau genommen nicht, man bekommt sie auch nur zusammen mit dem PPS.
Nachdem alle benötigten Teile eingetroffen sind, habe ich
alles auf einem Brett fixiert.
(Der GPS-Empfänger findet recht schnell Empfang).
Dann dachte ich mir: Fragst du mal die KI.
Programm: 1800 Impulse zählen (Lichtschranke Pendel über Optokoppler)
Dann Zeitstempel auf SD-Karte schreiben.
Lichtschranke war da noch nicht in Betrieb. Das war der Test
auf Fehler im Programm.
Anscheinend kann der Arduino mit "failedChecksum" nichts anfangen?
Einen mechanischen Fehler in meinem analogen Anzeigeinstrument konnte ich
aber heute finden: Der Sekundenzeiger sitzt nicht fest genug.
Die Magnetspule schaltet recht knackig, das Futter (Kunststoff) des Zeigers
sitzt nicht fest genug. Nach 10 Stunden (36,000) Klicks, verschiebt er sich
um ca. 1 Sekunde +. (1,5 mm).
Abhilfe: Neues Futter aus Messing drehen und in den
Sekundenzeiger einbauen.
Die lastCommitTime hängt auf den Ersten Blick davon ab, wann der letzte gültige NMEA-Datensatz vollständig vom UART gelesen wurde, und nachdem die Datensätze keine fixe Länge haben, ist das ein sehr "wackeliger" Wert.
Norbert, die Hoffnung stirbt zuletzt.
Natürlich habe ich mir als Neueinsteiger mal Grundlagen angesehen
und eine Led blinken lassen.
Das soll aber ein Werkzeug werden. So wie eine Wasserpumpenzange.
Da muss ich den Stahl auch nicht selbst herstellen und die Teile
aus dem Vollen fräsen.
Deswegen frage ich die KI.(Dieses Fragen ist ja noch verbesserungswürdig).
Bernd, das ging selbstverständlich nicht gegen dich.
Vielmehr darum, dass ich – wie alle andere Neulinge auch – beim Erstflug zur PPL Ausbildung natürlich erst einmal mit einer Extra300 sowie einer Pitts Kunstflug-Manöver geflogen bin. Was man halt so macht wenn man gerade anfängt.
Ich oute mich gerne als Fan von Micropython. Python nutze ich sowieso, ich bin zu alt (bzw. zu faul) um noch eine Programmiersprache zu lernen (Algol und Fortran etc habe ich schon wieder vergessen) also Micropython. Damit geht eine Menge auch auf µC-Ebene.
Anmerkung. time.ticks:diff() ist motwendig, da der Timer überlaufen kann. time.ticks_diff() berücksichtigt das und errechnet die richtige Differenz auch bei einem Überlauf.
Nachdem alle benötigten Teile eingetroffen sind, habe ich
alles auf einem Brett fixiert.
(Der GPS-Empfänger findet recht schnell Empfang).
Dann dachte ich mir: Fragst du mal die KI.
Programm: 1800 Impulse zählen (Lichtschranke Pendel über Optokoppler)
Dann Zeitstempel auf SD-Karte schreiben.
Läuft leider nicht. (Siehe Bild).
Grüße Bernd
Auf deinem gezeigten Bild steht sinngemäß das die Kompilierung fehlerhaft ist. Die Lösung könnte in der Beseitigung des Fehlers liegen. Ich habe selber schon einige Programme mit der Hilfe der KI programmiert und habe festgestellt das es eine Ochsentour sein kann bis es korrekt und zuverlässig funktioniert.
Also fleißig weiter machen und immer alle Versionen inklusive der Fehlermeldungen sichern.
Ich habe heute mal eine andere Variante von der KI angefordert.
Die lässt sich ohne Fehlermeldung aufspielen.
Blöd ist aber, dass keine Daten auf die SD-Karte geschrieben werden.
Das ist der Unterschied zwischen ›kann fehlerarm übersetzt werden‹
und
›macht was es soll‹
Da haben's die Gondolieri in Venedig einfacher. Die haben längere Stangen zum herumstochern.
Ich habe heute mal eine andere Variante von der KI angefordert.
Die lässt sich ohne Fehlermeldung aufspielen.
Blöd ist aber, dass keine Daten auf die SD-Karte geschrieben werden.
Die Überschriften (Zeit, Temperatur usw.) werden aber angezeigt.
Eventuell ein Verdrahtungsfehler?
dann sage das doch der ki, ist das sooo schwierig?
so fämngt man an:
hast du das pendel angeschlossen? wenn ja, dann klemme es ab und ersetze es durch einen schalter den du per hand betätigst
im Deinem Antwort Text schreibst Du Deine Bemerkungen wie gewohnt.
den Code-Block beginnst Du mit (code) in einer Zeile, dann kommt Dein Prograemm in einer neuen Zeile per copy/paste und dann (/code) in einer neuen Zeile zum Abschkluss. Statt der runden Klammern musst Du eckige Klammern benutzen, sonst klappt das hier mit meiner Anleitung nicht.
Danach kannst Du nochmal weitere Bemerkungen machen. Mit der Vorschau kannst Du das voarab kontrollieren.
// Pins definieren
const int GPS_PPS_PIN = 2; // PPS-Signal vom GPS für Sekundentakt
const int LICHTSCHRANKE_PIN = 3; // Signal von der Lichtschranke
const int SD_CS_PIN = 10; // Chip Select für SD-Kartenleser
// Speicher-Intervall für die Lichtschranke (jeder 1800. Impuls)
const unsigned long SPEICHER_INTERVALL_IMPULSE = 1800;
// Volatile Variablen für die Interrupts
volatile unsigned long ppsMicrosRef = 0; // Systemzeit der letzten GPS-Sekunde
volatile unsigned long eventMicros = 0; // Systemzeit des 1800. Impulses
volatile unsigned long eventPpsRef = 0; // PPS-Referenzwert beim 1800. Impuls
volatile bool eventTriggered = false;
// Globale Zähler und Zwischenspeicher
unsigned long gesamtImpulsZaehler = 0;
unsigned long logImpulsNummer = 0;
// Temporäre Kopien der Zeit für das sichere Loggen im Loop
uint8_t logStunde, logMinute, logSekunde, logTag, logMonat;
uint16_t logJahr;
// Interrupt-Service-Routine für den präzisen GPS-Sekundentakt (Pulse Per Second)
void ppsISR() {
ppsMicrosRef = micros();
}
// Interrupt-Service-Routine für die Lichtschranke
void lichtschrankeISR() {
gesamtImpulsZaehler++;
// Nur beim exakt 1800. Impuls frieren wir die Zeiten ein
if (gesamtImpulsZaehler % SPEICHER_INTERVALL_IMPULSE == 0) {
eventMicros = micros();
eventPpsRef = ppsMicrosRef;
1
// GPS-Zeitstempel für diesen Moment sichern
2
logStunde = gpsStunde;
3
logMinute = gpsMinute;
4
logSekunde = gpsSekunde;
5
logTag = gpsTag;
6
logMonat = gpsMonat;
7
logJahr = gpsJahr;
8
9
logImpulsNummer = gesamtImpulsZaehler;
10
eventTriggered = true;
}
}
// Hilfsfunktion zur Formatierung des CSV-Zeitstempels (DD.MM.YYYY;HH:MM:SS)
void schreibeZeitstempel(File &file, uint8_t tag, uint8_t monat, uint16_t jahr, uint8_t stunde, uint8_t minute, uint8_t sekunde) {
if (tag < 10) file.print("0"); file.print(tag); file.print(".");
if (monat < 10) file.print("0"); file.print(monat); file.print(".");
file.print(jahr);
file.print(";");
if (stunde < 10) file.print("0"); file.print(stunde); file.print(":");
if (minute < 10) file.print("0"); file.print(minute); file.print(":");
if (sekunde < 10) file.print("0"); file.print(sekunde);
}
void setup() {
Serial.begin(115200);
Serial1.begin(9600); // Echte Hardware-Serielle für GPS auf Uno R4 (Pins 0/1)
Ich habe heute mal eine andere Variante von der KI angefordert.
Die lässt sich ohne Fehlermeldung aufspielen.
Blöd ist aber, dass keine Daten auf die SD-Karte geschrieben werden.
Mir fehlt jegliches Verständnis für die Leute, die hier meinen, ihre Aufgaben mit KI lösen zu können.
Du hast Arduino, da gibt es zu jeder Funktion Beispiele. Es ist zeitaufwendig, aber aus meiner Sicht ohne Alternative: Stück für Stück Einzelfunktionen programmieren und austesten, die man dann später zum Gesamtwerk zusammefügt.
Ich habe heute mal eine andere Variante von der KI angefordert.
Die lässt sich ohne Fehlermeldung aufspielen.
Blöd ist aber, dass keine Daten auf die SD-Karte geschrieben werden.
Mir fehlt jegliches Verständnis für die Leute, die hier meinen, ihre
Aufgaben mit KI lösen zu können.
Das hilft dem TO aber nicht.
Du hast Arduino, da gibt es zu jeder Funktion Beispiele. Es ist
zeitaufwendig, aber aus meiner Sicht ohne Alternative: Stück für Stück
Einzelfunktionen programmieren und austesten, die man dann später zum
Gesamtwerk zusammefügt.
Das habe ich mehrfach erfolglos versucht dem TO beizubringen.
Bernd F. schrieb:
Kleine Anleitung für Volldeppen wäre da angebracht.
... Er sollte erst einmal die guten Ratschläge befolgen...
Der TO kommt mir vor als wenn ein Stellmacher im Kopfe einen Formel 1 Rennwagen konstruieren will...
Es läuft schon fast. Aber der Zeitstempel stimmt so nicht.
Zwischen jeweils 1800 Impulsen vergeht ca. eine halbe Stunde.
Zwischen den beiden letzten Zeilen waren mehr als 2 Stunden Abstand.
Dann "prellt" deine Lichtschranke, und löst "lichtschrankeISR" pro
Durchgang mehrfach aus.
Quickfix:
void lichtschrankeISR() {
unsigned long jetzt = micros();
static unsigned long letzterPuls = 0;
if (jetzt - letzterPuls < 10000) return; // < Mindestabstand, hier 10
ms, ggfs. vergrößern.
letzterPuls = jetzt;
gesamtImpulsZaehler++;
....
Die Lichtschranke geht auf einen Optokoppler (C 817), dann zum Eingang.
Die Led am Koppler ist dauerhaft an und wird beim Pendeldurchgang kurz dunkel.
Eine Testled am Ausgang leuchtet bei jedem Durchgang kurz auf.
Das die Zeit nicht richtig angezeigt wird, müsste eine andere Ursache haben.
Wenn 1800 Impulse in kurzer Zeit gezählt werden, müssten mehr Datensätze nach
einigen Stunden auf der Karte sein.
nun, was kann man aus diesem thread lernen? die uhrmacher vor hunderten Jahren hatten einfach mehr drauf an wissen und fähigkeiten, ohne ki, ond controller, ohne software, ohne cad, ohne strom, ohne internet, ohne foren, etc pp
Ich habe den direkten Weg von der Lichtschranke (Eingang der Schaltung
für die Magnetspulen) genommen, vorher war es ein Ausgang, der auch die Magnet-
spule des Anzeigewerkes versorgt.
Rein optisch sieht das Aufblitzen der Led am Optokoppler immer noch
gleich aus, es wurde aber nur ein Datensatz in 30 Minuten auf die Karte
geschrieben. So soll das sein. (Länger habe ich noch nicht probiert).
Ich schau mal in ein paar Stunden, was da auf der Karte steht.
Der Kartenleser im PC macht mir etwas Probleme (Wackelkontakt ?)
Da muss ich mal nachsehen.
nun, was kann man aus diesem thread lernen? die uhrmacher vor
hunderten Jahren hatten einfach mehr drauf an wissen und fähigkeiten,
ohne ki, ond controller, ohne software, ohne cad, ohne strom, ohne
internet, ohne foren, etc pp
So einfach kann man das nicht sagen.
Nur wenige Uhrmacher waren auf der Jagd nach der letzten Sekunde.
Dazu mussten sie endlose Datenerfassung (auf Papier) machen.
Die Interpretation dieser Werte und dann eventuelle Fehlerabhilfe
am Schwingsystem zu finden, hat nichts mit dem Datenlogger zu tun.
nun, was kann man aus diesem thread lernen? die uhrmacher vor
hunderten Jahren hatten einfach mehr drauf an wissen und fähigkeiten,
ohne ki, ond controller, ohne software, ohne cad, ohne strom, ohne
internet, ohne foren, etc pp
So einfach kann man das nicht sagen.
Nur wenige Uhrmacher waren auf der Jagd nach der letzten Sekunde.
Dazu mussten sie endlose Datenerfassung (auf Papier) machen.
Die Interpretation dieser Werte und dann eventuelle Fehlerabhilfe
am Schwingsystem zu finden, hat nichts mit dem Datenlogger zu tun.
Er erleichtert diese Datenerfassung nur ungemein.
Grüße Bernd
Auch du kommst ans Ziel. 😎 Ich verfolge deine Aktivitäten auch in den anderen Foren.
Heute Nacht lief das Teil durch.
Das ist natürlich ein viel zu kurzer Zeitraum, um an eine
Analyse zu denken.
Die Mikrosekunden sind Unsinn. Da bräuchte ich nur 3 Stellen.
Aber 1800 Impulse in 30 Minuten kommt schon hin.
Die Temperatur ist in meinem "Gewächshaus" nachts recht stark
gesunken. Das Kompensationselement des Pendel ist noch zu
wirkungsvoll. Wie geplant wird das kalte Pendel länger und
damit langsamer.
Die Mikrosekunden sind Unsinn. Da bräuchte ich nur 3 Stellen.
Dir ist schon klar dass sehr wahrscheinlich der 1PPS Interrupt nicht richtig funktioniert? (z.B. Problem mit der Verbindung zum GPS Empfänger, eine LED am 1PPS Pin hilft bei der Fehlersuche)
Heute Nacht lief das Teil durch.
Das ist natürlich ein viel zu kurzer Zeitraum, um an eine
Analyse zu denken.
Die Mikrosekunden sind Unsinn. Da bräuchte ich nur 3 Stellen.
Aber 1800 Impulse in 30 Minuten kommt schon hin.
Die Temperatur ist in meinem "Gewächshaus" nachts recht stark
gesunken. Das Kompensationselement des Pendel ist noch zu
wirkungsvoll. Wie geplant wird das kalte Pendel länger und
damit langsamer.
Grüße Bernd
Warum packst du Datum und Zeit nicht als Summe in eine Spalte?
Und warum importierst du die Daten für Temperatur, Luftdruck und Luftfeuchte nicht mit dem passenden Dezimaltrenzeichen.
So machst du es dir bei irgendwelchen Auswertungen unnötig schwer.
Warum packst du Datum und Zeit nicht als Summe in eine Spalte?
Und warum importierst du die Daten für Temperatur, Luftdruck und
Luftfeuchte nicht mit dem passenden Dezimaltrenzeichen.
So machst du es dir bei irgendwelchen Auswertungen unnötig schwer.
Weil es eben Schmarrn ist wie der TO vor geht. Er soll doch erst einmal hin bekommen Impulsnummer und die Zeit darzustellen. Hat damit genug zu tun. Den anderen Dreck erst einmal weglassen.
Es ist doch offensichtlich: wenn "sketch_sep10a.ino" von weiter oben noch aktuell ist dann ändert sich "ppsMicrosRef" nur gelegentlich und "eventMicros" ist um ca 1800 Sekunden größer als beim letzten mal. Und alle ca. 4294 Sekunden gibt es einen Überlauf (32-Bit Wert).
Daher auch mein Hinweis weiter oben auf den 1PPS Interrupt.
Wobei zZ. eine variable Abweichung von 1/3 bis 2/3 Sekunden pro Stunde
im Schaukelsystem ist.
Da korrigiere ich mich doch gleich mal selbst nach oben.
Es sind natürlich 2/3 bis 4/3 Sekunden pro Stunde. (Die eigentliche Messung war ja immer nur 1/2 Stunde lang)
Wobei zZ. eine variable Abweichung von 1/3 bis 2/3 Sekunden pro Stunde
im Schaukelsystem ist.
Da korrigiere ich mich doch gleich mal selbst nach oben.
Es sind natürlich 2/3 bis 4/3 Sekunden pro Stunde. (Die eigentliche
Messung war ja immer nur 1/2 Stunde lang)
Das Problem war wohl das Steckbrett, da gibt es Kontakte, die
durch das Einstecken von Mosfets etwas geweitet sind.
Steckplatz gewechselt und schon geht das.
War ein guter Tip, da mal mit einer Led zu schauen, ob am Board
auch ein Signal ankommt.
Der Kartenleser im PC geht aber gar nicht mehr. Mein freundlicher
Nachbar hatte aber noch einen externen mit USB rumliegen.
Dir ist schon klar dass sehr wahrscheinlich der 1PPS Interrupt nicht
richtig funktioniert? (z.B. Problem mit der Verbindung zum GPS
Empfänger, eine LED am 1PPS Pin hilft bei der Fehlersuche)
War ein guter Tip, da mal mit einer Led zu schauen, ob am Board
auch ein Signal ankommt.
Die LED am Sekundentakt zeigt diesen an, aber nicht, ob die Sekunde wirklich präzise ist. GPS-Empfänger geben ein Signal aus, wenn sie selbst auf mehrere SAT gelockt sind und den Takt als stabil ansehen. Ich weiß nicht, ob Dieter nicht eher diese Info meinte, bei Deiner Anforderung an die Genauigkeit ist die relevant.
Ich kenne mich mit der Arduino-Programmierung nicht aus und kann den ino-File nicht richtig deuten. Ein Problem bei den GPS-Platinen ist, dass die Ausgabe auf die serielle Schnittstelle nicht synchron zum 1PPS-Signal ist, siehe die anliegenden Hardcopies. Bei allen 3 Dateien sind die Einstellungen identisch. M.W. ist nur das 1PPS-Signal auch wirklich monoton und zeigt den genauen Beginn der Sekunde an.
Ich kenne mich mit der Arduino-Programmierung nicht aus und kann den
ino-File nicht richtig deuten. Ein Problem bei den GPS-Platinen ist,
dass die Ausgabe auf die serielle Schnittstelle nicht synchron zum
1PPS-Signal ist, siehe die anliegenden Hardcopies. Bei allen 3 Dateien
sind die Einstellungen identisch. M.W. ist nur das 1PPS-Signal auch
wirklich monoton und zeigt den genauen Beginn der Sekunde an.
Vergiss irgendeine Genauigkeit. Hier werden Signale mittels Interrupt gemess^H^H^Hgeschätzt. Wohl wissend, dass dieses Arduino bereits schon eine ISR (für millis()) nutzt.
Da der Quarz wohl eine etwas schlechtere Genauigkeit als 0ppm bzw. 0ppb hat, ergibt sich zu GPS zwangsläufig eine Schwebung. Da ist es nur eine Frage der Zeit, wann periodisch der Interrupt beim Eintreffen des PPS bereits gesperrt ist und sich alles etwas verzögert.
Manchmal geht's gut, manchmal nicht. Genau der richtige Ansatz um eine Uhr präzise zu vermessen. ;-)
Vergiss irgendeine Genauigkeit. Hier werden Signale mittels Interrupt
gemess^H^H^Hgeschätzt. Wohl wissend, dass dieses Arduino bereits schon
eine ISR (für millis()) nutzt.
Dass "sketch_sep10a.ino" gar keine millis() sondern micros() verwendet scheint Dir entgangen zu sein. Aber hauptsache irgendwas geschrieben...
Die gemessenen Daten sagen bisher nichts über die Qualität der Messung aus. Dafür braucht man eine Messung jeder Pendelschwingung über einen längeren Zeitraum.
Der entsprechend angepasste Source Code ist im Anhang, er basiert auf "sketch_sep10a.ino" von weiter oben. Sollte "sketch_sep10a.ino" nicht mehr aktuell sein muss man den Code anpassen.
Der Code im Anhang misst jede Pendelschwingung und gibt auch noch die Eventzeit in µs aus (nicht nur die Differenz zum 1PPS Impuls).
Es reicht wenn das für etwa eine Stunde läuft, dann das Ergebnis ("datenlog.csv") hier hochladen.
Da ist es nur eine Frage der Zeit, wann periodisch der Interrupt beim
Eintreffen des PPS bereits gesperrt ist und sich alles etwas verzögert.
Bis auf einen verschenken Faktor 100...1000 in der Genauigkeit, ist das doch egal ;-)
Wenn man die Genauigkeit des 1PPS-Pulses nutzen wollte, müsste man besser mit der Capture Funktion eines der Timer arbeiten, aber nicht mit dem latenzbehafteten Interrupt.
Ein Problem bei den GPS-Platinen ist, dass die Ausgabe auf die serielle
Schnittstelle nicht synchron zum 1PPS-Signal ist
Ein serielles Datentelegramm mit Symbolzeiten von 1 oder 2 Millisekunden kann prinzipbedingt nicht synchron zur Flanke eines auf besser als 100 Nanosekunden genauen Pulses sein. Für präzises Timing hat das serielle Datentelegramm keine Bedeutung und dient nur der Orientierung.
@Bernd F.
Die gemessenen Daten sagen bisher nichts über die Qualität der Messung
aus. Dafür braucht man eine Messung jeder Pendelschwingung über einen
längeren Zeitraum.
Der TO ist da sehr lernresistent und stur.
Der entsprechend angepasste Source Code ist im Anhang, er basiert auf
"sketch_sep10a.ino" von weiter oben. Sollte "sketch_sep10a.ino" nicht
mehr aktuell sein muss man den Code anpassen.
Der Code im Anhang misst jede Pendelschwingung und gibt auch noch die
Eventzeit in µs aus (nicht nur die Differenz zum 1PPS Impuls).
Es reicht wenn das für etwa eine Stunde läuft, dann das Ergebnis
("datenlog.csv") hier hochladen.
Ich habe mir gerade einmal die mechanische Befestigung der Pendellinse an dem Glasstab angesehen, ob sich dort nichts bewegt? Es geht ja eine präzise Messung.
Bei der zweiten Messung an dem Pendel mit elektromagnetischem Antrieb kann man bei der Schwingungsdauer eine leichte Wellenbewegung erkennen. Es hat sich herausgestellt dass dafür der Lüfter des etwas älteren Laptops verantwortlich ist, der für die Aufzeichnung der Daten verwendet wurde. Der Laptop war bei der Messung mehrere Meter vom Pendel entfernt und die Lüfteröffnung hat vom Pendel weggezeigt. Der Lüfter schaltet etwas alle 10 Minuten für ein paar Minuten ein, der Luftstrom ist so gering dass man ihn nur bemerkt wenn man die Hand direkt an die Lüfteröffnung hält.
Zur Verifikation dass tatsächlich der Lüfter für die Wellen verantwortlich ist wurde die Lüfteröffnung zusätzlich abgedämmt. Das Bild im Anhang zeigt das Ergebnis, die Parameter der Messung entsprechen denen der ersten Messung am Pendel mit elektromagnetischem Antrieb, die Skalierung der Y-Achse ist aber eine andere.
Seltsam sind die Fehler bei Temperatur. Wenn ich z.B. 23.Mai durch 23,5
ersetze oder z.B. 22.Nov durch 22,11 wäre es plausibel.
Den BME280 habe ich an 3,3 V angeschlossen, sollte ich mal 5 V probieren?
Die Spalten H und J habe ich mal angefügt. (Von Hand berechnet).
H wäre der Wert, der für die Pendeloptimierung wichtig wäre.
Hier wird die Zeit des vorherigen Intervall vom aktuellen Intervall
subtrahiert.
Das sollte später dauerhaft nahe Null bleiben.
Bei J fliesst die bisher noch nicht vorgenommene genaue Regulierung
der Länge mit ein. ( Um da was zu erreichen, müsste estmal H stimmen).
Den BME280 habe ich an 3,3 V angeschlossen, sollte ich mal 5 V
probieren?
Der BME280 will nur 3,3 V (max. 3,6 V). Es gibt zwar Boards für 5 V, da ist aber ein Spannungswandler drauf, der das Board natürlich etwas heizt, also zu hohe Temperaturen ausweist.
Seltsam sind die Fehler bei Temperatur. Wenn ich z.B. 23.Mai durch 23,5
ersetze oder z.B. 22.Nov durch 22,11 wäre es plausibel.
Wie hast du deine CSV-Datei erzeugt und wie die XLSX-Datei. Offensichtlich hat die Erkennung vom Dezimaltrenzeichen nicht funktioniert.
Poste doch einfach einmal direkt die Datei von der SD-Karte.
Und du denkst, nur weil millis() nicht benutzt werden, läuft die ISR
nicht trotzdem im Hintergrund.
Wieder so ein Schwätzer. Der Interrupt für millis() kann z.B. so aussehen (beim Arduino):
1
ISR(TIMER0_OVF_vect)
2
{
3
// copy these to local variables so they can be stored in registers
4
// (volatile variables must be read from memory on every access)
5
unsigned long m = timer0_millis;
6
unsigned char f = timer0_fract;
7
8
m += MILLIS_INC;
9
f += FRACT_INC;
10
if (f >= FRACT_MAX) {
11
f -= FRACT_MAX;
12
m += 1;
13
}
14
15
timer0_fract = f;
16
timer0_millis = m;
17
timer0_overflow_count++;
18
}
Dieser Code braucht kaum Zeit, das reicht damit die Genauigkeit der Zeitmessung in einer Grössenordnung liegt die erstmal ausreichen sollte (besser als 0.1 ms). Mehr weiss man wenn der TO die Daten für eine Bewertung der Messqualität liefert.
So schlecht sieht das nicht aus, zumindest ist ein klarer Trend bei der Abweichung vom 1PPS Impuls zu erkennen. Dennoch wären die weiter oben erwähnten kontinuierlichen Messdaten hilfreich um die Qualität der Messung zu beurteilen.
Und dass, während diese ISR läuft, die PPS-ISR gar nicht bearbeitet
wird?
Das ist das Prinzip der Interruptbearbeitung. Je nach Priorität muss der restliche Programmablauf warten.
Solange niemand das Interrupt-Flag löscht, werden die Interrupts der Reihe nach abgearbeitet und dann geht es im Hauptprogramm weiter.
Die Zeit zwischen Interrupt und Start der Bearbeitung hat man als Latenz. Schwankungen der Latenz hat man als Rauschen in den Zeitmessdaten, die Latenz selber als Fehler beim Stand der Uhr.
Rainer, ich denke das alles war uns bereits mehr als klar. ;-)
Dir scheint aber die Größenordnung der dadurch bei der Zeitmessung verursachten Fehler nicht klar zu sein. Der Gang der Uhr liegt laut den Daten im Bereich von 0,2 ... 0,8 s/d, d.h. in einer Größenordnung, die weit entfernt von einer möglichen Verzögerung durch den millis()-Interrupt ist. Sonst würde man Spikes oder andere merkwürdige Effekte in den Daten sehen.
Dir scheint aber die Größenordnung der dadurch bei der Zeitmessung
verursachten Fehler nicht klar zu sein. Der Gang der Uhr liegt laut den
Daten im Bereich von 0,2 ... 0,8 s/d, d.h. in einer Größenordnung, die
weit entfernt von einer möglichen Verzögerung durch den
millis()-Interrupt ist.
Ja klar, jetzt noch. Die Uhr soll irgendwann mal max. 1 Sekunde in 100 Tagen falsch gehen. Schreiben man dann jedes Mal, wenn eine bessere Genauigkeit (und Wiederholbarkeit) benötigt wird, das Programm neu?
Die momentane Genauigkeit des Pendels könnte man aber auch mit einem Abreißkalender bestimmen… ;-)
Gibt es ein leicht zu bedienendes Programm, um aus den Daten
so eine Grafik zu erstellen?
GNUplot. Vielleicht nicht leicht, aber da kann man helfen…
Und man muss es auch nur einmal machen, dann kann man's beliebig oft mit dieser Konfiguration aufrufen. Entweder Plot auf den Bildschirm oder in eine PNG-Datei. Oder Beides.
Ja klar, jetzt noch. Die Uhr soll irgendwann mal max. 1 Sekunde in 100
Tagen falsch gehen.
Für eine derartige Genauigkeit der Messung des Gangs, ist die Funktion micros() - Interrupt hin oder her - sowieso schlecht geeignet, insbesondere wenn man eine kurze Messzeit anstrebt, um die Pendellänge zu justieren. Da möchte man schon gerne eine der Genauigkeit des 1PPS-Signals angemessene Auflösung für die Zeitmessung verwenden und nicht mehr als einen Faktor 10 verschenken.
Für eine derartige Genauigkeit der Messung des Gangs, ist die Funktion
micros() - Interrupt hin oder her - sowieso schlecht geeignet,
Nicht weniger versuche ich seit Äonen zu vermitteln. Aber ganz offensichtlich völlig erfolglos. Inklusive auf mehr oder weniger geschickten Ablenkungen auf Nebenkriegsschauplätze einzugehen.
danke.
Um verwertbare Daten zu bekommen, werde ich das Pendel mal
provisorisch Einhausen.
Im Moment hängt es ja völlig frei, direkt neben einer Tür.
Da stört ja jeder Luftzug.
Die Umweltsensoren kommen in den Kasten.
Der Zacken in der Zeitaufnahme könnte ein Wackler am Draht oder
ein Synchronationsfehler des GPS gewesen sein.
Ich hatte das Teil auf ein Regal neben dem Pendel gestellt und
die Stromversorgung abgesteckt.
Du hast nicht vor die schon mehrfach angefragte Messung zur Beurteilung der Qualität der Messdaten zu machen? Source Code dazu siehe weiter oben, das dauert etwa eine Stunde.
Ist das Absicht dass Du nicht darauf reagierst, genauso wie Du immer noch keine Details zur Lichtschranke genannt hast?
Im Moment hängt es ja völlig frei, direkt neben einer Tür.
Da stört ja jeder Luftzug.
Kann ich mir gut vorstellen, vor allem wenn die Teile mit positivem und negativem Temperaturkoeffizienten unterschiedlich schnell erwärmen.
Korrigier' mich wenn ich falsch liege, ich vermute, dass die Spalte Mikrosekunden ein halbstündiger Schnappschuss mit der micros() Funktion ist.
Das leitet sich aber vom internen Quarz ab. Ist das Arduino denn mit der GPS-PPS synchronisiert? Sonst korrigierst du gegen den Quarz und die haben im Allgemeinen eine eher überschaubare Qualität (freundlich formuliert).
Wenn es denn ein Quarz wäre, es ist ein interner Ringoszillator, welcher zwar Temperaturkompensiert ist, aber eigentlich ziemlich unzuverlässig.
Ich würde Bernd F. dringenst ein günstiges Arduino uno empfehlen wo zwei Quarze ersichtlich sind, mit avr Microcontroller. Wenn es Pegelwandlung für das GPS Modul braucht, nicht so schlimm. Wenn er es dann später ernst meint kann er ja ein ocxo anstelle des quarzes anschließen, gibt es auch günstig.
Zur Bestätigung dass die Auswirkungen von anderen Interrupts wie der für millis() keinen Einfluss auf die gewünschte Genauigkeit haben ein kleiner Test:
Source Code siehe Anhang, der orientiert sich an "sketch_sep10a.ino", enthält aber nur den relevanten Teil und gibt das Ergebnis für jeden Impuls der Lichtschranke über die serielle Schnittstelle aus.
Der Code läuft auf einem Arduino UNO, der 1PPS Impuls und das Lichtrankensignal werden von einem Frequenzgenerator mit zwei Kanälen erzeugt (FeelTech FY6600). Der Kanal für den 1PPS Impuls steht auf 1.0 Hz, der Kanal für die Lichtschranke auf 1.000001 Hz. Die 0.000001 Hz sind der kleinste Unterschied denn man zwischen den beiden Kanälen einstellen kann, ganz passt das aber nicht, nach etwa einer Stunde unterscheiden sich die Impulse um ca. 6.4 ms, es sollte aber ungefähr die Hälfte sein (für den Test ist das aber egal).
Im Anhang ist ein Bild mit dem vom Arduino ausgegebenen Wert für den Unterschied zwischen den Impulsen. Außerdem noch der Unterschied des Impulsabstands, damit man besser sieht wie stark eventuelle Auswirkungen eines Interrupts sind, der die Messung stört. Daran sieht man gut die 4 µs Auflösung von micros() auf dem Arduino UNO.
Die Anforderung des TO sind 1 Sekunde Abweichung nach 100 Tagen zu erkennen. Das sind in 24 Stunden also 10 ms oder ca. 0.4 ms je Stunde. Wenn man eine Größenordnung genauer messen will reichen also 1 ms Messgenauigkeit je Tag bzw. 40 µs je Stunde. Das erreicht man mit dem Mikrocontroller, die eigentliche Beschränkung ist sowieso die Genauigkeit der Lichtschranke.
Zu der angesprochenen mechanischen Stabilität des Pendels.
Einige Teile sind bisher nur handfest verschraubt. Wenn ich
mir sicher bin, an diesen Teilen nichts mehr ändern zu müssen,
werden sie mit hochfestem Gewindekleber verschraubt.
Dann sind Änderungen aber fast nicht mehr möglich, da ein
Trennen nur mit hohen Temperaturen (ca. 250°) möglich ist.
Sonst korrigierst du gegen den Quarz und die haben im Allgemeinen eine
eher überschaubare Qualität (freundlich formuliert).
Damit man vom Quarz des µC weitgehend unabhängig ist, muss man doch nur einerseits den Abstand zwischen 1PPS-Puls und Lichtschrankendurchgang, und andererseits den Abstand zwischen zwei 1PPS-Pulsen ablesen. Der Quarz muss dann nur über eine Sekunde ausreichend stabil laufen und die Frequenz ist egal.
Damit man vom Quarz des µC weitgehend unabhängig ist, muss man doch nur
einerseits den Abstand zwischen 1PPS-Puls und Lichtschrankendurchgang,
und andererseits den Abstand zwischen zwei 1PPS-Pulsen ablesen.
Das ist eine der Möglichkeiten welche ich mit der Frage nach Synchronisation gemeint habe.
So schlecht sieht das nicht aus, zumindest ist ein klarer Trend bei der
Abweichung vom 1PPS Impuls zu erkennen. Dennoch wären die weiter oben
erwähnten kontinuierlichen Messdaten hilfreich um die Qualität der
Messung zu beurteilen.
Die "Kurve" taugt nichts. Ich habe daraus das Delta berechnet, siehe Foto.
Die Feinstellung der Uhren
ein Anleitungs- und Nachschlagewerk in 2 Teilen
Verfasser: Giebel, Friedrich Karl <1879-1950> GND link to dataset open/close GND search link open/close (DE-588)1023707381
Verfasser: Helwig, Alfred <1886-1974> GND link to dataset open/close GND search link open/close (DE-588)110439031
Repr. d. Orig.-Ausg. Berlin 1952
3-7667-0628-4
Die Feinstellung der Uhren
ein Anleitungs- und Nachschlagewerk in 2 Teilen
Verfasser: Giebel, Friedrich Karl <1879-1950> GND link to dataset
open/close GND search link open/close (DE-588)1023707381
Verfasser: Helwig, Alfred <1886-1974> GND link to dataset open/close
GND search link open/close (DE-588)110439031
Repr. d. Orig.-Ausg. Berlin 1952
3-7667-0628-4
Es gibt dieverse Nachdrucke
Der Zacken in der Zeitaufnahme könnte ein Wackler am Draht oder
ein Synchronationsfehler des GPS gewesen sein.
Ich hatte das Teil auf ein Regal neben dem Pendel gestellt und
die Stromversorgung abgesteckt.
p.s.
Das JPG-Format taugt für Graphiken übrigens noch viel weniger.
Warum?
Weil der Kompressionsalgorithmus beim JPG auf Photos (Farbverläufe) optimiert ist und mit scharfen Kanten (Graphikelementen) schlecht zurecht kommt. An harten Kanten entstehen in Folge dessen Kompressionsartefakte (Unschärfe bei Symbolen, Gitternetzlinien u.s.w.).
Datenblatt der Lichtschranke und Aufnahme Sekunden.
Mir sagt das jetzt wenig.
Panasonic PM Serie
Das Schaltfähnchen hängt aber nicht exakt in der Mitte,
deswegen Unterschie zu jeder zweiten Sekunde.
Da bringt es schon was, nur gerade Zahlen zu zählen.
Jepp, besser.
Hier ein ganz, ganz schneller und schmutziger ›Calc‹ Hack.
1 Zeigt jeweils die Summe zweier aufeinander folgender Sekunden ÷ 2
2 Zeigt nur die ersten 500 zur besseren Auflösung
3 Zeigt jeweilige Differenz zwischen Hin- und Herschwung
Anmerkung: Die Impuls_Nr ist ziemlich Witzlos und vor allem auch störend wenn sie mehrfach auftaucht. GPS sollte doch einen Mechanismus liefern um die jeweils tatsächliche Sekunde seit epoch auszugeben. Und wenn der kleine Controller bei großen Zahlen kotzt, dann vielleicht das Delta ab Anfang des Jahres. Damit hätte man eine saubere Nummerierung.
Fehlmessungen sollten besser auch gar nicht erst ausgegeben werden (1;01.01.2026;00:00:00)
Als Basis für die Auswertung der Messwerte wurde die Schwingungsdauer des Pendels genommen (Durchgang Lichtschranke von "links nach rechts" plus Durchgang Lichtschranke von "rechts nach links", also 2 Sekunden), damit ist die nicht exakt in der Mitte positionierte Lichtschranke kein Problem.
Da die Abweichung des Pendels von einer Sekunde noch relativ groß ist wurde die Eventzeit (micros() bei Lichtrankendurchgang) für die Zeitmessung genommen, unter der Annahme dass die Drift des Oszillators während der Messdauer von etwa einer Stunde zu vernachlässigen ist.
Im Anhang die Streuung ("Streuung.PNG"), Verlauf der Schwingungsdauer ("Schwingungsdauer.PNG"), sowie Verlauf der Schwingungsdauer mit gleitendem Mittelwert über jeweils 60 Werte ("Schwingungsdauer_Mittelwert.PNG").
Die Streuung bei meiner Messung an einem Pendel mit elektromagnetischem Antrieb war deutlich geringer, die Frage ist ob man das mit einer anderen Lichtschranke verbessern kann oder ob es an der Mechanik des Pendels liegt.
Um die Unterbrechungsdauer durch das Fähnchen zu messen, müsstest du das Signal invertiert auswerten. Aktuell ist die Zeit in der Spalte "Mikrosekunden" diejenige Zeit, die die Lichtschranke frei ist.
Datum und Uhrzeit könnte man also bequem extrahieren und in Sekunden
seit epoch umwandeln. So ungefähr:
Man hat den 1PPS-Sekundentakt und z.B. den NMEA ZDA-Sentence mit der UTC. Warum soll man irgendetwas umrechnen. Es wird doch alles bereit gestellt. Nur bei Schaltsekunden innerhalb des Messzeitraumes muss man ggf. aufpassen. Die kann die Uhr nicht, d.h. jede Schaltsekunde erzeugt einen Sprung beim Stand der Uhr und UTC-Minuten mit 61 Sekunden.
Warum soll man irgendetwas umrechnen. Es wird doch alles bereit
gestellt.
Hatte ich weiter oben bereits erklärt. Wenn in einer Spalte eine aufsteigende Nummer plötzlich wieder kleiner ist, sich das Ganze in einer Logdatei dann auch noch gleich mehrfach wiederholt, dann macht das eine automatische Auswertung zumindest mal ziemlich unbequem.
Natürlich kann man in seiner Auswerte-Software jedes Mal und bei jedem Aufruf erneut die Umwandlung machen. Allerdings verbirgt sich der Sinn einer solchen repetitiven Vorgehensweise ziemlich gut.
Abschließend, ein paar calls direkt im µC sollten doch nicht wirklich weh tun.
Da die Abweichung des Pendels von einer Sekunde noch relativ groß ist
Woraus entnimmst du das?
Solange der µC-Takt nicht anhand der 1PPS-Pulse kalibriert wird, ist das nur eine unbegründete Annahme. Ob der µC seinen Takt aus einem Keramikresonator oder einem Quarz bezieht, wissen wir auch nicht.
Um die Genauigkeit der Zeitbasis beurteilen zu können, sollte man wenigstens den Abstand zweier 1PPS-Interrupts zusätzlich loggen.
Die Frequenz des µC-Quarzes ist ziemlich uninteressant, solange sie stabil ist, ein TCXO reicht da völlig. Wichtig für die Genauigkeit der Uhr ist nur, dass sich der Abstand zwischen der Flanke des 1PPS-impulses und der Flanke der Lichtschranke nicht ändert (genauer gesagt: der Abstand jedes 2. Impulses, denn die Lichtschranke wird nicht absolut genau in der Mitte des Pendelweges liegen).
Wichtig für die Genauigkeit der Uhr ist nur, dass sich der Abstand
zwischen der Flanke des 1PPS-impulses und der Flanke der Lichtschranke
nicht ändert
Und womit wird dieser Abstand gemessen - mit dem µC-Takt. Je weiter 1PPS-Puls und Lichtschrankendurchgang zeitlich auseinander liegen, um so mehr geht eine Änderung der µC-Taktfrequenz ein - wenn auch als Fehler höherer Ordnung.
Das ändert nichts daran, dass der Wert Event Mikrosekunden eine Hausnummer ist, solange der µC-Takt nicht kalibriert ist, d.h. ohne Messung des 1PPS-Abstandes kann man sich den sparen.
Wichtig für die Genauigkeit der Uhr ist nur, dass sich der Abstand
zwischen der Flanke des 1PPS-impulses und der Flanke der Lichtschranke
nicht ändert
Und womit wird dieser Abstand gemessen - mit dem µC-Takt. Je weiter
1PPS-Puls und Lichtschrankendurchgang zeitlich auseinander liegen, um so
mehr geht eine Änderung der µC-Taktfrequenz ein - wenn auch als Fehler
höherer Ordnung.
Das ändert nichts daran, dass der Wert Event Mikrosekunden eine
Hausnummer ist, solange der µC-Takt nicht kalibriert ist, d.h. ohne
Messung des 1PPS-Abstandes kann man sich den sparen.
Und womit wird dieser Abstand gemessen - mit dem µC-Takt.
Es ist egal, womit und in welcher Zeiteinheit gemessen wird, sie muss nur fein genug sein. Bleibt der Abstand jeder 2. Pendel-Flanke zum 1PPS-Impuls gleich, ist die Uhr genau in 0.5-Hz-Takt, denn das Pendel von Bernd ist ein 1-Sekunden Pendel.
Hast du Schwierigkeiten mit Textaufgaben?
Bei dem Thema Event Mikrosekunden geht es um einen simplen Dreisatz.
Die sogenannten Mikrosekunden sind nur nominelle Mikrosekunden, aber nicht wirkliche Mikrosekunden.
Der To könnte ja, wenn er denn es nur wollte, die aktuell benutzte Software hier posten und die Messdaten hier zeigen. Es ist dumm wenn er innerhalb der Messung an seinem Pendel oder Arduino herumfummelt. Ja und ein wenig sorgfältiger damit umgehen. In der Temperatur Spalte haben Wochentage bzw. ... nix zu suchen.
Mein Prof. hatte immer ein ein kleines weißes Stäbchen in der Hemdentasche und damit alle Aufgaben in den Klausuren in den Nachbesprechungen ratzefatze gelöst. Die Studies mit Moos dadellten immer noch auf den eletrischen Rechenknechten herum, während der Prof. längst fertig war.
Mein Prof. hatte immer ein ein kleines weißes Stäbchen in der
Hemdentasche und damit alle Aufgaben in den Klausuren in den
Nachbesprechungen ratzefatze gelöst. Die Studies mit Moos dadellten
immer noch auf den eletrischen Rechenknechten herum, während der Prof.
längst fertig war.
Wenn beim Import Excel falsch eingestellt ist, werden aus den
Dezimalzahlen nun mal Texte oder, wenn's passt, auch ein Datum.
Wenn ich jetzt noch wüsste, welche Einstellungen ich ändern muss?
Excel gab es in meinem Berufsleben praktisch nicht.
Die Architekten haben manchmal "Bauzeitenpläne" als Excel-Datei
geschickt, aber das war eh immer reines Wunschdenken.
Wenn beim Import Excel falsch eingestellt ist, werden aus den
Dezimalzahlen nun mal Texte oder, wenn's passt, auch ein Datum.
Wenn ich jetzt noch wüsste, welche Einstellungen ich ändern muss?
Excel gab es in meinem Berufsleben praktisch nicht.
Die Architekten haben manchmal "Bauzeitenpläne" als Excel-Datei
geschickt, aber das war eh immer reines Wunschdenken.
Grüße Bernd
Ja dann lasse doch Excel einfach weg, eine *.csv Datei reicht doch allemal.
Du sammelst doch Daten, dafür ist Excel nicht gedacht, wird aber häufig verwendet.
Wenn ich jetzt noch wüsste, welche Einstellungen ich ändern muss?
Die Google KI empfiehlt in diesem Fall, beim Import von Dateien mit Dezimalzahlen nicht das Trennzeichen vom Betriebssystem zu übernehmen, sondern es selber auszuwählen. Alternativ geht es, indem man die Daten mit der Funktion "Aus Text/CSV" und dem zur Datei passenden Gebietsschema lädt.
Ich selber verwende leider (?) kein Excel.
Du sammelst doch Daten, dafür ist Excel nicht gedacht, wird aber häufig
verwendet.
Excel sammelt die Daten nicht. Das erledigt der Arduino.
Mit Excel sollen die Daten ausgewertet werden. Wenn man ihm sekündliche Werte von 100 Tagen anbietet, könnte es allerdings etwas zäh werden, d.h. da ist es wohl sinnvoll, die Daten vorher z.B. auf stündliche Werte zu reduzieren.
Wenn man ihm sekündliche Werte von 100 Tagen anbietet, könnte es
allerdings etwas zäh werden, d.h. da ist es wohl sinnvoll, die Daten
vorher z.B. auf stündliche Werte zu reduzieren.
Excel kann nur ca 1 Mio Zeilen verarbeiten. 100 Tage sind 8,64 Mio Sekunden. Braucht man auch nicht, stündliche Werte bei 100 Tagen reichen.
Wenn man so eine Auswertung über eine Tabellenkalkulation – gleich
welcher Art – macht, dann ist es höchste Zeit das Konzept zu überdenken.
Da stimme ich Dir zu 100% zu. Ich nutze dafür ausschliesslich Gnuplot: die Syntax ist einfach, wenn sich die Daten geändert haben einfach nochmal laufen lassen und es ist sauschnell.
Da stimme ich Dir zu 100% zu. Ich nutze dafür ausschliesslich Gnuplot:
die Syntax ist einfach, wenn sich die Daten geändert haben einfach
nochmal laufen lassen und es ist sauschnell.
Genau so ist das. Und wenn man zuvor noch ein wenig die Daten durchkneten möchte, dann matplotlib und der Tag ist gerettet.
