Den Zeitbrunnen.

In einen einfachen batteriebetriebenen kleinen Springbrunnen wird fluoreszierendes Wasser gefüllt und mit UV-LEDs zum Leuchten angeregt. Der Trick bei der Sache ist, dass die LEDs nicht dauernd leuchten, sondern stroboskopartig ein- und ausgeschaltet werden. Über einen “Tropfdetektor” wird erkannt, wann ein Tropfen herabfällt um den “Stroboskop-Timer” zurückzusetzen. Dieser sorgt dafür, dass die Beleuchtung etwa 5 mal ein- und ausschaltet, während ein Tropfen fällt. Über Taster kann die Geschwindigkeit der Pumpe beeinflusst werden und darüber auch der Effekt auf die Tropfen – so können diese etwa langsam vorwärts und sogar “rückwärts” fallen. Auch ein Stehenbleiben der Tropfen in der Luft ist möglich… achja: Auf der Seite gibt es auch ein Video dazu – sehr nett.
Ich glaube, wenn ich etwas Zeit habe, werde ich das auch mal probieren…

ISR(INT0_vect){

if (MCUCR & (1<<ISC00)){ // if rising edge…

// set to falling edge
MCUCR &= ~(1<<ISC00);
// increase counter
left_counter++;
// start_timer(left);
// turn on led
PORTC |= (1<<PC5);

} else { // if falling edge…

// set to rising edge
MCUCR |= (1<<ISC00);
// stop_timer(left);
// turn off led
PORTC &= ~(1<<PC5);

}
}

int main(void){

// …// enable external interrupts
MCUCR = (1<<ISC01)|(1<<ISC00); // rising edge of INT0 generates interrupt
GICR |= (1<<INT0); // enable external interrupt INT0

// …

}

(Sorry, für die grauselige Übersichtlichkeit, aber irgendwie mag Wordpress keinen C-Code… oder ich hab noch nicht raus, wie es geht )

In einer zusätzlichen Timerfunktion wird regelmäßig der aktuelle Zählerstand ausgelesen (, in Zukunft ausgewertet) und dann wieder auf Null gesetzt. Darüber lässt sich dann die Zahl der Umdrehungen der Räder (hier nur exemplarisch des linken) messen.
Dafür bereitet mir die Abstandsmessung mittels Ultraschall noch einige Probleme: Ich kriege zwar einen Ultraschall-Impuls gesendet, allerdings klappt es mit der Detektion noch nicht so ganz, da ich im Moment keine passenden OPs habe

In der Theorie soll es so ablaufen, dass ich einen 3ms langen Ultraschall-Impuls aussende und dann einen Timer starte. Der Timer zählt die Takte, die der Impuls braucht, um wieder detektiert zu werden. Sobald der Impuls erkannt wurde, wird der Timer gestoppt und die Entfernung berechnet:
dist = COUNTER / 2 * ULTRASONIC_SPEED * PRESCALER / OSCILLATOR_FREQ;

Sobald der Empfang dann mal funktioniert, müsste die Formel oben noch ein wenig angepasst werden, um den Fehler durch den 3ms langen Impuls herauszurechnen.
Naja, es könnte ja so leicht sein, wenn da nicht das Problem des Empfangs wäre

Dazu habe ich zuletzt einen alten, defekten DVD-Player zerlegt und dabei drei Motoren zutage gefördert: Einer hat die Schublade geöffnet, der andere den Laser bewegt und der letzte die DVD gedreht. Zwei dieser Motoren werde ich für den Antrieb des Roboters benutzen. Für den dritten ist mir bisher noch keine Verwendung eingefallen…

Bei Reichelt habe ich mir einen Ultraschallsender und -empfänger bestellt, die ich für die Entfernungsmessung benutzen möchte… ich bin mal gespannt, ob ich das hinkriege Wird bestimmt ne lustige Bastelei und Rechnerei.

Außerdem habe ich noch 6 Reflexoptokoppler bestellt. 2 davon werde ich nutzen, um zu messen, wie weit sich die Räder wirklich gedreht haben und evtl. Korrekturen an den Motordrehzahlen vornehmen zu können. Und 2 der anderen möchte ich dazu benutzen, den Boden zu kontrollieren, d.h. zu sehen, ob ein Abgrund oder eine schwarze Linie in der Nähe ist und diese(n) zu meiden. Die letzten 2 sind Reserve, falls ich Mist baue

Bisher bin ich soweit, dass ich über Pulsweitenmodulation (PWM) die Geschwindigkeit, mit der die Motoren drehen, steuern kann. Auch die prinzipielle Ansteuerung und Auswertung der Optokoppler habe ich fertig. Mal sehen, was die Verwirklichung noch so alles für Probleme aufwerfen wird.

Ich habe jetzt zusätzlich eine Überprüfung eingebaut, die testet, ob der DCF77-Empfang länger als 10 Minuten läuft und diesen dann abschaltet. Wenn nach 10 Minuten keine 2 brauchbaren Signale empfangen wurden, wird das in nächster Zeit wohl auch nix mehr. Nach 3 Stunden wird dann wieder versucht das Signal sauber zu empfangen – mit etwas Glück klappt es ja dann

Demnächst werde ich die Uhr in ihr Gehäuse einbauen. Dafür möchte ich aber erst eine Folie entwerfen, die ich dann auf die Front aufkleben kann, so dass die verschiedenen Knöpfe und Anzeigen (Alarm 1/2, DCF77-Empfang) auch beschriftet sind. Ich bin noch auf der Suche nach einer selbstklebenden, bedruckbaren Transparenzfolie. Mal sehen, ob es sowas gibt…

Als Lautsprecher benutze ich im Moment einen alten PC-Speaker. Diesen möchte ich aber noch gegen etwas kleineres tauschen, da das Ganze so nicht in das Gehäuse passen wird. Um den Lautsprecher möglichst einfach tauschen zu können, habe ich ihn nicht fest auf die Platine gelötet. Stattdessen habe ich eine kleine zweipolige Stiftleiste benutzt, an die der Lautsprecher dann angesteckt wird. Um die Lautstärke zu begrenzen, benutze ich einen 470 Ohm Widerstand. Die resultierende Lautstärke dürfte morgens eigentlich ganz in Ordnung sein.

Sobald die Uhrzeit die voreingestellte Weckzeit erreicht (und der Alarm natürlich aktiviert ist), wechselt die Uhr in einen neuen Modus (bisher gab es “Zeit anzeigen”, “Alarm 1 einstellen”, “Alarm 2 einstellen” und “Uhrzeit einstellen”), den man normalerweise nicht erreichen kann. Hier wird ganz normal die Uhrzeit angezeigt. Zusätzlich wird aber auch auf einem Ausgang ein Soundsignal erzeugt. Wird eine (beliebige) Taste gedrückt, ist der Alarm vorbei und die Uhr wechselt zurück in den “Zeit anzeigen” Modus. Der Wecker bleibt gestellt.

Um die eingestellten Weckzeiten auch über einen Stromausfall (egal welcher Art) hinweg zu behalten, werden diese nun im EEPROM des µC gespeichert. Um den EEPROM nicht unnötig zu belasten (er ist nur für etwa 100.000 Schreibvorgänge pro Speicherzelle ausgelegt), wird die Weckzeit nur gespeichert, falls sie auch wirklich geändert wurde. Sobald der µC sein Programm startet, lädt er die gespeicherten Weckzeiten aus dem EEPROM.

Das Problem, dass die Uhr plötzlich (ohne Tastendruck) den Modus wechselt, habe ich mittlerweile zusammen mit ein paar anderen lösen können: Ich habe den Anschluss für das Netzteil ausgetauscht und nochmal sauber (und stabil) verlötet. Jetzt wackelt nix mehr und die Spannungsversorgung scheint wirklich stabil zu sein. Jedenfalls springt der µC (bisher) nicht mehr durch die verschiedenen Modi und auch der DCF77-Empfang funktioniert viel besser.

Als letztes neues Feature habe ich nun noch eingebaut, dass sich die Binäruhr nach einem erfolgreichen DCF-Empfang erstmal nicht neu synchronisieren will, sondern dies nur alle 3 Stunden tut. Das sollte für eine genaue Zeitanzeige auf jeden Fall genug sein und evtl. noch ein paar Ressourcen des µC für zukünftige Features frei halten.

Ok, als letztes gibt es jetzt noch den Sourcecode und den aktualisierten Schaltplan. Achtung: Der Schaltplan ist doch etwas unübersichtlich geworden – ich hoffe, man kann noch alles erkennen. Evtl. werde ich demnächst noch eine etwas aufgeräumtere Version online stellen.

[Klick für größere Version]

Ich habe jetzt damit begonnen, ein paar Weckerfunktionen zu implementieren. Dafür habe ich der Uhr einen Taster zum Wechsel zwischen den verschiedenen Modi und noch zwei zusätzliche (rote) LEDs spendiert, die den Alarmstatus (ja, genau: zwei LEDs = zwei Weckzeiten) anzeigen: Leuchtet die erste rote LED, ist Alarm 1 aktiviert. Blinkt diese, stellt man gerade die erste Weckzeit ein. Wenn sie langsamer blinkt, ist der Alarm aktiv. Genauso funktioniert die zweite LED. Blinken beide LEDs, kann man die Uhrzeit ändern. Dafür habe ich einen eigenen Modus gewählt, damit im “normalen” Modus die Zeit nicht verstellt wird und die beiden anderen Taster zum Aktivieren der beiden Alarme genutzt werden können.

Momentan verhält sich die Uhr etwas merkwürdig: Sie springt ab und zu unmotiviert von einem Modus in den nächsten ohne dass eine Taste gedrückt worden wäre. Merkwürdig… ich muss wohl nochmal auf die Suche nach einem Kurzschluss oder Wackelkontakt gehen.

Außerdem habe ich einen 12 Ohm Serienwiderstand, der den Strom für alle LEDs begrenzt hat, gegen einen Transistor getauscht. Dieser wird über einen Fotowiderstand gesteuert, um die LEDs bei Dunkelheit etwas zu dimmen, damit bei Nacht nicht das ganze Zimmer beleuchtet wird

Den aktualisierten Schaltplan dazu gibt es demnächst, wenn alles so klappt, wie es soll…

Ich habe auch mal mit der Sounderzeugung mit Hilfe des AVR experimentiert: Wieder über einen Transistor habe ich einen Lautsprecher angeschlossen. Der Transistor wird diesmal von einem Port des AVR gesteuert, der mit einer bestimmten Frequenz ein- und ausgeschaltet wird. Im Moment benutze ich eine Überlagerung von 1000 und 440Hz. Dadurch entsteht ein Geräusch, das einen bestimmt wach kriegt, aber auch nicht zu fies klingt.

Ich habe den Lautsprecher noch nicht an die Binäruhr angeschlossen, da ich erst einmal das Problem der springenden Modi lösen möchte, bevor ich die nächste Baustelle anfange. Außerdem weiß ich auch noch nicht genau, wie ich die Sounderzeugung sinnvoll in den Code der Uhr einfüge, aber das wird sich schon noch lösen lassen… auf jeden Fall gibt es deswegen aber auch keinen neuen Code für euch.
Ach ja: Ich kann nur empfehlen, das DCF-Modul mit der Antenne auf einen starren Streifen Pappe zu kleben. Seitdem ich das gemacht habe, habe ich viel weniger Probleme damit.

Aber bis es soweit war, gab es noch einige Probleme:

• Die Spannung war für das Funkmodul nicht stabil genug und musste stabilisiert werden.
• Das dürftige “Handbuch” des Funkmoduls musste verstanden werden
• und zu guter Letzt ist natürlich auch noch die Antenne des Modules abgerissen, so dass ich sie auch erstmal wieder anlöten musste

In dem Handbuch zum Funkmodul wird – in Worten – erklärt, wie das Modul zu beschalten ist. Leider ist ein nicht ganz unwichtiger Punkt aber etwas schwammig formuliert: Das Modul lässt sich anscheinend in eine Art Schlafmodus versetzen. Dazu muss einer der vier Anschlüsse auf hohes Potential gelegt werden. Zum Einschalten soll er auf GND liegen. Soweit die Theorie. In der Praxis hat sich jetzt gezeigt, dass dieser Anschluss wohl intern bereits auf GND liegt und eine externe Beschaltung Probleme bereitet. Jedenfalls habe ich diesen Anschluss jetzt unbeschaltet gelassen und so scheint es zu funktionieren. Die anderen Anschlüsse sind +5V, GND und DCF. An DCF liegt das (invertierte) Signal an, das das Modul empfängt.

Normalerweise besteht das DCF77-Signal aus einem High-Pegel, der zu Beginn jeder Sekunde auf 25% der Leistung abgesenkt wird. 100ms für eine logische 0 und 200ms für eine logische 1. (Weitere Details gibt es hier.) Die Inversion bewirkt jetzt, dass das Signal an DCF grundsätzlich auf niedrigem Potential liegt und zu Beginn jeder Sekunde für 100 bzw. 200ms auf +5V gezogen wird.

Für einen “sauberen” Betrieb des Funkmoduls wird eine Spannung zwischen 1,2 und 5V benötigt, die im Betrieb allerdings um weniger als 0,1V schwanken darf. Bisher konnte ich meine Schaltungen einfach mit einem 5V Netzteil betreiben ohne Probleme zu kriegen. Aber für das Modul schien das nicht mehr zu reichen, so dass ich einen 7805-Baustein zusammen mit 3 Kondensatoren (2×100nF KerKo, 1×10µF ELKO) einbauen musste. Dieser erzeugt nun aus 7V Eingangsspannung eine stabilisierte Spannung von 5V, die auch dem mäkeligen Funkmodul genügt.

Bei dem nun folgenden häufigen Programmieren und damit verbundenem Bewegen der Schaltung, habe ich wohl die Antenne etwas zu viel und falsch bewegt, so dass sie sich schließlich vom Funkmodul gelöst hat. Mit etwas Arbeit ließ sie sich aber wieder anlöten, was sich aber schon recht schwierig gestaltet hat, da die dünnen Anschlusskabel die Wärme des Lötzinns nicht richtig ableiten konnten und so der Zinn nicht abkühlen konnte um zu erstarren… naja, schließlich und endlich hat es aber geklappt.

Den Code für die Auswertung des DCF-Signals habe ich von dieser Seite teilweise übernommen und angepasst. Meinen Code gibt’s dann auch hier. Die Funktionalität wurde nur um die DCF77-Routinen erweitert.

Auch das neue Schaltbild gibt es natürlich:

Hier sind auch alle Neuerungen eingetragen. Ich musste die Anschlüsse für die Stundenanzeige verändern, da ich den Pin für den externen Interrupt vorher belegt hatte.

Für die Zukunft steht jetzt noch ein Summer/Lautsprecher an, mit dem dann eine Weckfunktionalität hinzukommen kann. Ich werde mal ein wenig experimentieren, was sich da so machen lässt. Ein Gehäuse habe ich mittlerweile auch, allerdings werde ich die Uhr vorerst da noch nicht einbauen.

Im Moment scheint der Anschluss des DCF-Moduls einen Wackelkontakt zu haben, denn ab und zu empfängt die Uhr die aktuelle Zeit nicht Eventuell befestige ich das Modul und die Antenne noch auf einem starren Stückchen Pappe oder so um zusätzliche Bewegung und somit Belastung für die eh schon schlechte Verbindung zu vermeiden…

Eine Sekunde ist definitionsgemäß das 9.192.631.770-fache der Periode einer Mikrowelle, die mit einem ausgewählten Niveauübergang im Caesiumatom in Resonanz ist. Anders gesagt: das 9.192.631.770-fache der Periodendauer der dem Übergang zwischen den beiden Hyperfeinstrukturniveaus des Grundzustandes von Atomen des Nuklids ¹³³Cs entsprechenden Strahlung.
http://de.wikipedia.org/wiki/Sekunde

