Samstag, 2. Dezember 2017

RMS-Werte messen


Wie misst man den RMS (Root Mean Square) einer Wechselspannung ?

Der Effektivwert einer Spannung U ist definiert als diejenige Gleichspannung U_eff, die an einem Widerstand die gleiche Wärmemenge (Leistung) abgibt, wie die Wechselspannung U. Um den Effektivwert zu berechnen, berechnet man "einfach" die Fläche unter der Kurve, also das Integral über eine Periode, der Wechselspannung.

Es gibt eigentlich zwei "klassische" Methoden: Man nimmt einen "True RMS Konverter", den gibt es fertig als IC, etwa von Analog Devices, der eine dem Effektivwert der Spannung proportionale Gleichspannung erzeugt. Dazu wird die Eingangsspannung quadriert und der Mittelwert berechnet.

Oder man macht das digital, d.h. man erfasst die Spannung mit einem AD-Wandler und berechnet das Integral numerisch, berechnet also den Mittelwert des Absolutwerts. Die spannende Frage ist, welche Abtastrate braucht man. Handelt es sich um ein periodisches Signal, dann braucht man nicht besonders schnell abzutasten, die Abtastfrequenz kann durchaus auch niedriger als die Signalfrequenz sein (undersampling). Da letztlich ja nur der Mittelwert von Interesse ist, braucht man nur insgesamt genügend samples, um eine gute Näherung des tatsächlichen Werts zu erhalten. Außerdem kann es Probleme geben, wenn die Sample and hold-Schaltung zu langsam und ggf. nichtlinear ist.

Konkret geht es hier darum, eine sinusförmige Wechselspannung verhältnismäßig genau (besser als 1%) zu messen. Das Signal ist Bandpass-gefiltert, also gibt es keine Probleme mit Aliasing. Die Signalfrequenz ist 3 kHz, die (maximale) Abtastrate des verwendeten Arduino Due etwa 80kHz.

Aber wieviele Samples braucht man für welche Genauigkeit ? Ein einfaches Experiment soll Aufschluss geben. Ein Sinusgenerator erzeugt ein 3kHz-Signal, das an einen der analogen Eingänge des Arduino geht und mit 12 Bit Auflösung digitalisiert wird.


Es wird eine variable Anzahl von Samples aufgezeichnet, die Null-Linie berechnet (einfach der Mittelwert), quadriert, Mittelwert berechnet und wieder die Wurzel gezogen. Das gibt dann den Effektivwert. Um den Effekt verschiedener Abtastraten zu untersuchen, wird zunächst "ungebremst", dann mit einer variablen Verzögerung von 1-4msec gemessen. Das wird für unterschiedliche Anzahlen von samples (100 bis 2000 samples) wiederholt. In der Abbildung oben sieht man das Ergebnis. Dargestellt ist die Standardabweichung des RMS-Werts bei 20 aufeinanderfolgenden Messungen. 

Man sieht, dass die Standardabweichung mit steigender Anzahl von samples kleiner wird, zwischen etwa 1000 und 1500 samples scheint ein etwa konstanter Wert erreicht zu sein. Mit zunehmender Verzögerung zwischen den Samples wird das Ergebnis auch immer besser.

Die Verbesserung mit zunehmender Anzahl von samples ist leicht erklärbar: Da nicht über ganze Perioden gemessen wird, entstehen immer Fehler, die immer kleiner werden, je mehr samples betrachtet werden. Die Ursache des zweiten Effekts ist nicht so klar. Es könnte sein, dass der zeitliche Abstand zwischen zwei samples stärker schwankt, je größer der Abstand --> zufälligere Verteilung der Messpunkte. Möglicherweise kann sich aber auch bei längerem Abstand die S&H-Schaltung erholen .... Mal überlegen, wie man das rauskriegen könnte.

Montag, 25. April 2016

Temperatur messen ist meistens einfach ...


aber nicht immer.

Hier geht es darum, die Temperatur der Keramikleisten an einem Saugkasten zu messen. Da kommt man leider gar nicht gut ran, der rote Pfeil zeigt auf eine solche Leiste (das kleine graue "Ding" zwischen der blauen und der bräunlichen Kante (kann man kaum sehen). Das Problem dabei ist, dass auf dieser Leiste das Formiersieb (das hier im Bild am roten Pfeil schräg nach rechts oben verlaufende "Ding") läuft. Und zwar im Betrieb ziemlich schnell, da ranzukommen wäre gar keine gute Idee. Das ist übrigens die Leiste, an die man am besten rankommt, die anderen, zum Beispiel am blauen Pfeil, kann man hier im Bild überhaupt nicht erkennen ...

Um besser zu verstehen, was an einem solchen Saugkasten wirklich passiert, will ich die Temperaturen an mehreren Stellen messen, aber zunächst brauche ich ein Gefühl dafür, in welchem Bereich sich das ungefähr bewegt. Also ein Vorversuch. Im Prinzip ganz einfach, Kontaktthermometer mit langem Arm, an dem ein präziser, kleiner Fühler hängt. Gibt's bestimmt irgendwo zu kaufen, die Frage ist bloß wo und für wie viel.

Solche Thermometer mit einem 10cm langen Fühler gibt's an jeder Ecke, das hilft hier bloß nichts, man kommt nicht so nahe ran (es sei denn, man hat ernsthafte Ambitionen, vorzeitig aus dem Leben zu scheiden oder zumindest einen Arm zu opfern ...

Also selber basteln. Wie üblich ;-) Das Ergebnis:


Wunder der Globalisierung, das Material hat grade mal 20 € gekostet. Ein Miniatur Pt100, dazu ein Einbauinstrument zur Temperaturmessung und ein bisschen Kram aus der Bastelkiste. Das Interessante ist der Fühler selber. Die thermische Trägheit des Fühlers soll möglichst klein sein: Die Keramikleiste hat einen Querschnitt von vielleicht einem Quadratzentimeter und ist schön glatt poliert. Mit einem großen Fühler im Metallgehäuse kühlt man vermutlich eher die Leiste ab, als deren Temperatur zu messen, zumindest, wenn der thermische Kontakt gut ist und lang genug hält. Das ist aber gar nicht so einfach, da man das Ganze ziemlich freihändig einen Meter vom Körper entfernt möglichst ohne zu wackeln an die Leiste hält.

Um diesen Balanceakt zu erleichtern, eine spezielle Fühlerkonstruktion:

Der Messkopf (zum Größenvergleich die Pfote meines Katers) besteht aus einer dünnen Kupferscheibe (etwa 100µm dick, 10mm Durchmesser), auf der der PT100 (etwa 2x2x1mm) befestigt ist. Dieser Kopf ist mit einem Stückchen Silikonschlauch mit der Elektronik verbunden. Durch diese etwas elastische Kopplung ist es möglich, die Kupferscheibe vollflächig an die Leiste zu drücken, auch wenn man den richtigen Winkel nicht ganz trifft (man sieht ja nicht hin ...) und dabei eine möglichst große Kontaktfläche zu haben (dann kriegt man möglichst schnell Leiste und Fühler auf die möglichst gleiche Temperatur).

Da Silikon grundsätzlich schlecht zu kleben ist (hier zwar mit einem speziellen Silikonkleber, aber trotzdem ...), sollte man das mit der Elastizität nicht übertreiben, gedacht ist es ja, um einen Winkelfehler von vielleicht fünf Grad zu kompensieren. Die erste Version habe ich ein paar Ingenieuren überlassen, die den Messkopf prompt zerstört haben. Auf meine Frage, wieweit sie den Kopf gebogen haben, lautete die Antwort: "So weit, wie es ging". *arrrghhhhhhhh*


Montag, 11. April 2016

KI und so


IBM versucht ja seit einiger Zeit, mit dem Watson-Portfolio KI-Anwendungen in verscheidenen Branchen in den Markt zu bringen. Aktuell mit der Emotional Analysis API, einer Linguistik-Engine, die eine Persönlichkeitsanalyse aus einem Textmuster erzeugt.

So etwas gibt es ja schon lange, das kommerzielle Ziel ist (natürlich) effektivere Werbung, siehe den obigen Screenshot aus der Demo. Nur meistens funktioniert das nicht besonders gut. Um rauszufinden, ob es sich lohnt, Zeit zu investieren und gründlicher zu testen, wie gut das System funktioniert, habe ich mal mein letztes Paper analysieren lassen (eigentlich sollte man einen Text über Alltagsthemen verwenden, andererseits sind Industrie 4.0-Ansätze in der Papierindustrie heute ja ein Alltagsthema ;-)

"sceptical and strict", "imaginative", "intrigued by new ideas" sind ja durchaus Attribute, die einer wissenschaftlichen Arbeit zu stehen. "unconcerned with helping others" folgt hoffentlich nur aus der sachlichen Natur einer solchen Veröffentlichung ;-)

Jedenfalls scheint das Ergebnis mehr als zufällig zu sein, ich werde wohl in den nächsten Wochen (theoretisch bin ich im Forschungssemester und habe Zeit für solche Sachen ;-) ein bisschen mehr Zeit mit diesem System verbringen.

