Ein Blick auf: BLE – Bluetooth Low Energy

19. Juni 2015 by Platinenmacher Leave a comment

BLE, Bluetooth Low Energy, oder Bluetooth Smart ist ein und das selbe und in aller Munde. Jedes modernere Smartphone hat zumindest Bluetooth 4.0 implementiert und könnte somit theoretisch mit einem BLE Gerät kommunizieren. Als Entwickler befinde ich mich gerade in der Situation, dass eine in die Tage gekommene Funkstrecke mit einem moderneren, energiesparenden Verfahren ersetzt wird. Also warum nicht mit BLE?

Das Protokoll, dass von der Bluetooth Special Interest Group als Bluetooth 4.0 definiert und später mit 4.1 aktualisiert wurde ist modular aufgebaut. Ein Hersteller eines BLE Peripherie Gerätes kann das Gerät so aufbauen, dass es für den Host (Mobiltelefon oder PC/Laptop) selbsterklärend ist, welche Daten es zur Verfügung stellt. Dazu werden im Protokoll Stack verschiedene Client/Server Strukturen angeboten. Somit ist es möglich ohne spezielle Software auf der Host-Seite ein BLE Peripherie Gerät zu verwenden. Dabei hat man sich auf eineige Profile geeinigt, die von der Bluetoth SIG veröffentlicht und betreut werden.

Da mein aktuelles Projekt nicht in sehr hoher Stückzahl produziert werden wird (< 10000 / a) lohnt es sich nicht die RF-Hardware selbst zu implementieren und zu zertifizieren. Für diesen Zweck eignet sich ein Modul, dass bereits alle Zertifizierungen im RF-Bereich mitbringt. Die Auswahl an marktreifen Modulen von diversen Anbietern ist groß und viele weitere sind angekündigt. Daher habe ich mich auf eine kleine Auswahl beschränkt.

Hersteller	Chipsatz	Prozessor	Compiler	Debugger
RFduino	nRF51822	Cortex-M0	Arduino IDE/ Keil µVision	Segger J-Link
Laird BL600	nRF51822	Cortex-M0	SmartBASIC	SmartBASIC / Segger J-Link
LSR SaBLE-x	CC2640	Cortex-M3	Code Composer Studio / IAR Workbench	Segger J-Link / TI XDS100v3
Panasonic PAN1740	DA14580	Cortex-M0	Keil µVision	Segger J-Link
Cypress EZ-BLE PRoC Module	PRoC BLE	Cortey-M0	PSoC Creator	PSoC MiniProg3

Jedes dieser Module habe ich auf meinem Tisch liegen, oder mir näher anschauen können. Jedes Modul hat seine Vor- und Nachteile und spezielle Anwendungsgebiete.

Beginnen wir mit dem RFduino. Wie man an dem Namen schon erahnen kann, ist das Modul im Arduino-Universum angesiedelt. Es kommt mit einem Plugin für die Arduino-IDE und ermöglicht mit einer Bibliothek des einfachen Einstieg in die Entwicklung von BLE-Geräten. Die Einfachheit der Umgebung ist gleichzeitig auch das große Manko dieses Moduls. Wenn die Arduino IDE als Entwicklungunsumgebung verwendet wird, ist man auf die in der Bibliothek vorgegebene Funktionalität beschränkt. Vom ordentlichen Debuggen ganz zu schweigen. Mehr als ein printf() kann man dem Chip dann nicht abverlangen. Wenn jedoch der Arduino Bootloader mit einem J-Link überschrieben wird, kann man den Chip auf dem Board in vollem Umfang programmieren. Dann nicht mehr in der Arduino IDE sondern zum Beispiel in µVision und dem SDK von Nordic. Dass der RFduino allerdings in einigen Jahren noch lieferbar ist, ist zweifelhaft.

Das BL600 von Laird kommt mit einem etwas ungewöhnlichen Aufzug daher. Es wird nicht wie üblich cross-compiliert, sondern dem Modul wohnt ein BASIC Interpreter inne, der Skripte entweder zur Laufzeit, oder vorab als Bytecode interpretiert. Die Skripte werden in einem Teil des Flash-Speichers abgelegt und von dort dann auch Aufgerufen. Die Debug-Möglichkeiten halten sich hier auch begrenzt an ein printf(). Das Ausweichen auf eine richtige IDE mit SDK ist von Laird wohl nicht vorgesehen. Dafür ist der Einstieg mit der BASIC Programmiersprache wesentlich einfacher als bei den anderen Modulen. Die werden in C oder C++ programmiert und haben ein teilweise Echtzeit OS. All das bleibt dem BASIC Anwender verborgen.

Eines meiner favorisierten Lösungen ist das SaBLE-x von LSR. Das Modul bringt den Texas Instruments CC2540 mit, der der neueste BLE Chip von Texas ist und erst seit einigen Monaten auf dem Markt. Zusammen mit dem Fundus an Beispielen und Applikationen auf der Webseite von Texas Instruments, der kostenlosen IDE Code Composer Studio und dem XDS100v3 auf dem Evalboard steht einer erfolgreichen Entwicklung nichts im Weg.

SaBLE-x mit dem CC2640 auf einem kleinen Prototyp-Board

Das PAN1740 war eines der ersten Module, die ich getestet habe. Es hat im Gegensatz zu den anderen hier aufgezeigten Chipsätzen einen Dialog DA14580 an Board. Dieser besitzt kein Flash Speicher, sondern lediglich ein OTP ROM. Das bedeutet, dass jedesmal, wenn ein Update der Firmware gemacht werden soll das ROM weiter beschrieben wird, bis kein Platz mehr drauf ist und der Chip unbrauchbar. Während der Entwicklungsphase wird der Code im RAM getestet. Das Problem dabei ist, dass das Gerät nicht mit Batterie getestet werden kann, da bei einem Batteriewechsel der Code aus dem RAM verschwindet. Es fällt somit leider für meine Zwecke as.

