microcontrollergesteurte Windmessanlage

Hallo,

denn erstmal herzlich Willkommen im Forum

xEsG schrieb:

ich studiere Mechatronik und muss im Zuge meiner Praxisphase eine microcontrollergesteuerte Windmessanlage zur Bestimmung von Windlaststrategien von Bäumen entwerfen.
...
...
Leider bin ich auf mich allein gestellt und mir fehlen dazu die Kenntnisse und die Zeit die mir übrig bleibt ist knapp.
Deswegen schreibe ich hier an Euch und hoffe dass Ihr mir helfen könnt.

Zum Vergrößern anklicken....

das alte Problem
Wieviel Zeit bleibt dir denn noch ?
Am schnellsten geht es eigentlich wenn du alles auf den Tisch legst damit man mal drüberschauen kann.
Du solltest auch genau sagen wo du Hilfe (Hilfe und keine fertigen Programme!) benötigst. Das eine oder andere Schnipsel wird dir bestimmt zugeworfen. Es wird dir aber keiner deine Arbeit fertigstellen. Da mußt du selber durch.

Also was mit Mega16, 20x4-CharacterLCD, Echtzeituhr (RTC), später noch DCF77 und für die Meßwerte am besten nen dickes externes EEPROM. Strom sparen kann man mit den Sleep-Modus. Rausholen könnte ihn da der Timer2 (laut Datenblatt). Nen nidrigerer Takt spart auch noch Saft. Also nicht unbedingt 16MHz.

10 Min-Intervall => 24h x 6 = 144 Messungen pro Tag
3 Monat (jeweils etwa 30 Tage) => 90d x 144 = 12960 Messungen.

Je nach Menge der Daten ist das kleinste also schonmal 16kByte EEPROM (macht dann 128kBit-Chip).
Es geht also nicht an einem externen EEPROM vorbei. Das ist einfacher wie ne SD-Karte !! Außerdem kann das externe EEPROM mit an den I2C-Bus der RTC dran. Zwei Fliegen mit einer Klappe. Das ergibt dann aber nur 1Byte pro Messung. Recht dünne. Es gibt auch 512kBit EEPROMs. Das wären dann 4Byte pro Messung um zB auch einen Zeitstempel mit abzulegen. Dann kann man bei einem Reset/Neustart an die bereits abgelegten Messung anknüpfen und überschreibt nix was noch benötigt wird.

Soweit erstmal und nun Butter bei die Fische und Hose runter damit man weiß wo man helfen kann/soll.
Noch was wichtiges : mit welcher Sprache programmierst du ?

Gruß
Dino

Solange kein weiterer Input kommt, ist alles nur Spekulation.
Wenn Stromsparen, warum dann keinen Mega16L? Wieweit kann die Versorgungsspannung runter - mit dem Display/Sensor/etc?
Kann man den Windmesser nicht generell als Generator verwenden - nur mal so nebenbei (energyHarvesting)? Was steht überhaupt als Versorgung zur Debatte?
Zu Dinos Ansatz mit Timer2. Der kann auch asynchron mit einem 32kHz-Quarz betaktet werden. (genau genommen auch 32,768kHz???). Ein Überlauf des Timers kann zum Wecken der CPU verwendet werden. Timer2 ist ein 8bit-Timer. Kannst ja mal ausrechnen, wielange die CPU dann schon mal schlafen kann...

Hi,

xEsG schrieb:

Habe noch ca. 10 Wochen und programmiere mit C auf dem free AVR Studio 4.

Zum Vergrößern anklicken....

wenn man also noch Zeit für die Doku/Recherche einrechnet bleiben dir so etwa 5-7 Wochen für die reine Arbeit übrig in der du dich auch noch neben der Software um die Hardware kümmern mußt. Und das bei bei wenig Programmiererfahrung und wohl auch keiner großen Hardwareerfahrung. Dann solltest du auf keinen Fall Zeit verlieren denn so eine Woche ist verdammt schnell um.

xEsG schrieb:

Ich würde natürlich gerne die einfachste und beste Lösung nehmen und ich habe auch grünes Licht frei zu wählen und zu arbeiten jedoch habe ich keine Idee, welche Komponenten dazu ratsam wären.

Zum Vergrößern anklicken....

