Archiv der Kategorie: Internet of Everything

Teensy 4.0 – NXP’s i.MX RT1062 für alle

Teensy 4.0

Mit dem Teensy 4.0 steht ein kompaktes, aber dennoch handliches Boards mit NXP’s i.MX RT1062 (Arm Cortex-M7), einem sogenannten Crossover Processor (Kombination aus Mikrocontroller & Application Processor) , zur Evaluation bereit.

Die Ausstattungsliste im Datenblatt liest sich wie der Wunschzettel eines Embedded Entwicklers in der Vor-Weihnachtszeit. Ein Blick ins Datenblatt (https://www.nxp.com/part/MIMXRT1062CVL5A ) zeigt das.

Paul Stoffregen hat dafür gesorgt, dass der Teensy 4.0 auch als Arduino-kompatibler Mikrocontroller gehandhabt werden kann ( https://www.pjrc.com/teensy-4-0/ ) und somit der derzeit wohl leistungsfähigste Arduino zu einem sehr moderaten Preis von USD 19.95 zur Verfügung steht.

Den ersten Eindruck möchte ich mit den erweiterten Benchmarks aus meinem letzten Post https://ckblog2016.net/2019/08/19/maixduino/ beschließen.

Verglichen wurden eine Arduino Due (AT91SAM3X8E@ 84 MHz), eine ESPduino-32 (ESP-Wroom-32@80 MHz), ein Maixduino (Kendryte K210 RISC-V@400 MHz) und ein Teensy 4.0 ( i.MX RT1062@600 MHz). Hier sind die Resultate der beiden Benchmarks:

Benchmarkergebnisse Sieve of Erastothenes
Benchmarkergebnisse Coremark 1.0

Wie die beiden Benchmarks deutlich zeigen, hat Teensy 4.0 mit seinem mit 600 MHz getakteten i.MX RT1062 die Performance des Maixduino wesentlich überboten und kann als derzeit leistungsfähigster Arduino-kompatibler Mikrocontroller (oder eben als Crossover Processor) angesehen werden.

M5Stack Prototyping Platform

Im Blogbeitrag Rapid Prototyping mit M5Stack hatte ich die M5Stack Family als interessante Prototyping Platform vorgestellt.

Dieser Beitrag zeigt an Hand einer einfachen Wetterstation als Beispiel einer nahezu beliebigen IoT-Anwendung, wie mit M5Stack Komponenten schnell ein ansehnlicher Prototyp erstellt werden kann

Mit einem M5Stack Basic Core und einer ENV Unit zur Erfassung von Temperatur, rel. Luftfeuchte und Luftdruck sowie einem SIM800L Module zum Versenden der Daten über GPRS hat man schnell eine abgesetzte Wetterstation aufgebaut, die auch ohne WLAN Zugang autonom funktionieren kann.

Der M5Stack Core besitzt in seinem Unterteil nur einen 150 mAh. Will man die Akkuleistung, beispielsweise zur Pufferung, erhöhen, dann kann ein M5GO/FIRE Battery Bottom Charging Base als Unterteil eingesetzt werden.

M5Stack Basic Core

Die ENV Unit ist ein Umgebungssensor, der zur Messung von Temperatur, relativer Luftfeuchtigkeit und Luftdruck verwendet werden kann. Intern werden die Sensoren DHT12 und BMP280 verwendet.

Der DHT12 ist eine Weiterentwicklung des bekannten DHT11 Sensors, der nun präziser und mit einer I2C-Schnittstelle ausgestattet ist. Der BMP280 ist ein barometrischer Drucksensor, der speziell für mobile Anwendungen entwickelt wurde.

Kontaktiert wird die ENV Unit über den an der linken Seite des M5Stack Basic Core angeordneten Grove-PortA (i2C).

ENV Unit with Temperature Humidity Pressure Sensor (DHT12+BMP280)

SIM800L ist ein Mobiltelefonmodul auf Basis des SIM800L GSM / GPRS-Modul von SIMCOM,

GSM Module SIM800L with MIC & Headphone Jack

Mit diesen drei Komponenten wird die Wetterstation aufgebaut. Die Kosten der ansprechenden Anordnung belaufen sich dabei auf:

KomponentePreis
M5Stack Basic Core$ 27.95
ENV Unit$ 3.39
GSM Module SIM800L with MIC & Headphone Jack $ 9.95
Summe$ 41.29

Die folgenden Bilder zeigen den Ablauf vom Programmstart bis zum Abschluss der Übertragung des Temperaturmesswertes, der hier für die Evaluierung ausreichend erschient.

Initialisierung nach Programmstart
Messwerte erfasst – Versenden zum Thingspeak Server
Messwerte versendet

Der Quelltext für das Programm M5Stack_DHT12_Thingspeak ist auf Github unter https://github.com/ckuehnel/M5Stack/tree/master/M5Stack/M5Stack_DHT12_Thingspeak abgelegt. Anpassungen auf weitere Parameter und andere Displayausgaben können nach dem Download leicht vorgenommen werden. Programmiert wurde mit der Arduino IDE v1.8.9.

Das Ergebnis der abendlichen Abkühlung ist im folgenden Bild zu sehen.

Temperaturverlauf 6.08.2019 abends

Ein Wort noch zur Stromversorgung. Der SIM800L ist bekannt dafür, dass er in Spitzen bis zu 2 A Stromaufnahme verzeichnet. Die Spannungsversorgung kann beim M5Stack aber vernünftig nur über den USB-Anschluss erfolgen. Dadurch ist der zur Verfügung stehende Strom limitiert.

Ich habe einen D-Link DUB-H4 USB-Hub verwendet, der vier Downstream-USB-Anschlüsse Typ A (Buchse) inklusive Schnellladeanschluss besitzt und durch ein externes Netzteil gespeist wird.

Der fürs iPad u.a. stromhungrige Verbraucher gedachte Schnellladeanschluss dient hier zur Stromversorgung und die sporadischen Brown Out-Resets des ESP32 sind Vergangenheit.

Messung der Wassertemperatur

Auf meiner Website http://ckuehnel.ch/WetterVitte.html habe ich Temperaturangaben für Vitte auf der Insel Hiddensee.

Die Angaben aus dem Netz für die Wassertemperatur der Ostsee zeigen erhebliche Differenzen. Gelistet sind auf der Website Wassertemperaturen aus folgenden Quellen:

Mit dem im Post Rapid Prototyping mit M5Stack beschriebenen M5StickC und einem wasserdichten DS18B20-Temperatursensor mit einer Zuleitungslänge von 1 m habe ich ein portables Messgerät aufgebaut, mit dem die Wassertemperatur in 1 m Tiefe gemessen werden kann.

Die Messwerte für den Zeitraum 4.06. bis 13.06.2019 sind als Excel-Sheet abrufbar.

Gemessen wurde am Wasserrand nahe der Oberfläche und im Wasser (Strandnähe) bei 1 m Wassertiefe. Interessant sind für mich folgende Feststellungen:

  • die Messwerte schwanken viel stärker als vom BSH für Kloster angegeben
  • bei Ostwind sinkt die Wassertemperatur erheblich, was in den BSH Daten kaum sichtbar wird
  • bei Wellengang unterscheiden sich die Messwerte am Rand nur wenig von denen in 1 m Tiefe, was sich durch die Durchmischung des Wassers erklärt.
  • es erscheint dennoch recht schwierig, von solchen Messungen verallgemeinerungsfähige Aussagen abzuleiten
  • definierte Messbedingungen und die Einhaltung dieser sind unabdingbare Voraussetzungen für die Vergleichbarkeit solcher Messwerte
Lage der Messstelle

Maduino GPRS A6

Maduino GPRS A6 ist ein kostengünstiger Netzwerkknoten für das IoT. Der Hersteller
Makerfabs mit Sitz in Shenzhen, China hat auf dem Board einen Mikrocontroller ATmega 328, ein GRRS/GSM-Modul AI-Thinker A6, ein und ein integriertes Power-Management integriert.

Maduino GPRS A6

Das GRPS/GSM-Modul A6 unterstützt Quad-Band 850/900/1800/1900 MHz, das jedes GSM-Netzwerk abdeckt. In Verbindung mit einer SIM-Karte können Daten über GPRS übertragen werden. In meinem Post 2G für IoT Anwendungen hatte ich hierzu entsprechende Hinweise gegeben.

Das Modul kann über die Arduino IDE programmiert werden. Im Wiki sind Hinweise zur Inbetriebnahme und Programmierung enthalten. Hinweise zu einem Firmware Update sind hier zu finden.

Erfassen von Wetterdaten – gar nicht so einfach

Mit zahlreichen, heute angebotenen Sensoren zur Erfassung von Wetterdaten, wie Temperatur, relativer Luftfeuchte, Druck u.a.m. können mit etwas Elektronik sehr einfach Wetterdaten erfasst und im Internet bereit gestellt werden.Openweathermap.org bietet beispielsweise ein API an, mit dessen Hilfe diese Daten im Openweathermap Mapping sichtbar werden. Anforderungen an die Messstelle selbst habe ich auf deren Website nicht gefunden.

Temperatur Mapping

Das Temperatur Mapping in meinem Umfeld zeigt am 2.05.2019 bei bedecktem Wetter keine grösseren Abweichungen.

Mich hat das Verhalten der Openweathermap Messstation an meinem Wohnort im Vergleich zu lokalen Wettersensoren interessiert. Ich habe deshalb selbst einen Temperatursensor DS18B20 in einem von direkter Sonneneinstrahlung geschütztem Bereich installiert und vergleiche die beiden Messwerte. Bei großzügiger Betrachtung kann man sagen, dass beide Messwerte einen Offset von 2.5 ° aufweisen. Selbst wenn man diesen Offset eliminiert, gibt es über den Tagesverlauf unerfreuliche Abweichungen.

Da die Messwerte doch rechte Unterschiede auswiesen, habe ich ein weiteres Außenthermometer hinzugenommen, was allerdings in den Morgenstunden durch Sonneneinstrahlung keine brauchbaren Werte liefert. Das Außenthermometer sendet seine Daten nur zwischen 5:00 und 20:00, was für den Vergleich aber unerheblich sein sollte.

Die Grafik zeigt deutlich, dass ohne Sonnenbestrahlung die Ergebnisse der Openweathermap Wetterstation ausreichend gut repräsentiert werden.

Die Wahl der entsprechenden Messbedingungen entscheidet also erwartungsgemäß über das Ergebnis

Die Situation der im Internet zugänglichen Messstellen kann aber auch ganz anders aussehen. J. Kachelmann zeigt das in seinem Blog im Tagesanzeiger mit dem Titel „Das ideale Geschenk zur Konf“ und wirbt für die gute alte Wetterhütte, die immer noch nicht an Bedeutung verloren hat und für zuverlässige Messwerte die Grundlage schafft.

2G für IoT-Anwendungen

Bislang schon bereits für tot erklärt und mit Abschaltungsszenarien belegt, stellt das mittlerweile betagte 2G-Netz immer noch eine Alternative zu 3G/4G und 5G dar.

Dass ein schnelles Internet und damit 5G seine Bedeutung haben, ist keineswegs strittig. IoT Anwendungen mit geringem Datenvolumen und mglw. auch geringen Datenraten kommen aber mit deutlich weniger Ressourcen aus.

Vergleicht man die Netzabdeckung der deutschen Telekom, dann bietet auch das 4G-Netz noch Lücken, die das 2G-Netz nicht bietet. Bei den anderen Anbietern sieht das weniger erfreulich aus.

Netzabdeckung 4G Telekom

Kostengünstige GSM-Module sowie preiswerte und flexible IoT-Tarife lassen 2G für IoT-Anwendungen (M2M) durchaus interessant erscheinen.

Ich verwende für einen abgesetzten Temperatursensor einen Arduino Uno und ein SIM800L EVB.

SIM800L EVB am Arduino Uno

Alternativen sind z.B. Maduino GPRS oder das GSM Modul aus der M5Stack-Familie.

Auf die Software selbst möchte ich hier nicht eingehen. Programmbeispiele zum SMS-Versand und HTTP-Zugriff sind auf Github zu finden.

Ich verwende hier den Mobilfunkanbieter ThingsMobile, der sich ausschließlich dem IoT widmet und international aufgestellt ist.

Der SMS-Versand ist einfach und bequem, allerdings kostenmäßig nicht zu empfehlen. Ich sende den Temperaturmesswert über HTTP-GET alle 5 Minuten an den Thingspeak-Server zu Visualisierung. Die erhobenen Messwerte können über die URL abgegriffen werden. Der Sensor selbst liegt auf meinem Arbeitstisch, misst also nur die Raumtemperatur.

Interessant sind die entstehenden Kosten. Aus dem Thingsmobile Report für die vergangene Woche kann man die folgenden Daten entnehmen:

Report für KW15

Der Datenverkehr belief sich auf 2.19 MB, die € 0.22 gekostet haben. Der Auszug aus dem Detailreport gibt einen Überblick über die versendeten Daten. Die Datenpakete sind entweder 980 oder 1950 Byte, was zu 370 KB am Tag führt. Diese 370 KB kosten dann € 0.036.

Auszug aus dem Report für den 15.04.2019

Bei diesen Kosten kann aus meiner Sicht für so oder ähnlich angelegte IoT-Anwendungen bedenkenlos mit dem 2G-Netz gearbeitet werden.

Open-Source Real-Time OS für das IoT

Steht man heute vor der Aufgabe, ein neues Embedded System zu entwickeln, dann wird in den Anforderungen kaum die Anforderung nach einer Netzwerkverbindung fehlen. Dabei spielt es in erster Linie keine Rolle, ob es sich um eine drahtlose oder drahtgebundene Kommunikation handelt, ob die Kommunikation durch die Anwendung genutzt wird oder einen Remote Access für Konfiguration und Service darstellt. Möglicherweise lassen sich diese Dinge auch kaum vernünftig trennen.

Ein Embedded System, welches derartige Anforderungen erfüllen muss, ist mit vernünftigem Entwicklungsaufwand nicht ohne Betriebssystem umsetzbar. Die Suche nach einem für die betreffende Aufgabenstellung geeigneten Betriebssystem umfasst, viele und sehr unterschiedliche Aspekte.

Betrachtet man die Langlebigkeit von Investitionsgütern, dann erscheint schon aus strategischen Gründen der Einsatz eines OS-RTOS zwingend. Einer ersatzlosen Abkündigung eines etablierten, proprietären RTOS kann auf diese Weise der Schrecken genommen werden. In einer gewissen Klasse von Embedded Systems bis hin zu Supercomputern gibt es mit Linux ein ausgezeichnetes Beispiel für ein solches Open Source Betriebssystem.

Damit ist Linux heute ein mächtiges Betriebssystem, welches aber auch gewisser Ressourcen bedarf und für Systeme mit kleinem Footprint, geringen Ressourcen und möglichst für Batteriebetrieb angepasstem Stromverbrauch weniger geeignet ist.

Analysiert man aus Github Daten für Code Frequency, Commits und Contributions für Contiki, RIOT und Zephyr, dann kann deutlich eine größere Aktivität der Community beim Zephyr OS gegenüber den anderen beiden RTOS verzeichnet werden. Natürlich ist das Zephyr OS auch ein „junges“ RTOS, was nicht in allen Bereichen bereits ausgereift sein kann.

Das Zephyr Project (https://www.zephyrproject.org/what-is-zephyr) ist ein von der Linux Foundation gehostetes Collaboration-Projekt, eine Open Source Zusammenarbeit, die führende Kräfte aus der gesamten Branche zusammenbringt, um mit dem Zephyr OS ein skalierbares Echtzeit-Betriebssystem (RTOS) für mehrere Architekturen ressourcenbeschränkter Geräte zu entwickeln.

Der in der Zeitschrift Design & Elektronik erschienen Beitrag mit dem o.a. Titel (Design & Elektronik 3/2019, S. 42-48  ) soll Einblicke in das Zephyr OS und die Zephyr Entwicklungsumgebung geben. An Hand einiger einfacher und nachvollziehbarer Programmbeispiele wird die Vorgehensweise bei der Programmierung von Anwendungen und der Build Prozess dokumentiert. Die Programmbeispiele selbst sowie dazugehörige Screenshots sind auf Github unter https://github.com/ckuehnel/zephyrtests abgelegt.

Das Zephyr OS ist ein Open Source RTOS, welches durch das von der Linux Foundation gehostete Zephyr Project und die Nähe zu Linux das Potential hat, bei Embedded Systems mit kleinem Footprint in Zukunft vergleichbar erfolgreich zu werden, wie es Linux bei Systemen mit mehr Performance schon länger ist. Der Erfolg wird sicher stark durch die Community geprägt. Ausdauer und Kraft sind der Community zu wünschen. Die zentrale Mailinglist des Zephyr Projects [ https://lists.zephyrproject.org/g/main ] gibt aktuell Auskunft über die laufenden Aktivitäten.