Ein weiterer Favorit ist das PRoc von Cypress. PRoC steht für Programmel Radio on Chip und ist mit der PSoC (Programmable System on Chip) Familie von Cypress verbunden. Die Entwicklungsumgebung von Cypress, das PSoC Creator, ist eine hervorragende kleine IDE mit Code Generator, Compiler, Debugger und Online Hilfe.

BLE Grundlagen

Die obige Abbildung zeigt die Grundstruktur eines BLE Geräts. Jedes Gerät besitzt mindestens ein Profil. Dieses beinhaltet dann mindestens einen Service (GAP) und diese enthalten Charakteristiken, die Daten des Geräts. Schon zu Beginn wird klar, um BLE zu verstehen und zu Verwenden, müssen einige Begriffe geklärt werden. Es gibt bereits eineige umfangreiche Literatur [1] und viele Webseiten [2], die einen Einblick in BLE geben, daher hier nur das nötigste.

GAP, GATT

Das Generic Access Protocol (GAP) koordiniert das Advertising und die Datenübertragung, wenn keine Verbindung (Bonding) zwischen den Geräten besteht. Weiterhin leitet es bei Bedarf die Verbindung ein, kümmert sich um Authentifizierung und Verschlüsselung der Verbindung. Das Generic Attribution Profile (GATT) ist das Herzstück des Protokolls und kümmert sich um die einzelnen Charakteristiken und wie deren Daten übertragen werden. Es greift, sobald ein Bondig besteht und transferiert aus Charakteristiken und Descriptoren Daten anhand der UUID oder des Handles. Um den Kommunikationsfluss zwischen Device (Peripheral) und Basis (Central) zu steuern wird der CCCS eingesetzt. Der Client Configuration Characteristic Server. Dieser ist eine GATT Characteristic, die angibt, welche Daten veränderlich sind, ob und wann geschrieben, oder gelesen werden darf, oder ob eine Notification stattfindet, sobald der Wert sich geändert hat. All das sieht auf den ersten Blick sehr komplex aus und alles Andere als Energiesparend. Allerdings kommt hier zu Gute, dass die Kommunikation über BLE ein verbindungsloses Verfahren ist, das bedeutet, dass der ganze Aufwand nur einmalig getrieben wird um eine Verbindung mit Verschlüsselung zu erzeugen und das Gerät kennen zu lernen. Wenn auf beiden Seiten dieses Bonding eingeleitet wurde, kann die Verbindung anhand der ausgehandelten Verbindungsparametern weitergeführt werden. Dieser Teil ist dann erstaunlich energiesparend. Eine Funkstrecke funktioniert nur dann, wenn auf beiden Seiten das Radio eingeschaltet ist. Der Empfänger kann nur dann die Daten empfangen, wenn der Empfangsverstärker eingeschaltet ist. Ebenso kann der Sender nur senden, wenn der Sendeversteärker eingeschaltet ist. Ein Mitteilen, dass eine Sendung folgt muss über die Funkstrecke geschehen und so ist es schwierig eine energiesparende Konfiguration zu wählen, wenn der stromhungigste Teil der Schaltung immer aktiv ist. Daher hadelt das BLE-Protokoll zu Beginn einer Verbindung eine Wiederaufnahmezeit aus, nach der sich das Central wieder bei dem Peripheral meldet. Zu diesem Zeitpunkt muss das Peripheral dann sein Radio eingeschaltet haben um auf Anfragen des Centrals am GATT Server zu hören. Das ganze klingt relativ komplex, wenn man aber einmal die grundlgende Struktur verstanden hat stellt sich BLE als simples Protokoll heraus, das darauf ausgelegt ist, möglichst wenig Daten in sehr kurzer Zeit über die Funkstrecke zu senden und dann den größten Teil der Existenz im Tiefschlaf zu verbringen.

Zwei Übertragungsarten

BLE besitzt im Grund zwei Arten der Datenübertragung. Eine unidirektionale, verbindungslose Übertragung von kleinen Datenmengen. Diese Werden in einem so genannten Advertisement Paket verschickt. Dieses Paket besitzt eine Länge von maximal 32 byte und überträgt eine festlegbare Payload. Diese beinhaltet zum Beispiel den Namen des Gerätes, die ID, oder um weche Art es sich handelt. Erzeugt und gehandhabt wird das Paket vom GAP Server. Hier wird dem Zuhörer mitgeteilt, welche Möglichkeitem für eine weitergehende Verbindung bestehen. Verbindungslos bedeutet aber auch, dass die 32 Byte ausgesendet werden, wenn gerade niemand zuhört. Somit besteht für das Peripheral keine Möglichkeit zu erkennen, ob die Daten empfangen wurden. Der Rückkanal ist normalerweise für eine gebondete Verbindung vorgesehen. Dennoch wurde im GAP eine Möglichkeit geschaffen, eine Empfangsbestätigung zu simulieren. Das Peripheral sendet ein Advertisement Paket mit Scanable Flag aus und wartet dann für kurze Zeit auf einen Scan Request.

Beim aktiven Scanen wird vom Central eine Scan Request abgeschickt, auf den
das Peripheral mit einer Scan Response antwortet.

Sobald ein Central ein Advertisement Paket mit diesm Flag empfängt, kann es diesen Scan Request abschicken und dem Peripheral so einerseits mitteilen, dass das Paket empfangen wurde, andererseits auch noch weitere Daten gewünscht sind. Der Scan Request selsbt kann keine Payload übertragen. Für eine echte Bidirektionale Verbindung muss dann auf eine GATT Verbindung mit Bonding zurück gegriffen werden. Soweit erst einmal zu BLE. Der zweite Teil folgt dann in Kürze und wird den GATT-Server sowie eineige Profile näher betrachten.

[1] Townsend, Getting Started with Bluetooth Low Energy: Tools and Techniques for Low-Power Networking (2014) http://www.amazon.de/gp/product/B00K1N23LA [2] Ti.com,TI Bluetooth Smart tutorial – How to get started part 1 (2013) https://training.ti.com/ti-bluetooth-smart-tutorial-how-get-started-part-1

