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.

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.

Home Assistant auf Samsung ARTIK 520 installieren

Ich habe zuhause bei mir viele Funktionen mit Hilfe von Home Assistant automatisiert. Darunter fällt: Licht, Heizung, Fenster Überwachung und Thermometer. Das System läuft bei mir in einem Docker System unter Ubuntu Server auf einem Intel NUC PC. Mit SSD und 4GB Ram ist das eine performante und einfach zu wartende Sache. Letze Woche war die Embedded World in Nürnberg, eine der größten Elektronik und Embedded System Messen der Welt. Von dort habe ich ein ARTIK 520 Evaluations-Board mitgebracht. Samsung hat mit dem ARTIK System eine Komplettlösung für alle IOT Belange geschaffen. Neben kleinen Modulen im Endgerät über Sicherheit bis in die Cloud ist alles dabei um ein IOT-Gerät zu entwickeln.

Das ARTIK 520 Evaluations-Board hat ein Modul, jede Menge Antennen (4 Stück) für WiFi, Bluetooth, ZigBee, Z-Wave, Thread, Arduino Headers, Micro SD-Karten Slot und ein UART USB Interface. 
Dazu gibt es dann eine vollintegrierte Software Toolchain, die auf Eclipse basiert und weitere Tools zur Software-Entwicklung.
Auf dem ARTIK 520 Modul arbeitet ein 1GHz dual Core Cortex-A7 mit GPU, 512MB DDR3 RAM und 4GB eMMC Speicher. Zusätzlich zu dem Rechenkern gibt es noch je einen WiFi und Zigbee Co-Prozessor.

Das System ist leistungsfähig genug um eine Home Assistant Instanz laufen zu lassen. Dazu sind einige Schritte notwendig.
Mit einer SD-Karte ist es sehr einfach das System upzudaten. Das Image, dass auf das Modul geladen werden soll kann hier heruntergeladen werden: Downloads 

Wir benötigen ARTIK 520 Firmware Image A520-OS-2.0.0 (Fedora)

Um das Image auf eine SD-Karte schrieben zu können, benötigen wir eine Software wie zum Beispiel Etcher. Wenn die SD-Karte fertig beschrieben ist, steckt man sie einfach in den passenden Slot und schaltet auf SD-Boot Option. Dazu müssen beide Schalter von SW2 auf  „ON“ geschoben werden.

Der Debug USB Anschluss bietet uns eine serielle Konsole an, über die wir die Ausgaben des Moduls verfolgen können. Dazu einfach ein USB Kabel einstecken und mit zum Beispiel PuTTY eine Verbindung aufbauen.

Jetzt schalten wir das Board an und drücken den POWER Knopf für eine Sekunde. Auf der seriellen Konsole bekommen wir den Bootlaoder zu sehen, dort steht relativ weit am Anfang:

Checking Boot Mode … SDMMC

Das zeigt uns, dass die SD-Karte als Boot-Gerät eingestellt und erkannt wurde. Wenn das Update beendet ist, erscheint die Anzeige:

Please turn off the board and convert to eMMC boot mode

Jetzt also ausschalten, SD-Karte raus, die Schalter von SW2 zurück in die Ausgangsstellung und wieder einschalten und den POWER Knopf für eine Sekunde drücken. In der seriellen Konsole wird der normale Bootvorgang angezeigt, der mit einer Loginaufforderung endet. Wir melden uns als root mit dem Passwort root an.


Als nächstes benötigt das System Internetzugang um sich selbst weiter zu aktualisieren. Zum Glück bringt es direkt Wi-Fi mit, so können wir das Netzwerkkabel sparen. Die Einrichtung von Wi-Fi ist ein wenig kompliziert, da viele Informationen dem System zur Verfügung gestellt werden müssen. Außerdem wollen wir auch, dass das System nach einem Neustart noch weiß, wohin es sich verbinden soll. Die Login Informationen für das Wi-Fi Netzwerk werden in die Datei wpa_supplicant.conf eingetragen:

cd /etc/wpa_supplicant/
wpa_passphrase „SSID“ „PASSWORT“ >> wpa_supplicant.conf

