Schmartwatch [08]: BOM Management in KiCad

Um eine elektronische Baugruppe herstellen zu können benötigt man neben einer Leiterplatte elektronische Komponenten. Diese haben spezifische Werte, um die gewünschte Funktion zu erzielen. Spezifiziert werden die Werte beim Eingeben des Schaltplans. In KiCad geht das mit dem Programm Eeschema. Anhand der Funktion und angegebenen Parametern kann eine Auswahl getroffen werden, welche Bauteile von welchem Hersteller für eine Komponenten im Schaltplan verwendet werden können. Ähnlich wie bei der Herstellung von Leiterplatten können dann verschiedene Gründe, wie Lieferzeit und Preis, die Auswahl beeinflussen. Betrachtet man diese Schaltung, zeigt sich dass hier folgende Komponenten verwendet werden:

 
 
 
 

Zwei Widerstände, eine Spule , zwei Kondensatoren, drei Schottky Dioden und ein Transistor. Im Schaltplan sind alle wichtigen Informationen eingeblendet um die Schaltung ausreichend zu spezifizieren. Der Transistor ist angegeben als Si1308EDL. Dieser wird von der Firma Vishay hergestellt und ist nur im SOT-323 Package zu bekommen. Für die Schottky Dioden ist eine Typenbezeichnung angegeben: MBR0530. Ebenso eine Gehäuseform: SOD-123. Somit kann als Bauteil eine Diode von ON Semi oder MCC eingesetzt werden. Bei den Kondensatoren, Widerständen und Spule ist die Auswahl noch größer. Die Kondensatoren haben als Werte die Kapazität, Gehäusegröße und maximal Spannung angegeben. Mit diesen Werten bieten sich mehrere Hersteller an. Hier sind zum Beispiel Murata, Yageo oder TDK zu nennen. Jeder der Kondensatoren, der die angegebenen Werte erfüllt ist geeignet in dieser Schaltung verwendet zu werden. Die Spule ist ähnlich wie die Kondensatoren mit drei Charakteristiken spezifiziert. Der Induktivität, dem maximalen Strom und der Bauform. Mit diesen Parametern bieten sich Spulen der Hersteller Taiyo Yuden oder TDK an. Beide Spulen sind geeignet.
Bei den Widerständen sind lediglich die Gehäuseform (0603) und der Ohmsche Widerstandswert angegeben. Daher bieten sich eine Vielzahl an Herstellern an, z.B. Stackpole, Bourns, Vishay, Yageo oder Susumu.

Wie zu sehen ist, stehen für viele Komponenten der Schaltung Alternativen zur Verfügung. Diese sind grundsätzlich alle geeignet um eine funktionierende Baugruppe zu bilden. Beim Herstellen kann also die günstigste oder kurzfristig beschaffbare Variante gewählt werden. Das ganze zu verwalten nennt man BOM-Management (Bill of Material). In größeren Unternehmen sind ganze Abteilungen damit beschäftigt, die Verfügbarkeit von Alternativen für die Bestückung der Leiterplatte zu sichern. Im kleinen Rahmen reicht aber eine solche Tabelle völlig aus.

Im aktuellsten KiCad (5.0.0) ist das Management der BOM nicht ganz ausgereift, aber dennoch brauchbar. Die Tabelle wird dynamisch mit den Komponenten im Schaltplan aktualisiert und kann auch die einzelnen Gruppen als ganzes bearbeiten. So sind zum Beispiel alle Kondensatoren  mit 100nF gruppiert. Wenn in der Gruppe ein Feld geädert wird, ändert sich auch jede Komponente in der Gruppe. So kann nach der Schaltplaneingabe schnell eine Zuordnung der einzelnen Komponenten zu Bestellnummern (MPN) hergestellt werden. Das Feld Price habe ich noch zusätzlich eingefügt, um einen groben Überblick über die Kosten zu behalten. Wenn in der Tabelle die Felder fehlen, kann einem beliebigen Bauteil das Feld im Eigenschaften-Dialog hinzugefügt werden. Danach sthet es allen Komponenten zur Verfügung.

Mit diesen Feldern in den Eigenschaften der einzelnen Komponenten kann eine Stückliste erzeugt werden, die viele Informationen für eine Bestellung beinhaltet. Über den BOM Ausgabedialog kann das Plugin bom_csv_grouped_by_value ausgeführt werden. Wenn das in der Auswahl nicht aufgeführt ist, aknn es über Add Plugin hinzugefügt werden. Im Ordner „C:\Program Files\KiCad\bin\scripting\plugins“ befindet sich das Script.

Weiterhin sollte in der Kommandozeile das %O durch ein %O.csv ersetzt werden, wie in der Abbildung zu sehen. Dadurch wird der erzeugten Datei die Endung .csv gegeben anstatt keiner.

Nachdem die BOM generiert wurde, findet ihr die Ausgabe im Projektordner mit den Namen des Projekts und wenn die Kommandozeile angepasst wurde mit Endung .csv. Hier sind die Werte der Tabelle als Text abgespeichert und können in einer Tabellenkalkulation bearbeitet werden. Diese Liste kann auch dem Hersteller der Baugruppe übergeben werden. Eventuell müssen hier noch Komponenten gelöscht werden um mögliche Verwirrungen zu vermeiden.

Um Signale an der Flachbaugruppe gut messen zu können, werden Testpunkte in der Schaltung verwendet. Diese sind zwar Komponenten im Schaltplan, haben aber kein Bauteil, das bestückt werden muss. Daher kann in der Stückliste die Zeile entfernt werden. gleiches gilt für die Widerstände, die als DNP (Do Not Place) markiert sind. Auch einer der Steckverbinder soll nicht verlötet werden, daher kann er aus der Liste gestrichen werden.

Was jetzt übrig bleibt, ist eine vollständige Stückliste mit alternativen Bauteilen, wenn möglich, aus der jeder Hersteller ein Angebot für die Baugruppe erstellen kann.

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.