Abschaffung von Bargeld

8. Juni 2015 by Platinenmacher Leave a comment

Heute mal etwas nicht so technisches. Ich habe gerade einen Artikel im Stern zum Thema Bargeld gelesen. Darin ging es um Gründe, weshalb wir weiterhin Bargeld brauchen. Ich bin mir nicht sicher, ob diese Gründe ernst gemeint sind, denn sie sind alles andere als stichhaltig.

Der erste Grund ist gleich der für mich gewichtigste. Kein Geld mehr von der Oma. Dass ohne Bargeld das Zustecken von kleinen Geldgeschenken nicht mehr möglich ist, ist schade, dennoch gibt es auch hierfür Alternativen. Zum Beispiel eine Prepaid Kreditkarte, Guthabenkarten, oder ähnliches. Der zweite Punkt ist auch wieder ein alltägliches und weit verbreitetes Anwendungsgebiet von Bargeld. Der Flohmarkt. Wobei auch hier auf alternative Bezahlmöglichkeiten ausgewichen werden kann, sollte es zu einer Abschaffung von Bargeld kommen. Ich denke hier an Systeme, die mit dem Mobiltelefon funktionieren und den Geldtransfer übernehmen. Ein Feilschen mit dem letzten 5€ Schein, ist dann natürlich nicht mehr so einfach möglich, aber es wird sich sicherlich eine andere Möglichkeit finden für innovative Bezahlmethoden.

Der dritte Punkt, das Sparschwein, ist auch ohne Probleme digitalisierbar. Wieso sollte nicht ein Sparschwein mit Digitalanzeige funktionieren? Der Betrag auf dem Sparschwein wird über die Cloud mit einem Verrechnugnskonto abgeglichen. Immerhin ist es nur eine Frage der Zeit, bis Münzen im Geldbeutel zu Last fallen und dann nur alle paar Monate aus dem Sammelbehälter zur Bank gebracht werden. Das ist lästig, denn die Filialen haben immer nur dann offen, wenn ich arbeiten bin.
Dass Kinder den richtigen Umgang mit Geld lernen müssen ist klar, doch auch jetzt schon ist Geld nicht mehr das in der Hand haltbare Zahlungsmittel, sondern ein viel abstrakteres Modell. Für die Erziehung kann also auf eventuelle Ersatzmittel zurück gegriffen werden und später auf die Realität. Geld ist nur noch virtuell vorhanden und das sollten Kinder durchaus lernen.

Das nächste schwerwiegende Argument ist die Zahnfee. Wie soll die denn das nächste mal für den Zahn bezahlen? Vielleicht mit etwas Anderm als Geld. Das schafft ja auch der Osterhase und der Weihnachtsmann. Teilweise.

Argument fünf zählt nicht. Im Land des Trinkgeldes wird überwiegend mit Kreditkerte bezahlt und das funktioneirt hervorragend. Ich habe es selbst schon ausprobiert. Klar muss ein Umdenken stattfinden, aber dass muss es ständig. Anders werden wir mit unserer Gesellschaft nicht vorran kommen.

Das sechste Argument kann mit dem Fünften in Verbindung gebracht werden. Das Zahlen von Kleinstbeträgen mit der Kreditkarte ist ohne PIN möglich. Um das Argument des Sterns weiter auszubreiten wären hier noch zu nenen: Parkuhren, Kaugummiautomaten, Fahrscheinautomaten,. Zeitungskiste, das Kiosk von Nebenan usw. Für alle diese kleinen Transaktionen gibt es bereits Alternativen. So gibt es zum Beispiel Systeme wie das DipJar, dort können Trinkgelder einfach mit der Kreditkarte bezahlt werden. Karte rein und fertig. Es gibt auch schon Automaten im Parkhaus zum Beispiel. Die akzeptieren eine EC-Karte. Alternativen werden sicher auch auf dem deutschen Markt erscheinen, sobald es sich abzeichnet, dass Deutschland in eine neue Ära der Bezahlung geht.

Das letzte Argument werde ich einfach ignorieren, denn das ist wozu man Bargeld wirklich braucht. Alternativ kann man natürlich auf eine der vielen Kryptowährungen ausweichen. Die sind dann sogar noch schwerer zu verfolgen.

Ich bin generell der Meinung man sollte Bargeld nur noch als Alternative betrachten und nicht als alleiniges oder Hauptzahlungsmittel. Wir leben in einer Zeit, in der Bargeld nur noch einen virtuellen Wert wiederspiegelt und somit keinen echten Wert mehr besitzt. Das haben wir die letzten Jahre gelernt, als wir die Kursschwankungen des Euros erleben durften. Dieser Zwischenschritt zwischen dem Münzwert und dem Geldwert ist nötig, aber ich denke wir sind bereit uns langsam davon zu verabschieden. Zumindes könnten wir mit Münzen anfangen. Lästiges Kleingeld.

ESP8266 – 2: Ferngesteuerte Steckdose

17. Mai 2015 by Platinenmacher Leave a comment

Ein anständiger Name für eine Steckdose

Nachdem der Fenstersensor so weit funktioniert benötigen wir noch einen Aktor, der anhand des Signals sinnvolle Aufgaben erledigen kann. Wie zum Beispiel die Abzugshaube abschalten, wenn das Fenster geschlossen wird. Das ist ziemlich praktisch, wenn man nicht möchte, dass die Abzugshaube Luft durch den Kamin zieht. Daher die Regel, wenn das Fenster in der Küche offen ist, kann man die Abzugshaube einschalten, wenn nicht, dann nicht. Herzstück der Steckdose wird wieder ein ESP8266 Modul sein. Zusätzlich ein AC/DC Converter, der aus der Netzspannung eine akzeptable 5V macht. diese wird über einen LDO auf 3,3V für den Controller heruntergeregelt. Das Relais, dass die Phase schaltet wird aus den 5V versorgt und über einen Transistor gesteuert. Die Schaltung ist also so simpel, dass es sich noch nicht einmal lohnt einen Schaltplan zu zeichnen. Nichtsdestotrotz gibt es hier einen.

