Schmartwatch [07]: Erstes Watchface -> 7-Segment-Circuit

Auf meiner Pebble Smartwatch wird die aktuelle Uhrzeit mit dieser Watchface angezeigt. Die gefällt mir so gut, dass ich mich davon inspirieren ließ und für meine Schmartwatch eine 7-Segment Watchface entworfen habe.

Die Uhr ist im Moment nur in der Lage das Display komplett anzusteuern. Das heißt, es wird jede Minute das komplette Display neu gezeichnet. Der Prozess dauert einige Zeit und benötigt während der Aktualisierungsphase wesentlich mehr Strom als im Standby / Power-off Zustand. Um von der aktuell geringen Batterielaufzeit (einige Tage) auf eine bessere Laufzeit (einige Monate) zu kommen, sollte ein komplettes Update des Displays so selten wie möglich gemacht werden. Dazu mehr, wenn es um das partielle Update geht.

Die Watchface ist nach dem folgenden Muster aufgebaut:

  • Die RTC löst einen „Minute hat sich geändert“ Alarm aus.
  • Lösche den Framebuffer.
  • Zeichne den Hintergrund.
  • Schaue, ob sich der Monat geändert hat, wenn ja, aktualisiere den Bereich im Framebuffer.
  • Schaue, ob sich der Tag geändert hat, wenn ja, aktualisiere den Bereich im Framebuffer.
  • Schaue, ob sich die Stunde geändert hat, wenn ja, aktualisiere den Bereich im Framebuffer.
  • Schaue, ob sich der Minute geändert hat, wenn ja, aktualisiere den Bereich im Framebuffer.
  • Wecke das Display aus dem Energiesparmodus.
  • Warte, bis das Display bereit ist.
  • Schreibe den Framebuffer in das RAM des Displays und starte ein volles Update.
  • Warte, bis das Update fertig ist.
  • Setzte das Display in den Energiesparmodus.

Als Hintergrund Bild ist dieses binäre Bitmap hinterlegt. Es ist 152×152 Pixel groß und nimmt somit das komplette Display ein.
Bei dieser Größe hat das Bild 23.104 Pixel. Es benötigt also 2.888 Byte Programmspeicher und RAM. Der erste Schritt diesen Speicherbedarf zu kürzen ist, den großen Anteil weiß in der Mitte des Bildes auszulassen, das Bild also in zwei Teile zu zerlegen. Diese sind dann nur 45 Pixel hoch, benötigen also nur 855 Byte je Bild macht also eine Speicherersparnis von ca 30%.
Bei weniger komplexen Grafiken kann es sogar effizienter sein, die Grafik bei Bedarf in den Framebuffer zu zeichnen. Genau das ist nämlich die 7-Segment Anzeige. Die Segmente sind simple Grafiken, die bei Bedarf gezeichnet, oder weggelassen werden können. Wie die Abbildung zeigt, ist ein Segment nichts weiter als ein gefülltes Rechteck, an dessen Stirnseite je eine kürzere Linie gezeichnet wird. Die Grafik wurde mit dem Simulator Tool erzeugt, der den gleichen Render-Code besitzt, wie die Uhr. Allerdings sind die Pixel um das Zweifache vergrößert dargestellt. Das hilft beim Erstellen der Grafiken enorm. Da das Display ziemlich klein ist, ist ein einzelnes Pixel schwierig zu erkennen.

Eine Zahl im Sieben-Segment Display wird dann aus waagerechten oder senkrechten Elementen gezeichnet und so müss nicht jede Zahl von 0 bis 9 als Bitmap im RAM vorgehalten werden.

Wenn man den oben beschriebenen Ablauf genauer betrachtet, kann man erkennen, dass ein partielles Update des Displays relativ einfach zu bewerkstelligen sein sollte. Jedesmal wenn sich ein Wert geändert hat, wird die betroffene Fläche mit einem partiellen Update aktualisiert. Die Dokumentation des Displays ist leider nicht sehr aussagekräftig, was den Ablauf des Updates betrifft. Daher wird dieses Thema ein eigenes Kapitel bekommen.

Schmartwatch [06]: Display

