A solar supercap powered Moteino (15Farad charged by BQ25504)

[WhiteHare]

As described in my last post, I just now tried brute forcing the RFM69 into Stand-by mode after the code detects the PacketSent semaphore, and it seems to work pretty well (see attached screenshot below).  This is a pretty large current savings!

All I did was insert one line of code:

Code Select Expand

  radio.writeReg(REG_OPMODE,B00000100); //activate RFM69 Stand-by mode

between the PacketSent semaphore being detected and the final double shot voltage reading.  So, now the final double shot voltage measurement is higher than the last single-shot measurement during Tx, which is, as Perky points out, what one would expect:

Code Select Expand

45,[Sender:2],349 ABCDEFGHIJKLMNOPQRSTUVWXYZ012345678901234567890123456789,[RX_RSSI:-37]
46,[Sender:2],349,[RX_RSSI:-37]
47,[Sender:2],340,[RX_RSSI:-37]
48,[Sender:2],335,[RX_RSSI:-37]
49,[Sender:2],331,[RX_RSSI:-37]
50,[Sender:2],329,[RX_RSSI:-37]
51,[Sender:2],328,[RX_RSSI:-37]
52,[Sender:2],327,[RX_RSSI:-37]
53,[Sender:2],326,[RX_RSSI:-37]
54,[Sender:2],325,[RX_RSSI:-37]
55,[Sender:2],324,[RX_RSSI:-37]
56,[Sender:2],323,[RX_RSSI:-37]
57,[Sender:2],322,[RX_RSSI:-37]
58,[Sender:2],322,[RX_RSSI:-36]
59,[Sender:2],322,[RX_RSSI:-37]
60,[Sender:2],322,[RX_RSSI:-36]
61,[Sender:2],321,[RX_RSSI:-36]
62,[Sender:2],321,[RX_RSSI:-37]
63,[Sender:2],320,[RX_RSSI:-37]
64,[Sender:2],320,[RX_RSSI:-37]
65,[Sender:2],315,[RX_RSSI:-36]
66,[Sender:2],343,[RX_RSSI:-37]

[WhiteHare]

...I don't think that's needed now BTW, it's accurate with a single read...

In fact, I think the double-shot measurement which occurs after the packetSent flag goes high is now superfluous.  I originally threw it in as an extra check just to see what would happen, but after this last dataset generated using the brute force correction into Standby-mode,  I no longer see a use for it.

[ChemE]

That power savings obtained from brute forcing the radio back into standby does seem very substantial.  Do you plan to test that on a charged cap to see how many cycles you get before voltage collapse?

[perky]

@WhiteHare I assume you're not using auto mode for transmission? If you used that then you could use writing the first byte into the FIFO to start transmission (which would be done by entering intermediate mode programmed for TX mode), then immediately program RegOpMode to STANDBY before TX is complete. It should remain in TX mode then until the PacketSent event and then go to STANDBY immediately.

I think if you're not using auto mode then what you're seeing is normal manual driven process in that it will remain in TX until told otherwise even if the packet has been sent (presumably sending preambles). It's interesting that it exits TX at all in your case (do you use any other way to terminate things, like putting to sleep?). I actually specifically set to sleep after a packet sent event as I assumed it wouldn't stop TX until told to.

Edit: Also you seem to have current kicks at the beginnig and end of this sequence, and a strange 50mV drop on your last but one reading. Where are they coming from?

Mark.

[WhiteHare]

That power savings obtained from brute forcing the radio back into standby does seem very substantial.  Do you plan to test that on a charged cap to see how many cycles you get before voltage collapse?

Yup.  I doubt it will do better than the earlier 14111 cycle number, though.

[WhiteHare]

Edit: Also you seem to have current kicks at the beginnig and end of this sequence, and a strange 50mV drop on your last but one reading. Where are they coming from?

Rather than using the WDT, I'm using Listen-Mode to supply the interrupt to wake up from sleep.  So, the spike on the left occurs when Listen-Mode shifts from RFM69 Standby-Mode mode into RFM69 Rx-Mode.  The RFM69 PllLock produced in that process is the actual interrupt which wakes up the atmega328p.

Similarly,  before going back to sleep, the atmega328p initiates RFM69 Listen-Mode.  Unfortunately, the Listen-Mode template is an RFM69 Rx followed by RFM69 Standby cycle, instead of a RFM69 Standby followed by RFM69 Rx cycle.  So, the spike you see on the right hand side is the current drain caused the by RFM69 RX phase of RFM69 Listen-Mode immediately after RFM69 Listen-Mode is re-activated.  It is wider than the spike on the left because with the spike on the left, the atmega328p wakes up on the PllLock trigger and as quickly as it can tries to terminate Listen-Mode.  By the time Listen-Mode is terminated, some of the Rx has already happened,  but it appears that some of the Rx phase does get squelched.  In contrast, the Rx spike on the right is wider because I have to leave Listen-Mode running (or else I get no Listen-Mode timer).

As to the 50mv drop, I'm not sure which part of the scope shot you're referring to. 