Der Aufbau auf Lochraster ist wenig Spektakulär, nur dass darauf zu achten ist, möglichst zu keiner Zeit die Netzspannung in der Nähe des Digitalteils zu haben. Das kann sehr schnell zu magischem Rauch führen.

Aufbau der Hardware im Inneren der Steckdose.

Der Code für den ESP ist wieder auf GitHub zu finden. Es besteht aus zwei Dateien, dem Startup Script und dem eigentlichen Program.
http://gist-it.appspot.com/github/DasBasti/esp8266/blob/master/Aktoren/Steckdose/Timeout/init.lua?footer=minimalNach der Initialisierung wird der WiFi Accesspoint eingerichtet. http://gist-it.appspot.com/github/DasBasti/esp8266/blob/master/Aktoren/Steckdose/Timeout/AP.lua?footer=minimal&slice=1:6Eine Funktion zum ausschalten der Steckdose durch ein Timeout wird festgelegt http://gist-it.appspot.com/github/DasBasti/esp8266/blob/master/Aktoren/Steckdose/Timeout/AP.lua?footer=minimal&slice=7:11Der Server, der auf Port 80 nach Verbindungen lauschen soll wir über eine Zeile gestartet. Der Accesspoint hat nach vorgabe der NodeMCU Software die IP_Adresse 192.168.4.1, sie muss also nicht gesondert festgelegt werden. Zusätzlich wird noch ein Event-Handler angegeben, wenn der Server ein Request erhält. Fertig ist der Software Teil dieses zugegebenermaßen sehr einfachen Aktors. Allerdings kann die Hardware auch dazu verwendet werden, um in das Herbert-Netzwerk eingebunden zu werden. Allerdings ist Herbert am Einsatzort dieser Steckdose noch nicht verfügbar. http://gist-it.appspot.com/github/DasBasti/esp8266/blob/master/Aktoren/Steckdose/Timeout/AP.lua?footer=minimal&slice=13:29

Wichtig ist, dass nach einem vollendeten Projekt der Schreibtisch in den Ursprungszustand zurück

gesetzt wird, um beim Nächten Projekt alles wieder vor Ort zu finden.

Finish eines 3D-Druck aus ABS Kunststoff

27. April 2015 by Platinenmacher Leave a comment

Marvin für 3D Hubs

Meistens erkennt man einen 3D-Druck am Linienmuster der einzelnen Schichten. Jede neue aufgetragene Schicht führt dazu, dass das Ergebnis dieses Linienmuster aufweise. Um ein optisch ansprechendes Ergebnis für den Druck zu erziehlen kann daher nach dem Druck ein Prozess in Gang gebracht werden, der mit Aceton das eben gedruckte ABS wieder anlöst. Da Aceton allerdings ABS sofort auflöst, darf es nicht direkt auf den Druck aufgebracht werden. Bei dieser Methode wird Aceton als Dampf um den Druck herum gebracht. Die Oberfläche löst sich an und ‚verschmilzt‘ zu einer glatteren Struktur. Die Linienmuster komplett kann man damit nur sehr schwer entfernen, aber eine glänzende Oberfläche wird auf alle Fälle erziehlt. Um den Dampf zu erzeugen lege ich in Aceton getränktes Küchenpapier an den Rand einer Tasse. Die kommt dann auf das noch warme Druckbett. Das ganze lasse ich dann für 15 Minuten stehen. Danach ist die Außenseite des Modells noch ziemlich weich und sollte nicht mit dem Finger berührt werden. Nach einigen Minuten ist das Aceton verdunstet und die Ausßenseite des Drucks wieder fest. Und immer an genügend frische Luft denken!

Marvin ist frisch poliert

Aceton-Dampfbad

Renkforce RF1000 von Conrad

18. April 2015 by Platinenmacher Leave a comment

Als ich im Februar auf der Embedded World bei Conrad meine Visitenkarte an einen Gewinnspielzettel getackert habe, habe ich tatsächlich den Renkforce RF1000 3D Drucker gewonnen. Noch auf dem Stand habe ich mich mit einem der anwesenden Verkäufer über den Drucker unterhalten und fand ihn für den Preis von ~2.000€ viel zu teuer. Die Möglichkeit den Drucker zur Fräse umzubauen allerdings hat was. So durfte ich gestern in der Conrad Filiale meinen Hauptgewinn abholen. Zwei sehr nette Mitarbeiter haben mir dann auch noch das Angebot der Mannheimer Conrad Filiale näher gezeigt. Nach der Führung ging es dann in die Abteilung mit den Druckern und 3D Druckern. Dort wurde ich von einem Verkäufer in die Verwendung des RF1000 und den Workflow von Stl Modell nach GCode eingewiesen. Gleichzeitig wurde ein 3D-Scan von mir angefertigt. Der hat allerdings nicht so gut funktioniert; ich bin wohl nicht 3D-fotogen. Neben einem riesigen Karton gab es noch eine 750g Rolle PLA Filament (3mm) dazu und ich war Besitzer eines 2.000€ teuern 3D Druckers. Abgefahren.

Zuhause angekommen begann dann das Aufbauen. Neben dem komplett zusammengebauten Drucker befindet sich noch eine Tüte mit Einzelteilen und dem Stromkabel in der Packung. Der Verkäufer hat mir gesagt, der Drucker sei einsatzbereit und kann sofort losdrucken, dass die Druckerdüse auf dem Druckbett schleift, wenn man um den Achsennullpunkt herum fährt, stellte diese Aussage als nicht ganz die Wahrheit hin.

