So ähnlich soll das Systemgehäuse aussehen.

Das Gehäuse soll aus 3mm MDF/HDF oder Plexiglas gefertigt werden. Die möglichen Größen sollen in einem Raster liegen. Dadurch werden die Gehäuse stapelbar. Die Gehäuse sind so gestaltet, dass die Kühlluft von unten oder vorne ins Gehäuse strömt und nach hinten abgegeben wird. Die Gestaltung des Gehäuses verhindert, dass warme Luft von hinten in die Kühlluftzufuhr gelangen kann.

Material:

  • MDF/HDF 3mm
  • Pexiglas 3mm
  • andere Kunststoffe 3mm – sofern sie mit dem Lasercutter geschnitten werden können.

Mindestabmaße für ein Raster.

Damit mehrere Gehäuse über- und nebeneinander angeordnet werden können ist es erforderlich ihre Größen durch ein Raster festzulegen. Die Rastergrößen machen mir z.Z. noch Probleme. Für das Tiefenraster habe ich mich auf 200 mm, 250 mm und 300 mm festgelegt. Für das Breiten- und Höhenraster tue ich mich noch schwer ein Maß zu finden. Es gibt Lösungen für eher flache und breite Gehäuse oder hohe und schmale Gehäuse. Die goldene Mitte habe ich bisher noch nicht gefunden.

Rasterentschluß: Breite 100/50 mm, Höhe 135 mm

100 mm, 150 mm, 200 mm, 250 mm, 300 mm, 400 mm, 500 mm (passt für 19″ Baugruppenträger – 482,6 x 133,35 mm)

Höhenraster:

Das Höhenraster sollte auf der einen Seite flache Gehäuse ermöglichen, auf der anderen Seite aber auch nicht zu sehr hohen Gehäusen führen.

Wahrscheinlich werden Höhen von 2/3 – 1 – 4/3 angemessen sein.

  • 1 – 2/3 – 4/3 – 1/2 – 1,5 – 5/3 – 2
  • 100: 66,7(50,7) – 133,3(117,3)
  • 125: 83,3(67,3) – 166,7(150,7)
  • 135: 90(74) – 180(164) – 67,5(51,5) – 209(193) – 225(209) – 270(254)
  • 67,5(51,5) – 90(74) – 135(119) – 180(164) – 209(193) – 225(209) – 270(254)

Bezugsgrößen:

  • 4×4 Folientastatur – 75mm
  • M5Stick C – 50mm / mit USB-C-Winkeladapter 70mm
  • 1-3 Zellen 18650 USB-Stromversorgungsplatine (5V und 3,3V) –

Daraus ergibt sich eine lichte Höhe von mindestens 80 mm.

Flaches Gehäuse:

  • Lichte Höhe ca. 50 mm
  • => Systemhöhe = 50 mm + 2 * 3 mm + 10 mm = 66 mm
  • => Standarthöhe = 2 * 66 mm = 132 mm

Standardgehäuse:

  • Lichte Höhe 80 – 120 mm
  • => Systemhöhe = 80 mm + 16 mm = 96 mm
  • => Systemhöhe = 120 mm + 16 mm = 136 mm

Hohes Gehäuse:

  • Lichte Höhe ab 150 mm
  • => Systemhöhe = 150 mm + 16 mm = 166 mm

Breitenraster:

  • M5Stack Core – 55mm
  • M5Sick C + 4×4 Folientastatur = 25 + 70 = 95mm

Daraus ergibt sich eine lichte Breite von mindestens 100 mm. In 50 mm Schritten.

Tieferaster:

Für die Tiefe habe ich 3 Abmaße überlegt:

  • 200 mm
  • 250 mm
  • 300 mm

Design:

Das Gehäuse ist in der DIY-üblichen Art mit ineinandergreifenden Fingern gestaltet. Rückwand, Bodenplatte und Front werden zu einer U-förmigen Grundstruktur verleimt. Der Deckel wird von oben, ebenfalls mit Fingern eingesetzt. Die Stabilität erhält das Gehäuse durch die Seitenwände. Diese haben Aussparungen für die seitlichen Finger der anderen Teile. Im Boden und im Deckel sind M3-Gewindebuchsen eingearbeitet. Durch die Seitenwände geführte M3-Senkschrauben wird das Gehäuse verschraubt.

