I recently picked up some HTU21D's on breakout boards from eBay since so many folks have switched to the Si7021 and the latter seems to be less precise and uses 3x more power while idle (20nA vs. 60nA). For some reason my lower precision measurements are taking significantly longer than the datasheet indicates that they should. I am curious if anyone here has the same sensor and gets very different timings.
From the datasheet for RH:
(http://i44.photobucket.com/albums/f26/cdl1051/RH_zpsfgzw9aap.png)
And my timings are as follows:
12-bit: 21ms
11-bit: 11ms
10-bit: 11ms
8-bit: 11ms
From the datasheet for Temperature:
(http://i44.photobucket.com/albums/f26/cdl1051/Temp_zps2yzigcrh.png)
And my timings are as follows:
14-bit: 41ms
13-bit: 21ms
12-bit: 11ms
11-bit: 11ms
I can't yet rule out some bottleneck in the code itself since I'm using SparkFun's demo which while convenient is massively bloated since it is built upon Wire which itself relies upon twi. I am recording a start time and end time via micros on each side of a call to either a temperature or humidity measurement in my loop and adding an extra SetResolution to the loop only adds 1ms so I don't think my bottleneck is the I2C conversation itself. Does anyone have any ideas on why this sensor isn't performing as the datasheet predicts?
The SparkFun code was adding a 10ms delay between asking to read data and actually reading it; this is padding all my sub 10-ms measurements obviously. I turned this down to 500µs and am now getting results which mirror the datasheet. So now my loop from power on to sleep is 11ms total and this includes powering up the HTU21D (supposed to take 15ms but it doesn't), getting the temperature and RH, sending the data to my gateway and then going back to sleep. This is so short that I cannot measure the current used during this sequence with my µCurrent and multimeter. My sleep current is 6.4µA and most of that is the WDT and LDO. Now to ditch both in favor of a TPL5110 and running directly off two AAs. That should get me down to 35nA sleeping current.
Quote from: ChemE on August 30, 2016, 04:54:22 PM
My sleep current is 6.4µA and most of that is the WDT and LDO. Now to ditch both in favor of a TPL5110 and running directly off two AAs. That should get me down to 35nA sleeping current.
You bet ;)
FWIW What I see in some of these fly-off-the-shelf products from adaf ruit/sparkfun products is they make libraries/examples that include plenty of such "padding".
Agreed Felix. Good for the masses but not at all appropriate for our purposes. Given that we are trying to get back to deep sleep as quickly as possible, the code that runs during wake cycles needs to be as tight as possible. Lately I've started to wonder if a highly optimized ASM implementation of I2C or SPI would help us all out since we all use one or both protocols to talk to our peripherals during each wake cycle and the arduino libraries seem less than svelte to me.
Quote from: ChemE on September 07, 2016, 08:37:56 AM
Lately I've started to wonder if a highly optimized ASM implementation of I2C or SPI would help us all out since we all use one or both protocols to talk to our peripherals during each wake cycle and the arduino libraries seem less than svelte to me.
This is where the ARM based processors with DMA and peripheral interconnects (EVSYS, PRS, etc) really shine. Serial IO can take place in the background while the processor sleeps. No wasted cycles while the processor polls/transfers each byte transferred and you can have overlapped IO on different buses.
Tom