Einfachste Lösung hört sich gut an Da würde ich dir auch zu raten.

xEsG schrieb:

Die Hauptsache ist, dass das System am Ende zuverlässig funktioniert.
Soweit ich weiß welche Komponenten ich benötige ist meine Universität bereit diese zu finanzieren, solang sie nicht den Rahmen sprengen.

Zum Vergrößern anklicken....

Grundsätzlich vorweg. Besorg dir den ORIGINALEN AVRISPmk2 ! Du hast keine Zeit dich mit Problemen des Proggers rumzuschlagen und Fehler zu suchen die eventuell durch nen paar Euro günstigeren Progger ausgelöst werden.

xEsG schrieb:

Also der Standpunkt ist soweit der hier:

Also 1. ein ATmega16L wurde empfohlen und ist zum Einsatz geplant.

Zum Vergrößern anklicken....

Der ATmega16 steht bei dir oben drin. Es wurde wegen Stromverbrauch nur die LowPower-Version empfohlen.
Wenn du noch keinen rumliegen hast dann nimm den Mega32 oder besser den Mega644 weil du da mehr Flash für dein Programm zur Verfügung hast. Beide gibt es auch in LowPower-Versionen.

xEsG schrieb:

2. was die Stromversorgung angeht, kam auch die Idee eine Autobatterie einzusetzen, welche alle paar Monate ausgetauscht werden soll (was hält ihr davon ?)

Zum Vergrößern anklicken....

Denk dran das die Technik draußen hängt und die Batterie/Akku auch bei -20°C sauber laufen muß. Such dir also eine Stromquelle die das kann.

xEsG schrieb:

3. zur Datenverwaltung ist der Quellcode auf eine 2GB SD-Kartenspeicherung konzipiert

Zum Vergrößern anklicken....

Wenn du den Code mit der SD-Karte bereits am laufen hast, dann benutze es weiter weil du die Daten dann direkt über die SD-Karte zum PC bekommst. Der Code für das FAT-Filesystem füllt dir beim Mega16 allerdings recht gut dein Flash das du eventuell besser für andere Routinen brauchen kannst (LCD-Routinen, ...) Da würde ich also eher den Mega644 empfehlen. Für SD-Karte mußt du außerdem mit Pegelwandlern auf 3,3V arbeiten da eine SD-Karte keine 5V verträgt. Die günstigen LCDs brauchen aber meißt alle 5V und die restliche Elektronik eventuell auch.

Wenn du das mit der SD-Karte noch nicht angefangen hast dann würde ich dir wirklich das EEPROM am I2C-Bus empfehlen. Die Daten kannst du dann direkt über ne Serielle Schnittstelle (evtl über nen USB-Adapter) aus dem System zum PC übertragen lassen. Damit kannst du dann auch OnTheFly Debug-Daten zu nem PC übertragen was mit ner SD-Karte nicht geht.

Außerdem brauchst du ne RTC (zB DS1307) um nach dem Aufwecken sofort die richtige Uhrzeit zu haben. Sonst mußt du eventuell erst mehrere Minuten mit DCF77 synchronisieren. Das wäre kontraproduktiv für Energiesparen. Die SoftwareUhr wird wohl beim Sleep-Mode nicht weiterlaufen. Mit ner RTC kannst du dir die Softwareuhr auch sparen. Dann fragst du einfach öfter mal die RTC am I2C-Bus ab. Ist zwar nicht schön aber einfach und es funktioniert

xEsG schrieb:

4. für die Synchronisation ein DCF77-Empfänger

Zum Vergrößern anklicken....

Das benötigt einen IO-Pin des Controllers und eine entsprechende Lib für den DCF77-Empfang.

xEsG schrieb:

5. ein HD44780 20x4 Character LCD

Zum Vergrößern anklicken....

Ein LCD kannst du auch im 4Bit-Modus betreiben. Dann benötigst du nur 6 oder maximal 7 Pins am Controller.

xEsG schrieb:

Ich sehe ihr habt schon andere Ideen und ratet von der SD-Kartenspeicherung ab. Ich nehme diesen Rat sehr gerne an und würde mich darum kümmern den Vorschlag, einen externen EEPROM zu nutzen, zu realisieren. Leider habe ich zwar noch keine Vorstellung was das wirklich ist, ich werde mich aber schlau machen.
Sehr gefällt mir übrigens auch die Idee des energyHarvesting, wie könnte ich dies verwirklichen ?

