Following all the initial testing and debugging throughout the past weeks, it finally comes to the time to let the SPINES Mote run untethered.

At the time of writing, the SPINES Mote pictured above has already been operating on its internal power (i.e., the attached 14500, or AA-sized, Li-ion cell rated at 750 mAh) for over 30 hours non-stop. The board is running a test sketch to take measurements from its onboard sensors, and transmit them to ThingSpeak every minute (consider this as a stress test to drain the battery). It keeps in the deep sleep mode for the rest of time to conserve energy, which should draw only around 100 µA from my back-of-envelope calculation for the worst case (without using the RTC for power gating), prior to implementing any of my planned optimizations.

Although a solar panel is attached to the board (see the top left cable), it is not actually helping recharge the battery yet: Putting the high duty cycle aside, I found a significant leakage current at ~6.4 mA even when the board is supposedly in the deep sleep mode!

Of course, I have run some tests to trace the source of the leakage. In order to locate the leakage, I ran the tests on two boards, the untethered one shown above ("Board A"), and a separate board without the ESP8266, sensors, and battery fuel gauge ("Board B"). Here are some current measurements in several scenarios:

	Description	Current Drawn
1	Board A: ESP8266 and sensors active	~80 mA
2	Board A: ESP8266 in deep sleep; buck converter (i.e., sensor power rail) disabled	~6.4 mA
3	Board A: LDO disabled (with fuel gauge presumably on)	~56 µA
4	Board B: LDO disabled (i.e., completely "no load" with only the BQ25570 circuit left operating)	~1 µA
5	Board A: LDO enabled but no load	~220 µA
6	Board B: LDO enabled but no load	~100 µA

Scenario 1 is nominal and pretty much what I expected according to the ESP8266 datasheet and past experience (80 mA is an average figure; there are spikes at >300 mA during transmission).

Scenario 2 is problematic: I never imagined it would reach the mA range. Deep sleep with a mA-range current consumption would virtually make self-sustainability via energy harvesting infeasible (unless using ridiculously large solar panel and battery pack).

Disabling the LDO regulator (currently enabled automatically using BQ25570's VBAT_OK signal) in Scenarios 3 and 4 revealed that LDO is actually the source of the leakage. Scenarios 5 and 6 further confirmed that enabling the LDO would cause a significant leakage even if there is no load attached to its output.

These test results forced me to resolve the RTC module issue (keeps crashing the ESP8266 in boot loop), such that I can make use of the RTC to disable the LDO and achieve sub-10 µA consumption during deep sleep (assuming that the fuel gauge is removed too). Some initial testing has indicated that the RTC issue was due to reset line jamming. Cutting the RTC module's reset trace brings it back to service. More to follow soon.