Regenbogen LED Tower

Im Letzten Urlaub habe ich meinen LED Turm mit einem AVR ATMega32U2 gebaut. Mit dem Ergebnis bin ich allerdings nicht ganz zufrieden gewesen. Mechanisch war alles wie ich es wollte, allerdings hat der ATMega32U2 nicht so funktioniert, wie ich mir das gewünscht habe. Außerdem war einer der Footprints falsch und der USB Stecker ist nach dem zweiten mal Stecken abgerissen.

Regenbogen Modus

Ebenso habe ich lange auf die Plexiglas Platten warten müssen. In den Bildern sind nur die Untere und die Obere verbaut.

Ich habe wieder einmal Urlaub und habe mir das Projekt nochmal vorgenommen. Versuch 2 ist fertig und bestellt. Diesmal habe ich einen ESP8266 als Controller verwendet. Jetzt hat Die LED Regenbogen Lampe WLAN und kann über MQTT gesteuert werden. Wenn alles glatt geht. Die Hardware habe ich jetzt mal wieder bei PCBWay bestellt. Fertig bestückt mit allem außer ESP8266 Modul und RGB LEDs. Die müssen nachträglich noch eingelötet werden.

Wenn die Leiterplatte geliefert wird, alles funktioniert und die Daten nochmal aufgehübscht sind, werde ich sie online stellen, für jeden, der interessiert ist das nachzubauen.

Nokia 3210 Retro Fit Board Teil 9

Ich habe leider immer noch Probleme mit der Power Versorgung. Der LiPo Chip, der die Ladespannung für den Akku aus die 5V USB zur Verfügung stellt, funktioniert einwandfrei. Der dahintergelegene Teil, der zwei mal 3,3V aus den 4,2 V der Batterie machen soll, hat teilweise Probleme die Spannung stabil zu halten, was dazu führt dass der Microconroller abstürzt.

Die Lösung wird sein, den kompletten Spannungsregler zu ersetzen. Dazu werde ich eine kleine Schaltung aufbauen, die das mit möglichst wenig Komponenten schafft. Dann hoffe ich, dass ich eine stabile Verbindung zum Controller bekomme um die anderen Komponenten in Betrieb zu nehmen.

Für den 3,3V Regler werde ich auf ein integriertes Schaltregler Modul zurück greifen. Das kann dann hoffentlich die Spannung zuverlässig zur Verfügung stellen.

Ein Redesign des PCB werde ich wahrscheinlich nicht durchführen, dafür ist das 6-Lagen Board zu teuer.

Nokia 3210 Retro Fit Board Teil 8

Ich bin mitten in der Inbetriebnahme des Retro Fit Boards für das Nokia 3210. Dabei sind mir einige Probleme aufgefallen.

Das Board hat einen Fehler im Kupfer der Rückseite. Glücklicherweise ist das Kupfer eine große Struktur und kann relativ einfach aufgekratzt werden um den Fehler zu entfernen.

Die Kupferfläche zum Anbinden der Speicherdrossel der 3V3 Versorgung ist mit der GND Plane kollidiert. Beide Planes besitzen die Priorität 0 und werden daher übereinander liegend generiert. Das ganze ist sehr ärgerlich, wird aber im DRC gezeigt… Den hätte ich besser mal komplett durchgeschaut.

Jetzt bleibt nur die manuelle Nachbearbeitung der Leiterplatte. Wenn die beiden Kupferflächen aufgetrennt sind, funktioniert auch der Buck Regler für das 3V3 Netz. Allerdings nur auf instabilen 2,6V.  Die Instabilität der Versorgungsspannung führt dazu, dass die CPU nicht zuverlässig läuft. Die Kommunikation mit JTAG funktioniert nur sporadisch und es kommt oft zu Abbrüchen der Verbindung. Hier helfen 10µF am Ausgang der Spule L202, aber in manchen Situationen bricht auch so die Spannung zusammen.

