Donnerstag, 24. Oktober 2013
Erster Praxistest der Sensoren
Den Dauertest auf dem Schreibtisch haben die Sensoren gut überstanden, trotz gelegentlicher Übertragungsstörungen (ich vermute Interferenzen mit dem jeweiligen WLAN, dazu später mehr) lief das System stabil.
Aber die "echte" Welt ist doch etwas anderes. Die Umgebungsbedingungen in einer Papiermaschine sind für Elektronik-Komponenten schon außerhalb des normalen Consumer-Bereichs. Es gibt natürlich von praktisch allen Komponenten MILSPEC-Versionen oder solche für den Automotive Bereich, aber für eine Low Cost Anwendung ist das natürlich keine Lösung. Jetzt sind sie in einer echten Papiermaschine, die Basis steht in der Warte neben dem System zur Produktionssteuerung.
Unser Vorteil ist, daß wir keine lange Lebensdauer brauchen. Also sollte etwa die Alterung von Kondensatoren kein ernstes Thema sein. 85 Grad halten auch die "normalen" Typen aus und das ist ziemlich genau das Klima, in dem wir sie betreiben. Mehr Sorgen machen mir die Batterien. Die LiPos in den Sensoren sollten mit diesen Umgebungsbedingungen gut klar kommen. Aber im Router haben wir normale Alkaline Batterien verbaut. Da ist es schon eher fraglich, ob die durchhalten.
Unser erster Versuch geht über 4 Wochen. Bei 85 Grad und gut 30 Prozent relativer Feuchte. Damit kann man schon ganz komfortabel Mahlzeiten zubereiten ;-)
Aber zumindest bisher funktioniert alles. Am 24. haben wir die Sensoren installiert und bis heute keine (schlechten) Nachrichten bekommen.
Update: Eine Woche vorbei und alles noch OK.
Donnerstag, 17. Oktober 2013
Wie lang hält die Batterie ....
Grau mein Freund ist alle Theorie ....
Also messen. Und zwar in der endgültigen (na ja ... zumindest mal für dieses Jahr) Konfiguration. Arduino FIO, Standard-XBee, LiPo-Akku mit 850 mAh, Messung alle 4 Sekunden, Datenübertragung einmal pro Minute, keine Routing-Funktion in den Sensorknoten, Pin-Sleep-Mode, d.h. die XBee-Module werden vom Arduino einmal pro Minute per Hardware aufgeweckt (das ist der größte Unterschied zur "endgültigen" Version, bei der werden die XBee-Module den Arduino wecken, um ZigBee-Routing zu ermöglichen. Aber eins nach dem anderen).
Nach etwa sechs Wochen ist die Spannung von anfänglich etwa knapp 4,2 Volt auf gut 3,7 Volt gefallen.
Gehen wir mal davon aus, dass wir dann weniger als die Hälfte der Kapazität verbraucht haben. Eine genaue Abschätzung ist schwierig, da üblicherweise für LiPos nur Entladekurven bei hohen Strömen publiziert werden. Die würden uns allerdings wenig nutzen, da solche Messungen idR nicht bei den für uns relevanten Temperaturen von 80-95 Grad durchgeführt würden.
Gehen wir also mal davon aus, dass wir dann noch die Hälfte der Kapazität haben, sind wir was die Akkus betrifft auf der sicheren Seite.
Also messen. Und zwar in der endgültigen (na ja ... zumindest mal für dieses Jahr) Konfiguration. Arduino FIO, Standard-XBee, LiPo-Akku mit 850 mAh, Messung alle 4 Sekunden, Datenübertragung einmal pro Minute, keine Routing-Funktion in den Sensorknoten, Pin-Sleep-Mode, d.h. die XBee-Module werden vom Arduino einmal pro Minute per Hardware aufgeweckt (das ist der größte Unterschied zur "endgültigen" Version, bei der werden die XBee-Module den Arduino wecken, um ZigBee-Routing zu ermöglichen. Aber eins nach dem anderen).
Nach etwa sechs Wochen ist die Spannung von anfänglich etwa knapp 4,2 Volt auf gut 3,7 Volt gefallen.
Gehen wir mal davon aus, dass wir dann weniger als die Hälfte der Kapazität verbraucht haben. Eine genaue Abschätzung ist schwierig, da üblicherweise für LiPos nur Entladekurven bei hohen Strömen publiziert werden. Die würden uns allerdings wenig nutzen, da solche Messungen idR nicht bei den für uns relevanten Temperaturen von 80-95 Grad durchgeführt würden.
Gehen wir also mal davon aus, dass wir dann noch die Hälfte der Kapazität haben, sind wir was die Akkus betrifft auf der sicheren Seite.
Sonntag, 22. September 2013
Vergleichstest der Sensoren
Um einen Eindruck von der Genauigkeit - genauer gesagt von der Abweichung der Sensoren untereinander, die absolute Genauigkeit ist gar nicht so einfach zu messen - habe ich die Sensoren in einen luftdichten Koffer gepackt und eine Weile gewartet.
Bis auf den Sensor 5 (links unten) liegen alle recht nah beieinander. Der liegt knapp 1 Grad unter den anderen. Berücksichtigt man die Abhängigkeit der relativen Feuchte von der Temperatur stimmt die Luftfeuchtigkeit zwischen den Sensoren sehr gut überein, das ist der Wert, der relevant ist. Absolut gleiche Werte für die Temperaturen sind nicht zu erwarten, da die Umgebung unterschiedliche Temperaturen hat. Dazu müsste man eine Klimakammer verwenden, das war mir aber zu aufwendig.
Da für die geplante Anwendung im wesentlichen die Abweichung der Werte und nicht der Absolutwert von Interesse ist und eine Genauigkeit von 2% locker reicht folgt: Test bestanden.
Interessant wäre natürlich die Genauigkeit bei den später relevanten Umgebungsbedingungen (etwa 85 Grad bei 20-30% relativer Feuchte). Aber das läßt sich ohne Klimaschrank tatsächlich kaum prüfen. Im Feldversuch haben wir dann ja einen sehr großen Klimaschrank mit vielen eingebauten Sensoren zum testen ;-)
Freitag, 20. September 2013
Die Basisstation
Die Basis besteht aus einem Raspberry Pi, einem XBee-Modul und einer Echtzeituhr (da das Modul im Betrieb keine Netzwerkverbindung hat und die aufgenommenen Daten später mit anderen Daten synchronisiert werden müssen). Das XBee-Modul ist über die serielle Schnittstelle des Raspberry Pis angebunden. Das alles ordentlich auf einem Pi Plate Kit von Adafruit aufgebaut.
Was im Bild fehlt, ist das Display, ein 20x4 LCD-Display mit I2C-Schnittstelle. Was ausserdem fehlt, ist der 3.3 Volt Spannungsregler: Der Raspberry Pi liefert nur 50mA, das reicht für ein Standard XBee-Modul (wie im Bild). Wird ein XBee-PRO-Modul verwendet, reicht das bei weitem nicht aus. Die Entwicklungsversion (im Bild) läuft mit einem normalen Modul, also ist der separate Regler nicht nötig, in der Produktionsversion natürlich schon. Da hat das XBee-Modul auch eine externe Antenne.
Donnerstag, 22. August 2013
Dynamische Messung der Stromaufnahme
Um die Belastung der Batterie unter realen Bedingungen zu
messen, wurde der Stromverbrauch des Gesamtsystems in einer dem Zustand bei der
tatsächlichen Messung ähnlichen Konfiguration bestimmt. Die Messungen wurden
ohne Sensor durchgeführt, da verschiedene Sensoren einen unterschiedlichen
Stromverbrauch haben. Falls der Sensor keine erhebliche Stromaufnahme oder
(insbesondere) eine erhebliche Anlaufzeit benötigt, ist dieser für die folgende
Betrachtung zu vernachlässigen.
Die Stromaufnahme des Arduino im sleep-mode (powerDown,
ADC_OFF, BOD_OFF) beträgt statisch gemessen ca. 40 µA (direkte Strommessung,
Philips PM 2503).
Konfiguration:
Arduino Fio, XBee Series 2, LiPo Akku 850 mAh, LowPower V. 1.30 https://github.com/rocketscream/Low-Power)
Die dynamischen Messungen wurden als Spannungsmessungen über
einem 1 Ω 1% Widerstand mit einem HP 54200A Digitaloszilloskop ausgeführt.
Um zu prüfen, ob die Stromaufnahme, insb. des XBee-Moduls
beim Einschalten einen höheren Peak als während des Betriebs hat, wurde eine
Kontrollmessungen mit einem analogen Speicheroszilloskop (HP1741A)
durchgeführt, die keine Anzeichen dafür lieferten.
Zunächst wurde der Stromverbrauch des Arduino-Boards ohne
XBee-Modul gemessen:
Dazu wurde der Controller 15msec in den sleep Modus
versetzt, dann über die Standard-delay-Funktion 100msec gewartet. Die
Stromaufnahme des Controllers beträgt etwa 5mA.
Die sleep-Dauer scheint nicht ganz der Angabe von 15msec zu
entsprechen, sondern eher etwa 20msec zu betragen. Bei Bedarf sollte dies durch
eine genauere Messung geklärt werden. Die Messung wurde bei längeren
sleep-Dauern wiederholt, um eine erhöhte Stromaufnahme bei längerer Dauer
auszuschließen. Dafür ergab sich kein Anhaltspunkt.
Daraufhin wurde die Stromaufnahme mit XBee-Modul gemessen.
Da das XBee-Modul mindestens etwa 3 Sekunden „wach“ blieb[1],
wurde im Versuch eine sleep-Dauer von 8 Sekunden (der Maximalwert) verwendet.
Die Abbildung zeigt, dass die Stromaufnahme jetzt etwa 40 mA beträgt. Dies
deckt sich mit statischen Messungen (Digital- und Analog-Voltmeter) und ist
auch plausibel. Man erkennt eine leicht erhöhte Stromaufnahme zu Beginn (etwa 3
mA mehr Stromverbrauch für etwa 300 msec). Auch dies ist plausibel. In einer
Messung (von etwa 50, kein Bild) erschienen einzelne Datenpunkte, die einen
höheren Stromverbrauch zu Beginn andeuten könnten, diese konnten aber durch
Messungen mit einem analogen Speicheroszilloskop nicht verifiziert werden und
werden deshalb als Artefakte (etwa Einstreuung des benachbarten PCs oder
Lötstation) interpretiert. Bei Bedarf sollte eine präzise Messung – etwa per
analoger Integration und Mittelung – durchgeführt werden. Der hierfür nötige
Aufwand scheint aber nur gerechtfertigt, falls Probleme mit überlasteten
Batterien auftreten.
NB: Die Messungen wurden insbesondere durchgeführt, da ein
Testaufbau mit einem Arduino-Leonardo und XBee-Shield bei weitem nicht die
erwartete Betriebsdauer erzielte, sondern nur gut eine Woche aus 4
Standard-Mignon-Zellen. Dies rührte aber, wie zu Beginn der Messungen klar
wurde, vom Ruhestrom des Spannungsreglers des XBee-Shields, der bei etwa 10 mA
lag. Dies würde dann zu einer Batteriekapazität von etwa 10 Tagen x 24 Stunden
x 10 mA = 2400 mAh (plus die eigentlich nötige Stromaufnahme von Board und
XBee-Modul, die bei etwa 1 mA im Mittel liegt und damit vernachlässigbar ist),
also einem plausiblen Wert.
Dies führt zu folgenden Betriebsdauern:
Quellcode des Programms zur Messung mit XBee-Modul. Für die
Messung ohne XBee-Modul wurde der entsprechende Code auskommentiert und die
Zeit im Aufruf von powerDown auf 15Ms gesetzt.
/**
* Short sleep cycles to measure power consumption
* essentially a fast blink with sleep during off time
**/
#include "LowPower.h"
char c = 'A';
const int XBEE_WAKE = 7;
void setup() {
Serial.begin(9600);
// Send
XBee to sleep, never wake it up
digitalWrite(XBEE_WAKE,HIGH); // just in case
// XBee
pins are clamped internally
pinMode(XBEE_WAKE,INPUT);
}
void loop () {
LowPower.powerDown(SLEEP_8S, ADC_OFF, BOD_OFF);
digitalWrite(13, HIGH);
// Send
to XBee Module
// first
wake it up
pinMode(XBEE_WAKE,OUTPUT);
digitalWrite(XBEE_WAKE,LOW);
// wait
a little bit
delay(100);
Serial.print(c);
Serial.flush();
// wait
a little bit and send XBee to sleep again
delay(100);
digitalWrite(XBEE_WAKE,HIGH); // just in case
// XBee
pins are clamped internally
pinMode(XBEE_WAKE,INPUT);
delay(100);
digitalWrite(13, LOW);
}
[1] Vermutlich
wurde das so konfiguriert, prüfen ! Ist aber nicht so kritisch. Letztlich
sollte per Versuch – aufwendig – geklärt werden, wie lange das Modul mindestens
wach bleiben muß, um eine verlässliche Übertragung zu gewährleisten. 3 Sekunden
sind meiner Erinnerung nach der default und realistisch.
Samstag, 10. August 2013
AD7714 - die Software
Der AD7714 - ein 24 Bit Sigma-Delta-Wandler mit integrierter Signalaufbereitung - ist ein toller Chip (und wenn man bedenkt, wie aufwendig es wäre, all diese Funktionen selbst aufzubauen, nicht mal teuer), aber leider gibt es (bisher) keine Beispiele im Web, wie man ihn an einen Arduino anbindet, das ist nämlich nicht ganz trivial. Also los.
Angebunden wird er über die SPI-Schnittstelle. Da ich nur einen SPI-Chip verwende, wird das /CS-Signal (Pin 19) nicht verwendet, sondern fest auf low gelegt. So braucht man nur drei Leitungen, MISO (Daten vom Wandler, Pin 21), MOSI (Daten vom Arduino, Pin 22) und SCK (Takt, Pin 1).
SPI ist kein "absoluter" Standard, sondern ein de-facto-Industriestandard, heisst, es gibt verscheidene Ausprägungen. Deshalb muss zunächst festgelegt werden, wie die Daten übertragen werden: Zunächst der SPI-Mode, der festlegt, welche Polarität das Taktsignal hat und welche Flanke zur Signalübernahme dient. Wir nehmen Mode 2, das bedeutet Takt ist aktiv low und die Daten werden bei der fallenden Flanke übernommen. Das wird chipseitig durch die entsprechenden Pins festgelegt (POL, Pin 4 auf high) und Arduino-seitig durch
SPI.setDataMode(SPI_MODE2);
Der AD7714 liefert (und erwartet) die Daten MSB first, das wird mit
SPI.setBitOrder(MSBFIRST);
definiert. Bleibt noch die Taktrate, wir haben es nicht allzu eilig und nehmen
SPI.setClockDivider(32);
das müssten 500kHz sein.
Der Zugriff auf die internen Register erfordert zunächst die Auswahl des zu schreibenden oder zu lesenden Registers. Dies geschieht durch Schreiben des Communication Registers. Dieses legt in den unteren drei Bits den Kanal des Wandlers fest. Wir verwenden nur einen Kanal, den aber differentiell an AIN1 und AIN2, dieser hat den Code 100 (also 4 dezimal). Das nächste Bit definiert, ob gelesen oder geschrieben wird, 1 bedeutet Lesen (also 8 dezimal). Die nächsten drei Bits geben das Register an, auf das als nächstes zugegriffen werden soll.
Die Codes 110 und 111 sind die Calibration Registers und im Moment uninteressant.
Das oberste Bit des Communication Registers ist das /DRDY muss beim Schreiben immer 0 sein, beim Lesen liefert es den Wert des /DRDY-Pins (low, wenn Daten gelesen werden können).
Zur Initialisierung des AD7714 wird zunächst das Filter konfiguriert, das durch Schreiben von 4 (Kanal AN1+AN2, Schreibzugriff) + 32 (Filter High Register) = 36 (0x24) ausgewählt wird.
Im Filter-Register werden im oberen Byte einige Parameter konfiguriert, hier unipolare Operation, 24 Bit Auflösung der zu lesenden Daten, Current Boost (da wir mit hoher Verstärkung und hohem Takt arbeiten) und ohne Clock Disable. Dies ergibt 1110 für die oberen 4 Bit. Die unteren 4 Bit sind die höherwertigen Bits des Filter-Teilers. Die niedrigste Filterfrequenz ergibt sich mit dem Teiler 4000 (0xfa0), nämlich fCLOCK/128/4000 = 4,8 Hz. Da die Zeitkonstante des zu messenden Temperatursignals sicher länger ist, ist die Genauigkeit umso besser, je niedriger die Filterfrequenz.
Also zunächst das Filter High-Register auswählen (0x24), dann die Werte schreiben (0x4f), dann das Filter-Low-Register auswählen (0x34) und das untere Byte (0xa0) schreiben.
Als nächstes muss das Mode-Register konfiguriert werden, dazu zunächst Mode-Register für einen Schreibzugriff auswählen 0x14 (20)
Angebunden wird er über die SPI-Schnittstelle. Da ich nur einen SPI-Chip verwende, wird das /CS-Signal (Pin 19) nicht verwendet, sondern fest auf low gelegt. So braucht man nur drei Leitungen, MISO (Daten vom Wandler, Pin 21), MOSI (Daten vom Arduino, Pin 22) und SCK (Takt, Pin 1).
SPI ist kein "absoluter" Standard, sondern ein de-facto-Industriestandard, heisst, es gibt verscheidene Ausprägungen. Deshalb muss zunächst festgelegt werden, wie die Daten übertragen werden: Zunächst der SPI-Mode, der festlegt, welche Polarität das Taktsignal hat und welche Flanke zur Signalübernahme dient. Wir nehmen Mode 2, das bedeutet Takt ist aktiv low und die Daten werden bei der fallenden Flanke übernommen. Das wird chipseitig durch die entsprechenden Pins festgelegt (POL, Pin 4 auf high) und Arduino-seitig durch
SPI.setDataMode(SPI_MODE2);
Der AD7714 liefert (und erwartet) die Daten MSB first, das wird mit
SPI.setBitOrder(MSBFIRST);
definiert. Bleibt noch die Taktrate, wir haben es nicht allzu eilig und nehmen
SPI.setClockDivider(32);
das müssten 500kHz sein.
Der Zugriff auf die internen Register erfordert zunächst die Auswahl des zu schreibenden oder zu lesenden Registers. Dies geschieht durch Schreiben des Communication Registers. Dieses legt in den unteren drei Bits den Kanal des Wandlers fest. Wir verwenden nur einen Kanal, den aber differentiell an AIN1 und AIN2, dieser hat den Code 100 (also 4 dezimal). Das nächste Bit definiert, ob gelesen oder geschrieben wird, 1 bedeutet Lesen (also 8 dezimal). Die nächsten drei Bits geben das Register an, auf das als nächstes zugegriffen werden soll.
Code | dezimal | Register |
---|---|---|
000 | 0 | Communications Register |
001 | 16 | Mode Register |
010 | 32 | Filter High Register |
011 | 48 | Filter Low Register |
100 | 64 | Test Register |
101 | 80 | Data Register |
Die Codes 110 und 111 sind die Calibration Registers und im Moment uninteressant.
Das oberste Bit des Communication Registers ist das /DRDY muss beim Schreiben immer 0 sein, beim Lesen liefert es den Wert des /DRDY-Pins (low, wenn Daten gelesen werden können).
Zur Initialisierung des AD7714 wird zunächst das Filter konfiguriert, das durch Schreiben von 4 (Kanal AN1+AN2, Schreibzugriff) + 32 (Filter High Register) = 36 (0x24) ausgewählt wird.
Im Filter-Register werden im oberen Byte einige Parameter konfiguriert, hier unipolare Operation, 24 Bit Auflösung der zu lesenden Daten, Current Boost (da wir mit hoher Verstärkung und hohem Takt arbeiten) und ohne Clock Disable. Dies ergibt 1110 für die oberen 4 Bit. Die unteren 4 Bit sind die höherwertigen Bits des Filter-Teilers. Die niedrigste Filterfrequenz ergibt sich mit dem Teiler 4000 (0xfa0), nämlich fCLOCK/128/4000 = 4,8 Hz. Da die Zeitkonstante des zu messenden Temperatursignals sicher länger ist, ist die Genauigkeit umso besser, je niedriger die Filterfrequenz.
Also zunächst das Filter High-Register auswählen (0x24), dann die Werte schreiben (0x4f), dann das Filter-Low-Register auswählen (0x34) und das untere Byte (0xa0) schreiben.
Als nächstes muss das Mode-Register konfiguriert werden, dazu zunächst Mode-Register für einen Schreibzugriff auswählen 0x14 (20)
Sonntag, 12. Mai 2013
Hobel sind Präzisionsinstrumente ....
und vor allem wenn sie aus Holz sind sehr empfindlich. Ein gut eingestellter Hobel nimmt grade mal ein Hundertstel dicke Späne ab. Das bedeutet aber auch, dass die Geometrie des Hobels in eben dieser Größenordnung stimmen muss. Leider verändert Holz seine Größe mit der Luftfeuchtigkeit, Holz arbeitet eben.
Um diesen und anderen Unbillen zu trotzen, schützt man empfindliche Werkzeuge üblicherweise durch eine Werkzeugkiste (oder einen Schrank, der ist aber erheblich schlechter zu transportieren). Am besten eine möglichst dichte, die Feuchtigkeit gar nicht erst eindringen läßt. Voila !
In einer ausgeglichen temperierten Werkstatt reicht das aus, in einem feuchten Keller nicht :-( Dabei ist nicht einmal der tatsächliche Wert entscheidend, sondern die Schwankungen. Aber wie vermeidet man die ?
Die erste Idee war eine Heizung: Im Inneren der Werkzeugkiste angebracht, erhöht sie erstens die Temperatur (und senkt damit die relative Feuchtigkeit) und sorgt zweitens durch Konvektion durch die unvermeidlichen Lecks in der Hülle der Werkzeugkiste für einen Abtransport der eingedrungenen Feuchtigkeit. Doch wie ? Zu viel Heizleistung ist ja auch eher kontraproduktiv, wegen Energieverschwendung und dann viel zu warmen und zu trockenen Werkzeugen, die sich dann beim ersten Kontakt mir der Umgebung verziehen. Also nur ein paar Watt.
Nach längerer (na ja, so lang war das gar nicht) Überlegung die Lösung: Ein LED-Streifen von 2m Länge liefert die grob überschlagen nötige Heizleistung:
Vermutlich bin ich einer der wenigen Menschen mit einer beleuchteten Werkzeugkiste ;-)
Sieht - ehrlich gesagt - auch etwas dekadent aus, wenn man den Deckel aufmacht, vielleicht stelle ich irgendwann mal auf eine inverse Kühlschrankbeleuchtung um: Leuchtet nur, wenn der Deckel zu ist.
Idee gut, Ergebnis leider nicht überzeugend: Bringt etwa 0,2 Grad und knapp 3 Prozent weniger Luftfeuchtigkeit .... Nächster Versuch.
Vielleicht erstmal messen .... also eine kontinuierliche Messung von Temperatur und Luftfeuchtigkeit installiert. Für die "normalen" Anwendungen arbeiten wir ja mit Datenloggern, aber für diesen Zweck ist das zu mühsam: Alle paar Tage in den Keller gehen, den Windows-Rechner hochfahren um die Auswertesoftware zu starten, Daten runterladen, in Excel transferieren usw. Das dauert insgesamt etwa eine halbe Stunde, zu viel für die regelmäßige Verwendung.
Normalerweise hätte ich das zähneknirschend akzeptiert. Aber da ich zur Zeit sowieso gemeinsam mit einem Startup an einer Lösung zur industriellen Datenerfassung bastle, stapeln sich die Sensoren, Controller, Funkmodule usw. sowie auf meinem Schreibtisch also musste eine professionelle Lösung her
Ein Carambola Board und ein Feuchtesensor mit digitalem Ausgang liefern nach etwa einem Tag fluchen über die I2C tools unter Linux (die nämlich exakt nicht den I2C Bus unterstützen sondern nur so etwas ähnliches und deshalb zu einem Tag verschärftem debugging und bare metal Programmierung führen - dazu demnächst mehr) ein System, das die Temperatur und Luftfeuchtigkeit in meiner Werkzeugkiste misst und (mehr oder weniger - auch dazu demnächst mehr) live ins Internet bringt.
Hoch interessant, was man mit geeigneten Sensoren alles messen kann ....
Man sieht sehr schön, wie ich etwa am 27.4. am späten Nachmittag kurz zum Basteln in den Keller gegangen bin, die Feuchtigkeit steigt um gigantische 0,4% innerhalb weniger Minuten ...
Wenn drei Erwachsene (?) mit aller Hingabe an Bumerangs basteln, sieht das noch mal ganz anders aus:
3,6% in nicht mal einer halben Stunde ! Big Data ist was Feines ....
Wer sich selber den aktuellen Stand anschauen will, findet den (wenn ich nicht grade an der Hardware bastle) hier.
Conclusio
Erstens: Die Luftfeuchtigkeit konnte durch den Einsatz eines modernen Controllers mit WLAN-Interface nicht nur beobachtet, sondern um etwa 10% gesenkt, die Schwankungen erheblich reduziert werden. Insbesondere dadurch, dass der Controller und vor allem das WLAN-Interface so viel Strom verbrauchen, dass die Heizleistung zu eben diesem Effekt führt. Arduino und ZigBee, sie leben hoch !
Zweitens:
Es ist inzwischen mit minimalem Aufwand (etwa 50 Euro und ein Tag Arbeit) möglich, sich einen "Internet-Kühlschrank" oder eben eine Internet-Werkzeugkiste zu bauen, ohne Experte zu sein (Ich bin Wirtschaftsinformatiker, kein E-Technik-Ingenieur).
Drittens:
Die Datenlogger, die wir bisher zur Messung von Temperatur und Feuchtigkeit verwendet hatten, zeigen die Temperatur recht genau (paar Zehntel Grad), aber die Feuchtigkeit zwar untereinander konsistent, aber absolut um etwa 6% zu niedrig an (ich traue den einzeln kalibrierten Luxus-Sensoren mit garantierter Maximalabweichung von 2% mehr als den China-Billigteilen. Fairerweise muss man aber auch sagen, dass hier der Sensor etwa soviel gekostet hat, wie der komplette Datenlogger).
PS: Die allererste Idee zur Lösung des beschriebenen Problems war die Regulierung der Luftfeuchtigkeit durch wasseraufnehmende Salze, gibt's in jedem Baumarkt für wenig Geld, muss man aber regelmäßig kontrollieren und auswechseln. Nicht eben elegant. Wenn nichts anderes hilft, werde ich darauf zurück kommen, aber so leicht gebe ich nicht auf !
Samstag, 4. Mai 2013
Feuchtesensor
Für die Messung der Luftfeuchtigkeit und der Temperatur verwenden wir einen HYT939 Sensor der Firma IST. Der ist zwar ziemlich teuer, hat aber eine exquisite Performance, spezifiziert ist er mit +/-1,8% Fehler bei der Feuchte (bei einer Wiederholgenauigkeit von 0,2%) und +/- 0,2K bei der Temperatur. So wie es aussieht, halten die Sensoren das auch ein.
Die Anbindung an einen Controller (hier ein Arduino FIO) ist simpel, da I2C-Schnittstelle:
Source (vollständiger Quellcode bei Github):
// HYT 939 Humidity Sensor Address
#define I2C_SENS 0x28
Wire.beginTransmission(I2C_SENS);
// send MR command --> write address of sensor
Wire.write(I2C_SENS);
Wire.endTransmission();
// wait til sensor data available
delay(100);
Wire.beginTransmission(I2C_SENS);
Wire.requestFrom(I2C_SENS,4);
unsigned char data[4];
while(Wire.available()) {
data[i++] = Wire.read();
}
humidity = data[0];
humidity &= 0x3f;
humidity *= 255;
humidity += data[1];
double dHumidity = 100.0/16384.0*humidity;
temp = data[2];
temp *= 255;
temp += data[3];
temp /= 4;
double dTemp = 165.0/16384.0*temp-40;
Ein weiterer Vorteil dieses Moduls ist der niedrige Standby Verbrauch von < 1 µA (sleep) und wenigen µA während der Messung.
Durch das runde Gehäuse mit Keramikmembran ist auch die Montage sehr einfach. Deshalb. Trotz des Preises (etwa 40 € als Einzelstück) lohnt sich das in Summe.
Ergänzung: Die Faktoren zur Umrechnung finden sich in den Application Notes
Dienstag, 29. Januar 2013
Reichweitentest der ZigBee Module
Da zunächst nicht ganz klar war, wie die Reichweite der Sensoren innerhalb einer (im wesentlichen aus Metall bestehenden) Papiermaschine sein würde, war der erste Vorversuch ein simpler Ausleuchtungs-/ Reichweitentest. In der Abbildung sind einige der Messpositionen gezeigt. Zunächst wurden normale XBee-Module mit Drahtantennen verwendet (ein Unterschied zu Chipantennen war nicht erkennbar). Es wurde eine Reihe von Messungen über einen Zeitraum von mehreren Minuten ausgeführt, angegeben sind jeweils Mittelwerte. Die Werte sollten nur als Anhaltspunkt angesehen werden, eine exakte Messung müsste systematischer ausgeführt werden. Da das Ziel aber nicht eine genaue Ausleuchtungsmessung dieser einen Maschine war, sondern es darum ging, eine Idee von den im Allgemeinen erzielbaren Reichweiten zu erhalten, reicht diese grobe Art der Messung hier aus.
Von Messposition 1 aus wurde zuerst die Dämpfung horizontal in Maschinenrichtung erfasst (Position 2 – FS). Im Anschluss wurde von Messposition 1 aus die Dämpfung zu Position 3 (TS) erfasst. Dies entspricht nahezu der maximalen Distanz innerhalb der Trockenpartie diagonal durch die Sektion. Hier wurde eine Signaldämpfung von -20 bis -25 dB ermittelt --> kein Problem. Als zweites Datenset wurde die Dämpfung im Übergang von innerhalb der Trockenpartie nach aussen erfasst. Dazu wurde auf Höhe der Messposition 1 auf TS der Empfänger ausserhalb der Trockenpartie (auf PM Boden) platziert. Der Sender wurde – zunächst bei geöffneten Haubentüren – auf Messposition 3 positioniert. Danach wurden die Haubentüren (TS) nacheinander geschlossen um Auswirkungen auf die Dämpfung zu erkennen. Hier wurde eine Dämpfung von etwa -35 (Haubentüren offen) bis -55 dB ermittelt, das ist an der Grenze einer verläßlichen Datenübertragung.Als letztes wurde noch die Dämpfung mit stärkeren Modulen (XBEE Pro) und Stabanttennen vom Haubeninneren bis in die Warte geprüft. Anfangspunkt war die Positionierung des Senders in Position 2 und des Empfängers im nächstgelegenen Wartenraum. Im Anschluss wurde die Dämpfung erfasst, wenn die Distanz erhöht wird. Dazu wurde der Sender auf Position 1 platziert. Hier wurde eine Dämpfung von -25 bzw. -35 dB gemessen.Insgesamt sind die Ergebnisse sehr ermutigend. Im Gegensatz zu den Erwartungen reduziert die metallische Umgebung das Signal wesentlich weniger als beispielsweise Stahlbetonkonstruktionen. Es kann eindeutig gefolgert werden, dass sich der Sender mit geringer Sendeleistung für den Einsatz eignet. Somit können die Ziele Kompaktheit des Sensors, Einzelkosten, Einsatzdauer voraussichtlich mit reduziertem Aufwand erreicht werden.
Donnerstag, 24. Januar 2013
In der Papiermaschine ...
Um zu testen, wie sich die XBee-Module in dieser Umgebung verhalten, haben wir eine einfache Reichweitenmessung (letztlich fast nichts anders als der Reichweitentest der von Digi gelieferten Software) durchgeführt: Ein Sensormodul (ein Standard-Xbee mit einem simplen Temperatursensor) sendet Daten an eine Basisstation, dort wird die Signalstärke (RSSI) ausgewertet:
Man erkennt das lose rumhängende XBee-Modul am USB-Kabel ... aber es ist ja schließlich nur der erste Versuch, der klären soll, ob sich weiterer Aufwand überhaupt lohnt: Wenn die Reichweite nur ein paar Meter beträgt, wird das Projekt umgehend wieder eingestampft.
Aber damit nicht alles "frei verdrahtet" aussieht, haben wir wenigstens den Sensor in ein Kästchen eingebaut:
Abonnieren
Posts (Atom)