Jump to content

Obere Grenze beim Ambient Light V2 Bricklet


LPD

Recommended Posts

Hi,

 

ich habe seit 2 Tagen das neue Ambient Light V2 Bricklet für meine Wetterstation eingesetzt. Der Sensor soll die Sonnenlichtintensität messen, daher habe ich ersteinmal den größtmöglichen Bereich (64000lx) und eine möglichst große Integrationszeit (400ms) gewählt.

Eigentlich klappt auch alles wie es sollte, nur scheinen Werte oberhalb von 38070.90 Lx nicht dargestellt zu werden (siehe Anhang: Graph ist nach oben abgeschnitten...).

TagesHelligkeit.gif

Ich vermute den Fehler bei der Einstellung des Verhätnisses Messbereich/Integrationszeit - welche Werte würdet Ihr nehmen bzw. empfehlen?

TagesHelligkeit.thumb.gif.df2f706184b6b230ef22d314e45b953c.gif

Link zu diesem Kommentar
Share on other sites

Nic beschreibt das schon richtig.

 

Mit höheren Integrationszeiten verringert sich das Rauschen, aber du kannst nicht mehr unbedingt denn vollen Messbereich abdecken. Ich füge dazu gleich noch einen Hinweis in die API Dokumentation ein.

 

Da war allerdings auch noch ein Problem im Plugin des Bricklets, dass zu falschen Messwerten führen konnte, wenn der Sensor aufgrund zu langer Integrationszeiten gesättigt war.

 

Flashe bitte mal über Brick Viewer das angehängt korrigierte Plugin auf das Bricklet und teste mal mit 50ms oder 100ms als Integrationszeit.

ambient-light-v2-bricklet-2.0.1-rc1.bin

Link zu diesem Kommentar
Share on other sites

Hallo,

 

vielen Dank ersteinmal für die Hilfe.

Ich hab' natürlich gleich Nic's Rat umgesetzt und die Integrationszeit auf 100ms herabgsetzt. Das Ergebnis ist wirklich besser geworden (vgl. Graph1)

 

Nach dem Aufspielen von Protons Update habe ich aber Aussetzer (bei 100ms) - siehe Graph2 ?!

 

Anhand der Anzahl der Downloads haben anscheinend auch andere dieses Update ausprobiert - hat noch jemand Probs mit Aussetzern?

 

Ich werde morgen nocheinmal mit dem gleichen Wert aufzeichnen - vielleicht hat ja nur ein Vogel mein Gehäuse schön gefunden :D ...

 

Graph1.thumb.gif.583c1ee753263aa3a873e6481dca7087.gif

Graph2.thumb.gif.29f93d4d7b5ee125b6778a6a23ddc51c.gif

Link zu diesem Kommentar
Share on other sites

Nun, der heutige Graph sieht zwar auf den ersten Blick etwas besser aus, alledings kann ich hier auch wieder Einbrüche erkennen, speziell wenn die Werte großen Schwankungen ausgesetzt sind - schade.

 

Vielleicht messe ich ja einfach nur zu häufig (1/min) und die Übertragung mit den anderen Werten (Temperatur, Feuchte) über POE auf einen Raspi dauert einfach zu lange ...

TagesHelligkeit.thumb.gif.2f06d4e90b2b8c34fbb4eec8031adf84.gif

Link zu diesem Kommentar
Share on other sites

Diese Lücken in den Graphen sind mir nicht klar. Zeichnet das Tool keinen durchgehenden Graph, sondern nur Punkte? Oder sind die Lücken absichtlich da?

 

Kannst du mal dein Skript zeigen, dass die Daten abfragt und in die RRD Datei packt?

 

Einmal pro Minute 3 Werte messen sollte überhaupt kein Problem sein. Fragst du die Daten per GetIlliminance() ab? Behandelt dein Script Fehler die der GetIlliminance() Aufruf haben kann, z.B. Timeout?

 

Das einzige was ich in Firmware 2.0.1 geändert habe ist die Behandlung ungültiger Werte vom Sensor. Firmware 2.0.0 hat versucht die zu verwenden und hat dann potentiell falsche Ergebnisse geliefert. Das war der Grund warum deine erste Messreihe mit 64000 Lux Messbereich und 400 ms Integrationszeit bei 38070 Lux stecken geblieben ist.

 