Anwendungen gibt es dafür ja viele, von der Früherkennung von Problemen bei der Analyse von Besuchsberichten von Außendienstlern (das ist das, was mich am meisten interessieren würde) bis zur massenhaften Untersuchung von emails nach anderen Kriterien, vielleicht "Likely to be a terrorist".

Freitag, 3. Juli 2015

Mal was ganz anderes ....


ich habe heute aus aktuellem Anlass den Nachmittag über mit dem neuronalen Netz von google rumgespielt, das Bilder "träumen" kann .... cooler Stoff. Allerdings ging das nicht ganz ohne Probleme ab: Grundsätzlich schon so, wie in der Anleitung, aber nachdem endlich alles installiert war (also nach etwa zwei Stunden) stürzte python immer beim import von caffe mit einer segmentation violation ab.

Nach einigem suchen stellte sich raus, dass das daran liegt, dass die mit dem Betriebssystem (Mac OS X 10.10) mitgelieferte python Library (natürlich) nicht zur aktuellen, installierten python Version (2.7.10) passt. Abhilfe: Die System-Libraries ausser Gefecht setzen (/System/Library/Frameworks/Python.framework umbenennen und durch einen Link auf die aktuelle Version ersetzen, bei mir /usr/local/Cellar/python/2.7.10/Frameworks/Python.framework/) und schon geht's.

Dafür funktioniert jetzt iPhoto nicht mehr, das will nämlich die alte Version *grrrr*

Mittwoch, 1. Oktober 2014

Ingestion rates


Im September gab es eine (durchaus interessante) Veranstaltung in Stuttgart, die mongoDB IoT european city tour. Thema war, ob (na ja, also natürlich "das") mongodb die ideale Basis für das Internet of Things sei. Dabei ergab sich die Gelegenheit, einen der Chief sonstwas Architects von mongodb zu fragen, warum (zum Geier) man denn eine (dokumentenorientierte) NoSQL-Datenbank braucht, um sehr einfach strukturierte Sensordaten zu speichern. Nach meiner unmassgeblichen Ansicht ist eine relationale Datenbank hier viel besser geeignet.

Die Antwort war: "Ingestion rate" (nach einigem Nachdenken kam dann noch "If you want to annotate your data ...", das ist ein guter Punkt, aber halt nur, wenn man das dann auch in unstrukturierter Form machen will. Und nach noch längerem Nachdenken "Open Source").

Also "Ingestion rate". Das Lieblingswort der NoSQL-Anbieter, wie mir scheint. Solche Aussagen wecken immer ganz schnell meine Neugier. Also habe ich die Zeit vor Semesterstart für einen kleinen Benchmark genutzt.

Das Szenario ist einfach: Eine Anzahl von Sensoren, die Daten liefern, beispielsweise 100 Sensoren, die ein paar Mal pro Sekunde einen Wert (etwa einen Ort oder eine Geschwindigkeit) liefern. Gespeichert wird für jede Messung die Zeit, der Wert, die Art des Werts und die ID des Sensors. Alles ints. Transaktionen brauchen wir hier eigentlich keine, da keine Werte geändert werden. Die einzigen Operationen sind das Anlegen neuer Datensätze und Lesen bereits bestehender.

Zunächst in einer mysql-Datenbank. Ein INSERT pro Wert, MyISAM-Engine. Kein Index. Dann mongoDB. Zunächst auch ein Wert pro insert, dann bulk-insert mit jeweils 1000 Werten. Auch ohne Index. In der Realität werden hier also die Zahlen schlechter (also langsamer) werden, denn ohne Index dauert es viel zu lang, die Daten zu finden.

Wenn man sich mal genauer überlegt, was man in diesem Fall eigentlich braucht, dann kommt man (hoffentlich) früher oder später darauf, dass eine Datenbank eigentlich overkill ist: Eine Zeitreihe kann man leicht in einer (Binär-) Datei speichern. Das Einfügen (also hier ja nur ein Anhängen) geht einfach. Suchen ist etwas schwieriger. Die typischen Abfragen in einem solchen System sind "Gib mir die Werte aus einem bestimmten Zeitintervall", beispielsweise den letzten zehn Sekunden usw.