Der Boostconverter, der Die Batteriespannung auf 4V hochsetzen soll, passt nicht auf das Footprint, das vorgesehen ist. Hier habe ich vorerst eine Brücke zwischen Dem Eingangs Kondensator und der Spule L202 gelötet. Ich habe ein „Texas_S-PVSON-N8_NoThermalVias“ aus der KiCad Bibliothek verwendet. Der Chip der da drauf soll ist allerdings ein WSON Chip mit 2x2mm Kantenlänge der PVSON ist 3x3mm. Da hilft nur manuelles Nacharbeiten.

Für den 3V3 Buck-Konverter habe ich einige Experimente mit dem Layout gemacht. Die stabilste Spannung habe ich bei zwei Spulen je 4,7µH und verteilter Ausgangkapazität > 22µF erhalten.

Zwei Spulen und verteilte Ausgangskapazität

Diese Schaltung werde ich nun auf dem komplett bestückten Board ausprobieren und dann sehen wir weiter.

Nokia 3210 Retro Fit Board Teil 7

Die Prototypen Boards sind da. 10 Leiterplatten des 6-lagigen Designs sind letze Woche angekommen und ich habe mit der Bestückung einer Leiterplatte begonnen. Wie in den Videos 1 und 2 gezeigt, ist das manuelle Löten ein zeitaufwändiges Unterfangen.

Die über 150 Komponenten müssen zuerst einmal sortiert und bereitgelegt werden. Dann kann die eigentliche Bestückarbeit beginnen. Für dieses Projekt habe ich mich entschieden alles per Hand zu löten, also keine Schablone mit Lötpaste zu verwenden. Das hätte den Bestückungsprozess zwar beschleunigt, aber macht es für die Inbetriebnahme schwerer. Die kann nämlich jetzt Stück für Stück erfolgen, da nicht alle Komponenten bestückt sind. Für einen zweiten Produktionslauf, würde ich die Lötpasten-Schablone bevorzugen.

Mit etwas Übung und einem professionellen Lötkolben* kann man 0402 Bauteile problemlos löten. Für die ICs habe ich Lötpaste, Flussmittel* und ein Heißluftfön*.

Beim Zusammensetzen sind mir ein paar kleine Fehler aufgefallen. Einige Löcher, die für Befestigungsschrauben oder Kuststoffbolzen im Gehäuse vorgesehen sind, passen nicht genau. Hier muss das Gehäuse angepasst, oder das Loch aufgefeilt werden. Es ist aber nichts dramatisches.

Ebenso passt die Metall-Rückseite nicht mehr drauf, wenn der JTAG Stecker und die Kopfhörerbuchse bestückt sind. Auch hier muss das Gehäuse angepasst werden.

Die Nächten Tage wird es mit der Software weiter gehen.

* Links gehen auf Amazon.de

KiCad Net Class Constraint Management

Ich bin gerade dabei ein relativ komplexes Design in KiCad zu entwicklen. Es handelt sich dabei um ein i.MX7 Prozessor mit DDR3 Anbindung. Für DDR3 sind einige Designrichtlinien einzuhalten. Diese sind neben der Leitungsimpedanz (50 Ω Transmission Line und 100 Ω Differantial Line) auch die Länge der einzelnen Signalgruppen und des Clock Signals. Darüber ein Überblick zu behalten ist nicht leicht. KiCad hat keine Funktion einfach diese Constraints zu checken und zu verwalten. Zum Glück handelt es sich um ein Open Source Projekt und daher habe ich den Versuch gestartet, pcbnew mit den nötigen Funktionen auszustatten. Ziel ist es einen angenehmen Routing-Vorgang solcher komplexen Schaltungen zu erhalten. Dazu gehören neben der Verwaltung der Constraints auch noch andere Features:

  • Live Tracking der Leitungslängen
  • Reporting der Constraints
  • DRC der Constraints
