Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Humidity and pressure seems way off the for the very first read #3

Open
leinardi opened this issue Jan 27, 2018 · 2 comments
Open

Humidity and pressure seems way off the for the very first read #3

leinardi opened this issue Jan 27, 2018 · 2 comments
Assignees
Labels

Comments

@leinardi
Copy link
Contributor

leinardi commented Jan 27, 2018

For the very first reading I'm getting values of humidity and pressure very different from the successive readings.

For example, with this code:

BME280 bme280 = new BME280(BoardDefaults.getI2CPort(), 0x76);
bme280.setSamplingWeatherStation();
for (int i = 0; i < 10; i++) {
    float[] floats = bme280.readAll();
    Log.i(TAG, String.format(Locale.getDefault(), "Temp: %.1f°C, Humidity: %.0f%%, Pressure %.0f hPa", floats[0], floats[1], floats[2]));
}

I'm getting this output:

I/TemperatureActivity: Temp: 22,1°C, Humidity: 27%, Pressure 735 hPa
I/TemperatureActivity: Temp: 22,5°C, Humidity: 33%, Pressure 971 hPa
I/chatty: uid=10039(com.example.androidthings.driversamples) identical 1 line
I/TemperatureActivity: Temp: 22,5°C, Humidity: 33%, Pressure 971 hPa
I/TemperatureActivity: Temp: 22,5°C, Humidity: 33%, Pressure 971 hPa
I/chatty: uid=10039(com.example.androidthings.driversamples) identical 4 lines
I/TemperatureActivity: Temp: 22,5°C, Humidity: 33%, Pressure 971 hPa

Is this behavior intended? Should I manually do multiple readings and discard the firsts?

@knobtviker
Copy link
Owner

This behavior is exactly the reason I wrote this fork of contrib-driver.
Usually, I don't instance these drivers directly but with *UserDriver class.
I'll test and research what is going on, I suspect first value released is read faster than buri in time of the hardware itself.

@leinardi
Copy link
Contributor Author

leinardi commented Jan 28, 2018

For my specific use case I need only one reading of all 3 values every 5 min, so the sensor manager seems too complex and wasteful of resources (I would need 3 separate DynamicSensorCallback() that are going to poll several time per seconds each), when, accessing directly the sensor, I should be able to do only the reads I really need.

If the problem is only the first read, maybe you can call a readAll() at the end of the connect(), so that the wrong readings are discarded. This is a workaround, not a fix, but should work until is properly fixed.

@knobtviker knobtviker added the bug label Mar 21, 2018
@knobtviker knobtviker self-assigned this Aug 4, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants