Propelleruhr und Ansteuerung über RaspPi

[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:
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.