This post covers some design details that wouldn't fit (or too much detail) in the previous post.
Coding Details
As noted in the original post, the digitalWrites were replaced with Assembler code.
The back to back digitalWrites worked, charging the capacitor reliably, but, when examining the signal at the junction of L1, R3, and D1, I discovered that most of the time the voltage was ringing, meaning that there was wasted energy - no charge being pumped into the cap during the ringing. (See 1st photo below)
Looking at the loop timing, it appeared that the 'tight' C-coded loop was pretty 'loose', taking a little over 27uS to complete one cycle and, during the 'off' phase of Q5, only about 3uS was actually charging the cap. This told me that the loop needed to be tighter than I could get with the built-in I/O functions.
I decided that the easiest thing to do was simply switch to assembler during this phase so that I could control the timing more accurately and with shorter cycles. After some tweaking, I ended up with about 7uS ON, 7uS OFF as the optimum cycle time. This was longer than the 3uS/3uS cycle I expected from the ringing trace, but taking the longer time to charge the inductor ended up charging the capacitor quicker and resulting in the shortest overall time. (See 2nd photo below)
Current Consumption
In terms of current drain on the battery, this Mote spends most of it's time sleeping. It spends 10 minutes sleeping if it's 'idle' (the valve is not ON) and simply reports into the Gateway its status at the end of every 10 minute interval. Every hour it adds a complete status block which includes its current transmit level and battery voltage.
Either of these transmissions to the Gateway may trigger the Gateway to reply that effectively says "I've got 'something' for you". If the Mote is ready to accept the 'something', then it sends a new packet to the Gateway telling it "Ok, give it to me". Normally1 this would occur when some daemon running on the home server determines that the Valve should be turned on and had sent the command to be forwarded to the sleeping Mote.
When the Mote receives the command to turn on the valve, it sets a timer based on the default time or a time included in the request, opens the valve, and changes its 'sleep' time to 10 seconds and its 'report' interval to one minute. This prevents the Mote from snoozing through its turn off time and gives the Gateway a shorter window to command the Mote to override its timer and shut off the valve immediately (within one minute, anyway). During this time, the Mote reports that the valve is open and the time remaining.
When the time is exhausted or overridden, the Mote reverts back to its 'Idle' cycle times.
Net is that MOST of the time, the Mote is operating just a few mS out of 600 seconds or ~0.02% duty cycle. With its 3300mAH batteries and <20uA sleeping current, the Mote will rot before the batteries run down due to current drain.
So the worst case load is when turning the valve on or off. As it turns out, the current required is less than what the RFM69HW radio consumes during transmit, however, the power to charge up the cap takes a lot longer than it takes to transmit the periodic status packet (840mS vs 3mS) (see third photo below) so overall current drain is higher.
Looking at the fourth photo below, which measures the current drawn on the battery during the charge/fire cycle, you can see (in the yellow trace) the current drawn over time. The scale is 1mA/1mV so the peak, right at the beginning, is approximately 61mA, but quickly levels off to about 29mA for the remainder of the cycle. If this occurred often, the batteries would drain quickly, but it's unlikely that a pair of cycles would occur more than a couple of times a week. Using a worst case scenario (one ON/OFF cycle per day) the power consumed would be (2 x 840mS/(24hr/day*3600seconds/hr)) * ~38mA = ~74uA average power consumed. Add the 25uA for sleeping and the occasional transmission, gives us about ~100uA average current drain, or, with 3300mAH batteries, equals about 'ARLT'2 (3.67years), which exceeds my goal of lasting at least one season by 'enough'...
Notes:
1. The 'got something' may alternatively include a request to download a new code update or command to reboot. The Mote can reject these if it determines that it's too busy (valve is open) or the battery level is too low to reliably download. Note that this code is NOT included in the example code. The example simply shows how to control the Valve electronics.
2. 'ARLT': A Really Long Time
That's pretty much it. Ask questions if you got 'em...
Tom