Die beiden Befehle wechseln das aktuelle Verzeichnis in das wpa_supplicant Konfigurationsverzeichnis und ergänzen dann die Daten in wpa_supplicant.conf mit den Zugangsdaten (PASSWORT) für das WLAN mit dem Namen SSID.
Wichtig ist zusätzlich noch die Informationen zur Gruppe und zum Control Interface. Das checken wir mit

cat /etc/wpa_supplicant/wpa_supplicant.conf

Die Ausgabe sollte ergeben

ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=wheel

update_config=1

network={
        ssid=“SSID“
        #psk=“PASSWORD“
        psk=1e5ed3c450c25eb08xxxxxxxxxxxxxxxxxxxx878bcd17f3b5f797a2ab4fd1292
}

Das sind die vollständigen Konfigurationsdaten für den Wi-Fi Zugang. Mit einem Neustart durch reboot werden die Daten auf den eMMC geschrieben und permanent gespeichert.

Um nach jedem Neustart Wi-Fi zu aktivieren muss der wpa_supplicant Dienst gestartet werden. Das geht mit

systemctl start wpa_supplicant
systemctl status wpa_supplicant

Der zweite Befehl zeigt uns, ob der Dienst gestartet wurde oder nicht. Wenn der Dienst läuft, benötigen wir noch eine IP Adresse für das Wi-Fi-Interface diese bekommen wir über DHCP mit

dhclient wlan0

Nach einiger Zeit hat das WLAN-Interface eine IP bekommen. Um das zu checken fragen wir den Netzwerkdienst

ip a

Ganz unten wird uns das wlan0 Interface angezeigt

6: wlan0: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 30:07:4d:84:d0:b3 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.101/24 brd 192.168.0.255 scope global dynamic wlan0
       valid_lft 43151sec preferred_lft 43151sec
    inet6 fd0f:5a7d:267f:0:3207:4dff:fe84:d0b3/64 scope global dynamic
       valid_lft forever preferred_lft forever
    inet6 fe80::3207:4dff:fe84:d0b3/64 scope link
       valid_lft forever preferred_lft forever

Hier wurde uns die IP 192.168.0.101 zugewiesen. Das ist alles schön und gut, aber wir wollen, dass sich das System nahc dem Booten automatisch beim WLAN anmeldet und eine IP bezieht. Dazu müssen wir ein Startscript anlegen. Das funktioniert mit Hilfe des Init Dämons, der die Initialisierung des Systems übernimmt. Wir legen dazu eine Datei im Verzeichnis /etc/init.d an.

vi /etc/init.d/wlan

Der Befehl startet den Editor vi und legt die Datei wlan im /etc/init.d Ordner an. Im vi Editor geben wir diese Befehle ein: mit der Taste i schalten wir in den ‚Einfügen Modus‘ und können den unten stehenden Text hinzufügen (hier Strg+c und in PuTTY mit Rechtsklick einfügen)

#! /bin/bash
#chkconfig: – 99 10
start()
{
/usr/sbin/dhclient wlan0
}
stop()
{
kill dhclient
}
restart()
{
stop
start
}
case „$1“ in
start)
start
;;
stop)
stop
;;
restart)
restart
;;
*)
echo „Usage:$0 {start|stop|restart}“
esac
exit 0 

Der Druck auf Esc und 😡 mit anschließendem Druck auf Enter speichert die Datei und schließt den Editor.
Jetzt fehlt nur noch dass das System das Skript als Programm erkennt und der Moment im Bootvorgang in dem der Init-Dämon das Programm laden soll.

chmod a+x /etc/init.d/wlan
chkconfig –add wlan
chkconfig –level 12345 wlan on

Der erste Befehlt schaltet das Skript auf ausführbar, der Zweite fügt es zur Initialisierung hinzu und der letzte Befehl aktiviert es für alle Run-Levels. Ein weiterer reboot konserviert die Änderung und startet das WLAN beim Booten.

Jetzt können die aktuellsten Updates eingespielt werden. Das erfolgt durch das Programm DNF