In 2.0.1 werden ungültige Werte jetzt ignoriert. Dass heißt, wenn der Sensor in Sättigung läuft, weil der Messbereich zu klein und/oder die Integrationszeit zu lang ist, dann liefert das Bricklet so lange den letzten gültige Messwert bis der Sensor wieder gültige Werte liefert.

Link zu diesem Kommentar
Share on other sites

Hallo photron,

 

sorry, wenn ich erst jetzt antworten kann:

Kannst du mal dein Skript zeigen, dass die Daten abfragt und in die RRD Datei packt?

Gerne: Die Daten werden minütlich mittels crontab abgeholt, ein Graph wird alle 15 Minuten erstellt. Hier sind folgende Zeilen eingetragen:

[...]
* * * * * /home/lpd/aussenwerte.sh > /home/lpd/aussenwerte.lst 2>&1
*/15 * * * * /home/lpd/helligkeitsgraph.sh

 

Das shellscript aussenwerte.sh sieht so aus:

#!/bin/bash
HOST=192.xxx.yyy.zzz
UID_MASTER=1ABcdE
UID_TEMPERATURE=aBc
UID_HUMIDITY=dEF
UID_AMBIENTLIGHT=gHi

OutsideTemperature1=$(/usr/local/bin/tinkerforge --host $HOST call temperature-bricklet $UID_TEMPERATURE \
get-temperature  --execute "echo 'scale=2; {temperature} / 100' | bc | xargs printf '%.1f\n'| tr ',' '.'")

OutsideHumidity1=$(/usr/local/bin/tinkerforge --host $HOST call humidity-bricklet $UID_HUMIDITY \
get-humidity --execute "echo 'scale=2; {humidity} / 10' | bc | xargs printf '%.1f\n'| tr ',' '.'")

OutsideLuminance1=$(/usr/local/bin/tinkerforge --host $HOST  call ambient-light-v2-bricklet $UID_AMBIENTLIGHT \
get-illuminance --execute "echo 'scale=2; {illuminance} / 100' | bc | xargs printf '%.1f\n'| tr ',' '.'")

/usr/bin/rrdtool update aussenwerte.rrd N:$OutsideTemperature1:$OutsideHumidity1:$OutsideLuminance1

echo "Temperatur: $OutsideTemperature1 °C"
echo "Feuchte: $OutsideHumidity1 %Rh"
echo "Helligkeit: $OutsideLuminance1 lx"

 

... in der Datei aussenwerte.lst stehen dann die letzten Werte und/oder Fehlermeldungen drin, z.B.:

Temperatur: 24.8 °C
Feuchte: 37.2 %Rh
Helligkeit: 16284.9 lx

 

Für die Erstellung der Graphen hab ich folgendes Script (helligkeitsgraph.sh)

#!/bin/sh
rrdtool graph TagesHelligkeit.gif \
--start end-1d \
--vertical-label "lx" \
-w 1200 -h 400 \
--title "Tages-Aussenwerte Helligkeit" \
DEF:l1=aussenwerte.rrd:helligkeit:AVERAGE \
DEF:l1min=aussenwerte.rrd:helligkeit:MIN \
DEF:l1max=aussenwerte.rrd:helligkeit:MAX \
VDEF:l1durch=l1,AVERAGE \
VDEF:l1a=l1,LAST \
VDEF:lmina=l1min,MINIMUM \
VDEF:lmaxa=l1max,MAXIMUM \
LINE3:l1#00ff00:"Helligkeit\n" \
GPRINT:l1a:"aktuell\: %5.2lf lx\n" \
GPRINT:l1durch:"Durchschnitt\: %5.2lf lx\n" \
GPRINT:lmina:"tiefste\: %5.2lf lx\n" \
GPRINT:lmaxa:"höchste\: %5.2lf lx\n" \
> /dev/null

 

Mehr mache ich derzeit nicht - hat ja auch bisher (mit dem 'alten' Bricklet) prima geklappt.

