11-16-2021 08:38 PM
I am using the BSEC software with a BME680 on a Microchip SAMD21 processor. I have the code setup using the example code bsec_iot_example
It is initialzed using the code below
Then run in a loop as in example with code below.
I am not seeing any output from the output_ready function. This function is never called by the BSEC library.
Library version is BSEC 188.8.131.52
The I2C routines seem to be working fine. Here are a couple plots of I2C Traffic.
Zoomed in you can see when we read the 1D register the new data flag is never set. And the sensor data is always 80 00 00 meaning its being skipped.
What could be the cause of the the system is set to LP config so I should see new data every 3 seconds.... I never see new data.
Solved! Go to Solution.
11-17-2021 12:39 AM
It's difficult to investigate your issue with current information, but here is the suggestion for debugging.
If output_ready function is not called, root cause of this issue could be related to sleep function in bsec_iot_loop.
If you are using LP mode, the sleep should be around 3s, so please check the value of time_stamp_interval_ms line 615 in bsec_integration.c.
( Your get_timestamp_us() function probably doesn't work as we expect)
11-21-2021 10:44 PM
I am using LP mode. I don't see the sleep as 3s but rather 300msecs.
What is the output from the get_timestamp_us() function
1) is it in nsec, micro sec or milli seconds?
2) is the output a continuous count looping when the int64_t wraps or is it a counter that gets reset after get_timestamp() function is called?
11-22-2021 04:37 PM
I have time stamp working in LP mode. I can see the I2C traffic happen every 3seconds.
The issue I am seeing is that the num_bsec_inputs variable is always zero.
I can also see in the I2C traffic that no new data is available. (it almost looks like the sensors are not enabled)
If I check the bme680_bsec_update_subscription.. it is run as part of bsec_iot_init and seems to be sucessful.
Any Advice please
11-24-2021 06:44 AM - edited 11-24-2021 06:47 AM
get_timestamp_us() should be in micro-secconds, and it desires the current timestamp of the system which is typically a continous counter that keeps increasing until it rewinds (because of the range of uint64_t)