Mein Traum seit vielen Jahren ist es ein drahtloses Multimeter aufzubauen. Mit den M5Stack Geräten ist dieser Traum der Wirklichkeit sehr viel näher gerückt und mit dem Erscheinen der isolierten Units VMeter und AMeter steht der Realisierung nun nichts mehr im Wege.

Auf dem Bild seht Ihr den ersten Testaufbau. Dank der Steckmöglichkeiten war es schnell zusammengesteckt und getestet und funktionierte. Die Spannungswerte sind zwar nicht real aber die Grundsätzliche Funktion ist gegeben. Die Spannungseingänge sind offen und fangen sich offenbar alle möglichen Störsignale ein. Die Stormaufnahme von 500mA enthält den Ladestrom für den Akku des M5Stick Cplus. Mit geladenem Akku sind es immerhin noch 460mA.

Ganz einfach war es nicht diese Kombination zu realisieren, weil die UIFlow-IDE es nicht ermöglichte ohne weiteres die Units am PaHUB zu betreiben. Erst der in diesem Beitrag beschriebene Trick brachte den Durchbruch:

M5Stick C und ATOM: Units hinter PaHUB betreiben – geht jetzt auch mit UIFlow!

Der Workaround ist nun nicht mehr erforderlich.

Die Units können inzwischen auch direkt in der UIFlow-IDE hinter einem PaHUB benutzt werden.

Das erste Testprogramm

Messgenauigkeit

VMeter Unit

Um überhaupt etwas messen zu können habe ich eine LiIon-Zelle an alle drei VMeter angeschlossen. Eine davon invers gepolt. Das geht Dank galvanischer Trennung der Messteile problemlos. Die Anzeige schwankt zwischen 3,463 und 3,475 Volt. Als eine Unsicherheit von 12 mV. Die Spannungsänderungen springen in 4 mV Schritten. Mein Rigol DM3068 zeigt 3,4629 Volt an. Das entspricht -0% … +0,35% Abweichung. Für allgemeine DIY-Messungen völlig in Ordnung.

AMeter Unit

Zum testen der AMeter habe ich alle drei und das Rigol in Reihe geschaltet und an ein Hameg HM8040 Netzgerät angeschlossen. Mit dem Stromegrenzungspoti habe ich den Stron eingestellt. Da ich die Stromanzeige auf ganze mA eingestellt habe gibt es bei den kleineren Strömen ungenauigkeiten. dazu werden ich anschließend eine Weitere Messreihe durchführen.

DM3068	AMeter
10,0776 mA	10 mA
20,461 mA	20/21 mA
50,762	51/50 mA
99,315	100/99 mA
201,025	201/202 mA
301,47	301/302/304 mA
404,92	405/406/407 mA
mehr geht nicht beim HM8040

Auch diese Werte können sich sehen lassen. Alle Abweichungen <1%.

Maximal können Ströme bis ±4 A gemessen werden. Die höheren Ströme werde ich später testen. Genauso wie Ströme <1 mA.

Drahtlose Kommunikation

Ein großer Vorteil des ESP32 ist es, dass die Messwerte drahtlos übertragen werden können. Dafür stehen die WLAN-Einheit oder die Bluetooth-Einheit des ESP32 zur Verfügung.

Ein eigenes Übertragungsprotokoll

Im Prinzip ermöglichen die unten aufgeführten drahtlosen Übertragungsprotokolle schon Alles. Warum also noch ein eigenes Protokoll darauf setzen?

Der wesentliche Grund ist, dass es mir beim ESP Now – das ich bevorzugt einsetzen möchte – noch nicht gelungen ist mit der UIFlow-IDE im laufenden Betrieb neue Peers in ein Netzwerk aufzunehmen. Die MAC-Adresse muss zur Programmierzeit bekannt und fest im Programm vorgegeben sein. Damit lässt sich aber kein flexibles zur Laufzeit zusammenstellbares Mess-Netzwerk aufbauen.

https://www.peters-bastelkiste.de/wp-admin/post.php?post=694&action=edit

ESP Now

ESP Now ist ein Protokoll von Espressif, dass die UIFlow-IDE unterstützt. Damit ist recht einfach ein kleines Netzwerk aufgebaut, dass keinen Accesspoint benötigt. Die einzelnen ESP32 Geräte kommuniziernen direkt miteinander. Der Nachteil ist, das bei der Programmierung mit der UIFlow-IDE die MAC-Adressen aller Mitglieder eines solchen Netzwerkes bekann sein müssen. Ob das bei ESP Now grundsätzlich so ist glaube ich nicht. Es ist mir bisher aber nicht gelungen einen Workaround für Micropython und damit für Blockly zu finden. Man kann mit ESP Now aber auch Broadcast Packete aussenden, so dass jedes andere Gerät die Informationen empfangen kann. Das ist zwar nichts für reale Anwendungen, aber zum Ausprobieren ist es zu gebrauchen.

