![[schematic]](../../common/images/article284/druckschemaric.gif)
F�r eine gr��ere Ansicht auf den Schaltplan klicken.
![[Photo of the Author]](../../common/images/RalfWieland.jpg)
original in deRalf Wieland
de to en name of translator
Ich besch�ftige mich mit Umweltsimulation, neuronalen Netzen und Fuzzy-Systemen, indem ich sie programmiere. Letzteres vollzieht sich immer unter Linux (seit 0.99pl12). Weiterhin bin ich an Elektronik und Hardware interessiert und versuche das mit Linux zu verbinden.
![[Illustration]](../../common/images/article284/barographa.jpg)
F�r die Entwicklung eines jeden Messsystems sind folgende drei Fragen zu kl�ren:
Obwohl die Fragen trivial klingen, sollte man sich vor einer Eigenentwicklung jeden Schritt genau �berlegen.
Der Luftdruck ist eine interessante Messgr��e.
F�r Segler oder Bergsteiger gibt er Hinweise auf bevorstehende
Wetter�nderungen. Aber auch mir, als Gro�stadtbewohner
macht die Beobachtung des Luftdrucks Spass. Dass das auch anderen so
geht, sieht man in den vielen Wetterstationen, die die Wohnzimmer
schm�cken. Oft sind diese Ger�te aber mehr Spielzeuge als
ernsthafte Messger�te. Will man ernsthaft den Luftdruck
messen, so sind eine Reihe von Randbedingungen zu beachten.
Der Luftdruck kann mit dem oben gezeigten Barographen recht genau
ermittelt werden. So ein Ger�t auf rein mechanischer Basis
sieht nicht nur sch�n aus, es kostet auch recht viel. Um diese
hohen Kosten zu umgehen, misst man heute den Luftdruck mit
Halbleitersensoren. So fertigt z.B. Motorola
eine ganze Serie von Drucksensoren f�r unterschiedliche
Einsatzgebiete. Halbleitersensoren sind aber immer temperatur- und
spannungsabh�ngig. Um diese Charakteristik muss man sich
k�mmern. Der Luftdruck ist vergleichsweise einfach zu
ermitteln, da er im ganzen Haus als konstant angesehen werden kann.
Damit braucht der Sensor nicht im Freien angebracht, sondern kann
direkt am Rechner platziert werden. Das kommt einer
Temperaturkompensation sehr zu Gute, da ja davon ausgegangen werden
kann, dass die Temperatur am Rechner sich nicht sehr �ndert.
Trotzdem ist bei hoher Aufl�sung eine Temperaturkompensation
unumg�nglich. Bei dem vorgeschlagenen Sensor, der von ELV , einem renommierten europ�ischen
Elekronikversender als Bausatz angeboten wird (und der auch
freundlicherweise die Genehmigung zum Nachdruck der Schaltung gab),
wird die Temperaturkompensation in der Software durchgef�hrt.
Dazu misst der Sensor nicht nur den Druck, sondern auch die
Temperatur. Der Algorithmus zur Temperaturkompensation kann dem
Datenblatt von Intersema, dem Hersteller des Sensors, entnommen werden. Die Spannungskompensation
�bernimmt ein integrierter Spannungsregler. Damit ist die
Frage der Sensorwahl und des Aufstellungsortes gekl�rt.
Der Luftdruck ist nicht nur vom Wettergeschehen abh�ngig,
sondern auch von der H�he �ber dem Meeresspiegel (NN).
Will man den Luftdruck vergleichen, so ist er auf NN zu beziehen.
Das kann mit der internationalen H�henformel:
p0=p/(1-6.5*h/288000)^5.255
geschehen. Sie ber�cksichtigt neben der H�henabh�ngigkeit des Luftdrucks auch die Abnahme der Temperatur mit der H�he und erweitert damit die bekannte barometrische H�henformel. Der gemessene Luftdruck p wird mit der H�he h �ber NN korrigiert. Grob gesch�tzt kann man mit Druckverminderung von 1.2mbar/10m rechnen. Die H�he �ber NN ist im Programm myclient als #define HIGH_NN einzugeben. Die Druckdifferenz wird dort nach der internationalen H�henformel ermittelt. Mit Ber�cksichtigung der H�he ist man noch nicht fertig. Es bleibt noch die Frage, wie genau will man messen und wie oft muss man messen. Die Genauigkeit h�ngt direkt vom verwendeten Sensor ab. Dabei ist zwischen Genauigkeit, also der Verl�sslichkeit des Messwertes und der Aufl�sung, also wieviele Stellen angezeigt werden, zu unterscheiden. Der verwendete Wandler hat eine Genauigkeit von +- 1.5mbar �ber einen Bereich von 750..1100mbar bei 25°. Die Aufl�sung betr�gt aber 15Bit+-7Bit, d.h 1/2^15 = 3*10^-5 oder 0.03mbar. Vergleicht man die Aufl�sung mit der Genauigkeit, so wird die Unsinnigkeit einer derart hohen Anzeigegenauigkeit offensichtlich. Im Programm wird daher auf eine Stelle hinter dem Komma gerundet. (Und das auch nur, damit die Anzeige nicht unsinnig springt.) Als Letztes ist noch zu kl�ren, wie oft gemessen werden sollte. Der Luftdruck �ndert sich nicht gerade sprunghaft. Erfasst man den Luftdruck alle 5..10min, so sollte das f�r alle in der Praxis auftretenden F�lle ausreichend sein. Um ein zuf�lliges Schwanken der Messwerte auszugleichen, mit anderen Worten um Rauschen auszufiltern, wird der Messwert alle 10..60s abgefragt und einer digitalen Tiefpassfilterung unterzogen werden. Das ist zwar nicht unbedingt n�tig, schadet aber auch nicht. Die Belastung des Rechners ist dabei noch vernachl�ssigbar. Im konkreten Beispiel f�hrt das letztlich dazu, dass alle 10s gemessen, aber nur alle 2min die Messwerte gespeichert werden. Damit fallen t�glich 60*24/2=720 Messwerte an, die dann einer Anzeige zuzuf�hren sind. F�r eine Darstellung der Druckentwicklung stehen somit 720 Werte zur Verf�gung, was eine sehr detailreiche Darstellung erm�glicht.
F�r eine gr��ere
Ansicht auf den Schaltplan klicken.
Als Interface wurde die parallele Schnittstelle des PC
gew�hlt. Das ergibt einigen Sinn, nachdem die neueren Drucker
den USB-Port nutzen. Au�erdem ist die parallele Schnittstelle
recht einfach zu programmieren, so dass die Aufgabe ohne
zus�tzliche Hardware l�sbar war. Au�er den Gattern,
die zur Pegelanpassung und zur Erzeugung des von dem Sensor
ben�tigten Taktes notwendig waren, wurde nur noch die
Spannungsstabilisierung integriert. Falls man nicht auf den Bausatz
zur�ckgreifen m�chte, lassen sich die wenigen Bauteile
auch bequem auf eine Universalleiterplatte l�ten. Die
Entwicklung einer speziellen Leiterplatte d�rfte nur in den
seltensten F�llen lohnen.
Kurz zur Schaltung:
Die Zahlen am linken Rand bezeichnen die Anschl�sse an der
parallelen Schnittstelle. Die Anschl�sse 18..25 bilden die
Masseleitungen, die Anschl�sse 12,3 und 4 sind Dataleitungen,
also Outputs auf den Sensor. Der Anschluss 12 ist der sogenannte
Paper-Error, der einen Fehler im Drucker signalisiert und als Input
in den Rechner fungiert. �ber die Widerst�nde R1/R2 bzw.
R3/R4 wird die Spannung von 5V auf einen Wert unter 3.3V reduziert.
Sie dienen somit zur Pegelanpassung. Erw�hnenswert ist noch
der Taktgenerator f�r den Sensor, der schaltungstechnisch aber
keine Besonderheiten aufweist. Mit der Stromversorgung von 5V auf
stabile 3.3V ist die kleine Schaltung auch schon komplett.
Es wurde ein Programm entworfen und in C implementiert, das den
Sensor abfragt, die Temperaturkompensation durchf�hrt, die
Werte einer digitalen Filterung unterzieht und die Werte letztlich
speichert. Das Ganze ist recht �bersichtlich und kann leicht
nachvollzogen werden. Zur Abfrage des Sensors wird eine Folge von
Impulsen an den Sensor gesendet. Der Sensor interpretiert diese
Folge als Befehl und antwortet seinerseits mit einem als
Impulsfolge kodierten Messwert. Dieses Handshake ist im Datenblatt
sehr gut dokumentiert und kann anhand des Programmtextes leicht
nachvollzogen werden.
Eine Aufnahme und Speicherung der Messwerte ist nur ein Teil der
Aufgabe bei der Entwicklung eines Messsystems. Die sehr wichtige
Frage nach der Visualisierung ist zu kl�ren. Es stellte sich
n�mlich heraus, dass eine Visualisierung von Druckentwicklungen
w�hrend eines Tages bzw. einer Woche nicht unbedingt auf
Gegenliebe von Familienmitgliedern sto�en. Der Rechner macht
L�rm und verbraucht Energie. Um diesem Problem aus dem Wege zu
gehen, kann man einen DIL/NetPC einsetzen. So
ein Teil ist v�llig lautlos und verbraucht auch wenig Energie.
Leider sind diese Dinger nicht gerade billig. Au�erdem haben
DIL/NetPC keine eigene Auswerteeinheit, sondern m�ssen via
Netzwerk abgefragt werden. Die Kopplung via Netzwerk schien
interessant. Letzteres brachte mich auf die Idee, einen Linux-Server
auf Arbeit f�r die Druckmessung zu missbrauchen. Wir setzen
Linux-Server f�r vielf�ltige Aufgaben ein, da macht eine
gelegentliche Abfrage des Sensors nicht viel aus. Wer nicht
�ber so einen Luxus verf�gt, kann vielleicht einen
ausgedienten PC irgendwo im Keller platzieren, wo er kaum
auff�llt. (Strom verbraucht er aber trotzdem ;-) Wie dem auch
sei, eine Abfrage via Netzwerk musste her. Die Idee bestand darin,
einen Server zur Datenerfassung und Speicherung aufzubauen, der
dann bei Bedarf vom Client abgefragt werden kann. Damit ist eine
multiple Nutzung im Netzwerk gesichert. Auch meine Kollegen kommen
nun in den Genuss der Luftdruckmessung. Eine Einschr�nkung sei
hier allerdings gemacht, der Server l�uft in der jetzigen Form
mit Rootrechten. Das ist erforderlich, da die Schnittstelle direkt
angesprochen wird. Ein Treiber, wie Parapin,
kann genutzt werden, um die Schnittstelle auch als
nichtprivilegierter Nutzer anzusprechen. Das setzt aber in den
meisten F�llen die Rekompilation des Kernels voraus und ist
nicht jedermanns Sache. Bei einer Verbindung zum Internet sollte
aus Sicherheitsgr�nden diese M�he auf sich genommen
werden. F�r meine Anwendung reichte die einfache Variante
aus.
Es wurden also zwei Programme entwickelt. Einen Server, der die
Daten erfasst und speichert und einen Client, der die Daten vom
Server anfordert. Beide sind mittels einer Socket-Schnittstelle via
Ethernet verbunden. F�r den Server ergab sich dabei noch, dass
hier zwei unabh�ngige Prozesse laufen. Einer, der die Daten
vom Sensor abfragt und einer, der die Netzwerkverbindung abwickelt.
Beide schlie�en sich gegenseitig aus, d.h. wenn die
Schnittstelle abgefragt wird, muss der Netzwerkprozess warten und
umgekehrt, wenn der Netzwerkprozess gerade die Werte
�bermittelt, darf der Abfrageprozess keinen neuen Wert
bereitstellen.
Diese Prozesse wurden leichtgewichtig mittels Threads realisiert.
Dazu kam die PThreads-Library zum Einsatz, die
aber in jeder Linux-Distribution enthalten sein sollte.
Der Client wurde bewusst einfach gehalten. Hier werden im
wesentlichen nur die Daten empfangen und die H�henkorrektur
durchgef�hrt. Ausgegeben werden die Daten via stdout. Es
werden ausgegeben:
die Zeit ab Messbeginn in Stunden als float
die Messwerte als float
gefolgt von einem nl.
Eine Ausgabe sieht dann beispielsweise wie folgt aus:
0.000000 1008.2
0.033333 1008.1
0.066667 1008.2
0.100000 1008.0
0.133333 1008.1
...
Damit k�nnen Visualisierungsprogramme wie gnuplot oder die Plotutils einfach genutzt werden. Ich habe wegen der guten Darstellungsqualit�t die Plotutils gew�hlt. Auch wenn die Darstellung als Diagramm mit den erw�hnten Hilfsmitteln ziemlich leicht zu realisieren ist, sollte man sich doch ein paar Gedanken bez�glich vergleichbarer Darstellungen machen. Was n�tzen sch�ne formatf�llende Diagramme, die aber jeden Tag mit einer anderen Skalierung aufwarten? Man m�chte schlie�lich einen Tag mit den vorhergehenden vergleichen und sich nicht immer mit anderen Skalierungen herum�rgern. Deshalb bevorzuge ich eine absolute Skalierung.:
./myclient modell1 | graph -T X -C -g 3 -L "air pressure" \
-X "t from start of messurement in h" -Y "mbar" --x-limits 0 24\
--y-limits 950 1040
Der Client "myclient" ruft vom Rechner "modell1" die Daten ab und gibt sie via Pipe den Plotutils zur Darstellung. Die Skalierung des Luftdrucks liegt zwischen 950mbar..1040mbar. Als Zeiteinheit werden 24 Stunden verwendet. Tauscht man in den Befehlszeilen die Option -T X in -T ps, so wird eine Postscriptbefehlsfolge erzeugt, die sich wunderbar drucken oder in eigene Dokumente einbinden l�sst. Das nur als Hinweis, f�r jemanden der die Plotutils noch nicht ausgiebig nutzt.
![[graph]](../../common/images/article284/graph.gif)
Das Diagramm zeigt das Ende einer Sch�nwetterperiode und Einsetzen von Niederschlag.
Die Installation ist ziemlich einfach. Nachdem das Modul
aufgebaut wurde, und auf Fehler (Br�cken, kalte
L�tstellen etc.) kontrolliert wurde, kann es an die parallele
Schnittstelle angeschlossen werden. Die Software wird wie
�blich mittels tar -zxvf druck-0.1.tgz entpackt und danach
wechselt man ins Verzeichnis druck-0.1
und kann nach Eintragen der H�he �ber NN in die Datei
myclient.c durch ein einfaches make die �bersetzung starten.
Alles sollte problemlos laufen. Bevor das Modul aber genutzt werden
kann, muss in der /etc/services der Port f�r die
Socketschnittstelle eingetragen werden. Ich verwendete hierzu:
socktest 7123/tcp # Air pressure sensorden bei mir freien Port 7123 als socktest. Ist das geschehen, kann unter Root das Programm ./druck LPT1 (oder LPT2) gestartet werden. Ging alles klar, so meldet sich der Server und gibt alle 10 Sekunden die rohen Werte f�r Druck, Temperatur und die aktuelle Zeit aus. Damit ist gleichzeitig eine Kontrolle des Sensors gegeben. Der Client kann nun auf dem gleichem oder sinnvollerweise auf einem anderen Rechner gestartet werden. Dazu ist ebenfalls auf dem Client-Rechner der Port socktest in die /etc/services einzutragen. Um die Visualisierung etwas zu vereinfachen, wurde ein Shellskript druck.sh entwickelt. Dort ist der Servername durch den aktuellen Servernamen zu ersetzen und alles sollte laufen.
Aus dem �rger, dass es fast nie einen Treiber f�r Linux bei dem Anschluss von Sensoren gibt, sollten die Schritte zur Entwicklung einer Schnittstelle einmal nachvollziehbar gestaltet werden. Es war interessant, dass bei einer scheinbar so einfachen Sache, wie dem Anschluss eines Luftdruckmoduls, doch eine Reihe von Dingen zu beachten sind, bis alles vern�nftig l�uft. Erst durch Einbeziehung der Netzwerkschnittstelle konnte eine befriedigende L�sung erzielt werden. Trotzdem bleiben noch eine Reihe von Dingen ungekl�rt. Wenn auch die Nutzung der parallelen Schnittstelle mittels Parapin die leidigen Rootrechte verhindern kann, so ist eine weitergehende Nutzung dieser Werte via Internet noch v�llig offen. Gesetzt den Fall, es wollen sich mehrere Leute Wetterstationen aufbauen, indem sie vielleicht noch Temperatur- und Luftfeuchtef�hler integrieren (eine Windmessung ist recht kompliziert und durch den Laien nicht ohne weiteres durchf�hrbar). Dann bleibt die Frage, in welcher Form sie ihre Daten austauschen. Vielleicht hat jemand eine Idee und kann diese Frage in einem gesonderten Beitrag er�rtern?