@WhiteHare I assume you're not using auto mode for transmission? If you used that then you could use writing the first byte into the FIFO to start transmission (which would be done by entering intermediate mode programmed for TX mode), then immediately program RegOpMode to STANDBY before TX is complete. It should remain in TX mode then until the PacketSent event and then go to STANDBY immediately.

I think if you're not using auto mode then what you're seeing is normal manual driven process in that it will remain in TX until told otherwise even if the packet has been sent (presumably sending preambles). It's interesting that it exits TX at all in your case (do you use any other way to terminate things, like putting to sleep?). I actually specifically set to sleep after a packet sent event as I assumed it wouldn't stop TX until told to.

Given the additional background supplied by your helpful comments, I think it's the code's above mentioned re-activation of Listen-Mode which is what is terminating Tx mode.  Maybe without that, the RFM69 would have lingered in Tx mode indefinitely.  So, yeah, as long as I can fill the FIFO faster than it empties in automatic mode, and then issue an immediate RegOpMode to STANDBY (before TX completes), it sounds like automatic mode would be optimal.

[perky]

Rather than using the WDT, I'm using Listen-Mode to supply the interrupt to wake up from sleep.

That explains the spikes, thanks!

As to the 50mv drop, I'm not sure which part of the scope shot you're referring to. 

I was curious why the 2nd from last reading dropped by 50mV rather than at most 10mV. Just an observation really:

Code Select Expand

61,[Sender:2],321,[RX_RSSI:-36]
62,[Sender:2],321,[RX_RSSI:-37]
63,[Sender:2],320,[RX_RSSI:-37]
64,[Sender:2],320,[RX_RSSI:-37]
65,[Sender:2],315,[RX_RSSI:-36]
66,[Sender:2],343,[RX_RSSI:-37]

Good work though WhiteHare, it'll be interesting how long you can get it to last for. I suspect you may well get significantly more iterations than your last test but we wait to see

Mark.

[WhiteHare]

I've never used RegAutoModes before, but it looks as though

Code Select Expand

radio.writeReg(REG_AUTOMODES, B00111011)

should induce the desired automatic behavior.  Thanks for the suggestion!

[WhiteHare]

I was curious why the 2nd from last reading dropped by 50mV rather than at most 10mV. Just an observation really:

Code Select Expand

61,[Sender:2],321,[RX_RSSI:-36]
62,[Sender:2],321,[RX_RSSI:-37]
63,[Sender:2],320,[RX_RSSI:-37]
64,[Sender:2],320,[RX_RSSI:-37]
65,[Sender:2],315,[RX_RSSI:-36]
66,[Sender:2],343,[RX_RSSI:-37]

I'm not sure what would have caused that either.  However, I just now switched to  an ADC prescaler of 8 (which, given the 8Mhz on-chip resonator, implies an ADC clockspeed of 1Mhz).  As you'd expect, it does give a smoother plot:

Code Select Expand

163,[Sender:2],348 ABCDEFGHIJKLMNOPQRSTUVWXYZ012345678901234567890123456789,[RX_RSSI:-38]
164,[Sender:2],347,[RX_RSSI:-37]
165,[Sender:2],342,[RX_RSSI:-38]
166,[Sender:2],338,[RX_RSSI:-38]
167,[Sender:2],335,[RX_RSSI:-38]
168,[Sender:2],332,[RX_RSSI:-37]
169,[Sender:2],330,[RX_RSSI:-37]
170,[Sender:2],329,[RX_RSSI:-37]
171,[Sender:2],329,[RX_RSSI:-38]
172,[Sender:2],328,[RX_RSSI:-37]
173,[Sender:2],327,[RX_RSSI:-37]
174,[Sender:2],327,[RX_RSSI:-38]
175,[Sender:2],327,[RX_RSSI:-37]
176,[Sender:2],327,[RX_RSSI:-38]
177,[Sender:2],327,[RX_RSSI:-37]
178,[Sender:2],326,[RX_RSSI:-37]
179,[Sender:2],326,[RX_RSSI:-38]
180,[Sender:2],326,[RX_RSSI:-38]
181,[Sender:2],326,[RX_RSSI:-37]
182,[Sender:2],324,[RX_RSSI:-37]
183,[Sender:2],324,[RX_RSSI:-37]
184,[Sender:2],323,[RX_RSSI:-37]
185,[Sender:2],323,[RX_RSSI:-37]
186,[Sender:2],323,[RX_RSSI:-37]
187,[Sender:2],323,[RX_RSSI:-37]
188,[Sender:2],323,[RX_RSSI:-37]
189,[Sender:2],323,[RX_RSSI:-37]
190,[Sender:2],323,[RX_RSSI:-37]
191,[Sender:2],323,[RX_RSSI:-37]
192,[Sender:2],322,[RX_RSSI:-37]
193,[Sender:2],322,[RX_RSSI:-38]
194,[Sender:2],322,[RX_RSSI:-37]
195,[Sender:2],322,[RX_RSSI:-37]
196,[Sender:2],321,[RX_RSSI:-38]
197,[Sender:2],321,[RX_RSSI:-38]
198,[Sender:2],321,[RX_RSSI:-38]
199,[Sender:2],321,[RX_RSSI:-37]
200,[Sender:2],321,[RX_RSSI:-37]
201,[Sender:2],320,[RX_RSSI:-37]
202,[Sender:2],320,[RX_RSSI:-38]
203,[Sender:2],320,[RX_RSSI:-39]
204,[Sender:2],320,[RX_RSSI:-38]
205,[Sender:2],320,[RX_RSSI:-38]
206,[Sender:2],320,[RX_RSSI:-39]
207,[Sender:2],320,[RX_RSSI:-39]
208,[Sender:2],320,[RX_RSSI:-38]
209,[Sender:2],320,[RX_RSSI:-38]
210,[Sender:2],320,[RX_RSSI:-38]
211,[Sender:2],320,[RX_RSSI:-38]
212,[Sender:2],320,[RX_RSSI:-38]
213,[Sender:2],320,[RX_RSSI:-38]
214,[Sender:2],319,[RX_RSSI:-38]
215,[Sender:2],319,[RX_RSSI:-38]
216,[Sender:2],319,[RX_RSSI:-38]
217,[Sender:2],319,[RX_RSSI:-38]
218,[Sender:2],319,[RX_RSSI:-38]
219,[Sender:2],319,[RX_RSSI:-38]
220,[Sender:2],319,[RX_RSSI:-38]
221,[Sender:2],319,[RX_RSSI:-38]
222,[Sender:2],318,[RX_RSSI:-38]
223,[Sender:2],317,[RX_RSSI:-38]
224,[Sender:2],317,[RX_RSSI:-38]
225,[Sender:2],317,[RX_RSSI:-38]
226,[Sender:2],317,[RX_RSSI:-39]
227,[Sender:2],317,[RX_RSSI:-38]
228,[Sender:2],317,[RX_RSSI:-38]
229,[Sender:2],317,[RX_RSSI:-38]
230,[Sender:2],317,[RX_RSSI:-38]
231,[Sender:2],317,[RX_RSSI:-38]
232,[Sender:2],317,[RX_RSSI:-38]
233,[Sender:2],317,[RX_RSSI:-37]
234,[Sender:2],317,[RX_RSSI:-38]
235,[Sender:2],317,[RX_RSSI:-38]
236,[Sender:2],317,[RX_RSSI:-38]
237,[Sender:2],317,[RX_RSSI:-38]
238,[Sender:2],317,[RX_RSSI:-38]
239,[Sender:2],317,[RX_RSSI:-38]
240,[Sender:2],317,[RX_RSSI:-38]
241,[Sender:2],317,[RX_RSSI:-38]
242,[Sender:2],317,[RX_RSSI:-38]

[perky]

Interesting, you're clocking the ADC way over 200kHz, so technically shouldn't have high resolution...
Mark.

[ChemE]

You guys may not recall, but the source I cited stated that you can clock the ADC up to 1MHz and still get full resolution even though the datasheet doesn't quite state the same.

[WhiteHare]

Actually, ChemE, although that article was certainly a good find by you (and kudos for that), it was really your reports of success with it that inspired me to give it a try too.

Are there any known downsides to the 1Mhz ADC rate?

[WhiteHare]

@WhiteHare I assume you're not using auto mode for transmission? If you used that then you could use writing the first byte into the FIFO to start transmission (which would be done by entering intermediate mode programmed for TX mode), then immediately program RegOpMode to STANDBY before TX is complete. It should remain in TX mode then until the PacketSent event and then go to STANDBY immediately.

I think if you're not using auto mode then what you're seeing is normal manual driven process in that it will remain in TX until told otherwise even if the packet has been sent (presumably sending preambles). It's interesting that it exits TX at all in your case (do you use any other way to terminate things, like putting to sleep?). I actually specifically set to sleep after a packet sent event as I assumed it wouldn't stop TX until told to.

Have you ever succeeded in getting auto mode to work for transmission?  My first attempt failed, and I'm not finding anything outside the datasheet when I do topic searches for it.

[perky]

Have you ever succeeded in getting auto mode to work for transmission?  My first attempt failed, and I'm not finding anything outside the datasheet when I do topic searches for it.

I've never used it personally. How is it failing? Can you do a very simple transmit (program RegAutoModes intermediate state to be TX, enter condition to be fifo not empty, exit condition packet sent), i.e. RegAutoModes = 0b00111011 = 0x3B

Can you post code?
Mark.

[WhiteHare]

It failed by not transmitting.  Meh, I decided to backtrack to the previous code that was already working and leave AutoTx for a future "someday/maybe" optimization.

So, to that end, I ran the supercap to exhaustion using the working code.  Interestingly, toward the point of failure, the voltage does seem to drop much more rapidly than when the voltages are higher.  Here's the log:
http://pastebin.com/UTVyLtTt