Seitenteile:

Für die beiden Seitenteile wird eine gemeinsame Zeichnung erstellt. Sie liegt auf der rechten ansicht auf der Symmetrieachse des Gehäuses. Es ist jeweils eine Zeichnung zur Erstellung der Füsse und für die Durchbrüche erforderlich.

Die Seitenteile unterscheiden sich je nach Tiefe des Gehäuses erheblich. Die Zeichnungen müssen für jede Gehäusetiefe erstellt werden.

Kontur für 200 mm Tiefe.

Aussparrungen für 200 mm Tiefe.

Boden:

Boden und Deckel sind von der Geometrie identisch. Während der Boden die Befestigungslöcher für zu Montierenden Baugruppen bekommt, bleibt der Deckel unbearbeitet. Warme Luft soll nach Hinten und nicht nach Oben entweichen.

Die blauen Linien kennzeichnen die maximale Größe der Boden-/Deckelplatte. Die Zinken gehen nach Innen.

Zinken für 80 mm Rasterbreite.
Zinken für 100 mm Rasterbreite.
Zinken vorne und hinten für Rasterbreite 125 mm
Änderung für 160 mm Rasterbreite.
Zinken bei 187,5 mm Rasterbreite.
Zinen bei 200 mm Rasterbreite.
Zinken bei 240 mm Rasterbreite.
Zinken links und rechts für Tiefe 200 mm

Frontplatte:

Deckel:

S. Boden.

Rückwand:

Die Rückwand ist bis zur Oberkante eines ggf. darunter stehenden Gehäuses herunter gezogen. So wird verhindert, das warme Luft von hinten in die Kühlluftzufuhr gerät.

Einpressmuttern:

Das Maß für die Einpressmuttern ist recht kritisch.

  • Bei 5,3 mm waren die Muttern locker.
  • 5,2 mm hielte sich gerade so.
  • 5,1 mm gingen nur mit Kraft in den Schlitz. Ging aber noch.
  • 5,15 mm als Kompromis.
  • Die Werte dürften auch von der Leistung und Geschwindigkeit des Lasers abhängen.
Das Zen von Python, von Tim Peters

Schön ist besser als hässlich.
Explizit ist besser als implizit.
Einfach ist besser als komplex.
Komplex ist besser als kompliziert.
Flach ist besser als verschachtelt.
Spärlich ist besser als dicht.
Lesbarkeit zählt.
Spezialfälle sind nicht speziell genug, um die Regeln zu brechen.
Obwohl Praktikabilität die Reinheit schlägt.
Fehler sollten niemals stillschweigend passieren.
Es sei denn, sie werden explizit zum Schweigen gebracht.
Im Angesicht von Mehrdeutigkeit, widerstehen Sie der Versuchung zu raten.
Es sollte einen - und vorzugsweise nur einen - offensichtlichen Weg geben, es zu tun.
Auch wenn dieser Weg anfangs vielleicht nicht offensichtlich ist, es sei denn, Sie sind Niederländer.
Jetzt ist besser als nie.
Obwohl "nie" oft besser ist als "jetzt".
Wenn die Implementierung schwer zu erklären ist, ist es eine schlechte Idee.
Wenn die Implementierung einfach zu erklären ist, kann es eine gute Idee sein.
Namensräume sind eine verdammt gute Idee - lasst uns mehr davon machen!

Übersetzt mit www.DeepL.com/Translator (kostenlose Version)

Durch den Touchscreen des M5Stack Core 2 bieten sich viele Eingabemöglichkeiten die bei den Geräten ohne Touchscreen extern nachgerüstet werden müssen. Mein erster Versuch gilt einem nummerschen Keyboard auf dem Touchscreen.

