Comments (5)
The readLightLevel
function also returns an inconsistent number right after switching between the two CONTINUOUS HIGH_RES modes, as there are no delay (to allow a new measurement) in configure(). In this case, the return 2-byte measurement value is based on the previous-mode measurement, but the interpretation (int 2 float) in readLightLevel is based on the new mode.
Example code:
BH1750 lightMeter((byte) 0x5C);
void setup() {
...
lightMeter.begin(BH1750::CONTINUOUS_HIGH_RES_MODE);
lightMeter.configure(BH1750::CONTINUOUS_HIGH_RES_MODE);
lightMeter.setMTreg(BH1750_DEFAULT_MTREG );
delay(180);
plotlight();
lightMeter.configure(BH1750::CONTINUOUS_HIGH_RES_MODE_2);
plotlight();
delay(180);
plotlight();
}
void plotlight(){
Serial.print(millis());
Serial.print(" Light: ");
Serial.print(lightMeter.readLightLevel());
Serial.println(" lx");
}
Result (@~800lx light) - my comments after the hash marks
1536 Light: 800.00 lx # Correct HRES_MODE measurement
1547 Light: 400.00 lx # False. HRES_MODE interpreted as HRES_MODE_2
1728 Light: 799.17 lx # Correct HRES_MODE_2 measurement
Maybe configure() should add a delay also for CONTINUOUS modes (and not just for ONE_TIME modes)?
/Bjarne
from bh1750.
I'm happy to receive pull requests if you would like to propose a fix? With so many other things on the go it's hard for me to find the time.
from bh1750.
I understand.
Unfortunately, I do not presently have a git pull (nor a way to actually expose that to you).
In order to do this "right" I would suggest to keep a "reset_time" with the object, so that a new/updated measurement can be taken only whenever the module is ready to deliver it. This would impact the delay()
(or _delay_ms
) in setMTreg()
and readLightLevel()
. The advantage would be that "hard" delays would not be necessary, ie the module/code could be non-blocking.
In addition, it might be an advantage to store the latest (read and compute) light measurement (as a float), so that could be returned until a new measurement is ready and could be read.
I would not actually implement changes on this magnitude without consulting with the original author (you) in order to assert that it is a way, which you would approve for the module.
from bh1750.
- Maybe we could do this like the BSEC library from bosch where they return a timestamp where the next measurement is ready. (It is somehow a little bit different from our case, because the bosch sensors contains a microcontroller, whereas we do not have this)
- store the millis() timestamp in the library instance -OR-
- return this value to the user for further processing -OR-
- boolean for the status 'new value possible' ?
- an internal storage for the last value is not straight forward, as the sensor can deliver it. I think the user should be aware of holding the right value, as the user needs to set this specific value into a context. If we would use a thread based concept, I would understand that
from bh1750.
a call of setMTReg
should touch lastReadTimestamp
because of the direct mode I2C call:
Line 162 in 37068ca
But maybe I missed something?
from bh1750.
Related Issues (20)
- Huge difference in readings CONTINUOUS_HIGH_RES_MODE vs CONTINUOUS_HIGH_RES_MODE_2 HOT 3
- Usage information MTreg HOT 3
- add this library to Arduino Library Manager HOT 13
- Hello, the library dont really want to work with my esp32s, anyone? HOT 52
- Lower bits of MTreg HOT 5
- [BH1750] Set address _after_ constructor HOT 1
- Frequent calls to readLightLevel prevents measurement update HOT 2
- [BH1750] Device is not configured! ESP8266 afterESP.deepSleep HOT 4
- Trouble using 2 sensors HOT 3
- The library works for STM32 HOT 2
- [TIP] Device not configured - temporary fix. HOT 5
- BH1750 does not work on ESP32 HOT 3
- BH1750 MTreg min is 31 in the datasheet, HOT 2
- Debug messages can cause the MCU stuck HOT 1
- 'Wire1' was not declared in this scope; did you mean 'Wire'? HOT 1
- BH1750 readLightLevel() eventually returns 27k value in low light environment HOT 1
- Possible arithmetic error evident with larger MTreg
- delete
- clarification on executing next OneTime measurment and getting delay time HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from bh1750.