dnf upgrade

Das kann eine Weile dauern, je nachdem wie viele Updates seit Fertigstellung des SD-Karten Images veröffentlicht wurden.

Wenn das alles geschafft ist, können wir mit der Installation von Home Assistant beginnen. Dabei sind einige Dinge zu beachten, denn Home Assistant benötigt Python Version 3.5 und das ARTIK System arbeitet viel mit Python 2.7. Beide sind nicht sonderlich kompatibel. Daher begrenzen wir die Home Assistant Installation auf eine abgeschlossenes Python Umgebung, eine so genannte virtual environment. Darin wird ann auch jedes von Home Assistant benötigtes Python Paket geladen und verwaltet, ohne mit der Pyhton Installation des Systems zu interagieren.

dnf install python-devel
dnf install redhat-rpm-config
dnf install libffi-devel
dnf install python3-devel

Nachdem die Softwarepakete installiert wurden, legen wir einen Benutzer für unsere Home Assistant Instanz an, da wir des Dienst nicht als root ausführen wollen und können.

useradd -rm homeassistant

Home Assistant benötigt ein Installationsverzeichnis. Das legen wir unter /srv an

cd /srv
mkdir homeassistant

Danach geben wir dem Verzeichnis den Besitzer homeassisatant

chown homeassistant:homeassistant homeassistant

Um auf USB Sticks und Dongles zugreifen zu können fügen wir den Benutzer noch der dialout Gruppe zu
usermod -a -G dialout homeassistant
Im homeassistant Verzeichnis legen wir dann die virtuelle Python Umgebung an.
cd /srv/homeassistant
su -s /bin/bash homeassistant
pyenv-3.5 .
source bin/activate
Der zweite Befehl startet eine Benutzereingabe als homeassistant, denn ab sofort wollen wir Befehle in diesem Benutzerkontext ausführen. Der dritte Befehl legt die eigentliche Python Umgebung an. Mit der letzten Zeile wechseln wir aus dem Linux Umfeld in die virtuelle Umgebung für Home Assistant in Python 3.5. Die Kommandozeile sollte jetzt so aussehen:
(homeassistant) [homeassistant@localhost homeassistant]$
Hier können wir jetzt endlich Home Assistant installieren. Das machen wir unter Zuhilfenahme von PIP.
pip3 install homeassistant
pip install sqlalchemy
Nachdem alle Pakete heruntergeladen und entpackt wurden können wir Home Assistant das erste mal starten. 
hass –script check_config
Der Befehl startet Home Assistant, installiert ein zusätzliches Paket (jetzt sind die Ausgaben in verschiedenen Farben markiert), führt einen Check der Konfiguration durch, und beendet sich dann wieder mit einem Fehler. Wir haben nämlich noch gar keine Konfiguration angelegt. Also starten wir Home Assistant nochmal auf den normalen Weg, diesmal mit hübschen farbigen Meldungen.
hass
Jetzt wird das Konfigurations-Verzeichnis .homeassistant unter /home/homeassistant angelegt und mit eine Standardkonfiguration geladen. Fehlende Pakete werden im Verlauf des ersten Starts installiert. Das ganze kann eine Weile in Anspruch nehmen. Bei mir hat es über 5 Minuten gedauert alle Komponenten zu laden. In der Ausgabe ist irgendwann die Zeile
2018-03-07 15:43:11 INFO (MainThread) [homeassistant.bootstrap] Home Assistant initialized in 322.72s
zu sehen. Jetzt können wir unter der IP die wir über DHCP erhalten haben die Weboberfläche von Homeassistant erreichen
http://192.168.0.101:8123
Herzlichen Glückwunsch, Home Assistant läuft jetzt auf dem ARTIK Board. Da ich den Haupt-Server jedoch nicht ablösen möchte, werde ich die Instant auf dem ARTIK Board als Gateway zu den Schnittstellen nutzen, die der Intel NUC nicht mitbringt. Also Zigbee, Thread und Z-Wave. Jetzt brauche ich allerdings erst einmal ein paar Sensoren, die diese Protokolle verwenden.

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.