Ehrlich gesagt ist mein zweiter Versuch. Der Erste war nur mal zum probieren wie das überhaupt geht. So war die GUI nach einem LCD_clear oder Clear_screen verschwunden und nicht wieder herstellbar. Auch war mir nicht klar, ob die Touch-Button wenn sie unsichtbar sind noch reagieren. Das alles habe ich beim ersten Austesten herausbekommen und ist in diesen Beitrag eingeflossen.

Auf diese Erfahrungen aufbauend ist dieser Versuch am Ende wirklich einsetzbar.

Das Ergebnis des zweiten Anlaufs kann sich sehen lassen:

Darstellung des Versuchsprogramms

Die Nutzung des Touchscreens geht am einfachsten mit dem UI-Simulator der UIFlow-IDE. Der ist aber nicht sonderlich komfortabel. Ich habe mich deshalb zu folgender Vorgehensweise entschlossen:

  • Die Darstellung der GUI und die erforderlichen Objekte werden vorher entworfen.
  • Die GUI-Elemente mit dem UI-Simulator erzeugen und nur die wesentlichen Eigenschaften festlegen.
  • Sie werden platzsparend irgenwie und -wo im UI-Simulator angelegt.
  • Die Anordnung auf dem Display wird vom Programm vorgenommen.
  • Sie werden im Programm sichtbar bzw. unsichtbar geschaltet. Dadurch wird ihre Funktion aktiviert bzw. deaktiviert.
So sehen die grafischen Elemente beim Erstellen aus.
Das ist ein Programmausschnitt der die Objekte anordnet.

Die Blöcke der Buttons und Labels bieten eine große Gestaltungsmöglichkeit. Diese sollte man nutzen um ein ansprechendes Aussehen zu erzeugen. Vor allem kann man die Objekte sichtbar (show) und unsichtbar (hide) machen. Unsichtbare Button reagieren nicht auf Berührung. So kann man auch verschiedene Objekte übereinander legen. Aktiv ist immer nur das sichtbare Objekt. Eine sehr interessante Gestaltungsmöglichkeit für eine GUI.

Ich habe im Testprogramm die Button „show“ und „hide“ eingebaut, mit denen ich die Tastatur ein- und ausschalten kann. Die Anzeige der Eingabe „label_input_show“ bleibt aber und so kann überprüft werden, dass tasächlich keine Eingabe erfolgt, wenn die Tastatur unsichtbar ist.

Die Funktionen und Buttom-Aktivities zum sichtbar und unsichtbar machen der Tastatur.

Hier kann die Programmdatei für die UIFlow-IDE heruntergeladen werden:

Bearbeitung zur Einsatzreife

Nachdem die wesentliche Funktionaltät erreicht war habe ich Anpassungen vorgenommen, die dieses Programm für Projekte einsatzfähig machen soll.

Ich wollte mal JSON ausprobieren und lernen wozu es zu gebrauchen ist. Die Erklärungen im Internet waren mir alle zu abstrakt. Also habe ich dieses Prgramm geschrieben;

https://www.peters-bastelkiste.de/ein-eigenes-uebertragungsprotokoll/

Zuerst sah es noch etwas anders aus. Das ist die funtionsfähige Version.

Zuerst wird ein Dictionary (in Micropython Map) erstellt. Diese Map wird in ein JSON-Objekt umgewandelt und schließlich wird dieses Objekt wieder in eine Map zurückverwandelt.

Der große Unterschied der Map-Objekte und des JSON-Objektes besteht darin, dass das JSON-Objekt direkt mit print ausgedruckt werden kann – also ein Stream ist – wohingegen bei den Maps erst die Werte einzeln herausgeholt werden müssen. Sonst erscheint nur ?@.

D.h. eine komplexe Datenstruktur wird in eine einfache verwandelt und zurück.

Ob mir das für mein Messdatenprotokoll von Vorteil sein kann?

Das wäre der Fall, wenn ich Texte und Zahlen gemeinsam um- und wieder zurückwandeln kann.

Mit diesem Programm habe ich es ausprobiert.