Also in der Anleitung geschaut und den Übeltäter gefunden. Die Kontermutter des Z-Achsen Nullpunkt ist nicht ganz festgezogen worden. Die Schaube schnell neu eingestellt, Kontermutter fest gezogen, Automatische Druckbettvermessung gestartet. Kalibrierungswürfel von der SD-Karte gestartet und schon ging sie los, die wilde Fahrt. Was während der Vermessung schon aufgefallen ist zeigt sich beim Drucken sehr deutlich. Der RF1000 ist laut. Nicht nur die Drehenden Motoren machen einen riesen Lärm, sondern auch die Halteströme der Motoren sind so getaktet, dass sie noch im höhbaren, aber hohen Frequenzspektrum liegen. Hier wird hoffentlich ein Firmwareupdate Abhilfe schaffen denn der Drucker ist so laut, dass es kein Spaß macht sich im gleichen Raum aufzuhalten.

Die mitgelieferte Filamentführung ist bescheiden und das Filament bleibt teilweise im Schlauch hängen, bzw die Reibung am Schlauch ist so hoch, dass der Extruder es nicht schafft das Filament durch den Schlauch zu ziehen. Glücklicherweise gibt es auf der SD-Karte bereits eine alternative Halterung zum Drucken. Beim Druck musste ich dem Extruder dann Händchen halten um eine konstante Zuführung des Filaments zu erreichen. Dabei ist mir aufgefallen, dass der Extruder noch einiges an Optimierungspotential mitbringt. Das Filament ändert je nach Position des Druckkopfes den Eintrittswinkel in den Extruder. Dieser schabt dann im ungünstigsten Fall kleine Kunststofffäden ab. Diese sammeln sich dann im Extruder und werden von dem geriffelten Rad mitgenommen. Allerdings bleiben sie meistens in den Riffeln hängen und führen so langsam aber sicher zur Verstopfung. Hier werde ich in der nächsten Zeit einige Versuchsobjekte drucken, die das hoffentlich beheben.

Die blaue Bauraumbeleuchtung mit dem orangenen Filament ist allerdings schon ein Hingucker!

Reinigen einer 3D Drucker Düse

12. April 2015 by Platinenmacher Leave a comment

Ich habe heute ausprobiert, wie gut man die Düse eines FFM Druckers mit einer Lötlampe reinigen kann das Ergebnis ist erstaunlich. Die Düse sieht fast aus wie neu.

In den Bildern zu sehen ist die 1mm Düse. Durch den großen Durchmesser muss die Temeratur der Düse beim Drucken auf 255°C erhöht werden. Das führt dazu, dass Kunststoffreste außen an der Düse verkohlen. Mit einer einfachen Propangas Flamme aus der Lötlampe lassen sich die Kunststoffreste problemlos entfernen. Nebenbei wird die Zange gleich noch mit abgeflammt. Die Technik funktioniert auch hervorragend für den Heizblock, sollte der auch mit verkohltem Kunststoff verdreckt sein. Nach dem Flambieren habe ich die Teile auf dem Abziehstein wieder glatt und glänzend geschliffen und eingebaut. Funktioniert hervorragend.

Herbert Reloaded: Haus Automation

6. April 2015 by Platinenmacher Leave a comment

Mein Projekt, die Wohnung komplett über ein Automationsbus zu steuern, geht langsam voran. Aber warum noch ein Haus Automations Bus? Weil die bereits verfügbaren nicht genau dem entsprechen, was ich gerne hätte. Einige sind auf eine dauerhafte Verbindung ins Internet angewiesen, andere sind zu teuer, oder nicht vollständig. Oder benötigen Datenleitungen zu den Knotenpunkten.

Herbert wird einmal die Wohnung steuern und dafür werde ich existierende Hardware umbauen, oder eigene Hardware entwerfen, die genau die Aufgaben erfüllt, die ich mir von einem Hausbus wünsche. Der Aufbau wird folgende Topologie besitzen:

Herbert Topologie V2.0

Das Zentrum von Herbert ist ein Raspberry Pi 2, der in einem externen Festplattengehäuse untergebracht ist. Die externe Festplatte ist immer noch in dem Gehäuse und wird die Speicherzentrale für das NAS. Der Pi hat leider nur langsames USB 2.0. Da das WLAN und die Festplatte über USB angeschlossen sind werden keine neune Geschwindigkeitsrekorde aufgestellt werden können. Für regelmäßige Backups ist es allerdings schnell genug.

Herbert 2.0

Neben dem NAS besitzt Herbert ein openHAB Interface. openHAB ist ein offenes Haus Automation System, dass in Java entwickelt wurde, dadurch ist es auf vielen Plattformen lauffähig. Es besitzt Module um viele bereits verfügbaren Systeme zusammen zu schließen und über die eine Plattform zu steuern. Ich habe mich entschieden die Kommunikation über MQTT zu lösen. MQTT ist eine Kommunikationsplattform für Maschine-zu-Maschine Kommunikation. Man kann sich ein einem Verteiler (Broker) anmelden und für verschiedene Nachrichten anmelden. Danach erhält man die Nachrichten auf diesem Kanal. Der Part des Brokers wird von der offenen Software Mosquitto übernommen, die ebenfalls auf dem Raspberry Pi läuft.

Die Firmware NodeMCU besitzt ein Lua Modul, dass die Kommunikation mit einem MQTT Broker sehr einfach gestaltet. Das Modul mqtt.Client() bietet Funktionen zum Anmelden für Nachrichten, als auch zum Verschicken von Nachrichten.

Diese Nachrichten werden an vereinbarte Topics gesendet. Diese sind in der Konfigurationsdatei von openHAB und in der Lua Quelltext abgespeichert. Weitere Funktionen des NodeMCU sind der Stromsparende Tiefschlafmodus und die Kommunikation über die serielle Schnittstelle. Beide dieser Funktionen werden an unterschiedlicher Stelle benötigt. Der Tiefschlaf ist für die Sensoren notwendig, wenn diese nur Nachrichten senden, aber keine Empfangen sollen. Die serielle Schnittstelle ist für die Kommunikation mit einem anderen Controller gedacht, der dem ESP die nötige Berechnungspower zur Verfügung stellen kann.