Zum Vergrößern anklicken....

Ich rate lediglich davon ab wenn du von der SD-Karten-Lösung noch nichts fertig hast.
Wegen energyHarvesting: Wenn du Wind messen willst, warum packst du dann nicht einfach noch nen zweites Windrad für Energieversorgung dran. Da gibt es mit Sicherheit auch fertige Lösungen die dir ne Menge Arbeit sparen.

xEsG schrieb:

Ich möchte nochmals betonen, dass all dies noch Neuland für mich ist und ich sehr wenig davon verstehe und bitte euch darum geduldig mit mir zu sein.

Zum Vergrößern anklicken....

Genau aus dem Grund solltest du keine Zeit verlieren da du sonst sehr schnell ins kurze Gras kommen wirst. Es ist besser wenn du später zum Ende Zeit übrig hast und Däumchen drehst. Wenn du aber am Anfang trödelst und dich nicht reinkniest, dann wirst du das am Ende nicht mehr aufholen können.

xEsG schrieb:

Darüberhinaus sollen FailSafe-Zusatzfunktionen integriert werden, wovon ich noch keinerlei Vorstellungen habe. Zuerst jedoch soll das Hauptprogramm in guter Modularisierung ablaufen.

Zum Vergrößern anklicken....

Da würde ich dir den eingebauten WachDog empfehlen. Der wird mit seiner kurzen Laufzeit (ich glaube maximal eine Sekunde) nicht mit einem Aufweckrhythmus von 10 Minuten zusammenspielen.

xEsG schrieb:

Den Quellcode, der bisjetzt entworfen wurde, kann ich uppen. (Wie am besten ?)

Zum Vergrößern anklicken....

Am besten das ganze Projektverzeichnis des Quellcodes zippen und mit der Büroklammer in den Beitrag packen. Dann hat man alles zusammen und andere können es ohne fehlende Dateien testen und dir Fehler aufzeigen.

C kann ich allerdings nicht Ich mache eher BASCOM und Assembler.

Gruß
Dino

ist vl bei einer Autobatterie nicht eher das problem, das durch die Selbstentladung mehr Energie flöten geht, wie man mit ner µController-Schaltung benötigt?

Die Selbstentladung macht lt. Wikipedia 2-30!!% aus.
Wahrscheinlich wäre ne Solarlösung mit Pufferakku besser.
Ein bisschen licht sollte auch in nem Wald vorhanden sein.
So gross ist der Stromverbrauch ja nicht, da würde ja ne kleine solarzelle event schon reichen,.,.

Den Mega16 hast Du selbst festgelegt, ich hab lediglich das L drangehängt...
Der 164 sagt mir nix.
Der 168 ist quasi sowas wie ein Nachfolger des Mega8. Halt nur 23 I/Os, aber doppelt so viel Flash. Dazu diverse Verbesserungen, allerdings auch einiges bei der I/O-Register-Verteilung zu beachten (allerdings eher für Assembler-Programmierer).
Wenns auf die Pins ankommt, käme als nächstes der 644er. Allerdings erheblich teurer.
Zum Strom: Siehe Bonze. Die Controller bewegen sich höchstens im einstelligen mA-Bereich - wenn sie schlafen deutlich weniger. Das Display solltest Du auch nur seltenst an haben. Ob Dein Sensor Dich was kostet, weiß ich nicht.
RTC und SD-Kram sollten eigentlich auch nicht der Rede Wert sein.
Was sind die zu efassenden Daten eigentlich genau. Also in welchem Format sollen sie gespeichert werden?
Energieharvesting: deswegen ja 'n 2tes Windrad, oder eben die Solarzelle. AFAIK gibt es zum laden von Mignonzellen aus Solarzellen vorgesehene ICs...
STK500 etc brauchst Du nicht. Du hast ja schon den Programmer vorgesehen - Als Entwicklungsumgebung sollte 'ne Lochrasterplatine reichen, oder wie habt Ihr Euch das mit der Schaltung letztendlich vorgestellt?
Wie ist das mit dem Auslesen der Daten geplant? Soll das irgendwie möglich sein, oder genügt die Speicherung auf der SD-Karte. Muß dann während des Betriebes ein Wechsel der Karte möglich sein, oder wird die Karte erst am Ende Ausgewertet?