Es sah nicht gleich so aus. Da eine Liste hier nicht mit dem Print-Befehl ausgegeben werden kann habe ich erst die Schleife zum Auslesen der Liste einbauen müssen. Das ist der Beweiß, dass tatsächlich wieder eine Liste entsteht.

Das Ergebnis zeigt, dass JSON für meine Zwecke sehr nützlich ist.

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.

Erster Testaufbau – ein chaotisches Gewusel

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:

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

Das erste Testprogramm – Die GUI wurde mit dem UI-Simulator von UIFlow erstellt.
Das an die neuen Möglichkeiten der UIFlow-IDE angepasste Programm (MVA033-010.m5f).

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.

DM3068AMeter
10,0776 mA10 mA
20,461 mA20/21 mA
50,76251/50 mA
99,315100/99 mA
201,025201/202 mA
301,47301/302/304 mA
404,92405/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.

Ein einfaches Programm, dass alle 6 Messwerte ermittelt und anzeigt. U1 wird als Broadcast mit ESP Now gesendet.
Hier das dazugehörige Empfangsprogramm

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.

Ein universelles Empfangprogramm. Es wird eine Liste mit Daten erwartet und dargestellt.

Hier kann das Programm heruntergeladen werden:

Das dazugehörige Sendeprogramm sieht so aus:

Ein einfaches Sendeprogramm, dass die Daten der 6 Messstellen in eine Liste verpackt überträgt.

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.

Die VMeter-Unit ist ein isoliertes Voltmeter. Der Messteil ist also galvanisch von der übrigen Schaltung, also dem M5Gerät getrennt. Deshalb kann damit an beliebiger Stelle in einer Schaltung gemessen werden, auch wenn diese mit dem M5-Gerät elektrisch verbunden ist. Weiterhin hilft es Störungen zu verringern und die Unit vor Zerstörung zu schützen.

M5Stack gibt an, dass jede Unit individuell mit einer Genauigkeit von 0,1% Skalenendwert ±1 kalibriert wird. Die maximal messbare Spannung beträgt ±36V.

Die Auflösung beträgt mit automatischer Messbereichswahl bei Spannungen ≤ 16V 1mV und bei Spannungen > 16V 7,9mV.

Die Isolierung verträgt Spannungen bis 1000 Veff.

Der ADS1115

Das Herz dieser Unit ist der 16-bit-ADC ADS1115. Hier möchte ich dieses IC näher betrachten.

Der ADS1115 besteht aus einem Multiplexer mit 4 Eingängen, einem programmierbaren Verstärker PGA) dem 16Bit-ADC, einer Referenzspannungsquelle und dem I2C-Interface. Mich interessieren hier nur die analogen Blöcke.

Der Multiplexer

Der Multiplexer interessiert bei der Betrachtung der VMeter-Unit wenig, weil dieser nicht genutzt wird. Es werden nur die Eingänge AIN0 und AIN1 als differenzeingang genutzt, wobei AIN0 auf 2,5 Volt liegt, um positive und negative Spannungen messen zu können. das IC kann entweder vier Single-Ended- oder zwei Differenzsignale messen. Entladungsdioden (ESD), die mit VDD und GND verbunden sind, schützen die analogen Eingänge des ADS111x. Um das Einschalten der ESD-Dioden zu verhindern, darf die Eingangsspannung eines jeden Eingangs nur im angegebenen Bereich von GND- 0,3 V < V(AINX)< VDD+ 0,3 V. Wenn die Spannungen an den Eingangspins potenziell die Bedingungen verletzen können, verwenden Sie externe Schottkydioden und Serienwiderstände, um den Eingangsstrom auf sichere Werte zu begrenzen.

Soweit die wichtigsten Informationen aus dem Datenblatt.

Die Analogeingänge

Die Informationen im Datenblatt zu den Analog Eingängen sind für die Anwendung der VMeter-Unit uninteressant.

Der Wandler