Der Auf/Zu Sensor ist in der Aktuellen Version dem Fensterwächter sehr ähnlich. Allerdings ist er noch nicht so weit veröffentlicht zu werden. Alle Module mit allen Programmen und Schaltungen werden aber in der nächsten Zeit hier zur Verfügung stehen. Der Code und die Konfigurationsdateien für Herbert liegen ebenfalls auf GitHub.

Resourcen:
Raspberry Pi Debian Variante: Rasbian
openHAB Dokumentation + Autostart Anleitung
MQTT auf dem Raspberry Pi installieren
NodeMCU API Dokumentation

Unboxing: Raspberry Pi 2 B++

1. April 2015 by Platinenmacher Leave a comment

Ich habe heute ein Paket mit dem neuen Raspberry Pi 2 B++ erhalten. Nachdem die Hardware des Raspberry Pi in der neuen Version 2 auf einen bessern CPU Chip geändert wurde sind die Schnittstellen zu USB und Ethernet die Flaschenhälse zum Controller gewesen. Mit der neuen Version des Raspberry Pi 2 B++ wurde das jetzt auch behoben. Wie angekündigt sind zu Beginn des zweiten Quartals 2015 die ersten Muster des neuen Modells mit Gigabit Ethernet und USB 3.0 verfügbar.

Der neue Raspberry Pi 2 B++

Gleich zu Beginn sieht man, die Muster wurden schnell verpackt, um dem Liefertermin gerecht zu werden. Neben dem relativ aussagelosen Ettikett, dass einfach auf die Verpackung geklebt wurde finden sich keine Hinweise zu der neuen, bessern Embedded-Hardware-Plattform, die im Inneren auf uns wartet. Schnell aufmachen, um die trostlose Erscheinung der Verpackung hinter uns zu lassen und zu sehen, wie die Performance des neuen Gigabit Ethernet im Vergleich zum Alten Pi 2 abschneidet.

ESD – Schutzverpackung im passenden Kartonausschnitt

Der Pi 2 B++ ist in einer ESD-Schutzhülle verpackt und wird in einem Kartonträger geliefert. Was die trostlose Kartonhülle zu erwarten ließ wurde vom Inhalt weit überboten. Das Auspackerlebnis gleicht dem eines hochwertigen Apple Produktes. Nach genauer Betrachtung zeigt sich, dass die Module einfach nur mit auf das Board gebracht wurden. Die Hardware unterstütz zwar USB 3.0 allerdings erkennt der Kernel des aktuellen Rasbian den USB 3.0 und Ethernet Controller nicht. Doch wie bereits angekündigt soll das nächte major Release von Rasbian (RasbiAF) die nötige Software mitbringen.

rPi 2 B++ mit USB 3.0 und Gigabit Ethernet

Soylent Yellow – The future of food, oder der Unterschied zwischen Essen und Nahrungsaufnahme

26. März 2015 by Platinenmacher Leave a comment

Wer einmal den Film Soylent Green gesehen hat wird die dystopische Zukunft die in den 70ern gesehen wurde teilweise wieder erkennen. Nicht, dass es uns schon so geht, aber die exzessive Nutzung von nicht regenerierbaren Ressourcen ist immer noch ein Problem. In unserem, zumindest meinem, Alltag ist das Essen in zwei Situationen aufgeteilt. Die schnelle Nahrungsaufnahme zur Befriedigung des Hungers während man eigentlich andere Dinge tut und zu einem sozialen Ereignis, bei dem das Essen und teilweise dessen Zubereitung mit anderen Menschen im Vordergrund steht.

Es gibt mittlerweile einige Firmen, die sich mit der Erzeugung von pulverisierten Nahrungsmitteln beschäftigen. Ich muss hier wirklich eine Differenzierung machen, denn ein Pulver, dass mit Wasser zu einer nährstoffhaltigen Pampe verrührt wird ist definitiv kein Essen, sondern Nahrung.

Heute kam ein Paket der Firma Queal an. Darin befinden sich acht Beutel mit jeweils einem Tagesbedarf an Nährwerten. Dazu noch ein Fläschchen mit Öl, dass zusätzlich zu dem Pulver und Wasser zu einer Mahlzeit verrührt werden soll. Zu den acht Kunststoffbeuteln gab es noch zwei Sticker und eine Kurzanleitung in der steht, wie ein Queal Meal zubereitet werden soll. Beim Auspacken zeigt sich auch schon warum der Titel Soylent Yellow heißt. Egal welche Geschmacksrichtung für die Pulver angegeben ist, das Pulver ist gelb.

Queal Geschmackstester Set mit allen Geschmacksrichtungen

Donnerstag 19.03.

Was bei dem Starterkit meines Erachtens fehlt ist der auf der Webseite abgebildete Shake-Becher, immerhin handelt es sich um ein Set um mal zu probieren. (Mittlerweile gibt es zu jeder Bestellung einen Becher dazu.) Andererseits mache ich die Mischung sowieso in meinem Mixer. Zum Frühstück gab es heute die Geschmacksrichtung ‚Awesome Apple Pie‘. Wenn mein Apfelkuchen so schmecken würde, wäre er direkt im Müll. Der Geschmack ist pulverig bis mehlig und alles andere als Apfelkuchen. Trotzdem muss ich sagen, dass mir der Geschmack eigentlich egal ist, denn wenn ich ehrlich bin: Wenn ich etwas wegen des Geschmacks essen möchte, dann koche ich mir einfach was. Wenn es allerdings schnell gehen soll, dann kann es auch ruhig mal Pampe sein, die ein wenig nach süß und Mehl schmeckt. Hauptsache es dauert nicht länger als ein Brot zu belegen und ist nahrhafter als ein Glas Wasser.

