Propelleruhr und Ansteuerung über RaspPi

[quinze]

Hallo!

Im Folgenden werde ich meine Propelleruhr vorstellen. Benutzt wurde die Propelleruhrplatine (http://www.robotikhardware.de/download/rn_propellerclock_1.11.pdf) 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/threads/58703-Suche-Platine-f%C3%BCr-Propeller-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:
http://thilo.tjps.eu/pclock/images/pc11.jpg
http://thilo.tjps.eu/pclock/images/pc10.jpg


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/641138/C-Control-DCF-Empfaengerplatine?queryFromSuggest=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 (http://www.jonatkins.com/page/software/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 (http://wiringpi.com/) 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 (http://thilo.tjps.eu/pclock/images/pc12.jpg) 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:
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.

http://thilo.tjps.eu/pclock/images/pc8.jpg
Das neu hinzugekommende Bauteil ganz unten am Bildrand ist ein n-Kanal Mosfet, über den nachher der Lüftermotor an- und ausgeschaltet wird.

http://thilo.tjps.eu/pclock/images/pc9.jpg
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:

http://thilo.tjps.eu/pclock/images/pc7.jpg
http://thilo.tjps.eu/pclock/images/pc6.jpg
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.

http://thilo.tjps.eu/pclock/images/pc5.jpg
Ansicht von hinten

7. Romance


http://thilo.tjps.eu/pclock/images/pc1.jpg
Und wenn sie "nein" sagt:
http://thilo.tjps.eu/pclock/images/pc2.jpg


8. Normalbetrieb


http://thilo.tjps.eu/pclock/images/pc3.jpg
http://thilo.tjps.eu/pclock/images/pc4.jpg

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 :-)

[Croal]

Wow , nettes Teil was du da gebaut hast. Ich verstehe nicht wie der Propeller die Buchstaben darstellt. Hab sowas bis jetzt noch nicht gesehen, und ist die Idee von dir ? Und hast du die kleine schon klar gemacht? ;-)

[quinze]

Wow , nettes Teil was du da gebaut hast.

Danke!



Ich verstehe nicht wie der Propeller die Buchstaben darstellt. Hab sowas bis jetzt noch nicht gesehen,


Auf dem Bild mit dem stehenden Propeller siehst Du eine Reihe von Leuchtdioden. Wenn sich der Propeller dreht, werden diese genau zu den richtigen Zeitpunkten geschaltet, so dass an den entsprechenden Stellen eine Lichtquelle steht.


und ist die Idee von dir?

Die Propelleruhr selbst sicherlich nicht - da war ja mit der Platine von roboternetz.de ziemlich viel Arbeit schon gemacht.
Das mit den Knöpfen und der interaktiven Textausgabe war meine Idee.


Und hast du die kleine schon klar gemacht? ;-)

Noch nicht. Ist etwas kompliziert alles. Ich zier mich etwas -.-

[quinze]

Es sieht wohl leider nach einem Korb aus :cry:

[hans99]

Naja, macht ja nichts! Kopf hoch!!

Andere Mütter haben auch schöne Töchter.;)

Und bedenke, was Dir in etwa möglicherweise erspart geblieben ist.

Wenn Du eine neue Flamme hast, und ernsthaft dran bist, dann wirf auch ein Auge auf deine zukünftige Schwiegermutter.

Deine neue Flamme wird in zig Jahren in etwa genau so aussehen. -> Ob dir das dann noch gefällt?


P.S. Schöne Uhr. Du kannst sie ja öfters verwenden.

[mws-h]

Und Du hast jetzt jede menge Zeit den Code schön zu machen und zu veröffentlichen ;)

[quinze]

Naja, macht ja nichts! Kopf hoch!!
Andere Mütter haben auch schöne Töchter.;)

Danke für die aufbauenden Worte ;-)


P.S. Schöne Uhr. Du kannst sie ja öfters verwenden.

Dat könnt ich nicht. Hab sie ja in gewisser Weise für sie gebaut. :-)
Außerdem hab ich sie gefragt ob sie sie behalten will und noch hat sie sie nicht zurückgehen lassen.


Und Du hast jetzt jede menge Zeit den Code schön zu machen und zu veröffentlichen ;)

Und das tue ich hiermit!
*click* (http://thilo.tjps.eu/pclock/pclock.zip)

Es ist jetzt der komplette Code dabei. Für den ATMega auf dem Propeller (unter leddriver), den AT2313 für die Ansteuerung des Übertragers (pcdriver), und die Software die auf dem Raspberry pi läuft
Habe ein paar persönlich identifizierbare Merkmale rauseditiert. Ansonsten ist alles wie im Original.
Die AVR Geschichten müssen übrigens mit der AVR-GCC / avr-libc kompiliert werden. Die Software für den Raspberry Pi am besten auf dem Pi selbst oder mit irgendnem Cross-Compiler.
Viel Spaß beim Nachbau!

[HannoHupmann]

Nicht gleich aufgeben, bei deiner Uhr wird sicher auch nicht alles gleich auf Anhieb geklappt haben. Rückschläge gehören nun mal dazu und die gibt es nicht nur in der Technik, auch bei den Damen muss man dran bleiben, genauso wie bei seinen Projekten!

[wofei]

Vielen Dank für deinen Code. Ich bin grad dabei die Stromversorgung zu lösen :-)
fg
Wolfgang

[quinze]

Aufgrund einer Anfrage in den Privatnachrichten:
Die Links auf die Bilder und auf den Quelltext waren tot. Ich habe die Links oben korrigiert, so dass Bilder und Quelltext wieder da sein müssten.

[ManfredR]

