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.



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.


CodedezimalRegister
0000Communications Register
00116Mode Register
01032Filter High Register
01148Filter Low Register
10064Test Register
10180Data 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 ...



ist dann doch alles etwas anders aus. Schmutziger zum Beispiel ;-) Lauter, heißer und vor allem viel mehr Metall um einen rum ...

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:

Der hat inzwischen einen Ehrenplatz auf meinem Schreibtisch ;-)