Wenn hier jeweils die ganze Datei durchsucht werden muss, dann ist das viel zu langsam. Also braucht man einen Index. Da man in der Regel aber sowieso aggregierte Werte haben will, um die Darstellung auf unterschiedlichen Zeitskalen zu beschleunigen, ist das gar nicht so schwierig: Man speichert sowieso nicht nur die Originaldaten, sondern dazu noch Mittelwerte (und ggf. andere Verteilungsparameter) je Sekunde, Minute, Stunde, Tag usw. Wenn man hier jeweils noch die (ungefähre) Position dieses Intervalls in der grossen Datei mit den Originaldaten speichert, hat man eine Art B*-Baum für Zeitreihendaten. Der oberste Knoten sind die Monate(oder Jahre oder wasauchimmer). Auf der nächsten Ebene kommen die Tage, dann die Stunden, dann die Minuten, dann die Sekunden, dann die Daten. Sucht man die Daten für einen bestimmten Zeitpunkt, fängt man oben an, kommt so zum richtigen Tag, dann zur richtigen Stunde, zur Minute, zur Sekunde und schliesslich in die Datei, wo man einen Block oder so liest und die Daten hat. Programmieraufwand so in der Größenordnung von ein paar Tagen.

Das Ergebnis ist beeindruckend: MySQL und mongoDB liegen eher nah beieinander, MySQL etwa doppelt so schnell wie mongoDB. Beide in der Größenordnung (genauer ist das eh nicht, wir wollen ja nur ungefähre Zahlen haben) von 10.000 Datensätzen pro Sekunde.

Die "handgestrickte" Version mit Dateien (hier wurde nur der Index für die Sekunden realisiert, die oberen Ebenen wurden, da für die Performance irrelevant, weggelassen) schafft etwa 2 Millionen Datensätze pro Sekunde, also etwa 200 mal mehr als die Datenbanken !

Interessant ist hier, dass der bulk insert bei mongoDB praktisch keine Verbesserung bringt (bulk inserts scheinen ein schwieriges Thema zu sein, siehe etwa hier und hier).

Wenn man bei den Datenbanken noch Indices verwendet, muss man sehr ausfpassen, dass die Performance nicht in den Keller geht (siehe etwa hier).



Also: Wegen "Ingestion rate" braucht man keine NoSQL-Datenbank !



Üblicherweise kommt dann der Einwand, dass man NoSQL-Datenbanken leichter verteilen kann und so eine bessere Performance erzielen kann. Einen interesasanten Benchmark mit verteilten MySQL-Datenbanken, bei dem 15 Instanzen etwa 1 Million Datensätze pro Sekunde schaffen, gibt's hier.
Die schaffen etwa 150.000 pro Sekunde, was ganz gut zu meinen Messungen passt: Ich habe mein 4 Jahre altes Macbook verwendet, die hatten eine dicke Amazon Instanz. Passt.

Braucht man mehr Performance muss man in jedem Fall verteilen. Das ist dann aber schon ganz schön viel: Nehmen wir mal an, dass ein vernünftiger Rechner mit SSDs den zehnfachen Durchsatz wie mein altes Macbook schafft (das ist eher konservativ), dann wären das immerhin 20 Millionen Datensätze pro Sekunde .... die muss man erstmal haben.

Falls jeder Sensor pro Sekunde einen Datensatz liefert (das sind so übliche Szenarien, etwa auch bei der IoT-Veranstaltung die intelligenten Akkuschrauber von Bosch), dann sind das 20 Millionen Sensoren .....

Aber in der Tat, es gibt Anwendungsfälle, wo man so viele hat (etwa bei TelCos). Dann sind verteilte Dateisysteme notwendig, ein schönes Beispiel mit 100 Millionen Datensätzen pro Sekunde gibt's hier.

Also nochmal: Wegen Ingestion rates braucht man keine NoSQL-Datenbank ! Zumindest in einem IoT-Szenario, bei komplexen Dokumenten mag das wohl sein. Haben wir hier aber nicht ! Nein !

Bleibt also noch das Argument mit der Annotation. Bei Sensordaten kann man hier zwei Grenzfälle sehen: Bei Massendate die Annotation mit Events. Das also aus anderen Quellen stammende oder durch Auswertungen erzeugte Informationen über besondere Ereignisse (etwa die Überschreitung von Grenzwerten oder die Clusterung von Daten) hinzugefügt werden. Das geht mit relationalen Datenbanken natürlich hervorragend. Einfach eine zusätzliche Tabelle angelegt, die per Fremdschlüssel auf die entsprechenden Datensätze verweist.

Der andere Grenzfall wären meistens manuell erstellte, in jedem Fall aber unstrukturierte Daten in unvorhersehbarer Form. Die kann man tatsächlich gut in NoSQL-Datenbanken speichern. Die Frage ist, was bringt das ? Unstrukturierte Daten auszuwerten ist, insbesondere wenn man überhaupt nicht weiss, worum es sich handelt, gar nicht so einfach. Da bleibt eigentlich nur eine Volltextsuche, semantische Textanalyse usw. Das kann man aber auch mit einer relationalen Datenbank gut machen, wenn man diese Annotationen als BLOB speichert.