Die Portionierung der Beutel ist drei Portionen für ein Tag. Ich hätte auch kein Problem damit etwas mehr zu bezahlen, wenn ich dafür Portionsweise abgepackte Einheiten bekomme. Das Problem ist nämlich, dass ich nicht unbedingt einen Beutel am Tag benötige und daher ich die Portion abwiegen muss. All das führt dazu, das die Zubereitung wieder länger wird als alles einfach in den Mixbecher zu schütten. Eventuell werde ich mir einige Dosen vorbereiten, in denen dann immer eine Portion abgewogen ist einfach um sie schnell griffbereit zu haben. Das widerspricht dann leider wieder der Philosophie von schnell als Alternative zu echtem Essen.

Freitag 20.03.

Die zweite Geschmacksrichtung, die ich probiert habe ist ‚Crunchy Choco Cookie‘ das war schon besser als die erste Runde. Der Shake macht zum Frühstück angenehm satt. Das Gefühl hält eine sehr lange Zeit an und ich bin gespannt ob ich es mal schaffe einen kompletten Tag mit Shakes zu füllen und ob eine Tüte ausreichend ist für einen Tag. Zum Abend habe ich einen zweiten Shake getrunken. Diesmal bin ich von ‚Cool Chocolate‘ wirklich positiv überrascht. Der Geschmack ist leicht schokoladig und ich habe die Konsistenz perfekt hinbekommen. Das bedeutet 175g Queal, 1 Teelöffen Öl und etwa 500 ml Wasser im Mixer für 2×30 Sekunden. Dadurch erhält man ein relativ flüssiges aber dadurch nicht zu pulveriges Getränk. Morgen werde ich ausprobieren, wie der Shake sich auch als Müsli-Ersatz macht.

Kleine Anmerkung zum Thema Nährwert: Ich habe eine Portion Shake circa zwei Stunden vor dem Sport getrunken. Mein Magen war nicht zu voll und ich war Energiegeladen. Allerdings habe ich gemerkt, dass ich nach ungefähr einer Stunde Workout ein wenig mehr Power hatte als sonst. Typischer Fall von Unterzuckerung, die ich schon öfter hatte, wenn ich nicht ausreichend gegessen habe. Montag werde ich noch einmal sehen, wie viel Energie mir so ein Shake geben kann.

Montag 23.03.

Am Wochenende gibt es gemeinsames Essen und so hat der Essensersatz keinen Platz gehabt. Heute gab es Queal dann gleich zwei mal. Einmal zum Frühstück. Dann noch einmal zu Abend. Montags bin ich 1,5 Stunden im Training, esse dann zu Abend und habe anschließend noch 2 Stunden Training. Als Geschmacksrichtung gab es ‚Crazy Chocolate Peanut‘ komplett ohne Erdnüsse. Interessanterweise schmeckt der Shake ganz genau so, wie ich Reese’s Peant Butter Cups in Erinnerung habe. Da stellt sich die Frage, wie viel Erdnussgeschmack ist in den Butter Cups?
Der Shake ist nach 1 Stunde immer noch deutlich im Magen zu spüren, allerdings fällt die Bewegung wesentlich leichter als mit beispielsweise einem Käsebrot im Bauch. Genügend Energie bringt der Shake auch mit, sodass nach den drei Stunden Training noch genügend Energie da war um nicht direkt einzuschlafen.

Dienstag 24.03.

Zum Frühstück gab es einen Shake und zu Mittag den nächsten. Langsam gewöhnt sich meine Verdauung auch daran flüssige Nahrung zu erhalten. Ich bin immer noch gespannt, wie ein ganzer Tag mit Queal aussieht und ob das Hungergefühl aus bleibt. Gefühlt ist noch jede Menge Pulver da und ich habe so langsam den Dreh raus, das Pulver aus dem Beutel in den Mixbehälter zu transferieren, ohne absolutes Chaos in der Küche zu fabrizieren.

Mittwoch 25.03.

Ich habe jetzt bald alle Sorten einmal durchprobiert. Doch bis jetzt war keine dabei, die mich wirklich überrascht hat. Es schmeckt alles irgendwie süß und nach Geschmacksstoffen. Trotzdem ist es eine Alternative zu Fastfood. Ich habe diese Woche immer zwei Mahlzeiten mit Queal ersetzt und eine mit echtem Essen. Diese Konstellation ist für mich gut machbar.

Donnerstag 26.03.

Eine Woche habe ich jetzt Queal als Nährstoffquelle verwendet und ich bin überrascht zu sagen, ich kann es mir durchaus vorstellen, weiter zu machen. Die Testpackung ist ungefähr halb leer und ich überlege, welche Sorten ich als nächstes in größeren Mengen bestelle. Allerdings muss ich vorher das mit dem korrekten Portionieren hinbekommen, denn die Küchenwaage ist leider nicht die Beste (Das Display ist fast unmöglich zu lesen) und die drei Portionen pro Beutel sind auch nicht gerade ideal.

Fazit

Ein Soylent als Alternative zu echtem Essen? Unvorstellbar. Als Alternative in Situationen, in denen der Genuss nicht im Vordergrund steht, sondern der Hunger möglichst schnell gestillt werden soll ist es allerdings eine sehr sinnvolle Alternative. Vor allem zu dem Preis. Also: Ausprobieren!

ESP8266 – 1: Fensterwächter

26. März 2015 by Platinenmacher Leave a comment

Wie in einem früheren Beitrag schon beschrieben kann für die ESP8266 Module aus China die Entwicklungsumgebung für NodeMcu aufgesetzt werden. In diesem Beitrag werden wir das erste Projekt erstellen und den Controller programmieren.

Morgens mache ich das Schlafzimmerfenster immer auf, um zu lüften. Wenn ich dann vor dem ersten Kaffee schon auf dem Weg zur Arbeit bin, kann es passieren, dass das Fenster weiterhin offen ist. Mist. Also brauch ich etwas, dass mir sagt, dass das Fenster noch geöffnet ist. Ein Fensterwächter.

Mit Hilfe von einigen Komponenten, dem ESP-01 Modul, einem Mikroschalter und einer Batterie kann genau das erreicht werden.