Die beiden oben abgebildeten Programme zeigen die Möglichkeit der Übertragung mit ESP Now.

Eine Schwierigkeit bei ESP Now ist, dass die Daten als String übertragen werden. Wenn Die Daten in eine Liste gepackt werden und diese Liste übertragen wird sieht der String nach dem Empfang so aus: „[ Wert1, Wert2, Wert3, Wert4, Wert5 Wert6] „. Die Werte daraus zu entpacken ist etwas umständlich. Zuerst müssen die eckigen Klammern entfernt werden:

Aus dem von den eckigen Klammern befreiten String kann nun wieder eine Liste erstellt werden:

Nun ist tmp_date eine Liste die die Messwerte enthält.

In einer Schleife lassen sich nun die Messwerte auslesen. Hier ein kleines Programm, dass die Messwerte untereinander im Display darstellt, zurechtgestutzt auf ganze mV und mA.

Hier kann das Programm heruntergeladen werden:

Das dazugehörige Sendeprogramm sieht so aus:

Damit kann man schon erste Versuche anstellen.

MQTT

MQTT ist ein Protokoll, dass für den Zweck der Messwerverteilung sicher gut geeignet ist. Es benötigt im WLAN aber einen Brocker, der die Daten entgegen nimmt und weiterverteilt an die Geräte die diese abonniert habe.

WLAN

Das Gerät mit einem Webserver auszurüsten und die Daten dort abzuholen oder vom Server zuschicken zu lassen ist wohl die Königsklasse der drahtlosen Übertragung. Dazu fehlt mir aber noch einiges an Wissen, so dass dieser vorläufig nicht von mir beschritten werden wird.

Grenzwertüberwachung

Die integration einer Grenzwertüberwachung erweitert den Einsatzbereich des Gerätes. Dazu ist eine Tastatur zur Eingabe der Grenzwerte und eine Ausgabe durch Logiksignale, ggf. eine Darstellung auf dem Display.

Für die Grenzwertüberwachung ist wie schon erwähnt eine Tastatur erforderlich, die 5, 7 oder 8 Leitungen benötigt, je nach Anzahl der Tasten. Ausserdem sollte eine Grenzwertüberschreitung auch nach
Außen gemeldet werden. Dazu sind weitere 6 oder 12 Leitungen erforderlich. Je nach dem ob Über- und Unterschreitung oder nur eine einfache Meldung erfolgen soll.

Nun wird es eng auf dem I2C-Bus. Es werden weitere 2 bis 3 I/O-Expander benötigt. Das funktioniert nicht weil deren Adresse nicht umgestellt werden kann (in der UIFlow IDE). Ein weiterer PaHUB kan auch nicht eingesetzt werden, aus dem selben Grund. Der Versuch einen I/O-Expander und einen PbHUB zu kombinieren schlug auch fehl, weil ein I2C-Error gemeldet wurde. Der PbHUB belastet den I2C-Bus offenbar zu stark. Eine M5Stack inherente Lösung gibt es offenbar nicht. Deshalb habe ich I2C-Bus -Expander-IC’s bestllt. Ich hoffe damit lässt sich das Problem lösen.

Ich habe das Proglem mit den fixen Adressen in der UIFlow-IDE und damit auch in Micropython zwar an M5Stack weitergegeben, aber aufgrund meiner bisherigen Erfahrungen rechne ich mit großer Resonanz.

Alternativ könnte das Problem mit den Adressen mit der Arduino-IDE gelöst werden. Soweit ich weiß, kann man dort die I2C-Adresse eines Bausteins angeben. Aber ich wollte doch bei Blockly und Micropython bleiben.

Eingabe Tastatur

Als Eingabetastatur käme eine 4×4-Matrix-Tastatur in Frage. Diese ist aber relativ groß. Alternativ könnten auch Touchkeys zum Einsatz kommen. Deren Eignung muss aber noch untersucht werden.

Software

Die Software muss zum Einen die Eingabe des Grenzwertes für jeden Messkanal ermöglichen. Während des Messens müssen die Werte überprüft und ggf. Aktionen ausgeführt werden.

Darstellung im Display

Im Display kann ein Wert normal grün, in der Nähe des Grenzwerte gelb und bei überschreiten des Grenzwertes rot angezeigt werden.

Ausgabe

Die Ausgabe könnte durch Darlingten-Treiber-IC z.B. ULN2008 realisiert werden. Das ist universal einsetzbar und kann ggf. auch Relais treiben.