Hallo,

xEsG schrieb:

2. fest steht denke ich, dass ich als Dateiverwaltung die SD-Kartenspeicherung mit FAT-Dateisystem nutzen kann, da das Programm schon dafür konzipiert ist oder wäre der Aufwand zu groß um auf EEPROM umzudesignen ?

Zum Vergrößern anklicken....

Wenn schon der Code für die SD-Karte existiert und funktioniert dann nimm die. Das spart wertvolle Zeit! Die Pegelanpassung benötigt nur ein weiteres IC wo du aber im Internet Lösungen für findest.

xEsG schrieb:

3. RTC um nach dem Aufwecken direkt die richtige Uhrzeit ohne Synchronisation ?

Zum Vergrößern anklicken....

Die RTC läuft ja unabhängig auf Batterie weiter. Egal ob die Schaltung grade schläft oder stromlos ist. Einfach die RTC über den I2C-Bus auslesen und du hast die aktuelle Uhrzeit.

xEsG schrieb:

4. für die Synchronisation ein DCF77-Empfänger ?

Zum Vergrößern anklicken....

Das ist dafür das du ab und zu mal die Uhrzeit automatisch stellen kannst damit du keine Ungenauigkeiten reinbekommst. Auch ein Quarz ist nicht unendlich genau.

xEsG schrieb:

5. ein HD44780 20x4 Character LCD ?

Zum Vergrößern anklicken....

Genau sowas. Versuch keine Experimente mit Grafikdisplays ! Dafür fehlt dir die Zeit. Außerdem verbraten Grafikdisplays recht viele Pins am Prozessor die du anders besser gebrauchen kannst. Nen Bargraph kann man auch auf nem Characterdisplay anzeigen lassen. Also nen schönes Display mit HD44780-Controller finden und freuen das alles läuft.

xEsG schrieb:

bezüglich 1.) Also 1. ein ATmega16L wurde empfohlen und ist zum Einsatz geplant.
"Würde ich dringend von abraten.
Warum sollte man für ein neues Projekt einen veralteten Controller auswählen? Nimm einen aktuellen aus einer der "Familien", z.b. Mega164 oder Mega168. Das hat den großen Vorteil, dass du bei Bedarf auf einen größeren der gleichen Familie wechseln kannst, bei voller Hardware-Kompatibilität. Oder gehe gleich auf Nummer sicher und nehme den größten der Familie, geht ja schließlich nur um ein Einzelstück. "

Zum Vergrößern anklicken....

Firlefanz. Der Mega32 geht auch noch gut. OK bei den neuen heißen die Register etwas anders. Aber naja ...

Nimm dir die LowPower-Version vom 644er. Der ist in 40pol-DIP (also auch für Steckboard geeignet -> Testaufbau), hat genug IOs und genug Speicher. Damit liegst du schonmal auf der sicheren Seite.

xEsG schrieb:

bezüglich 2.) energyHarvesting habe ich folgende Rückmeldung bekommen: Anemometer als Stromgenerator ausnutzen wurde mir geraten ! , was hält ihr davon ?

"Wenn das Teil nicht frei dreht, sondern einen Generator treibt, wie soll man dann noch zuverlässig und genau die Windgeschwindigkeit damit messen? Wenn du natürlich nur relativ grobe Angaben über den Wind brauchst, dann mag das gehen.
Aber davon abgesehen: Dein Zeitrahmen ist eng genug. Verschwende deine Zeit nicht mit solchen "Spielereien". Sieh zu, erst mal die Kernfunktionalität zum laufen zu bringen. Wenn dann noch Zeit ist, kannst du über "Verfeinerungen" nachdenken. "

Um das FailSafe genauso wie um das energyHarvesting sollte ich mich am Besten nachdem das Grundprogramm mit der am Ende auserwählten Hardware funktioniert kümmern oder ? Danach kann ich ja noch das System durch Add-Ons erweitern.

Zum Vergrößern anklicken....

