Winziges/flaches Echtzeitmodul gesucht

Morgen :slight_smile:

Mein Winterprojekt wird ein GPS-Logger mit Kartenanzeige sein. Es kommen aber mehrere Sensoren dran, die in bestimmten Intervallen abgefragt werden - unabhÀngig vom GPS.
Daher wollte ich bei jeder GPS-Abfrage (oder jede x-te) die Echtzeituhr neu einstellen, dass diese möglichst genau weiter lÀuft. Diese wird dann genommen, wenn z.B. nur Temperatur geloggt werden soll.
Die gebrÀuchlichen Module sind ja nicht gerade winzig..vro allem nicht die Knopfzelle bzw. deren Halterung. Konnte bisher nichts kleineres oder vor allem flacheres finden. Kann mir da jemand helfen?

Gruß
Paul

Wirklich groß sind die Module z.B. mit DS3231 ja nicht, vielleicht kannst du den Batteriehalter einfach ablöten und wo anders platzieren? Vielleicht könnte man ja auch komplett auf die Pufferbatterie verzichten, die Zeiteinstellung geht dann eben verloren sobald mal die Versorgungsspannung wegbricht...

Was nimmst du denn fĂŒr ein Board? Vielleicht könntest du ja ein Teensy nehmen, der hat eine integrierte RTC und somit könntest du auf ein zusĂ€tzliches Modul komplett verzichten.

An viele AVRs kann man einen Uhrenquarz anschließen.
Sie verfĂŒgen ĂŒber eingebaute RealTimeCounter
So auch der ATMega328p

Platzbedarf fĂŒr den Quarz:
ca.3mm Durchmesser
ca 8mm lang

Ouh...dann hat sich mein Problem erledigt! Habe das wohl in den technischen Daten ĂŒberlesen. Teensy 3.2 wird fĂŒr die Kartendarstellung verantwortlich sein..bei 96 MHz sollte der ausreichen. Sonst kommt noch ein zweiter dazu oder ein 8266er als Co-Prozessor fĂŒr die Bildschirmausgabe.

@combie : das kantne ich noch nicht..danke fĂŒr die Info :slight_smile:
Mein Weckerprojekt hat da ein doofes Problem trotz RTC - die Zeit geht nach 24 h gut 10-15 Minuten auseinander :confused: (zu schnell). Somit momentan unbrauchbar. Habe zwei verschiedene (Platinenlayout bzw. Hersteller), weshalb ich erstmal den anderen ausprobieren wollte.

Das mit dem Quarz ist interessant, da ich einen Pro Mini auf 8 Mhz umlöten wollte fĂŒr 3,3 V betrieb (LiIon) - der ĂŒbernimmt die Tasten/Joystick, Sensorabfrage und das Wegschreiben der Logdaten. Bedienung wird an Teensy weiter gegeben bzw. dieser aufgeweckt, wenn Kartendarstellung erforderlich.
Das mit dem Quarz funktioniert ja aber nicht, wenn sich der 328er im Tiefschlaf zwischen den Messungen befindet..richtig? Dann brĂ€uchte ich ja doch ein separates RTC, welches der Pro Mini abrufen kann ohne extra dafĂŒr den Teensy aufwecken zu mĂŒssen.

Wenn die Uhrzeit eh regelmĂ€ĂŸig via GPS aktualisiert wird, stellt sich mir die Frage, ob eine RTC wirklich nötig ist, oder die "Genauigkeit" des Arduinos ausreicht....

Ich glaube beim Teensy 3.2 muss man auch einen Quarz einbauen. Erst bei den 3.5/3.6 wird er bestĂŒckt sein.

Habe ich noch nicht probiert, wenn ich einen Controller mit Uhr brauche, nehme ich einen mbed.

MaHa76:
Wenn die Uhrzeit eh regelmĂ€ĂŸig via GPS aktualisiert wird, stellt sich mir die Frage, ob eine RTC wirklich nötig ist, oder die "Genauigkeit" des Arduinos ausreicht....

