I met some of the engineers at CES and explained how this should be done. They were more managers than engineers but said someone would eventually get back to me. We'll see... Basically it has to be simple to implment for the developer, right? That way the uptake and onboarding will be simple and fast and and developers can stay focused on their project instead of trying to implement the sensor. I had to incorporate 12 files and fix a few bugs and tweak a little Bosch code to finally get the BSEC to work properly. And even then, it's (assumed) PID loop is integrating too slowly for my use case so ultimately I probably won't be able to use it. From Bosch's end, to keep it simple for us developers, Bosch should provide a single file or two that contains all the code necessary to get the BSEC running. Just off the top of my head: that file should have just a single entry point to initialize everything (including telling the BSEC who the data consumer is), another single entry point to set settings like sample rate, voltage, etc., a single entry point to get a current sample (as an override), a single entry point to start or pause the system which will utilize best practices for energy management, and a single entry point to stop and release all resources. This way, all the developer has to do is implement a few calls into their application to utilize the BSEC and they are good to go. This needs to be all well documented with plenty of examples to show how to properly utilize the BSEC, how to integrate the binary, some common pitfalls like memory issues, etc. That's how I would implement this. That all said, in an ideal scenario: everything the BSEC does should really be contained onboard the BME680 iself. It should not require a developer to implement libraries and such. There should just be I2C data transfers to get and set everythning needed by the BSEC. Right? That way NONE of the above has to be implemented by a developer and, again, they can just stay focused on their project. Hope that helps. Contact me offline (my info was input into the iPad at the CES show) if you'ld like more input... Take care, Kevin.
... View more
I am speaking about the second paramter passed in to:
return_values_init err = bsec_iot_init(BME680_I2C_ADDR, BSEC_SAMPLE_RATE_LP, 0.0, bus_write, bus_read, sleep, state_load, config_load);
If instead of BSEC_SAMPLE_RATE_LP you pass in 1.0 (or 0.999), no error is ever returned however if you pass in say a 0.5, this error is appropriately returned:
BSEC_E_SU_SAMPLERATELIMITS = -12, /*!< The sample_rate of the requested output (virtual) sensor passed to bsec_update_subscription() does not match with the sampling rate allowed for that sensor */
If 1.0 is not allowed, it should probably also return an error. That said, page 24 of the data sheet does say that a 1Hz update rate is allowed however it seems to return values at a 0.5Hz rate.
Oh, understood now, then you are correct, the library doesn't return any error as it matches the definitions of the Continuous mode, but this mode is not released as you pointed out because not qualified for longer operation.
But the important issue for my application is that I need a faster update rate for the IAQ. Since the BSEC does not yet allow for faster sample rates, and since it appears that I am able to get faster data back from the sensor directly without the use of BSEC, is the general code for the BSEC or equations used in the BSEC available so that I could derrive my own pseudo IAQ?
A related question then is before the BSEC was avilable, how did users derrive anything useful from the gas resistance value (once they've calculated it) that they could use?
As mentioned we are hoping to bring a new official mode to BSEC with a sampling rate similar to the Continuous mode, but we cannot share any confirmation or timeline yet. BSEC was always made available together with the BME680. If you are an experts with a deep understanding of this sensing technology, you may use the BME680 is raw data mode and derive your own pseudo IAQ from it, but otherwise since BSEC cannot be open you would need to use one of the officially supported modes.
... View more
The save rate is only for the next power on, right? The data is not saved and loaded otherwise, correct?
Power cycles is typically when you would expect/want to reload the state. In some applications the state of BSEC's internal variables in RAM cannot be saved when entering deep sleep (e.g. of the MCU). Is such a case it would be mandatory to save/restore BSEC's state for every sample.
What are the advantages and disadvantages of having a more frequent save_data rate? Why wouldn't you choose say every 5 minutes or ever hour or something?
For the sake of BSEC, the impact on the application was described in my previous post. In practice you may need to consider other HW requirements, such as the number of write cycles of your non-volatile memory (e.g. already over 100k times per year if saved every 5 minutes), etc.
... View more
There is one (easy to miss) keyword that you missed in the original reply 😉
If no state file was loaded into BSEC (often the case if you are running the sensor for the first time, or if you got rid of the existing state file in your application), then the IAQ output will be fixed for the whole run-in duration (5min in LP mode) although the raw gas value will be reacting as expected.
On the on hand if a valid state file was successfully loaded into BSEC, then only you would see the IAQ output react to raw gas changes even during the run-in period (but as expected BSEC will report a low IAQ accuracy during this time).
... View more
- 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.
- 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.
- 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).
... View more