Other Parts Discussed in Thread: TMP116,
Hi,
I'm looking to create a simple battery powered temperature probe, pairing a CC2640R2F with a TMP116 sensor over I2C. I want this device to be as low power as possible, so I'm looking at all ways to pair them up. The plan is to simply BLE broadcast the results. What I want to do though is fetch the value from the TMP116 as close to the beacon broadcast as possible, and minimise the amount of time that the chip is on.
The TMP116 is capable of running semi-autonomously once configured, performing a temp conversion every second and outputting a GPIO to indicate that data is ready. This uses 1.2 uA while in standby. Alternatively, it can be put into one-shot mode where it powers down everything apart from the I2C circuit in between commands. In idle this only uses 0.25uA. Compare this to the 1uA that the CC26402RF will use when in standby mode.
I can think of a couple of different ways to do organise the timing.
- Use the periperhal controller with a timer to periodically wake up and do a one-shot conversion on the TMP116 and then wake up the main processor to update the advertising data with the new value. The main issue I see with this is the timer to get the value isn't really synchronised to the ble advertising, so there could be a significant delay between retrieving the value and broadcasting it.
- Put the TMP116 in continuous conversion mode, and use the GPIO data ready signal to wake up the one-shot conversion. This suffers from the above problem, but also has the issue of both chips drawing standby power.
- Start advertising initially, and get a notification when broadcast completes. Use this to synchronise the conversion so that it happens just before the next broadcast. My issue with this is that I'll need to add buffers into the timing to make sure it happens before broadcast, and I'm worried that this will require much more use of the main processor.
- Have the TMP116 drive the whole timing. Have the CC26402RF go into shutdown mode, but leave the TMP116 in continuous conversion mode. When conversion is complete, it wakes up the main processor, which immediately fetches the result from the TMP116 then performs a single broadcast. When the broadcast is complete, it goes back into shutdown mode. I really like this option, but I'm concerned about how long waking up will take and what this means for current consumption. I also don't know how long it takes to warm up the bluetooth stack and whether that will also have detrimental effect.
So I suppose my question is two-fold. Is it possible to work out what the current consumption of option 4 is without performing an experiment? I don't have an osciliscope yet so its hard for me to measure current conversion. I'll get one if needed, but I thought I'd check in first.
Are there any other clever ways that I've missed? What I'm doing is super simple, so would another controller provide me with better current consumption?
Thanks.
B.