Da sich der Pro Mini zu 99% im Tiefschlaf befinden wird - ja :wink: Und wie geschreiben, muss das unabhÀngig vom GPS funktionieren.
Es werden geloggt:

  • Temperatur
  • Luftfeuchte
  • LUX
  • Barometer / Höhe

Diese unabhĂ€ngig vom GPS lauffĂ€hig und mit unterschiedlichen Loggingzeiten. D.h. Temperatur jede 15 Sekunden. Barometer jede 10. GPS - falls ĂŒberhaupt geloggt werden soll - z.B. jede 30 oder 60 - ...dazwischen soll der auch im Standby sein. Dazu kommt ein 3-achsen Beschleuniger. Keine Bewegung = GPS aus.

@ArduFE: ok. Dann also RTC an ProMini, welcher die Zeit (welche in dem GPS-String vorhanden ist) sowieso an den Teensy weiter geben soll, wenn dieser aufgeweckt wird.

ah, ok

Alternative wÀre, den Chip DS3231 mit den nötigen Bauteilen auf eine eigene Platine setzen und eine kleinere "lötbare" Knopfzelle daneben setzen. Dann hast du eine sehr genaue RTC die auch klein und flach ist.

Daran dachte ich auch..aber ne SMD Platine schlachten und auf Lochraster wieder löten könnte frickelig werden :smiley: Das Echtzeitmodul ist ja gut halb so groß wie der Teensy/Mini (das andere Modul fast genauso groß). Mal schauen wieviel ich von der Platine absĂ€gen/feilen kann. Die Dicke kommt ja hauptsĂ€chlich durch die Batterie, die theoretisch wegfallen kann, da das ganze mit LiIon angetrieben werden soll, was vom Spannungsbereich her passt. Pufferkondensator fĂŒr leeren Akku bzw. Wechsel kann ich mir auch sparen, da ich hierfĂŒr ja kurz GPS beim Erststart aktivieren und die Uhr setzen kann.

Ich glaube das kleinere Modul, welches ich zu Hause habe, ist ein Tiny RTC mit dem DS1307. Da könnte ich ja die AnschlĂŒsse absĂ€gen und die Platine etwas kleiner Feilen.

Das mit dem Quarz funktioniert ja aber nicht, wenn sich der 328er im Tiefschlaf zwischen den Messungen befindet..richtig?

Muss es denn UNBEDINGT der Tiefschlaf sein?

Bei mir laufen einige ATMega168P in genau diesem Modus.
MĂŒssen sogar ein paar mal am Tag einen Motor drehen.
Versorgung: 2 AAA Batterien (halten ca 2 bis 3 Jahre)

Das Datenblatt des ATMega328P sagt:

Power-save Mode: 0.75”A (Including 32kHz RTC)

Bedenke, die Nutzung deiner externen RTC braucht auch Strom.
U.A. fĂŒr die I2C Pullups. (rechne das mal aus)

Aber was solls.....
Ist ja nicht meine Baustelle...

AlphaRay:
Die gebrÀuchlichen Module sind ja nicht gerade winzig..vro allem nicht die Knopfzelle bzw. deren Halterung. Konnte bisher nichts kleineres oder vor allem flacheres finden. Kann mir da jemand helfen?

Hallo Paul,

es gibt die DS3231 in klein. Ist zwar seltener als die "normale" große AusfĂŒhrung, aber doch oft zu finden , wie z.B.
http://www.ebay.de/itm/Mini-DS3231-I2C-Real-Time-Clock-rtc-mit-Temperatursensor-f-Arduino-Raspberry-PI-/182095174289

Abmessungen ca. (LxBxH): 13,2mm x 13,4mm x13mm

Wegen dem Steckverbinder 13mm hoch. Sonst wÀre das Ding noch kleiner.

Gruß, JĂŒrgen

Hallo AlphaRay,

wĂŒrde mich ja mal interessieren was es werden soll, wenn es fertig ist- und
was fĂŒr einen Sinn- das machen soll??

Machen wir das mal grob Beispielhaft
fĂŒr 8Std-