Wenn dann sollte man schon nen zweiten extra Propeller für die Stromgewinnung einsetzen damit sich die Drehzahl nicht auch noch je nach Last (Stromverbrauch) ändert. Also einer zum messen und einer zum tanken

Das fette ist aber das wichtigste da dran !!

Gruß
Dino

Hi,

kurz zwischendurch wegen deinem Windsensor ...

"Meßumformer......Hall-Effect-Sensor mit Frequenzausgang"
Sehr schön Damit hast du keine Probleme mit Kontaktprellen. Das vereinfacht die Sache ungemein.

Ich nehme dann deinen Rat an Dino und besorge mir den ATMega 644p-20PU (ist das der sparsamere?) aber wieviele Mikrocontroller bräuchte ich für die Schaltung ?

Zum Vergrößern anklicken....

Nein. Der ATmega644V-10PU wäre die Stromsparversion im PDIP40-Gehäuse.
Bei 1,8...5,5V kann er 0-4MHz und bei 2,7...5,5V kann er maximal 10MHz Takt vertragen.
(siehe -10PU , die 10 ist der maximale CPU-Takt)

2.) 1x DCF77-Empfänger ------> je nach Empfänger noch einen Transistor als Treiber (wegen hochohmigem Ausgang)

3.) wieviele Mikrocontroller ? --> ich würde dir 2-3 empfehlen. Einer auf nem Testaufbau, einer in der Endversion und einer als Reserve?

4.) für die Mikrocontroller benötige ich doch pro Mikrocontroller eine Fassung/Sockel für die Platine oder ? ---> Testaufbau auf dem Steckbrett. In der Endversion würde ich dir ne Fassung mi Präzisionskontakten (gedrehte Kontakte) empfehlen. Die ist langzeitstabiler.

6.) 1x RTC (den DS1307 ?) --> dazu noch ein 32,768kHz Uhrenquarz und ne 3V Lithiumbatterie mit Halter (CR2024,... oder so)

8.) 1x Lochrasterplatine: reicht eine 50x100 oder größer ? --> Nimm 100x160 (Eurokarte) aus Pertinax. Die kann man leicht teilen und ist recht günstig. Ich nehme meißt welche aus Epoxid aber die sind schon etwas hartnäckiger

9.) was ist mit einem Quarzoszillator ? ---> Für den Atmel reichen normale Quarze (mit 2x 22pF Keramiks)

10.) was ist mit Spannungs- und Schaltreglern ? --> Würde ich Schaltwandler empfehlen (Stromsparend).

11.) was ist mit Schaltern ? Das Display zum Beispiel möchte ich ja nicht die ganze Zeit anhaben. --> Das LCD-Display verbraucht nicht so viel. Es läßt sich auch schlecht abschalten da du dafür ALLE Verbindungen trennen müßtest um keine Phantomspeisung und damit Defekt des Displays zu haben. Das was Saft braucht ist die Hintergrundbeleuchtung.

Gruß
Dino