Der erste Schritt wird sein die Constraint Daten in die Netzklasse mit einzubinden. Dazu habe ich den Design Rule Dialog erweitert. Er hat 8 neue Spalten erhalten.
  1. Max Vias
  2. Topology
  3. Min Length
  4. Max Length
  5. Max Skew
  6. Stub Length
  7. Type
  8. Layer

Max Vias

Ein hochfrequentes Signal wird an jedem Materialeigenschaften-Übergang reflektiert und verliert Energie. Das können beispielsweise Änderungen des Leitungsquerschnitts, Bezugsmasse, Leitungsmaterials, oder anderer Umgebungsparameter sein. Eine Signalübergabe über ein Via in eine andere Lage ist genau so ein Übergang und führt zu Signalfehlern. Daher gibt es für manche Signale eine maximale Anzahl von Vias.

Topology

Die Routing Topologie ist die Art und Weise, wie das Signal von der Quelle zu einer Senke, oder mehrerer Senken übertragen wird. Es werden folgende Topologien erkannt:

  • STAR
    Das Signal geht von der Quelle sternförmig zu jeder Senke mit einer eigenen Leitung.
  • T
    Das Signal teilt sich (auch mehrmals) in jeweils zwei gleichlange Äste auf.
  • FLYBY
    Hier wird das Signal von der Quelle aus an jeder Senke vorbei geführt, ohne sich aufzuteilen. Alle Zwischenstücke sind gleichlang ausgelegt.
  • HORIZONTAL
    Alle Signale sollen horizontal geführt werden.
  • VERTICAL
    Alle Signale sollen vertikal geführt werden.
  • SIMPLE_DAISY_CHAIN
    Das Signal geht von der Quelle zur ersten Senke, von dort zur zweiten und so weiter. Vergleichbar mit der FLYBY Topologie.
  • MIDDRIVEN_DAISY_CHAIN
    Bei dieser Topologie geht das Signal von der Quelle nach beiden Seiten an mindestens zwei Senken. Dies ist eine Kombination aus eine Ebene T und FLYBY.
  • MULTIPOINT_TOPOLOGY
    Das Signal wird an vielen Stellen verbunden. (Niederfrequente Signale oder Spannung/Ground)

Min/Max Length

Signale, die laufzeitbegrenzt sind, oder in Relation mit anderen Signalen stehen, müssen eine gewisse Länge einhalten. Diese beiden Werte geben das Längenfenster an, in dem sich alle Signale der Netzklasse befinden dürfen.

Max Skew

Ähnlich wie die Min/Max Länge ist der Skew eine Toleranzangabe für die Länge aller Signale der Netzklasse. Beispielsweise muss ein Bus mit 8 Signalen maximal nur 60mm lang sein. Die 8 Signale sind aber auf einem Skew von 2mm begrenzt. So kann die Gruppe an sich in der Länge variieren, die einzelnen Signale sind aber strikter reglementiert.

Stub Length

Ein Stub ist eine Abzweigung des Signals. Am Ende der Leitung wird das Signal reflektiert und zurück geworfen. Das kann bei zu langen Stubs zu Problemen führen. Daher werden für diese Fälle maximale Stublängen angegeben.

Type

Hier kann zwischen den Leitungstypen Signal, Power oder Mixed gewählt werden. Diese werden an den globalen Layer Einstellungen gemessen.

Layer

Der Type Wert kann manuell überschrieben werden um die Lage in der die Leitung geführt werden darf weiter zu beschränken, oder weiter aufzulösen. Manchmal dürfen Signale nicht auf die andere Seite der Leiterkarte übertragen werden. Das kann mit dieser Einstellung konfiguriert werden.

Der aktuelle Stand ist, dass die Werte in die Tabelle eingetragen werden und mit dem Projekt abgespeichert werden können. Ich erweitere gerade die Tabelle dahin, dass die Werte schöner angezeigt werden und es für die Topologie, und Type Felder eine Dropdown-Liste gibt. Das Layer Feld soll eine Auswahlliste bekommen, in der die erlaubten Layer markiert werden können.

Live Tracking der Leitungslängen