Alle 10sec die Barometer/Höhe loggen, das sind 2880 Werte.
Alle 15sec die Temperatur/Luftfeuchte, das sind 3840 Werte.
Alle 15sec die Lux, das sind 1920 Werte.

Das sind fĂŒr 8 Std dann 8640 Werte. Wie- und fĂŒr was werden diese denn weiter-
verarbeitet?

Ja, ja- nehmen wir einmal die 30 und 60 Sek.
Das sind bei 5 Werten dann 960 Werte alle 30Sek oder 480 Werte fĂŒr 60sek.

Nehmen wir jetzt mal wohlwollend einen Log-Intervall von 60 Sek.

Wenn Dein Temperatur-Sensor gut ist, dann hat der eine "Genauigkeit" von
ca. ±0,2°C. D.h. eine Fehlertoleranz von 0,4°C.
Dein geloggter Wert von z.B. 20°C liegt also im realen Bereich von
19,8°C bis 20,2°C.

Was meinst Du denn, was sich an der Temperatur in 60sek Àndern sollte?
Das sind die Stellen hinter dem Komma- plus Messfehler, und das muß alle
60sek festgehalten werden?

Nehmen wir die Luftfeuchte mal dazu. Von welcher "Feuchte" reden wir hier?
Von der relativen Luftfeuchte oder von der absoluten Feuchte?
Wir nehmen einmal die relativen Luftfeuchte- das ist fĂŒr Dich einfacher zu
messen.

Wenn Dein Feuchte-Sensor gut ist, dann hat der eine Toleranz von ±0,2rF%
Wir gehen hier einmal von 50,8rF% aus.
Im realen Bereich wÀren das dann 50,7rF% bis 50,9rF%

Auch hier stellt sich mir wieder die Frage, was sich an der Leuftfeuchtig
sichtbar Ă€ndern muß, wenn diese in einem Zeitraum von 60sek aufgezeichnet
werden soll?
Die Luftfeuchtigkeit verÀndert sich viel zu langsam, um in 60sek einen ver-
wertbaren Wert zu erhalten.

LUX messen- ich halte das fĂŒr ein zweifelhaftes VergnĂŒgen. Sagen wird lieber
Helligkeit-Unterschiede feststellen und diese durch einen Wert darstellen.

Nun gut, aber was soll man da alle 60sek festhalten?
Wenn Du um 17:53:00h eine Tunnel betritts- und auch zur selben Zeit die Daten
log®s, dann weißt Du- wann Du diesen Tunnel betreten hast.
Log®s Du aber um 17:52:37h dann weißt Du nicht, wann Du diesen Tunnel betreten
hast. Du weißt nur, das es um 17:53:00h dunkler gewesen ist.

Was möchtest Du damit- mit was fĂŒr einem Sinn aufzeichnen? Wenn sich eine Wolke
vor die Sonne schiebt? Wenn das Licht ausgeht? Die Zeit, die jemand braucht, um
die Gardinen zu zuziehen?

Barometer, auch hier stellt sich wieder die Frage welchen Luftdruck Du zu
Grunde legen möchtest. Den, der am Sensor gemessen wird- oder den eines
bestimmten KĂŒstenpegel.

Wenn man einen 0815-Luftdrucksensor zu Hand nimmt, dann stellt man fest, das
diese Dinger ungenauer sind, als so mancher analoger Luftdruck-Messer.
Und in welcher Höhe möchtest Du diesen Druck messen? Es ist schon ein erheb-
licher Unterschied- ob Du diesen auf der grĂŒnen Wiese abnimmst, oder in den
schwarzen Bergen.

Wir gehen hier einmal von einer Toleranz von +2,5hPa aus. Du bekommst also
von Deinem Luftdruck-Sensor einen Wert von 1006,7hPa. Es ist also möglich, das
dann real, so um die 1009,2hPa sind.
Dieser Wert wird alle 60sek aufgezeichnet. Was glaubst Du denn damit entdecken
zu können? Wenn der Luftdruck in 1Std um 1hPa fÀllt oder steigt, dann ist das
schon ein ziemlich hoher Wert- und extrem selten zu beobachten.