Der Transistor von Punkt 2 ist irgendein NPN-Kleinsignaltransistor, oder?
ggf gleich ein paar mehr nehmen, falls der sich zum anschalten der Display-Hintergrundbeleuchtung verwenden läßt (oder ist das Backlight jetzt schon komplett gestrichen?
zu 9.: vielleicht ist bei Verwendung einer DCF77-synchronisierten RTC der interne Oszillator des Controllers hinreichend genau?
zu 10.: Schaltregler -> entweder etwas aufwändiger wegen zusätzlicher Beschaltung (Spule), oder etwas teurer...
zu 11.: Schalter, ok und vielleicht noch ein paar Kurzhubtaster, desweiteren werden sicher noch diverse Widerstände auf Dich zukommen - wir haben sowas im allgemeinen in der "Bastelkiste" rumfliegen - was habt Ihr?
Achso, Steckverbinder? Allerdings sollten die dann ordentlich gecrimpt werden - vielleicht sind Anreihklemmen (+Aderendhülsen) 'ne Alternative?
Ansonsten Pfostenleisten im Rastermaß 2,54mm. Die 2reihigen kann man auch zum kontaktieren von normalen (also nicht micro-)SD-Karten nehmen - allerdings eher nicht im Outdoor-Einsatz.

So, mehr fällt mir erstmal nicht ein.
Du solltest jetzt schon mal anfangen, 'nen Schaltplan zu erstellen und den hier zeigen. Dann sieht man auch, was noch fehlt und so... (einige arbeiten hier ganz gern mit Eagle).

LotadaC

Nachtrag: Dein SD-Card-Interface sollte eigentlich passen. Aber ob das mit Deinen C-Ansteuerroutinen läuft, können Ich (und Dino?) Dir nicht sagen. Es verwendet den SPI.

Hi,

LotadaC schrieb:

zu 9.: vielleicht ist bei Verwendung einer DCF77-synchronisierten RTC der interne Oszillator des Controllers hinreichend genau?

Zum Vergrößern anklicken....

also meiner Meinung nach braucht er keine Softclock. Er muß ja lediglich alle 10 Minuten (über Timer) einen Meßwert ermitteln und den mit einem Zeitstempel (von der RTC am I2C-Bus) abspeichern. Ab und zu wird dann das DCF77-Datagramm eingelesen und wenn es paßt (merkt man ja bei Sekunde 0) dann speichert man das einfach in die RTC und gut ist. Schon ist man synchron. Das ganze Gedöns mit Softclock und zusätzlichem Uhrenquarz am Atmel kann man sich da eigentlich sparen. Ist aber jetzt nur meine Meinung Wenn er den Meßwert nach 9Min:58Sec speichert wird die Welt auch nicht untergehen. Der Zeitstempel aus der RTC paßt ja wieder.

Gruß
Dino

meinte ich doch! Den internen Oszillator. So langsam wie möglich - so schnell wie nötig. Einen Timer zum Wecken verwenden (max Prescaler), und den Controller dann schlafen lassen. Sicher muß man den Timer noch mit einer Variable strecken. Und alle 10 min dann halt die Messung. Feintuning kann man dann mit der RTC auch noch machen, wenn der interne Takt die 10 min nicht genau genug trifft: einfach etwas früher wach bleiben, und auf die RTC warten.

Hallo,

LotadaC schrieb:

meinte ich doch! Den internen Oszillator. So langsam wie möglich - so schnell wie nötig.

Zum Vergrößern anklicken....

hast Recht Zwei Doofe ein Gedanke Mit dem internen Oszillator spart man sich sogar noch den Quarz.

Gruß und gute Nacht ...
Dino

Hallo,

xEsG schrieb:

2.)Nach persönlicher Absprache mit einem Fachmann kam außerdem das RTC-Modul zu Wort. Demnach wäre ein viel zu hoher Zeit-Drift nach monatelanger Aufzeichnung das Resultat, ich solle deshalb auf dieses Modul verzichten. Das Programm, das ich geuppt habe, also die darin enthaltende Softwareuhr, wäre genauer und somit ausreichend.

3.Desweiteren stellte sich heraus, dass der interne Oszillator des Microcontrollers nicht ausreicht und ich einen externen Quarz-Oszillator (4 MHz) benötige.
(Damit wär nicht einmal eine Daten-Kommunikation mit UART möglich, sagte man mir.)

Zum Vergrößern anklicken....

also erzähl ich mal was zu den RTCs ...

1. Ein Uhrenquarz ist um einiges genauer als ein normales Quarz das den Mikrocontoller versorgt. Darum wird eine RTC gegenüber einer Softclock die im Programm läuft immer genauer sein. Beide werden allerdings nach einiger Zeit wegdriften. Die Softclock wird aber stärker driften.

2. und damit kommen wir zum DCF77. Um den Drift (egal ob Softclock oder RTC) zu verhindern muß man ab und zu den ganzen Kram über DCF77 (oder eine andere Normalzeit) synchronisieren.

OSZI 4,000000 :: Quarzoszillator, 4,00 MHz
OSZI 4,000000
Quarzoszillator - C-Mos/TTL-kompatibel
• Frequenz: 4,000000 MHz
• Frequenztoleranz: ± 100 ppm
• Temperaturbereich: 0 bis 70 °C
• Speisespannung: 5 V
• Ausgang für 2TTL oder 10 LS-Gatter

4,0000-HC18 :: Standardquarz, Grundton, 4,0 MHz
Standardquarz im Gehäuse HC18/U.
• Frequenz: 4,0 MHz
• Modus: Grundton
• Cl: 20 pF
• Rsmax: 100 Ohm
• Temperaturkoeffizient: ± 30 ppm
• Frequenztoleranz: ± 30 ppm
• Gehäuse: HC18/U

