Hi!
I'm not sure I understand how everything strings together, so can you please help shine light on our use case and integration efforts?
Previously: BME680 + a TI Cortex M4 radio SoC. The chip was reading TPHG every 5 minutes. Worked great!
Goal: BME688 + same TI chip. Read every 5 minutes, but now a profile that we've developed using AI Studio.
Status: the BME688 works well in forced mode (ie no profile), no problem there, but we want to run it with a 10-step profile for CH4-detection.
We're using the Bosch driverlib, latest version. When we can use profiles, I assume we'll integrate the BSEC lib to run inference directly on the chip (but I'm not sure since it's possible we'll use edge or cloud smarts for that). Would this make sense to first get profiles working without BSEC, and then integrate BSEC?
So I configure the chip to use this 10-step profile of 10 x [temperature & duration in ms]. The driverlib then complains and wants me to provide a shared_dur, so I assume this means the driverlib wants me to translate to temperature + duration-multiple to go with a shared timebase?
For example, one step can be 300 degrees for 800 ms -> meaning 300 @ multiple 8 if shared_dur is 100 ms? Doing this translation the profile runs, but it takes about 10 secs for it to complete all 10 steps, instead of the calculated 7.7 secs.
I'm not sure how to best know when to stop the chip after this. Do you have guidance? It only has internal space for 3 samples, so step 4..10 will overwrite previous data. So instead I poll the data regs and read out when new data is available on a data reg. But that doesn't seem right, since I see this:
Poll-poll-poll until new data (on datareg 0). (step-)Index is 0. Here, instead of putting step 1 TPHG data in datareg 1, it overwrites data reg 0. This is before I have a chance to read it out. Data reg 1 and 2 are seemingly never used. It also sometimes shows index to be 15, which doesn't possible. (edit, this was wrong, fixed that, now index is not 15 anymore, but it still looks strange. Look at the bottom).
As a final question on this post, the bme68x_get_data() call will return number of new fields in the n_data argument, and this can never be more than 3 since it only reads out the internal dataregs 0..2, so this call is incompatible with profiles longer than 3 steps, correct?
edit: I'm using parallel mode btw, to work with profiles. I see there's a sequential mode too but read somewhere it shouldn't be used.
edit again: see here for an example of periodic polling while a profile is running. This simply reads out the three measurement status regs. It looks like it's not simply using a rolling scheme (0->1->2->0->1...) but moving around.
2023-12-20T16:40:20.324 0: (60) ix 0 measuring: 1, g 1 new 0
2023-12-20T16:40:20.327 1: (60) ix 0 measuring: 1, g 1 new 0
2023-12-20T16:40:20.331 2: (e1) ix 1 measuring: 1, g 1 new 1
2023-12-20T16:40:20.334
2023-12-20T16:40:20.459 0: (e1) ix 1 measuring: 1, g 1 new 1
2023-12-20T16:40:20.463 1: (60) ix 0 measuring: 1, g 1 new 0
2023-12-20T16:40:20.466 2: (61) ix 1 measuring: 1, g 1 new 0
2023-12-20T16:40:20.469
2023-12-20T16:40:20.596 0: (61) ix 1 measuring: 1, g 1 new 0
2023-12-20T16:40:20.601 1: (e2) ix 2 measuring: 1, g 1 new 1
2023-12-20T16:40:20.603 2: (61) ix 1 measuring: 1, g 1 new 0
2023-12-20T16:40:20.606
2023-12-20T16:40:20.733 0: (61) ix 1 measuring: 1, g 1 new 0
2023-12-20T16:40:20.737 1: (62) ix 2 measuring: 1, g 1 new 0
2023-12-20T16:40:20.739 2: (e2) ix 2 measuring: 1, g 1 new 1
2023-12-20T16:40:20.743
2023-12-20T16:40:20.870 0: (e2) ix 2 measuring: 1, g 1 new 1
2023-12-20T16:40:20.874 1: (62) ix 2 measuring: 1, g 1 new 0
2023-12-20T16:40:20.876 2: (62) ix 2 measuring: 1, g 1 new 0
Thanks so much,
AbstractFish
Ping @BSTRobin do you have any thoughts?