Ein weiteres großen Feature soll das messen der Leitungslänge in Echtzeit sein. Dazu gehören mehrere Elemente. Einerseits soll auf der rechten Seite des Fensters zwischen Zeichenfeld und Toolbar eine Liste mit den zu messenden Leitungen eingeblendet werden können. Das soll ebenso wie der Layer-Dialog entweder fest am Fenster verankert, oder frei beweglich im Fenster verschoben werden können.
Andererseits soll ein weiteres Element eine Statusbar-Anzeige sein, die in Echtzeit zeigt, ob die Leitung zu lang oder zu kurz ist. Idealerweise kann hier schon eine Prognose eingebaut werden, die versucht zu ermitteln, ob mit der Länge das Ziel überhaupt erreicht werden kann. Hier werde ich am Anfang auf die „Luftlinie“ zurückgreifen und den direkten Weg als Grenze nehmen.

Reporting der Constraints

Dieses Feature ist relativ einfach zu realisieren. Alle Netze mit Constraints in der Netzklasse werden in einem Report ausgegeben und stehen als Textdatei zur Verfügung.

DRC der Constraints

Der Design Rule Check soll um die Constraints erweitert werden und mit den Fehlerklassen Report, Warning, Error über die Constraints berichten.

Nokia 3210 Retro Fit Board Teil 4

Ich versuche gerade ein Android Image für den i.MX7 auf meinem Nokia Retro Fit Board zu bauen. Das Buildsystem für Android ist gigantisch. Es besteht aus über 100 Git repositories, die mit Hilfe eine Tools heruntergeladen werden. Dazu benötigt man über 90GB Festplattenspeicher! Zusätzlich zu Android benötigt man auch noch den Linux Kernel und die passenden Patches um das originale Android und Kernel auf die CPU anzupassen auf der das System später laufen soll. Das alles dauert eine ganze Zeit, bis es einmal steht. Anschließend muss das System aus dem Quellcode kompiliert werden. Damit man nicht jede einzelne Datei selbst kompilieren muss, gibt es auch hierfür ein Tool, dass den Prozess automatisiert. Dieses Tool, mit dem Namen ‚lunch‘ geht durch die Verzeichnisstruktur und sammelt alle Informationen, welche Dateien für welches System wann kompiliert werden sollen. Danach wird noch ermittelt, welche Dateien zum System Image hinzugefügt werden sollen und zum Schluss in welchem Format das System Image erzeugt werden soll. Wenn das alles fertig ist, dann kann der Prozess starten, der aus dem Android Open Source Project ein Firmware Image erstellt, dass auf einem Embedded System lauffähig ist.

Ich habe den Prozess, wie man zu der passenden Buildsystem kommt hier dokumentiert:
https://github.com/DasBasti/NokiaRetrofitAplications

Jetzt bin ich dabei herauszufinden, wie man das Android anpasst, sodass es nicht für das Sabre Board baut, sondern für meine Hardware mit meinen Treibern und meiner Boot Konfiguration. Danach werde ich versuchen, das System auf Android Wear umzustellen, da das für so kleine Bildschirme wie ich ihn verwenden möchte optimiert ist. Wie das geht weiß ich noch nicht. Aber ich werde es versuchen.

Hardware

Ich bin im Schaltplan ein wenig weiter gekommen, auch wenn ich noch kein Update in das Repository übertragen habe. Ich bin im Moment dabei die Ladeschaltung für den originalen NiMH Akku zu zeichnen. Zusätzlich wird ein LiPo Akku anschließbar sein. Ich weiß noch nicht, wie viel Strom der i.MX7 benötigt und wie lange dann der original Akku hält. Er ist mit 1200mAh angegeben. Das ist einiges, wenn man bedenkt, dass das kleine Display nur 30mA benötigt, wenn es an ist. Eine detaillierte Stromverbrauchsrechnung ist auch in Arbeit, die wird zeigen, ob die Verwendung der originalen Batterie überhaupt ein gangbarer Weg ist.