0,032768 :: Mini Uhrenquarz, 0,032768 MHz, TC38 zB für Softclock über TOSC am Atmel oder RTC DS1307
Mini-Uhrenquarz
• Frequenz: 0,032768 MHz
• Cl: 10 pF
• Rsmax: 35 kOhm
• Temperaturkoeffizient: max. -0,04 ppm/°C²
• Frequenztoleranz: ±20 ppm
• Abmessungen (ØxL): 3,1 x 8,0 mm
• Gehäuse: TC38

RV 3029-C2 :: RTC-Modul SMD-Keramik 3,2x5x1,2mm I²C-Bus
RV 3029-C2
Real-Time-Clock SMD-Modul
Keramikgehäuse 3,2x5x1,2mm
Nennfrequenz: 32,768kHz
Versorgungsspannung: 1,2~5,5V
Frequenztoleranz: +-20ppm
Arbeitstemperatur: -40~+85°C
I²C-Bus Interface (2-wire Serial-Interface)

Wobei eine RTC folgenden Vorteil hat. Wenn dein Prozessor wegen einem Fehler ein Watchdog-Reset ausführt kann durch Auslesen der Zeit aus der RTC sofort weitergearbeitet werden. Du hast sofort wieder die eventuell um wenige Sekunden falsch gehende Zeit zur Verfügung. Wobei diese wenigen Sekunden nach der nächsten Synchronisation mit DCF77 wieder auf Null sind. Über eine Softclock hast du so lange keine Zeit bis du nach mehreren Minuten wieder über DCF77 synchronisiert hast. Bei schlechter Empfangslage kann das auch mal wesentlich länger dauern.

Also wenn es dir auf Genauigkeit ankommt ... Eine Softwareuhr über den Systemtakt (4MHz) würde ich an deiner Stelle komplett ausschließen. Dann lieber eine Softwareuhr mit einem Uhrenquarz am TOSC-Anschluß und dem Asynchronem Timer des Atmels. Die selbe Genauigkeit wie die Softwareuhr mit dem Uhrenquarz bekommst du über die RTC mit dem zusätzlichen Bonus einer Batteriegepufferten Uhr die nach einem Reset sofort wieder die aktuelle Zeit liefern kann. Bei allen Möglichkeiten wirst du wegen dem immer auftretenden Drift nicht an einer Synchronisation mit einem Zeitnormal (zB DCF77, GPS, ...) dran vorbeikommen.

Wenn du es gut machen möchtet dann würde ich für die sofort verfügbare Zeit eine Batteriegepufferte RTC einsetzen. Im Atmel läuft über einen Uhrenquarz eine Softclock die sich über DCF77 synchronisiert und nach der Synchronisation die aktuelle genaue Zeit in der RTC sichert.

Gruß
Dino

Hi,

also zu RTC, DCF77, ...
eventuell hilft es dir trotz C (war ja glaube ich so) weiter ...
DCF77 und RTC mit ATmega unter BASCOM
... manchmal findet man ja brauchbare Teile und kann sie in eine andere Sprache portieren.

Noch was zu den DCF77-Modulen. Vergiß den Puffer/Treiber nicht. Die Module haben normalerweise recht hochohmige Ausgänge bei denen das Signal zusammenbricht wenn man es mit nem normalen Atmel-Eingangspin belastet. Außerdem brauchen die neuerdnigs wohl eher 3,3V statt wie früher 5V (sieht man im Datenblatt). Den Puffer kann man mit nem kleinen MOSFET oder nem hochohmig angekoppelten npn-Transistor machen.

Hier mal der Teil aus nem Plan von mir wo die RTC am I2C-Bus angeschlossen ist.

Ich hab statt der Batterie einen GoldCap mit 0,22F genommen. Der hält etwa 1-2 Wochen problemlos ohne Strom durch und läßt die Uhr weiterlaufen.

Gruß
Dino

Noch was vergessen ...

... vorhin schnell in Eagle zusammengestrickt. Sollte (hoffentlich) funktionieren.

Gruß und gute Nacht
Dino