Bleibt "Open Source". Ist MySQL auch. Zumindest die Community Edition. Wie bei mongoDB auch.

Was bleibt also von den Argumenten übrig ?

Nix.

Den Quellcode der verwendeten Programme gibt's hier.

Mittwoch, 2. Juli 2014

Wie in der guten alten Zeit ...


Von Intel gibt es ganz neu einen sehr schicken - na ja, was eigentlich - sagen wir mal Barebone (heisst NUC - Next Unit of Computing). Der ist wohl eigentlich für Kassensysteme oder Infoterminals gedacht: Sehr niedriger Stromverbrauch, sehr niedrige Rechenleistung, ohne mechanische Teile, also lüfterlos, 4GB Flash intern, VGA-Anschluss und, man höre und staune: eine serielle Schnittstelle.

Also ideal für embedded-Anwendungen wie das NBS. Die ideale Basisstation. Bisher war das ja ein Raspberry Pi mit einem LCD-Display, aber wenn man den Aufwand für das Gehäuse, Netzteil usw. mitrechnet, dann ist die Intel-Kiste ein Schnäppchen: Ohne RAM für etwa 140 Euro, insgesamt also etwa 180.

Bleibt die Frage nach dem Betriebssystem. Linux natürlich. In diesem Fall Lubuntu, ein Ubuntu für Systeme mit wenig Resourcen. Also nix wie los. Aber da gibt es ein Problem: Ich möchte natürlich keine separate Festplatte installieren, sondern das Betriebssystem auf das interne Flash packen.

Leider sagt Lubuntu bei der Installation aber, dass es mindestens 4,3 GB braucht *grrr* Das eigentliche Image braucht nämlich nur 2.3 GB. In den Anleitungen im Netz findet man überall, dass man die Größenberechnung patchen soll. Das hat bestimmt mal mit irgendeiner Version funktioniert .....

Die Lösung ist aber einfach: Letztlich muss man nur den Installer dazu bringen, trotz vermeintlich zu knappem Platz weiter zu machen. Und das erreicht man, indem man die Fehlerbehandlung dieses Problems (siehe oben, im File ubi-prepare.py) aehm, sagen wir mal, modifiziert:

In Zeile 102 einfach True statt False, dann läuft der Installer munter weiter .... wer bremst verliert ;-)

Und noch ein Versuch


Die Bewegungserkennung mit der-Maus-Kamera funktionierte im Labor zwar sehr gut, unterm dunklen Auto in der Tiefgarage allerdings nicht mehr. Zumindest ohne Beleuchtung wird das wohl nichts.

Da ich sowieso einen IR-Temperatursensor ausprobieren wollte, war das die Gelegenheit. Auch hier war das nicht besonders kompliziert, der Beispielcode funktionierte sofort. Beeindruckend ist die Auflösung, eine Hand in einem halben Meter davorgehalten erkennt der Sensor sofort, die Hauttemperatur wird mit etwa 30 Grad gut gemessen. Der einzige Hinderungsgrund, den Sensor für das Bewegungserkennungsprojekt einzusetzen, ist der Preis, etwa 20 Euro.

Da die Inbetriebnahme viel schneller ging, als gedacht, haben wir noch ein bisschen mit dem Sensor experimentiert: Unterschiedliche Materialien haben eine unterschiedliche Emissivität. Soll etwa die Temperatur einer (auch Infrarot spiegelnden) Metalloberfläche gemessen werden, wird das mit dieser Art Sensor schwierig.

Zum experimentieren verwendeten wir ein Stück Aluminium, auf der einen Seite blank poliert, auf der anderen mattschwarz lackiert. Man kann natürlich bei der Berechnung der Temperatur die Emissivität einstellen (sowohl beim verwendeten Sensor als auch bei dem als Kontrolle verwendeten IR-Thermometer), das löst aber das Problem nicht: Die von der Umgebung (in diesem Fall vom Experimentator) ausgehende Strahlung wird von der Metalloberfläche reflektiert. Man muss also sehr genau aufpassen, welche Temperatur man misst. Das ist kein (allzu grosses) Problem, wenn das zu messende Objekt sehr viel heisser ist als die Umgebung (die Temperatur geht in der vierten Potenz in die Sensorspannung ein), bei ähnlicher Temperatur (bei uns etwa 30 Grad Umgebung vs. gut vierzig Grad am Messobjekt) ist das praktisch aussichtslos.

Fazit: Geht, aber zu teuer. Den nächsten Versuch machen wir mit Ultraschallsensoren. Nächstes Mal ;-)