Ich war die private Anfrage :) Vielen Herzlichen Dank dafür, dass Du den Artikel nach all den Jahren aktualisiert hast :)
Darf ich noch fragen, wie die Romanze ausgegangen ist - seid Ihr mittlerweile verheiratet? Das wäre ja das Mindeste bei so einem tollen Antrag für ein Date!

[quinze]

seid Ihr mittlerweile verheiratet? Das wäre ja das Mindeste bei so einem tollen Antrag für ein Date!
Hihi! Wie schon oben geschrieben: es wurde ein Korb. Ein weiser Mann hat allerdings in diesem Faden hier bereits gesagt, dass auch andere Mütter schöne Töchter haben. So ist es jetzt gekommen :-)

[oberallgeier]

.. Ein weiser Mann hat .. gesagt, dass auch andere Mütter schöne Töchter haben ..Herrjeeee, jaaaa. Das ist ja schön und Jammer zugleich ;-)

[ManfredR]

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

[quinze]

1. Mir scheint auch schon das primärseitige Bild links genauso unsauber zu sein, wie Dein sekundärseitiges Bild rechts. Wenn das wirklich konstant 10 kHz wären, dann dürften sich die oberen und unteren Halbwellen nämlich nicht überschneiden. Das tun sie aber. Es sieht halt nicht ganz so hässlich aus, weil primärseitig pro Halbwelle jeweils eine konstante Spannung anliegt. Ich vermute mal, die Geschichte würde primärseitig ähnlich wie rechts aussehen, wenn Du statt der Spannung über einen (kleinen!) Serienwiederstand den Strom messen würdest.
- Oszilloskop richtig eingestellt?
- Läuft der IC, der den L298 ansteuert zu langsam, und jittert aufgrund verletzter Echtzeitbedingungen herum wie bolle?

2. Ich erinnere mich nicht mehr, wie schön das Signal bei mir war. Aber es hat definitiv nicht so rumgewackelt wie bei Dir. Schön zu sehen bei Dir ist auch, dass bei der steigenden Welle der Spannungsregler anfängt zu arbeiten, was die sekundärseitige Spannung kúrz einbrechen lässt. Das ist aber für die Datenübetragung kein Problem, solange der Einbruch nicht größer als die Hysterese des Schmitt-Triggers ist. Mein Programm guckt außerdem auf die fallende Flanke, und nicht auf die steigende, was ebenfalls etwas mehr Stabilität reinbringt.

[ManfredR]

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:35962
Ich hoffe mal, dass ich damit das Signal besser auswerten kann...

Viele Grüsse,
Manfred

[quinze]

Okay, na das sieht doch schon viel besser aus! Das passt auch für die Datenübertragung.

Bei mir war übrigens der IC, für die Auswertung der Daten, nicht bestückt. Wenn man die I²C Hardware (Atmel-Speak ist "TWI") des ATMegas nutzt, kann der problemlos die LEDs gleichzeitig ansteuern.

[ManfredR]

Ja, es gibt nix schlimmeres als ein noch halb funktionierendes Bauteil :(
Aber ja, ich bin nun zuversichtlich. Ein kleines Counterprogramm liefert sehr stabile Zeitwerte, somit sollten die paar Nullen und Einsen leicht zu übertragen sein :)
Den Mega168 habe ich auch drauf, mal schauen, wie ich das mit der Datenauswertung umsetze. Die LED - Steuerung läuft, bisher halt nur mit statischen Texten.
Ich hatte auch deine Routine einmal aufgespielt, allerdings werden da nur die zwei mittigen Kontroll-LED's angesteuert. So wie ich es gesehen hatte sollte ja bei Dir kurz nach dem Einschalten eben diese beiden aufleuchten und kurz darauf sollten die blauen LED's für 2 Sekunden aktiviert werden, tun sie aber nicht. Muss mich da mal noch in die TLC-Steuerung etwas einlesen, hatte nur gesehen, dass Du da scheinbar die Daten über die Broadcast-Adresse an die TLC's überträgst und vermtulich dann durch das automatische incrementieren der Register die einzelnen LED's ansteuerst.
So, nu muss ich mich aber erst mal für die Silvesterparty fertig machen.

[ManfredR]

Nun schaut es gut aus :) Die Steuerung lief schon einige Zeit ganz ordentlich mit allen LED's. Allerdings brach die I2C Verbindung immer ab, wenn ich mit 1000kHz takten wollte. Die Lösung hierfür war der Austausch der bei beiden 10KOhm Pullup Widerstände (R7 und R8, SDA, SCL) durch 1,5KOhm. Nun kann ich bei 1080 rpm (18 Umdrehungen pro Sekunde) 96 Zeichen in drei Ebenen darstellen und dazu noch eine Analoguhr ganz innen. Vermutlich gingen nun auch noch mehr rpm, der aktuelle Motor gibt aber nicht mehr her. Der I2C Bus lässt sich nun mit 1000kHz (TWBR=2) betreiben.
Die Idee mit dem Hintergrundpuffer von quinze ist sehr gut, die einzelnen Spalten werden nun in der "freien" Zeit vorberechnet und dann beim erreichen der nächsten Spalte dargestellt.
Für die Ansteuerung der Spule, des Motors und der Datenübertragung kommt ein ESP32 zum Einsatz. Auf dem läuft auch ein Webserver, über den man die Motorgeschwindigkeit und die darzustellenden Texte eingeben kann. Die Uhrzeit wird über WLAN empfangen und an die Propellerclock gesendet beim Start, intern läuft dort dann eine Uhr mit. Der Mega168 läuft arbeitslos einfach mit, alles ist auf dem 644er implementiert. Somit läuft das ganze nun autark vom PC.