Das IC ist mit einem prigrammierbaren Vorverstärker vor dem ΔΣADC ausgestattet. Damit lassen sich die folgenden Messbereiche einstellen: ±6,144V, ±4,096V, ±2,048V, ±1,024V, ±0,512V, ±0,256V.

Die analogen Eingangsspannungen dürfen die in den absoluten Maximalwerten angegebenen Grenzwerte nicht überschreiten. So können z. B. bei VDD = 3,3 V und FSR = ±4,096 V nur Signale bis VIN = ±3,3 V gemessen werden. Spannungen|VIN| > 3,3 V können nicht gemessen werden.

ADS111x verfügt über eine integrierte Spannungsreferenz. Eine externe Referenz kann nicht verwendet werden. Fehler, die mit der Genauigkeit der Anfangsspannungsreferenz und der Referenzdrift mit der Temperatur verbunden sind, sind in den Angaben zum Verstärkungsfehler und zur Verstärkungsdrift in der Elektrischen Kennlinien Tabelle enthalten.

Der ADS111x hat einen integrierten Oszillator, der mit 1MHz läuft. Für den Betrieb des Gerätes kann kein externer Takt angewendet werden.

Der ADS111x bietet programmierbare Ausgangsdatenraten von 8SPS, 16SPS, 32SPS, 64SPS, 128SPS, 250SPS, 475SPS oder 860SPS.

Rauschen

Das Rauschen beeinflusst die maximal nutzbare Auflösung. Im Datenblatt befinden sich dazu diese beiden Tabellen:

Tabelle 1 zeigt die Rauschspannung in µVeff und µVss.

Tabelle 2 gibt an wie viele der 16 bit Auflösung durch das Rauschen noch aussagekräftig sind. Ebenfalls bezogen auf das Rauschen in µVeff bzw. µVss.

Bis zu 64 Messungen/Sekunde sind demnach bei allen Messbereichen die vollen 16-Bit gültig. Bei 860 Messungen/Sekunde sind es nur noch ca. 14-Bit.

Die Betriebsarten

Der ADS111x arbeitet in einer von zwei Betriebsarten: kontinuierliche Wandlung oder Single-Shot.

Die analogen Eigenschaften aus dem Datenblatt

Interessant ist für mich noch der maximale Strom an den Eingängen, um die maximale Spannungsbelastung zu berechnen. Der beträgt ±10 mA.

Meine Beurteilung

Was mir zuerst auffiel ist der Eingangsspannungsteiler aus 680k / 11k. Dieser reduziert das Eingangssignel auf 0,01592 also ca. 1/60. Damit geht doch sehr viel Auflösung verloren.

Bei einem Widerstand von 680kOhm und 10mA maximalen Eingangsstrom darf die Eingangsspannung maximal 6800V betragen, bevor das IC zerstört wird. Das entspricht einer Leistung von 68Watt die der SMD-Widerstand mit Sicherheit nicht verträgt.

Die maximale Eingangs- und messbare Spannung wird mit +- 36Volt angegeben. Das ergäbe hinter dem Spannungsteiler am IC eine Spannung von 0,57312 Volt. Da die Betriebsspannung 5 Volt beträgt ist am IC eine Spannung von 5 Volt zulässig. Da AIN0 auf 2,5Volt liegt bleiben noch ±2,5Volt übrig die messbar sind, also etwa die 4fache Spannung. Hier werden ca. 2 Bit an Auflösung verschenkt.

Unter Berücksichtigung des Vorteilers und einer Eingangsspannung von 5 Volt am IC wäre eine maximale Spannung von 314 Volt noch messbar.

Es viel auszuprobieren in der nächsten Zeit.

Fazit für die VMeter-Unit

Die VMeter-Unit ist sehr auf Sicherheit ausgelegt und so wie es scheint dürfte sie im praktischen Einsatz ziemlich unverwüstlich sein. Praktische Erfahrungen habe ich bisher nur sehr wenige, aber das wird sich bald ändern. Diese werde ich dann hier niederschreicben.

Jedenfalls scheint diese Unit ein großes Potential für Modifikationen zu bieten.

Meine Erfahrungen

