Wegen der schwierigen Beschaffung des Raspberry Pi Zero teste ich das System headless für IoT Anwendungen.
Auf Github habe ich einige Scripts zum C.H.I.P. abgelegt. Zur Verdeutlichung der Performance sind da Ergebnisse von Benchmarks gelistet.
Zum Vergleich habe ich den C.H.I.P. mit in die Tabelle der UNIXBench Resultate mit aufgenommen.
Zahlreiche Online Medien habe in den letzten Tagen die neueste Erweiterung der Raspberry Pi Familie herausgestellt. ASUS erweitert mit dem Tinker Board die Familie hinsichtlich Performance deutlich.
Den Kern des Systems ist eine Quad-Core ARM Cortex A17-CPU mit 1,8 GHz Taktfrequenz und eine Mali-T764 GPU dar. Die Speicherausstattung des Systems liegt bei 2 GB. Für die Ausgabe kann wahlweise ein HDMI-Port mit einer maximalen Auflösung von 3840 x 2160 Pixel (4K) oder ein 15-Pin MIPI DSI dienen. Bei der Soundausgabe setzt das System auf einen Realtek-Chip mit 192 KHz/24-Bit Audio. Für den Anschluss einer Kamera steht ein CSI Port zur Verfügung. Als Betriebssystem wird Debian mit KODI eingesetzt.
Bestellt kann das Tinker Board derzeit nur über Farnell Irland zum Preis von ca. € 55,00.
Um realistisch abschätzen zu können, ob sich ein Produkt wie geplant realisieren lässt, ist nichts so aussagekräftig wie reale Hardware, auf der die Software getestet werden kann.
Mit dem Rapid Demonstrator Service sichert die Mainzer Phytec zu, schon nach 15 Arbeitstagen einen funktionsfähigen Prototyp zu liefern und gibt damit dem Entwickler ein Werkzeug in die Hand, welches die Evaluierung einer Produktidee bzw. den Aufbau eines Funktionsmusters oder Prototypen mit einem seriennahen Entwicklungsstand ermöglicht. Durch Einsatz eines solchen Design Tools wird es möglich, eine Entwicklung ohne Designbruch auf der Grundlage erprobter Hard- und Software-Komponenten vorzunehmen. Durch die Wiederverwendung erprobter Komponenten sinkt das Entwicklungsrisiko beträchtlich.
Nachdem in diesem, in der Zeitschrift Elektronik Heft 2/2017 veröffentlichten Beitrag der Entwicklungsprozess unter Verwendung des Rapid Demonstrator Service betrachtet wird, wird dieser Service in einer zweiten Folge von der Eingabe der gewünschten Funktionalität bis hin zur Inbetriebnahme des resultierenden Board untersucht werden.
Die Palette der Linux-Devices für weniger als 10 $ ist mit dem Omega2 von Onion um ein interessantes Teil erweitert worden. Hervorgegangen aus einer Kampagne bei Indiegogo wird dieses Devices nun ausgeliefert. Ich habe mein Exemplar heute zusammen mit einem Power Dock erhalten.
Meine Erfahrungen mit dem Omega2 werde ich in einem eigenen Blog zusammentragen.
Als Grundlage für meine Experimente habe ich von Github das Dragino Programmbeispiel lora_shield_ttn.ino verwendet und mit einer Sensorerweiterung versehen. Zur Erfassung der Umgebungstemperatur habe ich einen Temperatursensor TMP36 mit A0, VCC und GND verbunden.
Auf die Angabe des Listings des Programms lora_shield_ttn_tempC.ino möchte ich an dieser Stelle aus Platzgründen verzichten und auf Github verweisen. Dort ist das Programm abgelegt und kann von da heruntergeladen werden. Damit sind alle Vorkehrungen für das Versenden der Sensordaten in das LoRaWAN getroffen und es ist nun am Gateway diese Daten auch zu empfangen. Der Consolen Output zeigt die Messages dieser LoRa Node.
Die vom TTN LoRa Server empfangenen Messages zeigen hier im Bild Temperaturwerte von 24,71 und 27,64 °C (letzteres nach Auflegen eines Fingers auf den TMP36).
Beim Auruf des TTN LoRa Servers ist etwas Geduld notwendig. Nur alle 10 Minuten wird eine Message vom Gateway gesendet. Historische Daten werden nicht angezeigt.
Vom TTN Lora Server werde die Daten via MQTT bereitgestellt und können da mit einem MQTT Viewer (hier habe ich MQTTlens verwendet) dargestellt bzw. über Subscribe in eine Anwendung gezogen werden.
Heute habe ich zu Testzwecken ein LoRa Gateway installiert. Im TTN Mapping (TheThingsNetwork) ist es als „CK LoRa Gateway“ markiert.
Ein LoRa Concentrator iC880A ist bei IMST bestellt, dann wird das Gateway LoRaWAN kompatibel.
In den nächsten Tagen bekommt die eingesetzte LoRa Node (Dragino Lora Shield & Arduino Uno) noch einen Temperatursensor, dessen Daten dann übermittelt werden. Es folgen später stromsparende Varianten auf Basis des LoRa Transceiver RFM95W & Arduino Pro Mini, Raduino32 SX1272 und LoPy.
Mit dem LoPy habe ich nun nach dem WiPy das zweite Controller-Board von pycom in Betrieb genommen. Die Inbetriebnahme gestaltet sich nach der pycom Doku recht problemlos.
Aus der Pymakr IDE heraus habe ich über USB-Serial mit den Boards kommuniziert. Ganz wichtig ist ein gelegentliches Firmware Update, da die Firmware selbst noch spürbar in Entwicklung ist.
Ich hatte folgende Situation vorgefunden, die jeder mit seinem System durch die folgenden Schritte nachvollziehen kann:
>>>import os >>>os.uname()
WiPy:
(sysname='WiPy', nodename='WiPy', release='0.9.2.b2', version='7713d55 on 2016-10-28', machine='WiPy with ESP32')
LoPy:
(sysname='ESP32', nodename='ESP32', release='0.9.0b', version='8785822 on 2016-10-06', machine='LoPy with ESP32')
und musste feststellen, dass nicht alle von mir für erste Tests benutzten Funktionen erwartungsgemäß funktionierten. Nach dem Firmware-Update zeigte sich die Situation dann folgendermaßen:
WiPy:
(sysname='WiPy', nodename='WiPy', release='0.9.6.b1', version='v1.8.6-40-gd10463e on 2016-11-25', machine='WiPy with ESP32')
LoPy:
(sysname='LoPy', nodename='LoPy', release='0.9.6.b1', version='v1.8.6-40-gd10463e on 2016-11-25', machine='LoPy with ESP32')
Das Firmware-Update war also erforderlich und erfolgreich.
Mit ein paar einfachen Files habe ich meine Tests begonnen. Alles weiteren Experiment werden auf GitHub abgelegt.
Die Terminal-Ausgabe der Scripts hello.py, blink.py und TMP36.py sind im folgenden Screenshot zu sehen.
Weitere Infos und Programmbeispiele sind hier zu finden.
Das Echtzeitverhalten des Single-Core Raspberry Pi wurde im Beitrag Echtzeitfähiger Raspberry Pi untersucht. Der RT Patch des Kernel wurde beschrieben.
Mittlerweile sind auch Ergebnisse für den Quad-Core Raspberry Pi 2 verfügbar. In der QA-Farm von OSADL wird das Real-Time Verhalten einem ständigen Monitoring unterzogen. Bei Interesse sollte unbedingt der betreffende Beitrag in den OSADL News gelesen werden.
Mit dem RT Patch des Kernels werden nunmehr die folgenden Latenzzeiten erreicht.
Cayenne bezeichnet sich selbst als den ersten Drag & Drop IoT Builder in der Welt. Grund genug das Ganze auszuprobieren. Details sind unter http://www.cayenne-mydevices.com/ zu finden.
Was wird benötigt?
Am Einfachsten ist die Installation mit dem Smartphone. Nach Auswahl des hier verwendeten Raspberry Pi werden Libraries und ein Agent auf den Raspberry Pi installiert und nach ca. 10 Minuten kann das erste Projekt gestartet werden.
Ich habe hier einen mit einem Enviro pHAT von Pimoroni ausgestatteten Raspberry Pi Zero wegen des dort vorhandenen AD-Converters ADS1015 verwendet und an diesen einen Temperatursensor TMP36 angeschlossen. Dieser liefert eine zur Temperatur proportionale Ausgangsspannung.
Zuerst fügt man auf dem Cayenne Desptop den ADC hinzu und bekommt damit das Feld Analog Input, selektiert den ADC-Kanal und verbindet dann den Sensor TMP36 mit diesem. Daraufhin erhält man das Feld TMP36. Die anderen Felder werden defaultmäßig bereitgestellt. Die Anzeigen lassen sich konfigurieren.
Mit wenigen Schritten hat man erreicht, dass auf dem Dashboard eine funktionierende Anzeige der gemessenen Temperatur erscheint.
Ebenso kann der Verlauf des Messwerte über einer vorwählbaren Zeit als Graph dargestellt werden.
Die Cayenne Plattform ist noch in Entwicklung. Neue Devices, wie bspw. LoRa, kommen hinzu. Die Palette der Sensoren und Aktoren wird erweitert etc. Diesen Entwicklungsstand spürt man an der einen oder anderen Ecke. Ein Blättern im Forum hilft den Eindruck etwas abzurunden. Interessant bleibt der Ansatz aber allemal.
Olimex bietet ein ESP32-DevKitC an, mit dem der Einstieg gestartet werden kann.
Die technischen Ressourcen sind hier zu finden.
ck blog 