Wenn Du alle 60sek logÂŽs, dann zeichnest Du "mPa" mit einer Toleranz von +2,5hPa
auf!? Was soll das bewirken, wozu wird das benötigt?

Höhe, jetzt wird die Geschichte abenteuerlich. Welche Höhe wird denn als
Bezug zu Grunde gelegt? Da gibt es ja mehrere Möglichkeiten

Mit der Toleranz des o.g. Sensor sind das schon einmal 20m Unterschied.
20m Höhneunterschied in 60sek können schon ziemlich sportlich sein. Aber welche
Referenzhöhe legst DU zu Grunde? Die einer Höhenmarke des LVermA?
An so einem Punkt könntest Du den Sensor fĂŒr die Höhe kalibrieren- an dem Punkt,
mit dem Luftdruck und einer bestimmten Temperatur.
Was machst Du aber mit diesem Referenzwert in den schwarzen Bergen? Hast Du da
eine Formel- oder noch besser eine Sketch fĂŒr?
Höhenmessung mit einem barometischem Sensor ist bestimmt eine spannende
Geschichte. 20m in 60sek sind 33cm in der Sekunde. Wie soll das gehen?

Dann möchtest Du eine RTC mit der GPS-Zeit syncronisieren. Beneidenswerter
Gedanke. Nehme wir einmal an, das Du eine DreckŽs-RTC hast die ±15sek in 24std
macht. Das ist dann eine Toleranz von 30sek in 24std.
Das ist dann eine Toleranz von 0,035% in 24Std.

Diese 0,035% möchtest Du jetzt mit der GPS-Zeit syncronisieren?
Ich meine, Du willst das ja alles ziemlich "genau" haben- wie sonst kommt man
auf diesen Gedanken?
Wirklich spannen fĂŒr mich wĂ€re es nun zu wissen- wie errechnest Du den Laufzeit-
Fehler bei der Übertragung der GPS-Zeit?
Ich meine, Dich stören ja hier schon 0,035% bei der Zeitbestimmung

Gruß und Spaß
Andreas

P.S. ich muss ja auch auf den Punkt kommen...
RTC-IC

@combie: zwischen den Messungen hat er ja nichts zu tun. Dachte an 125 ms je Loop, damit er die Tasten noch oft genug abfragt - acht mal pro Sekunde sollte da reichen. Also 125 ms schlafen legen -> Zustand IOs checken + Uhrzeit abfragen -> Zeitpunkte fĂŒr Sensorabfragen checken -> Schlafen bzw. Funktionen ausfĂŒhren. Erfolgt ein Tastendruck, wird der Ardu eine bestimmte Zeit wach gehalten, falls weitere Eingaben kommen sollten. Das Teil soll wenn möglich 2-4 Wochen laufen mit 1000-2000 mAh 3.6/3.7V.

@Katsu: der ist echt schön klein..danke :slight_smile:

@SkobyMobil:
Die Zeiten waren doch nur Beispiele :smiley: Geht darum, dass man manche Werte nicht zusammen mit dem GPS-Signal braucht. Bzw. vollstĂ€ndig vom GPS getrennt geloggt werden können. Temperatur jede 10 Sekunden wĂŒrde ja nicht mal beim Biken Sinn machen..meinen aktuellen Temperaturlogger (gekaufter) ist auf 2 Minuten gestellt. Damit weiß ich noch im nachhinein wie warm es war oder wie kalt im Zelt (gefroren -> Temperatur checken -> AusrĂŒstung optimieren). FĂŒr Reiseblog ist mir die Temperatur wichtig..keiner merkt sich wie kalt es morgens/abens war oder wie warm tagsĂŒber. Oder einfach mal den KĂŒhlschrank ĂŒber nen Tag loggen - 20 mal öffnen: wie oft kommt der KĂŒhlschrank ĂŒber die eingestellte Temperatur? WIe lange braucht er um wieder auf die korrekte runter zu kommen? Auf welche Stufe muss ich den einstellen? uswusw.. Wohnungstemperatur messen wĂ€hrend man nicht da ist. Gibt diverse Einsatzmöglichkeiten.
Werte werden ĂŒbrigens nur geloggt wenn sich was Ă€ndert. Wenn Temperatur 5 h ĂŒber Nacht bei 10,0 bleibt, dann gibts erst nach fĂŒnf Stunden einen Änderungssatz. Ich arbeite in der Maschinendatenerfassung als Entwickler..daher kenne ich das Sammeln und Auswerten von Daten gut :wink:
Ist mir egal ob es 8, 8.1 oder 8.3 Grad waren. Es war kalt. Nur weil man keine 0,01 °C Genauigkeit hinbekommt muss man das Loggen doch nicht lassen..? Der Aktuelle Logger arbeitet irgendwo im Bereicht von +/- 0.5 Grad.
Relative Luftfeuchtigkeit natĂŒrlich. Der Sensor hat es halt - wieso dann nicht verwenden? Sind nur nur paar KB mehr Daten im Jahr.. Der dĂŒrfte viel genauer sein wie die meisten Luftfeuchte-Temperaturstationen Daheim.

Es ist ein digitaler LUX Meter (TSL2561). k.a. wie genau der ist - reicht aber aus um auszuwerten ob die SOnne schien, es regnete (in kombination mit der Luftfeuchte) oder ich noch geschlafen habe (in kombination mit Beschleunigersensor).

Als Barometer erstmal nur einen BMP180. SpĂ€ter solls ein iwas-311 werden (genaue Kennzeichnung weiß ich nciht mehr - das Breakout kostet um 18 €). Der 180er hat eine Genauigkeit von 0.02hPa - nix 2,5.
Der wird ggf sogar noch öfter abgefragt -> mit nem MTB kann man mal eben pro Sekunde 1-2 Meter Berg runter rasen. GPS ist da meistens zu ungenau. Das ganze wird halt in Kombination mit Beschleunigersensor/GPS variabel gehalten.
Der Höhenwert des Barometers ist ja meistens genauer als der des GPS-Signals. Dieser wird auch deshalb - wie von meinem Logger damals (weiter unten erwĂ€hnt) - mit den GPS-Koordinaten mit in die GPX-Datei weggeschrieben. Eine Kalibrierungsfunktion muss natĂŒrlich fĂŒr alle Sensoren rein. FĂŒr die Höhe hatte mein alter GPS-Logger das auch gehabt (Barometer).

Wieso sollte ich das GPS nur eine 24 h einschalten, wenn ich 1-2 mal pro Minute damit logge? Die Differenz dĂŒrfte nicht messbar sein, wenn ich nach jedem Abfrages des GPS die Zeit mit dem RTC vergleiche und bei einem Unterschied abgleiche :wink:

Ha, ha :smiley: Die RTC wird genommen fĂŒr die Sensoren - auch wenn da eine Abweichung von 1 Sekunde sein sollte - was solls? Ob die Temperatur von 20,5 Grad um 12:01:02 oder 12:01:03 herrschte ist mir ehrlich gesagt schxx egal :wink: Eine GrĂ¶ĂŸere Differenz wird nie auftreten, da GPS ja nach maximal einer Minute abgefragt werden soll.

Da du genauer wissen willst:
Es soll ein leicher und kleiner Datenlogger + Kartenanzeige fĂŒr's Trekking und Biken werden - hauptsĂ€chlich. Momentan nutze ich einen BT747SPro GPS-Logger und einen Temperaturlogger. Die OpenStreetMap-Karte wird auf einem Android-Smartphone angezeigt, was zu Akkuproblemen fĂŒhrt bzw. dem Verlust der Karte, wenn der Strom alle ist, was bei einem Smartphone meistens innerhalb eines Tages der Fall ist. Die GPS-Aufzeichnung wird hauptsĂ€chlich fĂŒr das Geotaggen meiner Fotos (Trekking+Fotografie Haupthobbys - neben Basteln+Elektronik :wink: ). Mit den GPS-Koordinaten können die letzten gemessenen Sensorwerte ebenfalls mit abgespeichert werden statt nur in einer Extra-Datei.
Statt der zwei/drei GerÀte soll jetzt eines her, was besser in der Sonne ablesbar ist, lÀnger hÀlt und kleiner/leichter ist. Smartphone kann dann die meiste Zeit aus bleiben, da ich es beim Trekking nur wegen der Karte/Routing an habe.