Bestimmt hab' ich aber noch einen Anfängerfehler drin - ich lerne gerne dazu ;-)

 

 

Der Graph von heute sieht übrigens richtig mies aus: auch hier gibt's wieder ein riesen-gap (s.Anhang)

TagesHelligkeit.thumb.gif.21a03b033e8d440b6e5a52998c91309b.gif

Link zu diesem Kommentar
Share on other sites

Verstehe ich die Graphen richtig, dass da zwischen ca 15:30 und 16:00 Uhr und kurz nach 18:00 Uhr einfach Daten fehlen? Warum da ab 13 Uhr so ein glatter Einbruch drin ist, ist mir nicht klar.

 

Ich habe deine Script jetzt mal genommen und lasse sie hier gerade mit 2 Bricklets laufen. Eines mit Plugin 2.0.0 und eines mit Plugin 2.0.1. Bei sind auf 64000 lx und 50 ms eingestellt.

 

Ich lasse allerdings cron nach aussenwerte.lst mit ">>" statt ">" schreiben, damit ich später auch noch ältere Fehler sehen kann.

 

Bisher läuft es.

Link zu diesem Kommentar
Share on other sites

Hi,

ich hab' mir nocheinmal alle Graphen angeschaut - ich glaube ich habe die Ursache des Problems gefunden....

 

Eine zyklische Wiederholung schliesse ich aus, da die Ausfälle willkürlich stattfinden und in keinem direkten zeitlichen Zusammenhang stehen.

 

Da die Graphen der Temperatur, der Feuchte und die des Version1-AmbientLight-Sensors  (seit Messbeginn vor ca. einem Jahr) keine Lücke aufweisen, gehe ich auch nicht von einem "Übertragungsfehler" aus.

 

Auffallend ist jedoch, daß kurz vor jeder "Lücke" die Lichtwerte sehr hoch waren - d.h. die Sonneneinstrahlung dementsprechend auch ...

 

... ich vermute dass das Bricklet im direkten Sonnenlicht extrem warm wird und sich daher einfach kurzzeitig "verabschiedet".

 

Begründen läßt sich die Vermutung damit, daß die heutige Kurve (bis jetzt) keine Unterbrechungen aufweist - die Außentemperatur ist ja auch längst nicht mehr so hoch wie in den letzten Wochen ... oder?

 

Wie hoch darf denn die maximal zulässige Betriebstemperatur bei dem Bricklet sein?

 

LG,

LPD

 

TagesHelligkeit.thumb.gif.05231d2cc538a38386c78a08ea43c94c.gif

TagesFeuchteAussen.thumb.gif.a56741f6990067c3a4f5b137ccb503cb.gif

aussentemperatur.thumb.gif.d0474cc28cf276bf9e1c7b6da8582818.gif

Link zu diesem Kommentar
Share on other sites

Mein Test hier läuft bisher ohne Probleme. Der Aufbau steht aber nicht ideal und bekommt nicht die maximale Sonne mit.

 

Der Sensor auf dem Ambient Light v1 ist im Datenblatt bis +85°C angegeben, der des Ambient Light v2 bis +70°C.

 

Möglich, dass die 15°C Differenz hier den Unterschied machen, aber ich glaube es nicht.

 

Ist das Ambient Light v2 am gleiche Master Brick angeschlossen, wie die anderen Bricklets deren Graphen keine Lücken aufweisen?

 

Kannst du mal in deinem crontab hier das > durch >> ersetzen und in aussenwerte.sh am besten auch noch date mit ausgeben?

 

/home/lpd/aussenwerte.sh > /home/lpd/aussenwerte.lst

 

Mich interessiert, ob zu den Zeiten an denen du Lücken im Graph hast die Shell Bindings Fehler/Timeouts melden.

Link zu diesem Kommentar
Share on other sites

Vielleicht ist die UV Strahlung das Problem?

 

Ist der Sensor zum Messen von (starkem) Licht oder zum messen von SONNENlicht (inkl. UV Strahlung) ausgelegt?

 

Wuerde eine UV Filterfolie helfen?

Liegt der Sensor hinter einer Scheibe? Filtert diese die UV-Strahlung?

 

<Spass>

Koennte ein Tropfen Nivea helfen?

</Spass>

 

Der Loetkolben

Link zu diesem Kommentar
Share on other sites

Das Datenblatt des Sensors schweigt sich über UV aus.

 

Das erste Bild ist von einem der zwei Ambient Light 2.0 Bricklets, die hier schon seit Montag messen. Heute morgen habe ich sie nach draußen gestellt und zu Mittag waren sie direkt in der prallen Sonne. Keine Probleme.

 

Das zweite Bild ist von einem weiteren Ambient Light 2.0 Bricklet, dass ich zur Westseite hinter ein Fenster gestellt habe. Die ersten beiden stehen an der Ostseite und sind jetzt mehr im Schatten. Dieses steht aber gerade in der vollen Sonne, allerdings hinter einer Fensterscheibe. Auch hier bisher keine Probleme.

 

Ich glaube mein RRD ist etwas unglücklich eingestellt, was zu diesen etwas "eckigen" Graphen führt.

TagesHelligkeit_amb201.thumb.png.744d56e702ac0f0c6774b9706fcdfd2b.png

TagesHelligkeit_amb201b.thumb.png.7cec28de70ecf6e25391b2a5a94bbee8.png

Link zu diesem Kommentar
Share on other sites

Hallo photron,

Hallo Loetkolben,

 

photron:

Kannst du mal in deinem crontab hier das > durch >> ersetzen und in aussenwerte.sh am besten auch noch date mit ausgeben?

 

Hab ich gerade gestartet und gegengecheckt: Aufzeichnung läuft inklusive Datum und Zeit...

Ich werde morgen Abend das Log mal durchschauen und "Auffälligkeiten" posten.

 

photron:

Ist das Ambient Light v2 am gleiche Master Brick angeschlossen, wie die anderen Bricklets deren Graphen keine Lücken aufweisen?

 

Jep - Aufbauschema findest Du im Anhang IMG_0282.jpg

 

Loetkolben:

Liegt der Sensor hinter einer Scheibe? Filtert diese die UV-Strahlung?

 

Der Sensor liegt unmittelbar hinter einem ca. 1mm dicken Stück Plexiglas (ohne Filter - siehe Foto im Anhang). IMG_0668.jpg

Soviel ich weis läßt Plexiglas weniger UV durch als Glas, bei der Dicke würde Nivea wohl eher helfen ;D

 

Ich melde mich morgen wieder,

Grüße aus Weilrod,

LPD

 

 

IMG_0282.thumb.jpg.630c5cc2348834048619e5b2af73b44e.jpg

IMG_0668.jpg.8b0bbf5c2b11fb9cae59e94c9ae6cd1b.jpg

Link zu diesem Kommentar
Share on other sites

Hi,

 

  na jetzt aber:  wie erhofft gab es im Graphen wieder Ausssetzer (siehe Anhang)

Geschätzt hatte ich so ca. 15:30 Uhr für den Ersten - also ab ins Logfile uns siehe da: keine Fehlermeldungen oder irgendwelche "Ungewöhnlichkeiten".

 

Beim genaueren Hinsehen wurde ich dann doch stutzig: wie sehen denn die Werte aus: um 15:32 Uhr hatte ich für 3 Minuten Werte von 66430 lx !?!

 

Hier liegt also das Problem: Beim Ambient Light v1 konnte der Wert nicht größer als 800lx werden - daher bin ich bei der Version 2 auch davon ausgegangen (-> Datenblatt: bis 64000lx).

 

Wie kreaktiv schon richtig angemerkt hat: ich habe natürlich als obersten Grenzwert 64000 beim Anlegen der RRD angegeben....

 

Die RoundRobin-Datenbank hat völlig richtig gearbeitet und Werte außerhalb dieser Grenze als Fehlerwert interpretiert und verworfen -> daher auch keine

"Punkte" im Graphen.

 

Ich werde den Wert jetzt mal auf 80000 erhöhen - die Aussetzer sind nun bestimmt weg ....

 

Vielen, vielen Dank - ohne Euch würde ich immer noch im Trüben fischen.

 

Aber woher diese hohen Werte ?

 

Grüße aus dem Hochtaunuskreis,

LPD

Link zu diesem Kommentar
Share on other sites

Na so was.

 

Im Datasheet wird von "Full dynamic range from 0.01 lux to 64k lux" gesprochen. (bei 16 bit Aufloesung) Das koennten dann auch 65535 lux sein.  ;)

 

Das Bricklet hat fuer die Lichtstaerke einen 32bit Wert. (uint32) Warum wird der eigentlich Wert als 16bit Wert nicht durchgereicht?

 

Aus der Doku: "Gibt die Beleuchtungsstärke des Umgebungslichtsensors zurück. Der Wertbereich ist von 0 bis 6400000 und ist in Lux/100 angegeben, d.h. bei einem Wert von 45000 wurde eine Beleuchtungsstärke von 450Lux gemessen."

 

Muss es nicht "... und ist in Lux * 100 angegeben ..." heissen?

 

Wie du aber auf deine "66430" lux kommst kann sicherlich der Programmierer der Brickletsoftware an schnellsten beantworten. Ich vermute mal eine  " *1024/1000 " Operation in der Software oder einen Tippfehler bei dir ;-).

 

 

Der Loetkolben

Link zu diesem Kommentar
Share on other sites

Hi,

 

... also den Rechtschreibfehler schliesse ich aus ! 8)

(die Log-Datei und der Graph waren wohl zu gross - daher fehlte der "rettende" Anhang ..)

 

Jetzt aber:

Ich hab meine RRD mit neuen Grenzen versehen (uG: 0.00lx, oG:100000lx) und mittels Logfile die Werte von gestern aufgezeichnet (und auf's Wesentliche gekürzt):

 

Auffallend sind die Stellen, an denen Petrus das Sonnenlicht "ausgeknipst" hat ;D (0 lx von 14:30 bis 14:45Uhr und 15:42 bis 16:11Uhr) und die maximalen Messwerte von 75026.8 lx um 15:01 bis 15:04 Uhr ...

 

... hier fehlt mir jede Erklärungsidee. 

TagesHelligkeit_29_08.thumb.gif.3073dcdbedc084ce70d6b19ae8aec375.gif

aussenwerte29_08.lst

Link zu diesem Kommentar
Share on other sites

Loetkolben: Der Sensor verwendet einen 16 Bit 2-Kanal ADC. Dies beiden 16 Bit Werte sind aber nicht in Lux, sondern müssen noch nach einer bestimmten Formel mit einander verrechnet werden um den endgültigen Messwert in Lux/100 zu erhalten. Daher mach es keinen Sinn die 16 Bit Rohdaten des Sensors durchzureichen.

 

Lux/100 sind schon richtig. Das Bricklet gibt den Wert in hundertstel Lux an (Lux/100). Du musst ihn als durch 100 Teilen um einen Wert in Lux zu bekommen.

 

Bezüglich der 64k Lux Grenze: Die ist nicht hart. Der Sensor kann bis zu 150% darüber messen, sprich bis zu ca. 100k Lux. Allerdings nimmt ab 64k Lux die Genauigkeit ab. Da ist kein Fehler diesbezüglich in der Firmware des Bricklets. Allerdings ist die Dokumentation nicht ganz vollständig an der Stelle. Ich habe das nun korrigiert.

Link zu diesem Kommentar
Share on other sites

LPD, ich nehme mal an dein Skript würde nicht 0 ins RRD eintragen, wenn der Sensor nicht wirklich 0 geliefert hat.

 

Ich hatte hier einen einwöchigen Test mit 3 Bricklets laufen, keine Probleme. Ich hatte sie allerdings nicht in einem geschlossenen Gehäuse wie du. Es besteht also die Chance, dass es dem Bricklet in deinem Gehäuse zu warm wird. Die Möglichkeit kann ich nicht ausschließen.

 

Abgesehen davon gehen mir die Ideen aus. Was ich dir anbieten kann, ist dir ein neues Ambient Light Bricklet 2.0 zu zuschicken, um zu sehen ob das einen Unterschied macht. Melde dich dafür mit deiner Bestellnummer bei info@tinkerforge.com und verweise auf den Thread hier.

Link zu diesem Kommentar
Share on other sites

  • 2 weeks later...

Es gibt jetzt Plugin 2.0.2 für's Ambient Light Bricklet 2.0. Darin wird zwar nicht das aktuelle Problem dieses Threads gelöst, da es noch nicht ergründet wurde, aber es geht mehr oder weniger noch mal um das Problem, das ich schon in Version 2.0.1 angegangen habe (Sensor ist gesättigt) und um den Messbereich des Bricklets. Daher will ich das hier kurz erläutern.

 

Wenn es viel heller als der eingestellt Messbereich ist oder die Integrationszeit zu hoch eingestellt ist für die aktuelle Helligkeit, dann kann der Sensor gesättigt sein. In diesem Fall hatte Plugin 2.0.0 versuch den Wert des gesättigten Sensors noch zu verwenden was zu falschen Ergebnissen führte. Das war das initiale Problem in diesem Thread.

 

In Plugin 2.0.1 wurden dann im Fall eines gesättigten Sensors, dessen Messwerte ignoriert und der letzte noch gültige Werte wurde weiterhin vom Bricklet gemeldet. Das löste das Problem der falschen Werte, machte es dem Nutzer aber nicht einfach zu erkennen, dass der Sensor in Sättigung war und eigentlich die Konfiguration hätte geändert werden sollen. Stattdessen sah es so aus, als ob sich die Helligkeit nicht ändern würde.

 

Zusätzlich war es schon seit Plugin 2.0.0 so, dass das Bricklet Werte außerhalb des eingestellten Bereichs zurückliefern konnte. Das ist bedingt dadurch, dass der Sensor ca. 150% über den eingestellten Bereich hinaus messen kann. Allerdings mit abnehmender Genauigkeit. Auch das hat hier im Thread Probleme gemacht.

 

Wir haben uns darüber jetzt noch mal Gedanken gemacht. In Plugin 2.0.2 liefert das Bricklet jetzt 0,00 Lux zurück, wenn der Sensor in Sättigung ist. Wenn er nicht gesättigt ist, ist der minimale Wert jetzt 0,01 Lux. Dadurch kann der Nutzer jetzt direkt erkennen, ob der Sensor in Sättigung ist und entsprechend reagieren.

 

Die Messwerte werden jetzt auf den eingestellten Messbereich +0,01 Lux beschränkt. Wenn der Messbereich also auf 0-8000 Lux eingestellt ist und das Bricklet 8000,01 Lux meldet, dann ist der wirkliche Messwert höher als 8000 Lux und der Messbereich sollte umgestellt werden.

 

Da der 0-64000 Lux Bereich jetzt wirklich nur noch bis 64000 Lux ausgibt, gibt es einen zusätzlichen unbeschränkten (unlimited) Messbereich, der bis zum absoluten Maximum (ca. 100000 Lux) des Sensors messen kann, wobei in diesem Bereich über 64000 Lux allerdings die Genauigkeit abnimmt.

Link zu diesem Kommentar
Share on other sites

Uih, das ist ja viel Neues.  ;)

 

Sicherlich habe ich noch viele Fragen, aber eine moechte ich hier selbst beantworten.

 

Was sind 100.000 Lux?

 

Antwort von hier: Beleuchtungsstärke Lux (lx=lm:m²)

 

Lichtverhältnis:                    Beleuchtungsstärke:
Mittagssonnenlicht im Sommer        100.000 Lux
Bedeckter Himmel im Sommer           10.000 Lux
Regenwetter mit dunklen Wolken         1000 Lux
Bürobeleuchtung                         500 Lux
Wohnzimmerbeleuchtung                   200 Lux
Treppenhausbeleuchtung                  100 Lux
Straßenbeleuchtung                       10 Lux
Dämmerlicht nach Sonnenuntergang          1 Lux
Mitternacht bei Vollmond                0,2 Lux
Mondloser Sternenhimmel bei Nacht    0,0005 Lux 

 

 

Wenn das nicht passen/stimmen sollte bitte ich um Korrektur.

 

Der Loetkolben

 

Link zu diesem Kommentar
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Gast
Reply to this topic...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Clear editor

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...