Das ganze soll neben dem Fenster am Fensterrahmen befestigt werden. Dazu werde ich ein 3D gedrucktes Gehäuse verwenden, in dem alles untergebracht ist. Wenn das Fenster geöffnet wird, wird der Mikroschalter nicht mehr betätigt und schließt den Stromkreis zum Controller. Dieser startet und geht sofort für 10 Minuten in den Tiefschlaf. Wenn er daraus erwacht, ohne dass die Batteriespannung zwischendurch getrennt wurde, verbindet es sich mit dem WLAN Accesspoint und sendet eine Email, die dann auch meinem Mobiltelefon angezeigt wird.

Hardware

Wie schon beschrieben benötigen wir mehrere Komponenten für den Aufbau des Fensterwächters. Das ESP8266 Modul ESP-01 hat 8 Pins mit dem es die wichtigsten Signale nach Außen führt. Wie zu erkennen sind lediglich zwei GPIOs herausgeführt. Für unsere Zwecke benötigen wir aber genau keine. Für das Flashen der NodeMcu Software allerdings werden genau diese beiden Pins benötigt. Weiterhin ist der CH_PD Pin herausgeführt, der sorgt dafür, dass das Modul abgeschaltet ist, wenn er nicht auf VCC liegt. Für Experimentierzwecke habe ich den Pin über einen 100Ohm Widerstand mit VCC verbunden. Zu beachten ist, dass auf dem ESP-01 Modul der Pin zum Aufwecken des Controllers (GPIO 16) nicht mit dem RST Pin verbunden ist.

ESP-01 Pinbelegung

Das Modul kommt mit einer Firmware ausgestattet, die über die Serielle Schnittstelle angesprochen werden kann. Um diesen Betriebsmodus zu verwenden benötigt man dann noch einen zweiten Controller, der mit dem Modul kommuniziert. Wir wollen allerdings nur den einen Controller einsetzen, müssen also die darauf befindliche Firmware ändern. Das kann ganz einfach mit dem NodeMcu Flasher passieren. Dazu verbinden wir die Pins GPIO0 mit GND und GPIO2 mit VCC. Dadurch befindet sich der Chip nache einem Reset in einem Zustand indem der Bootloader über die serielle Schnittstelle eine neue Firmware in den Speicher des Moduls schreiben kann. Der Flasher übernimmt alles was dafür notwendig ist.

Mit dem ESPlorer kann jetzt die Lua Software auf dem Modul geschrieben werden. Das Erste was wir tun ist eine ‚init.lua‘ erstellen, die wird beim Start des Controllers ausgeführt.
Der grundlegende Programmablauf ist oben schon aufgeführt:

Power up
Deep Sleep für 10 Minuten
Wake up
Verbinde mit WLAN Router
Sende Email
Deep Sleep bis Power down

Die API von NodeMcu gibt Informationen über die benötigten Funktionen:

Es fehlt lediglich der Programmteil zum senden der Email-Warnung.

So weit zur Theorie. Ein Problem zeigt sich bei der Umsetzung des Email Versandes. Da der ESP sich nicht als SMTP Server behaupten kann, Eine Möglichkeit ist es die Kommunikation mit einem SMTP Server manuell zu programmieren, einfacher ist es jedoch einen bereits existierenden Service, wie zum Beispiel PushingBox.com zu nutzen. Dort kann man über eine HTTP API eine Notification, oder eine Email abschicken. Das Ganze ist dann auch von dem PC aus konfigurierbar und lässt auf dem ESP genügend Platz für andere Funktionen.

Gestartet wird immer in der ‚init.lua‚. Egal ob aus dem Power down, oder dem Tiefschlaf. Das führt dazu, dass nicht genau erkannt werden kann, aus welchem Vorzustand der Chip kommt. Es wird also nach dem Aufwachen ein Timer gestartet und der Chip befindet sich im idle Modus. Welche Folgen das für den Stromverbrauch und die daraus resultierende Batterielaufzeit hat, wird sich noch herausstellen. http://gist-it.appspot.com/github/DasBasti/esp8266/blob/master/Sensoren/Fenster/FensterOffenWarner/init.lua?footer=minimal&slice=8:11
Nachdem die 10 Minuten, oder (600000 ms) abgelaufen sind, wird die Datei ‚fenster.lua‚ aufgerufen und interpretiert. Als erstes muss das WiFi-Modul gestartet werden. Dann wird die Verbindung mit dem Accesspoint hergestellt. http://gist-it.appspot.com/github/DasBasti/esp8266/blob/master/Sensoren/Fenster/FensterOffenWarner/fenster.lua?footer=minimal&slice=5:8
Sobald die Verbindung zum Accesspoint besteht und das Modul eine IP-Adresse erhalten hat, soll die Funktion pollPushingBox() aufgerufen werden. Dazu verwenden wir einen neuen Timer: http://gist-it.appspot.com/github/DasBasti/esp8266/blob/master/Sensoren/Fenster/FensterOffenWarner/fenster.lua?footer=minimal&slice=33:41
Die pollPushingBox() Funktion baut eine TCP Verbindung mit dem PushingBox Service auf und sendet einen API Request um einen Alarm auszulösen. http://gist-it.appspot.com/github/DasBasti/esp8266/blob/master/Sensoren/Fenster/FensterOffenWarner/fenster.lua?footer=minimal&slice=12:26 http://gist-it.appspot.com/github/DasBasti/esp8266/blob/master/Sensoren/Fenster/FensterOffenWarner/fenster.lua?footer=minimal&slice=28:31
Nachdem der Server geantwortet hat, geht das Modul in den unendlichen Tiefschlaf. Erst ein Wegfallen der Batteriespannung (durch Schließen des Fensters) wird der Chip resettet und bei erneutem Öffnen beginnt der Code wieder in der ersten Zeile der init.lua.

Der Code zeigt, wie einfach mit NudeMcu und Lua ein ESP2866 für einfache Zwecke verwendet werden kann.