In den letzten Tagen habe ich mit sowohl der Firmware als auch mit der Hardware einige Fortschritte gemacht. Die Kondensatoren, die für die Ladungspumpen des E-Paper Displays zuständig sind, können die Spannung (+/- 15V) nicht vertragen. Daher habe ich die Ansteuerelektronik des Evaluationsboards mit der Leiterplatte der Uhr verbunden. Nach einigen Unklarheiten der Bitreiehnfolge im SPI Bus habe ich eine erfolgreiche Initialisierung des Displays durchgeführt. Wenn das Display mit nicht korrekt formatierten Daten beschrieben wird, bekommt man eine Pixelwüste, wie im Video zu sehen:

[youtube=https://www.youtube.com/watch?v=QDUtd2z1FKA&w=320&h=266]

Nach dem ich mit Hilfe des Logikalaysators und Oszilloskop das SPI Protokoll so umgestellt habe, dass es mit dem des Evaluationsboards übereinstimmt, bekomme ich auch erfolgreich Daten auf dem Display dargestellt.

Die Software startet nach dem Initialisieren der Hardware einen Loop, der die Uhrzeit aus der RTC holt und darstellt. Das Display wird jede Minute aktualisiert. Im Video zu sehen ist die Aktualisierung des kompletten Bildschirms mit sehr kleiner Schrift. Daher pumpt der Treiber des e-papers auch die gesammte Fläche um. Idealerweise werden nur geänderte Flächen aktualisiert, das ist aber mit dem aktuellen Renderer nicht möglich.

[youtube=https://www.youtube.com/watch?v=iP9SEnifDoU&w=320&h=266] 
 
Hier noch ein paar Bilder von der Inbetriebnahme des Displays hin zur Darstellung der Uhr im aktuellen Watchface Design (7-Segment Circiut).
 
 
 

Schmartwatch [05]: Gehäuse

Eine anständige Armbanduhr benötigt ein anständiges Äußeres. Um mit dem DIY Stil der Uhr zu gehen, habe ich ein Gehäuse designed, das aus mehren Teilen besteht. Alle Teile sind so ausgelegt, dass sie im 3D-Druckverfahren hergestellt werden können. Gleichzeitig sollen sie aber auch aus Aluminium fräsbar sein.
Die Flex-Leiterplatte wird in die Gehäusebasis eingelegt. Dazu ist die Kontur des PCBs in der Innenseite abgebildet.

In die Löcher der Basis kommen Stößel für die Druckknöpfe. Je zwei pro Seite sind auf einer gemeinsamen Querplatte und betätigen mit der Platte die Taster auf der Elektronik.
Auf das PCB wird ein Kuststoffrahmen aufgesetzt. Dieser hat Aussparungen für das Display und die Batterie. Die Querplatten sind an der Kante gelagert, um eine Wippe zu bilden.

So kann immer nur die Taste hinter dem Stößel betätigt werden, egal wie feste gedrückt wird. Diese Konstruktion befindet sich also oberhalb der Elektronik und bildet damit auch die Auflagefläche für den Deckel. Wie genau ich den Deckel befestigen möchte ist mir noch nicht klar. Er ist nur 1,7mm dick, was eine Verschraubung erschwert. Die Batterie im Inneren muss wechselbar sein, daher kann ich den Deckel auch nicht verkleben. Hier brauche ich also noch eine Lösung. Ich habe schon eine Vorstellung, wie ich den Deckel mit dem Kunststoffrahmen verbinde und diesen dann von hinten mit Schrauben in der Basis-Schale halte. Wasserdicht ist die Uhr auf keinen Fall.

Wie gut sich die Modelle im 3D-Drucker herstellen lassen wird sich zeigen. Dazu brauche ich aber erst mal ein funktionierendes Board mit der wichtigsten Funktion: Anzeige der Uhrzeit.

Schmartwatch [04]: Firmware Blinky

Der Erste Schritt zur Inbetriebnahme einer Leiterplatte ist die Validierung der Stromversorgung.
Die Leiterplatten sind geliefert worden und ich habe eine teilweise bestückt. Ich habe zuerst den 3,3V Boost Regler installiert. Mit einem Oszilloskop habe ich die Spannung am Ausgang des Reglers bewertet. Mit einer Last, die dem Regler 15mA konstant abverlangte, kam ich auf einen Ripple von 20mV auf der Ausgangsspannung. Dieser Ripple änderte sich nicht, egal ob die Ausgangsspannung mit nur 1mA oder mit 100mA belastet wurde. Daher habe ich als nächstes das Funkmodul bestückt. Mit dem bestückten Funkmodul war ich dann in der Lage eine Verbindung mit dem Debugger herzustellen. Als Debugger verwende ich einen  JLink Pro von der Firma Segger. Nordic Semiconducters hat für diese Serie an Debuggern einen hervorragend Support.

Nachdem auch der Debugger mit dem Funkmodul in Betrieb genommen war, habe ich die restlichen Bauteile für die Ansteuerung des Displays aufgelötet. Das Display hat im Controller einige Reglerfunktionen integriert und kann sich eigene Hilfsspannungen erzeugen, dazu braucht es lediglich ein paar Kondesatoren, einen Transistor und einige SPI Befehle. Das Footprint des Transostors im Layout der Leiterplatte ist fehlerhaft, die Pins Gate und Drain sind vertauscht. Ein einfaches drehen des Transistors hat das aber wieder repariert.

Ohne angeschlossenes und konfiguriertes Display ist also die Schaltung nicht funktionsfähig. Trotzdem kann sie mit einem einfachen Toggle Signal an allen betroffenen IO-Pins auf Funktionalität und Kurzschlüsse getestet werden.
Kurzschlüsse auf Pins des Displays zeichnen sich hauptsächlich durch die Verlust der Signalqualität am Display Stecker aus. Wenn also ein Output Pin des Funkmoduls, der ein High Signal liefern soll, versucht gegen ein kurzgeschlossenes Low-Signal zu treiben, wird sich die Spannung ungefähr in der Hälfte des erwarteten Wertes befinden.
Nach Beseitigung der Kurzschlüsse am Displaysteckverbinder kann die Inbetriebnahme des Displays beginnen. Dazu habe ich eine Testsoftware geschrieben, die das Display startet und Werte anzeigen soll. Mit Hilfe der verfügbaren Ressourcen auf dem Funkmodul wird ein Bild erstellt, dass dem Display Pixel für Pixel übergeben wird. Danach wird gefragt, ob das Display bereit ist und wenn das der Fall ist, wird das nächste Bild übertragen.

Aktuell startet das Display die Hilfsspannungen nicht von alleine und es zeigt nichts an. Dieser Zustand benötigt viel (relativ zum normalen Betrieb) Strom, sodass das Display spürbar wärmer wird.

Wie genau sich die Ansteuerung in dieser Schaltung zu der Ansteuerung auf dem Eval-Board unterscheidet, wird sich zeigen, wenn das Evalboard den langen weg aus China zu mir gefunden hat.
Bis dahin stehen noch weitere Peripherien zur Verfügung die gerne in Betrieb genommen werden möchten. Darunter fallen:

  • I2C Bus für Echtzeituhr
  • I2C Bus für Bewegungssensor
  • Applikationsstruktur der Firmware (nachladbare Code Teile)
  • BLE Softdevice 
Im Moment können wir lediglich davon ausgehen, dass alle Pins des Funkmoduls korrekt gelötet und bisher keine Kurzschlüsse auf der Leiterplatte sind. 

Schmartwatch [03]: Firmware – Mockup

Die Entwicklung von Firmware für eine Hardware, die noch nicht im finalen Design vorliegt, oder überhaupt in Realität verfügbar ist, ist schwierig. Ebenso verhält es sich mit der Schmartwatch Firmware. Die Hardware ist in der Prototypenphase bestellt. Das heißt aber nicht, dass mit der Firmwareentwicklung gewartet werden muss. Ich habe vor so wenig Bibliotheken wie möglich einzubinden und viele Funktionen selbst zu schreiben. Das soll mehr zum Üben und Lernen dienen als zeiteffizient zu entwickeln.

Um die Funktionen testen zu können, werden sie in verschiedenen Abstraktionsebenen entwickelt.
Die grundlegende Ebene ist die direkte Hardware-Ebene; die CPU. Dort werden die Register der einzelnen Peripherien angesprochen. Das werde ich über die bereits verfügbare Hersteller SDK Schnittstelle machen. Auch den Bluetooth Stack des Herstellers werde ich übernehmen. Denn die Programmierung der Hardware Funktionen sind von Hersteller zu Hersteller, machmal auch von Chip zu Chip unterschiedlich. Einen Bluetooth-LE Stack selbst zu schreiben finde ich auch keine sinnvolle Beschäftigung. Vor allem, wenn das Ziel ist eine Smartwatch zu programmieren.

Eine der selbst geschriebenen Funktionen wird jedoch die Erstellung von Bildschirm Inhalten sein. Die Uhr besitzt ein 3-Farben e-ink Display. Rot, Schwarz und Weiß. Damit bieten sich verschiedene Möglichkeiten an, um Grafiken anzuzeigen. Ich habe mich für folgende Zeichenfeatures entschieden:

  • Einzelne Pixel
  • Linien
  • Rechtecke
  • Rechteckige Flächen
  • Rechtecke mit runden Ecken
  • Rechteckige Flächen mit runden Ecken
  • Kreisringe
  • Kreisförmige Flächen
Gezeichnet werden kann in den drei Fraben und transparent. Transparent bedeutet, dass die an dieser Stelle vorhandene Farbe beibehalten werden soll. Um noch weitere Elemente auf das Display zu zeichnen, werden diese Funktionen zur Verfügung stehen:
Diese Grundfunktionen zu grafischen Darstellung auf dem Display kann ich testen, ohne eine echte Hardware auf dem Tisch zu haben. Dazu schrieb ich eine Windows Software, die das Display der Uhr in 2-facher Vergrößerung anzeigt und alle die Funktionen meiner Grafik Bibliothek verwendet.
Um ein Bild für das Display zu zeichnen, befindet sich im RAM der Smartwatch ein Framebuffer, das ist ein Speicherbereich, der Informationen zu allen Pixeln des Displays beinhaltet. Mit dem ‚render‘ Befehl, werden alle Daten aus dem RAM in das Display kopiert und angezeigt. So können Bildteile verändert werden, ohne dass von Außen eine Änderung auf dem Display sichtbar ist. Erst wenn der Bildschirm fertig erzeugt ist, wird er an das Display übertragen und in einem Rutsch dargestellt.
Die Übertragung und das Rendern der Bilddaten ist eine Hardware abhängige Funktionalität. Das Schreiben auf den Framebuffer hingegen kann unabhängig der Hardware passieren. Das machen wir uns hier zu nutze. Die Windowsanwendung nutzt die Schmartwatch Funktionen der eigenen Grafik Bibliothek um auf ein Framebuffer zu schreiben. Eine Renderer Funktion der Windows Anwendung kopiert dann den Framebuffer in ein Windows geeignetes Speicherformat und gibt es um den Faktor 2 vergrößert am Monitor aus.
Hier sehen wir einen Screenshot der Anwendung. Die schwarzen und roten Rechtecke gehören zur Displayfläche dazu. Es werden zwei Texte gezeichnet, die einer Uhrzeit entsprechen, zwei unterschiedlich farbige Linien und ein Kreis, sowie eine große schwarze Fläche. Die Grafik rechts inclusive Text ist ein monochromes Bild, das ebenfalls als schwarz / transparent gerendert wird.
Transparent ist die virtuelle vierte Farbe des Displays. Sie bedeutet, dass für dieses Pixel der bereits im Framebuffer liegende Wert beibehalten werden soll. Somit können Bilder übereinander dargestellt werden. Das wird in der Phase der Watchface Programmierung noch häufiger genutzt werden. Die Schriftarten, die standartmäßig in dem Betriebsystem der Uhr verwendet werden, sind natürlich von der Größe her begrenzt. So bietet es ich an, für die Anzeige der Uhrzeit Bitmaps zu verwenden. Auch grafische Effekte können mit mehreren Layern erzeugt werden.

Der Windows Simulator hat den Vorteil, dass im PC nahezu unbegrenzte Rechenkapaität zur Verfügung steht. Im vergleich zu einer Embedded CPU in unserer Smartwatch, versteht sich. Daher kann der Bildschirminhalt so schnell wie möglich immer wieder komplett geschrieben werden. Für eine spätere Implementierung mit e-Paper ist es wichtig die Aktualisierungsrate der Frames gering zu halten. Wenn möglich soll nur ein Teil des Displays aktualisiert werden. Wie genau das funktioniert und wie performant sich das lösen lässt, wird sich zeigen, wenn das Display des ersten Prototyps angesteuert wird.

Die Lieferung mit den FR4 Prototypen ist heute eingegeangen. Jetzt kann die Bestückung beginnen ind die Inbetriebnahme der Hardware, sowie die ersten Funktionen der Firmware.

Schmartwatch [02]: Prototyp Layout

Mit den Anforderungen aus Teil 1 habe ich mich an eine Prototypen Layout gesetzt. Prototyp deshalb, weil es auf normalem FR4 gefertigt ist. Um die Schaltung zu validieren, die später auf Flex material gefertigt werden soll ist das völlig ausreichend. FR4 ist ein Material, dass wesentlich hitzestabieler ist als das Polyamid des Flex PCB. Das heißt, auf dem normalen Board kann man besser löten als auf dem Plastik des Flex Boards. Weiterhin ist ein FR4 Board weitaus günstiger.

Das Design soll von der Form her so sein, wie in Artikel 1 gezeigt. Das Display ist dort bereits eingezeichnet. Wenn später die Leiterplatte aus flexiblem material gefertigt wird, kann sie einfach gebogen werden.

Die Schaltung darf nur auf der Vorderseite des Boards platziert werden. Das heißt die Batterie und alle anderen Bauelemente kämpfen um den Platz unterhalb des Displays. Es sind zwar einige Bauelemente nötig, doch sie passen alle mehr oder weniger unter das Display.

Das Layout der Leitungen darf maximal zwei Lagen nicht überschreiten eine 4 Lagen Flex Leiterplatte ist wesentlich teurer als zwei Lagen. Weiterhin sollen 3,3V und GND als Fläche ausgelegt werden, wo immer das möglich ist.
In Lila ist der Stiffener eingezeichnet, eine Fläche aus stabilem Kunststoff, die auf das Polyamid der Flex-Leiterplatte aufgeklebt wird um an dieser Stelle eine stabile Ebene zu bilden. Als
Schnalle für das Armband habe ich mit eine Steckverbinder für Flex Literplatten ausgesucht, der
505147-0490 und 505148-0408 sollen den Schließmechanismus der Uhr bilden.

Das fertige Layout der Armbanduhr sieht für den Prototypen dann wie folgt aus. Einige Verbindungen haben sich für die Flex Variante allerdings geändert, da ich de Piezo Buzzer erst nachträglich in die Anforderungen aufgenommen habe.

Vorderseite (rot) und Rückseite (grün) des Prototypen Designs

Hier kann man im Design gut erkennen, dass die Richtung der Leitungen auf der Vorder- und Rückseite waagerecht, bzw. senkrecht ausgelegt sind. Dadurch verhindert man, dass sich die Netze zu sehr verheddern und man später überhaupt nicht mehr entflechten kann.
Die GND Fläche auf der Rückseite wird von den Leitungen zum Display durchschnitten. Um ein schwanken des Bezugspotentials zu verhindern, werden die beiden Teilflächen auf der Oberseite gebrückt. Gleiches ist bei dem Signal BATT+ zu sehen, das schneidet die 3V3 Fläche in zwei Teile. Auch hier wird über Brücken ein Potentialausgleich geschaffen. Die große violette Fläche ist eine Klebefläche für die Batteriehaltung. Beim Einlegen der Batterie werden ziemlich große Kräfte angewendet, dadurch können die Lötverbindungen kaputt gehen. Um das zu verhindern, werden die Kräfte hier über die Klebeverbindung auf die Leiterplatte gebracht.

Mit den FR4 Prototypen sind die Inbetriebnahme des DC/DC Boost Konverters, der MCU, IMU und des Displays möglich. Ebenso können Batterielaufzeit und allgemeine Performance des BLE Signals validiert werden.

Der nächste Teil wird sich dann mit den Grundfunktionen der Firmware beschäftigen.

Schmartwatch [01]: Smartwatch selbst gebaut

Das ist der erste Artikel in der Schmartwatch (sprich:  [ˈʃmaːɐ̯tˌvɔʧ]) Serie. In dieser Serie werden verschiedene Themen der Erstellung eines elektronischen Projekts angesprochen. Der erste Artikel beschäftigt sich mit der Idee und dem grundsätlichen Konzept

Ich besitze seit vielen Jahren die Pebble Smartwatch. Zuerst die Kickstarter Pebble, dann die Time und zum Schluss die Round. Die hat leider eine Fahrt in der Waschmaschine nicht überlebt.
Die Firma Pebble wurde von Fitbit gekauft und die Produktion der Uhren, sowie der Software-Support bis Juni 2018 eingestellt.

Das Beste Feature der Pebble ist, dass die Uhrzeit auf dem Display bei jedem Licht, zu jeder Zeit lesbar ist. Bei starkem Sonnenlicht kann das Display gelesen werden und bei Dunkelheit hilft die Beleuchtung. Bei vielen anderen Uhren, muss man das Display erst einschalten, um die Uhrzeit abzulesen. Das kann man zum Beispiel mit einem Schnick aus dem Handgelenk tun, oder über einen Touch am Display. Beides finde ich keine Option, um mal kurz auf die Uhr zu schauen. Weiterhin ist es für die Batterielaufzeit tödlich, wenn dauernd das Display an geht. Das passiert zum Beispiel, wenn der Untergrund beim Radfahren etwas holprig ist.

Meine Lösung: Eine Smartwatch mit langer Batterielaufzeit, ePaper-Display, Piepser, und Bluetooth-LE. Und ein besonders technisches Design. Dazu wird die Uhr aus einer Flex-Leiterplatte hergestellt, die gleichzeitig als Armband dienen soll. Wie und ob das funktioniert, wird sich herausstellen.

Hier sind die Features, für die ich mich entschieden habe:

  • nRF52832 im ISP1507-AX Modul
  • TPS610994 synchroner Boost-Converter
  • M41T62 RTC mit integriertem Kristall
  • LSM303AGR eKompass (Magnetfeld/Beschleunigung)
  • SMT-0940-T-3V-R Piezo Buzzer
  • GDEW0154Z17 ePaper Display

Die MCU ist ein Cortex-M4 mit vielen Peripherien auf dem Chip. Dazu auch ein BLE-Radio und NFC. Für die Uhr werden folgende Peripherien benötigt: BLE, I2C, SPI, NFC und einige GPIO Pins. Der Cortex-M4 mit Fließkomma Unterstützung läuft mit 64MHz. Dadurch kann er schnell auf Ereignisse reagieren und dann wieder in den Sleep-Modus wechseln. Je länger der Sleep-Modus ist, desto erheblicher kann Batteriekapazität gespart werden. Das RAM ist 64kb groß und bietet ausreichend Platz für die Display Daten, sowie BLE und Applikationen. Als Flash sind 512kb vorhanden, was ausreichend Platz für die Firmware, sowie Applikationen und Grafiken ist. Die MCU wird das „Gehirn“ der Uhr.

Betrieben werden soll die Uhr mit einer CR2032 Batterie. Die liefert eine Spannung von 3V … 1,8V. Um auf die Betriebsspannung von 3,3V zu kommen, muss ein Baustein her, der mit Hilfe einer Induktivität die Spannung hochsetzt. Dazu habe ich den Energiesparenden TPS61099 von Texas Instrument gewählt. Dieser Boost-Converter hat einen sehr kleinen Energiebedarf. Dadurch verbraucht der Regler kaum Energie für sich selbst und kann der nachfolgenden Schaltung die Energie zur Verfügung stellen. Eingeschaltet werden soll der Booster, wenn das Uhrband geschlossen wird. Das bedeutet, dass die Uhr keine Zeit anzeigt, wenn sie geöffnet ist. Ob das eine sinnvolle Funktion ist, wird sich im Alltag herausstellen.

Die M41T62 Echtzeituhr besitzt einen 32kHz Kristall und bringt alles mit, um die Uhrzeit auf +-5 Sekunden pro Monat genau zu halten. Angeschlossen wir die RTC über I2C und kann da bis zu 400kHz leisten. Das hilft, die Dauer der Kommunikation zwischen MCU und RTC kurz zu halten, denn auch hier ist die Zeit, die die CPU nicht schlafen kann und mehr Strom von der Batterie braucht unerwünscht.

Um die Schlafdauer zu maximieren, kann in der RTC ein Alarm programmiert werden, der die CPU dann aufweckt, wenn etwas abzuarbeiten ist. Somit muss die CPU nicht immer aufwachen und selbst nachschauen, ob etwas zu berechnen ist. Diese Funktion muss allerdings in der Software vorgesehen werden.

Um zu erkennen, ob die Uhr bewegt wird, wird ein elektronischer Kompass LSM303AGR verbaut. Dieser bietet Messwerte zur Beschleunigung und Magnetfelder in alle 3 Achsen. Dadurch können zum Beispiel ein Schrittzähler oder ein ‚draufschau‘ Modus implementiert werden. Auch kann die Uhr erkennen, wie der Arm gehalten wird, dadurch können verschiedene Applikationen implementiert werden. Ein Beispiel ist eine Maussteuerung für den PC, oder ein umschalten des Dialogfelds, wenn der Arm auf ‚wegschauen‘ gedreht wird.

Wie jede gute Uhr, soll auch meine Smartwatch piepen können. Der gewählte Piezo Buzzer ist mit 9 x 9mm sehr klein und passt unter das Display. Die Eigenfrequenz von 4kHz ist ein heller Pfeifton, aber er wird nur kurz zum Piepen verwendet. DerTon ist daher nicht so schmerzhaft, wie ein durchgehender Ton mit dieser Frequenz.

Zu guter Letzt das Display, mit dem eigentlich alles angefangen hat. Ich habe auf der Webseite AliExpress ein Display gefunden, dass die ideale Abmaße für eine Uhr hat und mich dann dazu entschlossen das Projekt Schmartwatch zu starten. Es hat eine Auflösung von 152×152 Pixel bei einer Größe von 1,54Zoll (39,11mm). Das ergibt eine Auflösung von ca. 5,5 Pixel pro mm. Ebenso hat das e-Paper zwei mögliche Farben, rot und schwarz, neben dem weißen Hintergrund.

Auf dem Display befindet sich ein zweiter Controller, der die Ansteuerung des Displays übernimmt. Dieser Controller ist auf dem Glas des Displays aufgeklebt und dann dort mit sehr feinen Golddrähten verbunden. Verbunden ist der Controller des Displays über den SPI Bus der MCU.

Der nächste wird sich mit der Erstellung der Prototypen Leiterplatte beschäftigen. Weitere Artikel werden dann die Software, Flex-Leiterplatte und Bestückung, sowie BOM-Management beinhalten.

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.

Home Assistant auf Samsung ARTIK 520: MQTT

Wir haben bisher das ARTIK 520 Board in Betrieb genommen, Linux und Home Assistant installiert, Zigbee aktiviert und mit Home Assistant verbunden. Jetzt ist es an der Zeit, die Home Assistant Instanz mit der bereits verfügbaren im Heimnetzwerk zu verbinden. Dazu verwenden wir den Home Assistant Eventstream. Dieser ermöglicht uns der Hauptinstanz jegliche Änderungen zu übertragen. Die lokale Instanz von Home Assistant kümmert sich lediglich um die Verwaltung der Zigbee Funktionen, teilt der großen Instanz alle Änderungen mit und wird normalerweise nicht über die Weboberfläche bedient.

Damit die beiden Instanzen miteinander kommunizieren können, kommt ein MQTT Broker zum Einsatz. Dieser sorgt dafür, dass die Events zu den passenden Instanzen kommen.
Jede Instanz hat einen Empfang- und einen Sendekanal. Für meine Installation bedeutet das, dass auf der Hauptinstanz der Eventstream wie folgt in der condifguration.yaml eingestellt ist.
mqtt_eventstream:
  publish_topic: /homeassistant/eventstream/Herbert
  subscribe_topic: /homeassistant/eventstream/ARTIK
Auf dem ARTIK Board drehen wir die Topics einfach um. Somit erhalten wir die spezifischen Kanäle zur Kommunikation.
mqtt_eventstream:
  publish_topic: /homeassistant/eventstream/ARTIK
  subscribe_topic: /homeassistant/eventstream/Herbert
Jetzt fehlt der ARTIK Instanz nur noch die Verbindung zum lokalen MQTT Broker. Dazu konfigurieren wir die MQTT Komponente mit der IP des Brokers. In meinem Netzwerk ist das die 192.168.0.21. Das ist aber in jedem Netzwerk unterschiedlich. Wenn ihr den MQTT Server der Hauptinstanz lokal auf dem Home Assistant Server laufen habt, dann ist die Adresse die des Home Assistant Servers.
mqtt:
  broker: 192.168.0.21
  client_id: „HomeAssistant ARTIK“
  protocol: 3.1
Nach einem Neustart verbinden sich die beiden Home Assistant Instanzen und teilen ihre Events. 

Home Assistant auf Samsung ARTIK 520: Zigbee

Weiter geht es mit dem ARTIK Board. Wir haben das letzte Mal das System aufgesetzt, aktualisiert und Home Assistant installiert. Jetzt starten wir Home Assistant bei jedem Boot, updaten die Firmware des Zigbee Controllers um mit Home Assisatant zusammen zu arbeiten und konfigurieren Zigbee für eine Philips hue Glühlampe.

Um nach dem Power-up Home Assistant direkt zu starten, müssen wir dem Initialisierungs-Dämon mitteilen, dass hass ausgeführt werden soll. Das machen wir ähnlich dem wifi mit Hilfe von einem Initialisierungsscript. Dazu erzeugen wir einen Service mit Namen home-assistant

vi /etc/systemd/system/home-assistant@homeassistant.service

[Unit]
Description=Home Assistant
After=network-online.target

[Service]
Type=simple
User=%i
ExecStart=/srv/homeassistant/bin/hass -c „/home/homeassistant/.homeassistant“

[Install]

WantedBy=multi-user.target



Wie der vi Editor verwendet wird, wurde im letzten Artikel kurz erklärt, weitere Informationen findet ihr hier.

Der eben erzeugte Service muss noch initialisiert werden, dazu müssen wir den Dienst neu starten

systemctl –system daemon-reload

Danach können wir den Dienst in den Autostart laden

systemctl enable home-assistant@homeassistant

Jetzt können wir einen reboot durchführen und Home Assistant wird beim Neustart automatisch gestartet.

Das ARTIK 520 Modul hat einen NCP (Network Co-Processor) für Zigbee. Dabei handelt es sich um den EM3587 von Silabs. Dieser hat in der aktuellen Konfiguration eine Firmware geladen, die mit RTS und CTS eine Hardware Flusskontrolle erfordert. Home Assistant hat dafür keine Unterstützung, daher müssen wir die Firmware des NCP (NCP Firmware 2017-04-25) ändern. Für das ARTIK 520 Modul gibt es leider nur die RTS/CTS Firmware, also nehmen wir das Image des ARTIK 710 Moduls. Das ist kompatibel und kommt mit Software Flusskontrolle. Es ist dadurch kompatibel mit Home Assistant. Also entpacken wir ARTIK710NCP.zip aus dem Set der Firmwaren.

Die Dateien müssen wir jetzt auf das Modul übertragen werden. Dazu verwenden wir die SD Karte aus dem ersten Teil. Auf diese kopieren wir die Dateien

flash_firmware
ncp-uart-xon-xoff-use-with-serial-uart-btl-5.7.4.ebl

Die SD-Karte legen wir wieder in den Slot auf dem ARTIK 520 Board und hängen die SD-Karte in das System ein, kopieren die zwei Dateien und machen das Flash-Programm ausführbar.

mkdir /mnt/SD
mount /dev/mmcblk1p1 /mnt/SD
cp /mnt/SD/flash_firmware /root/
cp /mnt/SD/ncp* /root/
chmod +x /root/flash_firmware
umount /mnt/SD

Jetzt müssen wir die Schnittstelle zum NCP frei bekommen. Dazu beenden wir den Zigbee Dienst und deaktivieren ihn. Ebenso stoppen wir Home Assistant.

systemctl stop zigbee-daemon
systemctl disable zigbee-daemon
systemctl stop home-assistant

Das Firmware-Update Tool wird als nächstes ausgeführt und updatet den Co-Prozessor

cd /root
./flash_firmware -p /dev/ttySAC1 -f \
  ncp-uart-xon-xoff-use-with-serial-uart-btl-5.7.4.ebl



Do you want to start firmware flashing application? Say Y(es) or N(o): Y



============================================
image transfer is completed (version : 0.1)
============================================

Das Firmwareimage ist erfolgreich übertragen worden und der NCP kann jetzt von Home Assistant verwendet werden.

Dazu schalten wir die Komponente zha ein. Diese verwaltet verschiedene Zigbee Komponenten wie Schalter, Lichter und Sensoren.

Dazu editieren wir die Datei configuration.yaml

vi /home/homeassistant/.homeassistant/configuration.yaml

Dort fügen wir ans Ende die folgenden drei Zeilen ein:

zha:
  usb_path: /dev/ttySAC1
  database_path: /home/homeassistant/.homeassistant/zigbee.db

Abspeichern, Home Assistant starten und laden lassen. Dieser Schritt dauert wieder einige Zeit.

systemctl start home-assisatant@homeassistant

Nach einer Weile ist die Webseite wieder erreichbar und wir können die Dienste Tools anwählen.

Dort können wir den zha Dienst mit der Funktion permit auswählen und so Home Assistant anweise auf neue Verbindungen aus dem Zigbee Netzwerk zu lauschen. Nach einem Druck auf CALL SERVICE werden für 60 Sekunden neuen Zigbee Geräte im Netzwerk akzeptiert.

Jetzt ist es an der Zeit unsere Zigbee Geräte einzuschalten, oder in diesem Fall einzudrehen.

Nach einigen Sekunden ist diese dann auch von alleine im Home Assistant Dashboard erschienen. Das Ein- und Ausschalten hat auch bereits automagisch funktioniert.

Somit haben wir Zigbee erfolgreich in Betrieb genommen und können weitere Geräte dem Netzwerk hinzufügen.