@kevyk wrote:
- How exacting and important is the timing my host MCU needs to return to get_timestamp_us? It sounds like timing is important when using the BSEC to get accurate readings.
- The function get_timestamp_us asks us to return a value in us. If the timing I provide is accurate in terms of transpired wall-clock time, what timing resolution is required? For example, is it OK if I return a timestamp updated every ms (1000us)?
Microsecond accuracy is not needed, a millisecond accuracy would be totally fine. Actually in BSEC's integration guide, you'll find that BSEC will support up to 50% timing overshoots(e.g. in LP mode, the delay between BSEC calls shall not exceed 4.5s). Consistent measurement periods will simply provide the best performance.
@kevyk wrote:
- Is it OK if I return a value incremented every second? Would the BSEC still operate correctly in these granularly incremented timing value cases?
The accuracy in your timings should be put in relation to your sampling period. Furthermore the timestamp is only fed into BSEC when calling its control loop, thus the granularity is transparent to BSEC as long as they are accurate. For example in LP mode, the sampling period is 3s. If your timestamp resolution is 1s, a wrong timestamp could be interpreted as a 30% error in your timing. In ULP mode where the sampling period is 300s, a 1s error in the timestamp would relatively have a much lower impact.
@kevyk wrote:
- When the sleep function is call, is that for simply short delays on the order of many ms, or could that be called with a sleep time of many seconds? If it is meant for a delay function more than a sleep function, shouldn't it be called "delay" instead of "sleep"?
I guess this is a matter of naming and you would be free to customize that in your solution. I would say that you could make a distinction between the delay function needed by the BME680 sensor API/driver (i.e. closer to HW requirements on par with I²C/SPI interface, with a ms resolution), and the sleep period between consecutive measurements/BSEC calls. In ULP mode, you may indeed want a different implementation for each 'delay' (e.g. one in ms, the other to put your device sleep mode).
