Berechnungen in 51_I2C_TSL2561.pm stimmen nicht mit Doku überein

Begonnen von arnoaugustin, 26 Dezember 2015, 01:23:10

Vorheriges Thema - Nächstes Thema

arnoaugustin

Hallo zusammen,
ich habe gerade gesehen, dass im Modul laut Doku an den beiden Stellen an denen
$channel1*pow($ratio, 1.4)
steht eigentlich
$channel0*pow($ratio, 1.4)
stehen müsste. Also Channel 0 statt Channel 1.
Ich hab hier die Doku vom December 2005. Seite 22.

Bei der Gelegenheit: Die LUX-Werte werden nur mit einer Nachkommastelle ausgegeben was für kleine Werte im Endeffekt auf eine zählende Stelle raus läuft.
(steht ja auch im Kommentar:      # Round to 1 fractional digit if less than 100)
Bei wenig Beleuchtung fallen damit einige Sensorwerte auf einen Rückgabewert zusammen, obwohl der A/D Wandler im unteren Bereich noch abstuft. Evtl. könnte man für kleine Werte auch 3 zählende Stellen zurück liefern (Evtl. einstellbar mit Attribut???).

Grüße, Arno

kaihs

Zitat von: arnoaugustin am 26 Dezember 2015, 01:23:10
stehen müsste. Also Channel 0 statt Channel 1.
Ich hab hier die Doku vom December 2005. Seite 22.

Danke für den Hinweis, das habe ich korrigiert und eingecheckt.
Der Fehler trat nur auf wenn das Attribute floatArithmetics gesetzt war.

Zitat
Bei der Gelegenheit: Die LUX-Werte werden nur mit einer Nachkommastelle ausgegeben was für kleine Werte im Endeffekt auf eine zählende Stelle raus läuft.
(steht ja auch im Kommentar:      # Round to 1 fractional digit if less than 100)
Bei wenig Beleuchtung fallen damit einige Sensorwerte auf einen Rückgabewert zusammen, obwohl der A/D Wandler im unteren Bereich noch abstuft. Evtl. könnte man für kleine Werte auch 3 zählende Stellen zurück liefern (Evtl. einstellbar mit Attribut???).

Ich möchte ungern noch ein weiteres Attribut einführen. Ich muss erstmal herausfinden, warum bei unter 100 Lux überhaupt auf eine Stelle gerundet wird. Der Teil des Codes stammt nicht von mir.
Kann sein, dass der Sensor am unteren Limit ungenau wird und die Werte dann zu sehr 'zappeln'.

Gruß,

Kai
Banana Pi, Add-On Board mit 1.8" TFT LCD und IR-Sender, CULFW V1.61, div. Homematic Komponenten, Pollin Funksteckdosen, Selbstbau CUL433 MHz, Jeelink Clone, EC3000
Selbstbau CUL868MHz für Wireless M-Bus, SIGNALduino mit Logilink Temp.-sensoren und Auriol Wetterstation

arnoaugustin

Hallo Kai,

besten Dank. Das ging schnell :)

Mit den unter 100 LUX auf eine Nachkommastelle zu gehen und ab 100 LUX auf 3 zählende Stellen macht "physikalisch" irgendwie wenig Sinn.
Wenn der A/D 16 Bit ausspuckt und ich mit Werten wie 0.0315 skaliere, dann mach ich bei einer Nachkommastelle im unteren Bereich aus 16 Bit nur grob gerechnet nur noch rund 14 Bit
Im obersten Bereich bei 3 zählenden Stellen mach ich dann aus den 16 Bit nur noch knapp 8 Bit.
Bei höherer $ratio bzw. mehr IR-Anteil verschwinden noch mehr Bits.
Der Sensor selber arbeitet ja (Zeigen auch die Formeln) annähernd linear zur eingestrahlten Lichtleistung.
Wenn man also sagt, irgendwelche unteren Bits sind rauschen und man möchte die "glätten", dann müsste man (bei nahezu linearer Skalierung der A/D-Werte) über den gesamten Bereich mit gleicher Anzahl Nachkommastellen rechnen.
Will man gleichen maximalen prozentualen Darstellungsfehler zum Messwert haben müsste man wohl im gesamten Bereich mit gleicher Anzahl zählender Stellen arbeiten.
Für ne Rollosteuerung, die nur Grob zwischen Hell und Dunkel unterscheiden soll, isses natürlich egal.

Danke nochmal fürs schnelle Einchecken.

Grüße,

Arno

jensb

Hallo Arno,

für den scheinbar unlogischen Ansatz bei den Nachkommastellen bin ich wohl verantwortlich. Der TSL2561 hat zwar einen 16 Bit Wandler aber auch einen 16fachen Analogverstärker und ein Integrationszeit, die man um den Faktor 31 ändern kann. Damit ist ein Signalhub vom fast 500fachen vor dem Wandler möglich. Insgesamt deckt der Sensor also mehrere Zehnerpotenzen Helligkeit ab. Mit einer festen Anzahl signifikanter Stellen zu arbeiten, macht aufgrund der Funktionsweise des Sensors also keinen großen Sinn.

Die nutzbare Auflösung bleibt, wie du selbst sagst, zumindest theoretisch oberhalb von 12 Bit und damit tendenziell 4 bis 5stellig. Nur 3 Stellen weiterzugeben ist also eine künstliche Beschränkung, die das (scheinbare) Rauschen reduzieren soll, insbesondere für das Logging und für Steuerungszwecke. Man könnte problemlos auch 4 ab 100 und 5 ab 1000 weitergeben, aber ich glaube nicht, dass du damit reproduzierbare Messwerte bekommst. Hatte auch versucht, im Bereich unter 10 lux mehr Nachkommastellen auszunutzen, aber die Werte waren nicht stabil reproduzierbar - deshalb hier die Beschränkung auf 1 Nachkommastelle.

Wenn du möchtest, kommentiere die folgenden Zeilen im Modul aus, indem du vor jede Zeile ein "#" einfügst:


   if ($lux >= 100) {
      # Round to 3 significant digits if at least 100
      my $roundFactor = 10**(floor(log($lux)/log(10)) - 2);
      $lux = $roundFactor*floor($lux/$roundFactor + 0.5);
    } else {
      # Round to 1 fractional digit if less than 100
      $lux = floor(10*$lux + 0.5)/10;
    }


Damit wird die Auflösungsbeschränkung unwirksam. Prüfe, ob das Ergebnis eher deinen Erwartungen entspricht bzw. welche Rundung du für sinnvoll hältst. Schreibe die Messwerte vielleicht auch in ein Log, um sie besser bewerten zu können.

Grüße,
Jens
FHEM 6.1 - RPi 4 Raspbian 12 + PiTFT - OPi Zero Armbian 5.35
EnOcean - (W)LAN/Firmata: BMP180, TSL2561, SHT21, Heatronic 3, OBIS - WLAN/ESP8266: Gardena 1251, Zirkulationspumpe - RTL433: Oregon - Bluetooth - MQTT
Contributions: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/jensb