Now that my analysis capabilities have improved, it thought it’d be interesting to see the power consumption profile of a Room Node, running the roomNode.ino sketch. Here’s an annotated capture of a motion event:
The yellow line is the current consumption of the entire room node. I’ve added some annotations, although there are still a few things I’m not so sure about, such as the 2.5 ms delay between SHT readout and XMIT start.
The red line is the integral of the yellow line, i.e. the total amount of energy consumed as time progresses. It took about 3 ms between the end of the packet transmission and the first ACK packet header byte coming in – this thumb-twitching with the receiver enabled accounts for about 1/3rd of the power consumption!
There is almost always room for improvement with this sort of stuff. The closer you look, you more you find things to optimize. For example, I noticed that there were blips every 32 mS or so (it’s slightly irregular):
This is zoomed in on both axes. The noise level is a bit higher, perhaps due to the 2 mV/div setting of the scope.
That’s over 1 ms @ 0.8 mA, at about 30 times per second on average. I don’t know what it is – it’s not the PIR sensor, which was removed during this measurement. Not a lot of energy per blip, but it does add up: ≈ each uses 1.1 µC, i.e. some 2,000 µC per minute. Whereas the first screen shows that a transmission takes only 130 µC.
So there you go: vampire power at microwatt levels!
Update – Ah, wait – of course! – it’s the Scheduler class in the Ports library! When idling, it lets time pass in steps of 0.1s (or rather 96 ms), and there’s no other way to do this than with 32 and 64 ms watchdog timer steps. I told you – there are no show-stoppers in this game, it works on logic and insight, all the way down!
What a superb diagnostic tool. I guess if you really wanted to identify particular areas of your sketch which are consuming power you could place a selection of different value resistors onto some of the ports and pulse them briefly so that a recognisable pulse of extra current will appear on the scope trace.
Is the 2.5ms transmit delay simply the time it takes for the RFM12B to switch into transmit mode and issue the first “feed me” interrupt? In which case the 2.5ms transmit delay and the 3ms whilst waiting for reply are actually the same thing, but on different nodes. The receive node could also “suffer” from the same 2.5ms “switch to transmit mode” delay before it can send the acknowledgement.
Connect up another input into your scope from the receiving node and have a look at both ends simultaneously.
So if you feel like investigating the delay before transmission starts you will actually get both birds with the one stone.
Or you could send me your scope and I’ll do it ;o)
I don’t think the transmitter startup takes that long, but it needs to be checked.
As for syncing to specific parts of a sketch – probably tons of ways to do it. Either via spare I/O pins (analog levels is nice, but note that I also have 8 logic inputs to trigger with), or even by sending out an SPI byte while no chip is selected (and then sync on a specific serial data pattern).
My hunch right now, is that the Scheduler “bug” (if you can call it that) points to that pulse being mis-identified as a SHT11 readout, but actually being a watchdog or other interrupt (the shape looks suspiciously similar to the ones in the second image).
I’ll definitely investigate further, although I suspect there’s no end to it – have already been thinking about how to avoid that energy waste between xmit and recv packet (if it’s indeed not an RFM12B issue).
As for connecting both nodes – that’s a neat idea. Would also expose the delays present across FIFO’s etc. For absolute optimal timing (and TDMA like extensions) that could provide some very useful info. Maybe it can lead to a clever way of receiving data with some sort of intermittent enabling (the RFM12B also has a low duty-cycle feature I haven’t explored yet).
And, ehm… I’ll hold onto the scope, if that’s ok with you.