Daher baue ich mir einen GPS/Temperatur-Logger mit zwei zusÀtzlichen Werten, welcher auch OpenStreetMap Karten anzeigen kann + in dieser die aktuell aufgezeichnete Strecke, POIs und spÀter auch ein vereinfachtes Routing anhand einer am PC vorberechneten und auf der SD gespeicherten Strecke.
Alles auf OLED-Basis, da man zu 90 % kaum was auf einem Handy Draußen erkennen kann ohne abzudunkeln und sich sehr anzustrengen. Zudem soll das ganze nicht nur wenigen Stundenm sondern mehrere Tage laufen.

Es wird grob eine erweiterte Version meines vorvorletzten GPS-Loggers werden. Dieser hatte ein SW-Display, wo die aufgezeichnete Strecke angezeigt werden konnte. ZusÀtzliche Anzeigen waren Temperatur Luftdruck, Höhe, GPS-Koordinaten, Kompass usw..

Aktuelle Gedanken zur Umsetzung:
Arduino Pro Mini 3.3/8: Bedienung des GerÀts (Taster+Joystick), Abfragen der Sensoren und Speichern der Daten auf SD, Wecken des Tennsy, wenn die Karte angfordert wird. Ausgabe der ganzen Daten auf 1,3" 128x32 OLED - nur bei Bedarf, um Strom zu sparen. Die meiste Zeit soll der Ardu im Schlafmodus verbleiben, wordurch der Stromverbrauch in uA-Bereich fÀllt.

Teensy 3.2 (vorerst - spÀter 3.6, wenn erhÀltlich): auslesen von vorgekauten OpenStreetMap-Kartendaten von einer zweiten MicroSD (hinten auf dem 1,69" Farb-OLED mit 160x128 Pixeln) und die Ausgabe dieser auf dem Bildschirm. Der Teensy wird nur geweckt, wenn die Karte angefordert wird. Als Zusatzram bekommt er 4 x 23L1024er ICs (4 x 128KB SRAM).
Reicht der Teensy von der Leistung her nicht aus, wird ggf. ein 8266er als CoProzessor mit eingebaut, welches ggf. nur die Bildschirmausgaben ĂŒbernimmt. Der 3.6er Teensy mit 180 MHz sollte da schon locker reichen. Das Kickstarterprojekt hat aber erst vor wenigen Tagen die angepeilte Summe erreicht. Dauert dann paar Wochen, bis man den erwerben kann.

Das kleinere Monochrom-OLED wird quer oberhalb des Farb-OLED platziert. Das ganze gerĂ€t soll dann etwa halb so groß wie ein aktuelles Smartphone werden. Als Akku ein Nokia-Akku (BLE5 oder so Ă€hnlich), welcher Standard bei GPS-Loggern ist.

Ich bin ein 37-jÀhriger Anwendungsentwickler und habe in den letzten 25 Jahren so manches gebastelst und programmiert...bin jetzt kein komischer Spinner, der jezt versucht ne Schnapsidee zu realisieren :smiley:

Hallo,
da hat ja mal einer geantwortet...
Jetzt macht das auch einen (anderen) Sinn. Man kann das nachvollziehen. Da hat sich mal jemand etwas aus-
gedacht, der nicht- nur Blubbels im Kopf hat.
Vielen Dank fĂŒr Deine MĂŒhe.
Gruß und Spaß dabei
Andreas

Danke! Werde ich bestimmt haben :wink: :slight_smile: