Liste der Anhänge anzeigen (Anzahl: 2)
Propelleruhr und Ansteuerung über RaspPi
Hallo!
Im Folgenden werde ich meine Propelleruhr vorstellen. Benutzt wurde die Propelleruhrplatine von Roboternetz. Lieben Dank an Hicki, der mich unterstützt hat wo er konnte :). À propos: Hicki hat ein paar Platinen nachbauen lassen und hat noch ein paar Stück übrig, falls Ihr also Interesse habt, so seht einfach in diesem Faden vorbei: https://www.roboternetz.de/community...ropeller-Clock
Zur Story: Ich will ein hübsches Mädel, in das ich verknallt bin, zum Essen ausführen. Ich will sie jedoch auf besondere Weise fragen. Über die Propelleruhr :-)
Die Idee ist, dass man beliebige Texte auf dem Propeller ausgeben kann, und dass dann mein Objekt der Begierde über Bedienknöpfe auf bestimmte Fragen mit "Ja" oder "Nein" antworten kann. Fürderhin soll das Ding nach Überbringen der Nachricht nicht nutzlos herumstehen, sondern einen Zweck erfüllen können. Ich dachte mir eine Uhr mit Alarmfunktion wäre ganz schön.
Die ursprüngliche Wunschliste:
- Die Uhr soll beliebige Zeichenketten auf dem Propellerdisplay ausgeben können, frei konfigurierbar zur Laufzeit.
- Die Uhr soll Töne ausgeben können.
- Bedienknöpfe für Konfiguration der Uhr
- DCF77 Empfänger
- Datenübertragung auf Propeller
- Raspberry Pi mit Netzwerkinterface. Ich wollte schon immer root auf meiner Uhr sein :-)
Offensichtlich lassen sich die meisten dieser gewünschten Features nicht mit der Roboternetz Platine alleine realisieren, es muss also ein statisches System her, das Daten auf die Platine zu übertragen vermag.
Einige werden sich vielleicht denken, dass ein Raspberry Pi mit Kanonen auf Spatzen geschossen ist, aber da dieses Projekt anfangs unter extremem Zeitdruck entstand, war das eine sehr einfache Möglichkeit viele Features gleichzeitig zu erschlagen. Ein Raspberry Pi hat einen GPIO pin header, über den man die DCF77 Empfängerhardware und die Bedienknöpfe leicht anschließen kann. Außerdem hat der Raspberry Pi einen analogen Audio output, ich kann also beliebige Sounds abspielen. Außerdem hat das Linux Betriebssystem bereits eine funktionierende Zeitverwaltung, und es existiert bereits Software für die Verarbeitung von DCF77 Signalen.
Hier ein Bild vom Grundsystem:
Bild hier
Bild hier
1. Sound
Der Raspberry Pi hat zwar analog audio out, allerdings ist dieser äußerst schwachbrüstig und ist nicht zum Treiben von schweren Lasten geeignet. Ich habe irgendeinen 08/15 Audio Operationsverstärker genommen der in der Lage ist 500mW auf einen Kleinlautsprecher zu übertragen. Reicht für unsere Zwecke, wir wollen nur einen Aufweckpiepton. Viel mehr gibt es eigentlich nicht zu sagen zu dem Thema. Im Bild kann man den Achtbeiner auf der Lochrasterplatine sehen.
2. DCF77 Empfänger
Dieses Thema ist schon etwas schwieriger. Es gibt bereits fertige Empfangsmodule, ich habe das von Conrad gewählt, weil es in meiner lokalen Conrad Filiale schnell und einfach abzuholen war: http://www.conrad.de/ce/de/product/6...omSuggest=true
Wie bereits erwähnt besitzt der Raspberry Pi einen frei programmieren GPIO Pin Header. An diesen lässt sich die Empfängerplatine relativ problemlos anschließen. Das einzige Problem stellt hier die Softwareseite dar.
Die Verarbeitung von DCF77-Zeitsignalen wurde schon mehrfach implementiert, ich habe mich für die radioclkd2 Software entschieden. Dieser Daemon ist für PCs ausgelegt, üblicherweise werden die DCF-Pulse auf die Steuerleitungen einer RS232 Schnittstelle gegeben, die ein Hardware Interrupt auslösen können, so dass eine recht genaue Bestimmung der Pulslängen möglich ist. Wenn eine gültige Zeit empfangen worden ist, so wird das Ergebnis an einen lokalen NTP-Zeitserver weitergereicht, der die Systemuhr entsprechend stellt.
Leider ist die Software für eine RS232 Schnittstelle ausgelegt, nicht für den Raspberry Pi. Glücklicherweise ist der Code zum Öffnen des seriellen Interfaces recht gut gekapselt, so dass ich meinen eigenen Code einfügen konnte. Ich habe hierfür die WiringPi Software benutzt, die den Zugriff auf den GPIO Header abstrahiert. Im Anhang befindet sich ein Patch, mit dem der radioclkd2 Sourcecode für den Raspberry Pi umgemodelt werden kann.
Nachdem man das "configure" von radioclkd2 ausgeführt hat, muss man aber noch in der Makefile die Zeile:
radioclkd2_LDADD = -lm
wie folgt modifizieren:
radioclkd2_LDADD = -lm -lwiringPi
Als Parameter gibt man beim Start von radioclkd2 die WiringPi ID von dem Pin auf dem GPIO header an, an dem das DCF Signal anliegt. Der Pin ist als hochohmiger Input konfiguriert, das lässt sich aber mit einer kleinen Änderung an folgender Zeile in serial.c leicht ändern:
pullUpDnControl(pinNum, PUD_OFF);
Die Software ist außerdem so modifiziert, dass sie die Datei /var/run/clock/decfail erzeugt wenn ein ungültiger Zeitpuls empfangen wurde, und diese wieder löscht wenn ein gültiger Zeitpuls empfangen wurde. So kann der radioclkd2 nach außen signalisieren, ob die Antenne korrekt ausgerichtet ist.
Leider funktioniert in meiner finalen Version der DCF77 Empfangsteil aber nicht, da im fertigen Gehäuse zu viel Metall in der Nähe der Ferritantenne ist. Entweder das, oder sie ist mir kaputt gegangen als ein Äderchen zur Antenne abriss, und ich es wieder rangelötet habe. Es ist mir auf jeden Fall zu viel Mühe das fertige Gerät wieder aufzuschrauben, es lässt sich vom Design her jetzt auch nur noch schlecht ändern. Ich hätte es gerne zusammen mit dem Übertrager im Betrieb getestet, aber es funktioniert leider auch mit ausgeschaltetem Übertrager nicht mehr.
3. Stromübertragung
Ein großes Thema ist natürlich wie man den Strom auf den rotierenden Teil bekommt. Wie schon vorher angedeutet benutze ich hier einen Übertrager. Wie dieser zu dimensionieren ist, steht in der Propelleruhr-PDF von Roboternetz.
Hier ein Bild von der Sekundärspule, aufgebracht auf die Nabe eines PC-Gehäuselüfters.
Die Spulenkörper waren etwas größer als die Nabe des Lüfters, um ihn mechanisch zu befestigen habe ich vier kleine Blöcke aus Plexiglas geschliffen, diese von vier Seiten auf die Nabe aufgeklebt, und dann den Spulenkörper mit vier Schräubchen befestigt, die in besagte Blöcke getrieben werden. Das hat den Vorteil, dass der Spulenkörper jederzeit wieder abgelöst werden kann, und innerhalb einer gewissen Toleranz der Schwerpunkt der gesamten Anordnung (Platine + Spulenkörper) genau ausgerichtet werden kann, so dass nicht zu große Unwuchten entstehen.
Um die Spule mit Strom zu beschicken habe ich einen L298 H-Brückentreiber gewählt. Er hat vier Ausgänge, von denen sich jeweils zwei parallel schalten lassen, so dass laut Datenblatt Ströme bis zu 4A möglich sind. Mehr als genug für unsere Zwecke. Für die Ansteuerung des L298 ist der Raspberry Pi leider nicht geeignet, Linux ist schließlich kein Echtzeitbetriebssystem. Deshalb übernimmt ein ATTiny2313 die Ansteuerung, aber dazu gleich mehr.
4. Datenübertragung
Das gesamte Nutzerinterface soll natürlich auf dem Raspberry Pi laufen. Der Propeller selbst ist in meinem Konzept "dumm". Er hat eine Anzeige von 4 Zeilen à 16 Zeichen, die anzuzeigenden Zeichenketten werden in einem Front- und Backbuffer abgelegt. Während die Datenübertragung in den Backbuffer stattfindet, wird einfach der Text im Frontbuffer ausgegeben.
Die Datenübertragung findet bei mir über den Übertrager statt. Dankenswerterweise hat der Designer der Propellerplatine eine Halbwelle der Versorgungsspannung auf einen Interrupt Capture Eingang des ATMegas gelegt. Die Daten werden durch Veränderung der Periodendauer übertragen. Den Übertrager steuere ich standardmäßig mit 6756Hz an (möglichst so, dass keine Oberschwingungen bei 77,5 kHz 'DCF77' entstehen), was Pulse mit 148µs Länge sind. Kodiert wird eine logische '1' dann mit einer Pulslänge von 122µs, logisch '0' 96µs. In meinen Experimenten hatte ich sogar einmal 256 verschiedene Pulslängen erfolgreich getestet, konnte also mit einem Puls ein ganzes Zeichen übertragen! Habe mich dann aber dagegen entschieden, da eine Bitrate von 7kBit/s für meine Zwecke mehr als ausreicht, und wesentlich robuster ist.
Der ATTiny2313 wird über RS232 Schnittstelle angesprochen. Der Raspberry Pi schiebt Bytes in den ATTiny2313, und dieser schickt diese Bytes ohne Umschweife weiter über den Übertrager. Ausgenommen davon sind ein paar Steuerbytes an den ATTiny2313 selbst, nämlich "Stromversorgung Propellerplatine an", "Stromversorgung Propellerplatine + Lüftermotor an" sowie "alles aus".
Ich habe sämtliche Software für die Mikroprozessoren in C geschrieben. Da ich aus der Linuxwelt komme und dort schon viel mit C programmiert habe, habe ich mich bei avr-gcc und der avr-libc sofort heimisch gefühlt. Hier ist der Code für den ATTiny2313:
Anhang 25648
5. Ansteuerung Propellerplatine
Ich habe die Möglichkeiten der Propellerplatine bei weitem nicht ausgenutzt. Vor allem habe ich den ATMega644 internen, Hardware TWI-Bus genutzt. Dadurch hatte ich genug Zeit für die Datenübertragung. Es ist nicht spektakuläres, falls jemand daran interessiert ist, werde ich das mal zusammenpacken und auch hier hochladen.
Bild hier
Das neu hinzugekommende Bauteil ganz unten am Bildrand ist ein n-Kanal Mosfet, über den nachher der Lüftermotor an- und ausgeschaltet wird.
Bild hier
Ich bin per ssh auf dem Raspberry Pi eingeloggt, und kann beliebige Zeichenketten ausgeben lassen
6. Gehäuse
Jetzt muss die ganze Steuerelektronik natürlich noch in einen präsentableren Zustand gebracht werden. Ich habe bei Conrad ein einfaches Plastikgehäuse gekauft, zwei Plexiglasplatten angebracht, den Lüfter auf die Rückwand aufgesetzt, die Bedienknöpfe ins Gehäuse eingelassen und am Raspberry Pi an den GPIO-Header angeschlossen. Das fertige Produkt sieht schließlich so aus:
Bild hier
Bild hier
Es sind zwei Lüftungsschlitze mit dem Dremel - zugegebenermaßen etwas hässlich - eingearbeitet. Habe leider keinen Schaltregler auf die Schnelle bekommen und stattdessen Linearregler benutzt, die etwas warm werden. Naja. Hauptsache es tut.
Bild hier
Ansicht von hinten
7. Romance
Bild hier
Und wenn sie "nein" sagt:
Bild hier
8. Normalbetrieb
Bild hier
Bild hier
Die Uhr wird - wegen des dysfunktionalen DCF-Empfängers jetzt über die Bedienknöpfe gestellt. Bin nicht ganz glücklich, aber beim nächsten Versuch wird es sicher klappen mit der Empfängerplatine :-)
Liste der Anhänge anzeigen (Anzahl: 2)
Ich habe den Aufbau nun mal getätigt. Zur Energieübertragung nehme ich eine Spule mit ca 4cm Durchmesser und 0,8mm Cu Lackdraht. Das funktioniert eigentlich gut. Die Spule wird über einen LN298 Treiberstein betrieben mit rund 10 kHz - gibt es mittlerweile für wenig Geld. Auf der Eingangsseite ist das Signal sehr sauber, allerdings kommt auf der Ausgangsseite an R13 nur ein ziemlich "verschmiertes" und teils verschobenes Signal an. Das hat aus meiner Sicht zur Folge, dass eine Datenübertragung einfach nur mit dem Variieren der Frequenz sehr schwierig sein wird. Ich bin mir nun nicht sicher, ob das eigentliche Problem die Phasenverschiebung ist. Wie sah das Signal denn bei Euch aus? Oder wie habt Ihr das Problem gelöst?
Anbei noch zwei Bilder, wie das auf dem Oscilloskop aussieht.
Vielen Dank und Grüsse,
Manfred
Liste der Anhänge anzeigen (Anzahl: 1)
Nun ja - ich muss gestehen, dass meine Kenntnisse bezüglich Oszilloskop nicht so wahnsinnig gross sind - ich hoffe halt mal, dass das einigermassen korrekt eingestellt ist. Wenn ich die Position auf eine Achse verschiebe, dann kann ich das Überschneiden nicht mehr sehen. Der L298 wird über einen Mega328P mit 16MHz getacktet. Der sollte das schon hinbekommen. Allerdings hat wohl der verwendete L298 einen Schuss. Ich habe den mal getauscht und nun sieht es sekundär am R13/ICP1 so aus:Anhang 35962
Ich hoffe mal, dass ich damit das Signal besser auswerten kann...
Viele Grüsse,
Manfred