Ich habe eine Genauigkeit von 0,2% vom Messwert bei ca. 3,6 V festgestellt. Gemessen mit einem Rigol DM3068 (0,0035% Grundgenauigkeit). Das Gerät ist allerdings nicht erneut kalibriert worden und mittlerweile ca. 3-4 Jahre alt.

Das Innenleben

Ich habe die VMeter-Unit geöffnet, weil sehen wollte, ob der Eingangsspannunsteiler einfach umzubauen ist. Das sind die beiden Widerstände parallel zur orangen Buchse. Unten der 680KOhm und darüber der 11kOhm Widerstand.

Diese beiden Widerstände sind sicher bald ein Ziel für Modifikationen.

Anwendung und Programmierung

Derzeit ist es nicht so ohne weiteres möglich an den M5Stck C aber auch an die ATOM’s Units über einen PaHUB anzuschließen. Ich hoffe, dass sich das in einer der nächsten Versionen der UIFlow-IDE ändern wird. Ich habe jedenfalls darum gebeten.

Die Reaktion darauf in der Comunity erfolgte sehr schnell. Noch am selben Tag wurde die Änderung angekündigt und als ich 2 Tage später wieder in der UIFlow-IDE nachsah war sie tatsächlich schon Realität! Ich habe mich sehr darüber gefreut. Außerdem wurde mir mitgeteilt, dass auch die Möglichheit die I2C-Adressen zu verändern implementiert werden soll. Das lässt hoffen und erzeugt bei mir eine große Vorfreude.

Der folgende Teil dieses Beitrages ist jetzt nicht mehr erforderlich (20.03.2021)

Bei der Unitauswahl für die Core Geräte ist es möglich den PaHUB-Kanal anzugeben an dem die Unit angeschlossen ist. Dann funktioniert alles problemlos mit den bereitgestellten Blöcken. Beim Core2 soll es in Firmware Version 1.7.2 auch Probleme geben.

Beim Stick C/plus und ATOM wird die Möglichkeit einen PaHUB-Kanal anzugeben nicht angeboten. Wenn man die Units trozdem anschließt gibt es eine Fehlermeldung beim Start des Programms.

Für das oben erwähnte Problem beim Core2 habe die folgende Lösung, oder besser den Workaround gefunden:

https://community.m5stack.com/topic/2852/not-possible-to-connect-pa-hub-on-m5stack-core2/6

Die Möglichkeit in der UIFlow-IDE den „Führe Code aus:“ Block einzusetzen bietet sehr viele Möglichkeiten die Einschränkungen bei den Blöcken zu umgehen. Hier wird die Initialisierung der Units hinter dem PaHUB nicht durch die UIFlow-IDE, sondern durch das Programm vorgenommen, inden der entsprechende Python-Code in den „Führe Code aus:“ Block eingetragen wird. Damit entfällt aber auch die Möglichkeit diese Units mit Blöcken anzusteuern. Diese stehen jetzt nicht zur Verfügung. In diesem Fall muss die Abfrage der Spannungs- und Stromwerte dann auch mit Python-Code in „Führe Code aus:“ Blöcken erfolgen. Deshalb ist dieser Weg für mich auch ein Workaround und keine Lösung!

Dieses Konzept lässt sich auch beim Stick C anwenden. Da die beiden Units VMeter und AMeter um die es mir hier geht in der Pythondokumentation bisher noch nicht aufgeführt sind habe ich einmal die dafür zur Verfung stehenden Blöcke eingesetzt und die Pythonübersetzung gegenübergestellt. Damit kann ich jetzt arbeiten.

Nun bleibt noch auszuprobieren, ob das auch wirklich funktioniert. Deshalb habe ich den kurzen Codeschnipzel produziert. Die PaHUB-Unit wird durch die IDE eingebunden. Das funktioniert ja. Die VMeter- und AMeter-Unit habe ich per Programm eingebunden.

Dieser Programmschnipzel funktioniert.

…und siehe da, es gibt keine Felermeldung! So kann man das Problem also umschiffen.