Von all dem weiß der AVR aber nichts. Gemäß seinem internen Takt von 1MHz besteht eine Sekunde aus einer Millionen Takte. Da der interne Takt aber recht ungenau ist, ist auch eine Sekunde für den AVR nicht so genau definiert. Möchte man den AVR aber z.B. als Uhr benutzen, ist das sehr unpraktisch. Abhilfe muss also her.

Deswegen wollte ich – schon bevor ich die falschen Fuse-Bits gesetzt habe – einen externen Quarz-Kristall mit dem AVR verbinden, um ein stabiles Taktsignal zu haben. Da ich in dem Datenblatt etwas über einen externen 32.768kHz Kristall gelesen hatte, für den der AVR ausgelegt sei, hatte ich diesen zuerst versehentlich für einen Ersatz zum internen Taktgeber gehalten. Daher auch der Artikel “Fuse-Bits sind böse…“.

Nachdem ich diesen Fehler wieder hingebogen habe, habe ich den externen Kristall mit den korrekten Eingängen TOSC1 und TOSC2 verbunden. Nachdem ich dann noch den zweiten Timer so eingestellt habe, dass er den externen Resonator auch verwendet, hatte ich plötzlich ein recht stabiles Signal von 32.768kHz zur Verfügung.

Auch wenn diese Zahl auf den ersten Blick recht unhandlich aussieht, fällt auf, dass sie sich prima durch z.B. 1024 teilen lässt – eine Zahl, die der AVR auch mag Also benutze ich einen Vorteiler von 1024 und löse alle 32768/1024 = 32 Takte einen Interrupt aus – also genau 1 Mal pro Sekunde.

Dieser Takt ist bedeutend genauer als der Takt des AVR. Mit diesem hatte ich innerhalb von 24 Stunden einen Fehler von mehr als 5 Minuten. Mit dem Uhrenquarz hatte ich in 12 Stunden einen Fehler kleiner als eine Sekunde. Wenn das mal kein Unterschied ist

Hier noch einige ausgewählte Code-Schnipsel, die das eben gesagte verdeutlichen sollen:

void main(){
//…
ASSR |= 1< TCCR2 = (1<<<
TIMSK |= 1<
//...
}
SIGNAL (SIG_OVERFLOW2){
TCNT0 = -32; // 1s: Prescaler 1024, resonator freq. 32.768kHz
// ...
}

Der Rest des Codes sollte eigentlich recht unverändert geblieben sein. Ich stelle ihn trotzdem mal zum Download, damit ihr einen Gesamteindruck kriegt

Mein nächster Plan ist jetzt, den AVR noch mit einem Funkmodul auszustatten, über das er sich die aktuelle Atomzeit besorgen kann, um auch den kleinen Gangunterschied des Quarzes zu korrigieren…

Dafür habe ich mir bei Reichelt einen 500kHz Keramik-Oszillator und zwei 22pF-Keramik-Kondensatoren bestellt. Entsprechend dem Diagramm im Datenblatt habe ich die Bauteile an den AVR angeschlossen. Dann habe ich ihn über den ISP-Port mit dem PC verbunden und die Standard-Einstellungen der Fuse-Bits wieder hergestellt.

Jetzt läuft er wieder mit einem MHz internem Takt und rechnet fröhlich vor sich hin

Um den AVR auf einen externen Oszillator einzustellen, muss man die Fuse-Bits entsprechend setzen. Sollte an sich ja nicht so schwer sein. Das Problem ist nur, wenn man die Bits falsch setzt – z.B. auf einen anderen Oszillator als man besitzt – tut der AVR danach nix mehr

Mein Problem ist, dass ich die Fuse-Bits so gesetzt habe, dass der AVR einen externen Quarzkristall mit einer Frequenz zwischen 0,4 und 0,9MHz akzeptiert. 0,032768MHz sind da allerdings etwas zu wenig für… und so habe ich im Moment einen toten Mikrocontroller, da auch zum Ändern der Fuse-Bits ein Taktsignal benötigt wird.

Aber demnächst besorge ich mir einen passenden Oszillator und dann geht es weiter