This post was prompted by a message on the forum, about what this whole “JeeNode” thing is, really.

Here are a JeeNode v6 and an Arduino Duemilanove, side by side:

Let me start by saying, tongue-in-cheek: it’s all Arduino’s fault!

Because – let’s face it – the core of each Arduino and each JeeNode is really 95% the same: an Atmel AVR ATmega328P chip, surrounded by a teeny little bit of support circuitry and placed on a printed circuit board. So part of the confusion comes from the fact that the Arduino introduced its own conventions, moving it further away from the underlying common ATmega technology.

The differences between an Arduino Duemilanove and a JeeNode v6 – which resemble each other most – are:

• the JeeNode has a “skinnier” shape, incompatible with Arduino “shields”
• the Arduino runs at 5V, whereas the JeeNode runs at 3.3V (this carries through to all I/O pins)
• the JeeNode includes a wireless radio module, called the RFM12B by HopeRF
• the Arduino includes an FTDI <-> USB interface, while the JeeNode relies on an external one

There are many other differences, of course – so let’s continue this list a bit:

• the Arduino’s “eco-system” is far, far bigger than the JeeNode’s (translation: everyone who finds out about JeeNodes probably already knows about the Arduino platform, and usually already has one or more of ‘em)
• this carries through to articles, websites, books, and discussion forums – Arduino is everywhere
• you can do lots of stuff with an Arduino without ever touching a soldering iron, whereas the JeeNode is really not usable without some soldering (even if just to solder on a few pin headers)
• different pinouts… it’s one big conspiracy to confuse everyone, of course! (just kidding: see below)

My reasons for coming up with the JeeNode have been documented in the past on this weblog, and can be summarized as: 1) running at 3.3V for lower power consumption and to better match modern sensors and chips, and 2) supporting a simpler form of expandability through the use of “plugs” – little boards which can be mixed and matched in many different combinations.

On the software side, JeeNodes remain fully compatible with the Arduino IDE, a convenient software environment for Windows, Mac, and Linux to develop “sketches” and upload them to the board(s).

The biggest stumbling block seems to be the way pins are identified. There are 4 conventions, all different:

• Atmel’s hardware documentation talks about pins on its internal hardware ports, in a logical manner: so for example, there is a port “D” with 8 I/O pins numbered 0..7 – the sixth one would be called PD5.
• Then there is the pin on the chip, this depends on which chip and which package is being referred to. On the 28-pin DIP package used for an ATmega328P, that same PD5 pin would be identified as pin 11. That’s the 11th pin, counting from the left side of the chip with pin 1 at the top.
• The Arduino run-time library has software to control these pins. For a digital output pin, you can set it to “1″ for example, by writing digitalWrite(5,1). This resembles PD5, but it fails for other pins (PB0 is “8″ in Arduino-land, and PC1 is “1″ if used as an analog input, or “15″ if used otherwise – go figure…).
• The JeeNode organizes several pins as part of 6-pin “Ports” (no relation to Atmels terminology!), each of them having 1 digital and 1 analog-or-digital pin.

The thing about JeeNode Ports is that there are 4 of them, and they can all be used for plugs in the same way. To support this, there’s a Ports library which lets you define port objects. This is an abstraction layer on top of the Arduino runtime. The reason is that it lets you associate a port object with a header on the JeeNode:

    Port myport (2);

Then you can connect your hardware / sensor / plug / whatever to the header marked “P2″ on the JeeNode, and access it as follows:

    myport.digiWrite(1);

This happens to be the same pin as in the examples above, i.e. PD5 of an ATmega, pin 11 of the 28-pin DIP chip, and digitalWrite(5,1) on an Arduino. This also means that there are numerous ways to perform the same action of setting pin 11 of the chip to a logical “1″ (i.e. 3.3V or 5V):

• the “raw” C-level access, using Atmel’s register conventions and definitions (fastest, by far):

      PORTD |= 1 << 5;  // or ...
      PORTD |= _BV(5);  // same thing
      bitSet(PORTD, 5); // same thing, using an Arduino macro
  

• the Arduino way of doing things:

      digitalWrite(5, 1);
  

• the JeeNode Ports library way of doing things, as shown above:

      Port myport (2);
      myport.digiWrite(1);
  

• … let’s throw in an extra bullet item, since every other list in this post appears to come in fours ;)

The one (minor) benefit you get from using the Ports approach on a JeeNode, is that if you attach your hardware to a different port, say port 3, then you only need to change a single line of code (to “Port myport (3);” in this case). The rest of the code, i.e. everywhere where its pins are being read or written, can then remain the same.

For an overview of all pinout differences, see also this weblog post. For full details, see the JeeNode PDF docs.

    $ jeemon examples/driver-demo/
    15:45:01.975 RF12demo config usb-A700fdxv RF12-868.5
    reading:RF12-868.5.3:radioBlip:ping = 493295
    reading:RF12-868.5.3:radioBlip:age = 365
    ^C

That’s nearly half a million packets, one every 64 seconds, all on a single LiPo battery charge:

The setup is very simple. A 1300 mAh LiPo battery (I just picked one up in a camera shop with a convenient size), attached to a JeeNode USB:

At 3.94 V the battery is still far from dead, so it’ll probably stay alive for quite a bit longer…

The sketch running on this node is:

(looks like I had lost the low-power stuff in the “radioBlip” code, now fixed on GitHub)

Lots of low-power nodes are holding out nicely here at JeeLabs, by the way. There are about half a dozen permanent room nodes, and with the latest roomNode sketch they just keep going. Some are running on 3x AA rechargeable EneLoop batteries, others use 3x AAA with even less juice, and all of them have been running with just a single charge since the beginning of this year.

To this end, I modified a JeeNode SMD, by replacing the 16 MHz resonator with a 32 KHz crystal:

I didn’t even bother adding capacitors, these are probably not needed with this crystal (same as on the RTC Plug) since there is probably enough parasitic capacitance already.

The tricky part is the code, since the ATmega is now running in a not-so-Arduino-like mode. Could almost have used OptiBoot with this setup, but the only internal RC clock build for it is the LilyPad, which has an ATmega168.

I ended up using the ISP programmer. IOW, I now compile for “LilyPad w/ 328″ and then bypass the bootstrap and serial-upload. Less convenient, but it works.

Here’s a quick test sketch which writes a dot on the serial line exactly once a second:

So this setup is working. It draws 4.10 ma, consistent with the recent current measurements: slightly less than with the 16 MHz resonator pre-scaled by two.

In idle mode, current use drops to 1.71 mA, not bad!

Now let’s power down with just the timer running as real time clock. There’s a special “power save” mode which does just that. The difference is that timer 0 will now be off, so there won’t be interrupts waking up the ATmega every 1024 µs (as side-effect, the millis() function will start to lose track of time):

A small adjustment is needed to make sure the serial port is finished before we go into low-power mode, hence the call to delay(3).

Hm, power consumption is still 0.67 mA – quite a bit, given that we’re really powering down most of the time.

Ah, wait. I forgot to turn off the radio. Doing that brings the reading down to 0.15 mA – and I forgot to turn off the ADC and other sub-systems. Now we’re down to … 0.05 mA, while still printing dots:

Note that these 1 second interrupts are very accurately timed, more so even than with the standard 16 MHz resonator. This could be used to perform time-domain tricks on the wireless side, i.e. waking up just in time whenever a “scheduled” packet is expected to come in – as described in yesterday’s post.

There’s probably more left to try. The delay is running on full power, waiting for the serial output to clear the USART. It could be done while in idle mode, for example. Anyway… that entire delay becomes superfluous when we stop sending out debugging output over the serial port.

So there you have it – a JeeNode running at ≈ 8 MHz, with a precise 32,768 Hz pulse feeding timer 2, in a way which supports low-power sketches while maintaining an accurate sense of time.

Wanna make a clock?

The difference is that with a remote node initiating all transmissions, it really only has to enable the RFM12B wireless module very briefly. With a 12..23 mA current drain, brevity matters!

So how do you get data from a central node, to remote and power-starved nodes?

One way is to poll: let the remote node ask for data, and return that data in an ACK packet as soon as asked. This will indeed work, and is probably the easiest way to implement that return data path towards remote nodes. One drawback is that if all nodes start polling a lot, the band may become overloaded and there will be more collisions.

Another approach is to agree on when to communicate. So now, the receiver again “polls” the airwaves, but now it tracks real time and knows when transmissions for it might occur. This is more complex, because it requires the transmitter(s) and receiver(s) to be in sync, and to stay in sync over time.

Note that both approaches imply a difficult trade-off between power consumption and responsiveness. Maximum responsiveness requires leaving the receiver on at all times – which just isn’t an option. But suppose we were able to stay in sync within 1 ms on both sides. The receiver would then only have to start 1 ms early, and wait up to 2 ms for a packet to come in. If it does this once a second, then it would still be on just 0.2% of the time, i.e. a 500-fold power saving.

Let’s try this out. Here’s the timedRecv.pde sketch (now in the RF12 library):

It listens for incoming packets, then goes into low-power mode for 2 seconds, then it starts listening again. The essential trick is to report two values as ACK to the sender: the time the receiver started listening (relative to that receiver’s notion of time), and the number of milliseconds it had to wait for the packet to arrive.

There’s no actual data processing – I’m just interested in the syncing bit here.

The sender side is in the timedSend.pde sketch:

This one tries to send a new packet each time the receiver is listening. If done right, the receiver will wake up at just the right time, and then go to sleep again. The ACK we get back in the sender contains valuable information, because it lets us see how accurate our timing was.

Here’s what I get when sending a new packet exactly 2,096 milliseconds after an ACK comes in:

Not bad, one ack for each packet sent out, and the receiver only has to wait about 6 milliseconds with its wireless receiver powered up. I’ve let it run for 15 minutes, and it didn’t miss a beat.

For some reason, send times need to be ≈ 2.1 s instead of the expected 2.0 s.

Now let’s try with 2,095 milliseconds:

Something strange is happening: there’s consistently 1 missed packet for each 5 successful ones!

My hunch is that there’s an interaction with the watchdog timer on the receiver end, which is used to power down for 2000 milliseconds. I suspect that when you ask it to run for 16 ms (the miminum), then it won’t actually synchronize its timer, but will fit the request into what is essentially a free-running counter.

There may also be some unforeseen interaction due to the ACKs which get sent back, i.e. there’s a complete round-trip involved in the above mechanism

Hmm… this will need further analysis.

I’m using a standard JeeNode on the receiving end, i.e. running at 16 MHz with a ceramic resonator (specs say it’s 0.5% accurate). On the sender side, where timing is much more important, I’m using a JeeLink which conveniently has an accurate 16 MHz crystal (specs say it’s 10 ppm, i.e. 0.001% accurate).

But still – even this simple example illustrates how a remote can receive data while keeping its wireless module off more than 99% of the time.

(old one on the left, new one on the right)

Sturdier, no need to disconnect the multimeter to short it out, and most importantly: high-side current sensing! That’s quite important, because multimeters can add a small voltage drop when used in current measurement mode, and that voltage drop will affect the serial I/O on the FTDI pins when placed in the GND line. Silly me, should have been on the PWR line all along!

The back side of the new connector is trivial:

The multimeter attaches to the top pins, bent apart for easy connection. The jumper shorts it out so this contraption can still be used when the multimeter is turned off.

Ok, time for some simple measurements:

• ATmega full speed, doing nothing: 6.84 mA
• ATmega full speed, with the RFM12B receiver on: 18.42 mA
• ATmega powered down, only the RFM12B receiver on: 11.53 mA
• ATmega full speed, with the RFM12B tranmitter on: 29.92 mA

Idle mode is a simple way to reduce power consumption without changing the logic of the code. It turns the MPU off until an interrupt occurs. Basically, you’re telling it “I’ve got nothing to do until something new happens”. It’s a pretty safe change, and well worth doing in any idle loop which isn’t directly polling I/O pins. The ATmega’s current consumption is slashed by more than half:

• ATmega in idle mode, doing nothing: 2.80 mA

Another way to reduce power consumption, is to slow down the clock at which everything takes place, by setting the “clock pre-scaler”:

• ATmega @ 16 MHz, doing nothing: 6.84 mA (as before)
• ATmega @ 8 MHz, doing nothing: 4.35 mA
• ATmega @ 4 MHz, doing nothing: 2.96 mA
• ATmega @ 2 MHz, doing nothing: 2.02 mA
• ATmega @ 1 MHz, doing nothing: 1.55 mA
• ATmega @ 500 KHz, doing nothing: 1.28 mA
• ATmega @ 250 KHz, doing nothing: 1.16 mA
• ATmega @ 125 KHz, doing nothing: 1.09 mA
• ATmega @ 62.5 KHz, doing nothing: 1.06 mA

Diminishing returns, clearly. Note that lowering the system clock in this way is not necessarily the best choice – getting something done N times faster and then powering down completely might be more efficient (see below).

One thing to watch out for: don’t go below 4 Mhz if you want to be able to use the RFM12B, or the processor will be too slow to process each byte.

When combining this, we get:

• ATmega @ 4 MHz in idle mode, doing nothing: 1.48 mA
• ATmega @ 62.5 KHz in idle mode, doing nothing: 1.03 mA

The advantage of this approach is that the clock is still running on the 16 MHz resonator (which probably draws most of that remaining current), so you’re still able to keep track of time – just more slowly.

A different approach is to go into real low power mode, and use the watchdog to get back out of this comatose state. The watch dog timer is less accurate, but depending on your application that may not be an issue.

Here’s the current consumption with the ATmega alternately in full speed and in power down mode:

• ATmega 16 ms @ 16 MHz / 16 ms powered down, doing nothing: 3.49 mA
• ATmega 8 ms @ 16 MHz / 16 ms powered down, doing nothing: 2.31 mA
• ATmega 4 ms @ 16 MHz / 16 ms powered down, doing nothing: 1.39 mA
• ATmega 2 ms @ 16 MHz / 16 ms powered down, doing nothing: 0.80 mA
• ATmega 1 ms @ 16 MHz / 16 ms powered down, doing nothing: 0.46 mA

That last one does about the same amount of work as when running constantly @ 1 MHz, but with a third of the power consumption. Here is the corresponding sketch:

And it will continues to scale downward:

• ATmega 100 µs @ 16 MHz / 16 ms powered down, doing nothing: 90.4 µA

Which still represents 100,000 active processor cycles per second…

And lastly, let’s take it into power down and run for just 1 ms per second, i.e. 0.1% of the time. I can’t measure this with the multimeter, because the power use jumps up every second, but the comatose period draws a mere 6.8 µA, which is consistent with what has been reported several times before (the watchdog is still active, and so is the brown-out detector).

Let’s find out how it’s performing. I’ve set up this little test circuit:

Well, it’s not really a test circuit at all – it’s in fact exactly what you need to use one of these things.

Putting 5V on the input (Vin), and leaving it a few minutes to settle, gives me a reading of 2.2 µA. Great, just what the specs say. It doesn’t really go up much with input voltage: 2.8 µA @ 12V. This is at no load.

With a 10 kΩ load, current draw rises to 338.1 µA, i.e. 330 µA for the resistor and about 8.1 µA for the regulator (assuming perfect calibration). That’s only 6 µA more, i.e. about 2% of the load.

Now let’s take the input voltage down, and see how this “low-drop” regulator behaves:

• 5.0 V -> 2.2 µA
• 4.0 V -> 2.2 µA
• 3.5 V -> 2.1 µA
• 3.3 V -> 2.1 µA
• 3.2 V -> 90.4 µA
• 3.1 V -> 84.1 µA
• 3.0 V -> 78.2 µA

Whoa… it sure doesn’t like being fed less voltage than it needs to supply a regulated output of 3.3V! The change is quite pronounced between 3.30 and 3.28V (I couldn’t get my power supply knob to adjust any more accurately).

For yesterday’s AA power board discussion that’s actually bad news, because it means that when the supply drops a mere 20 mV, it could cause the regulator to start wasting a fair amount of current (relatively speaking).

Let’s try something different: no power on Vin, but power on Vout instead.

This simulates connecting a battery to the +3V pin, and bypassing the MCP1702 voltage regulator altogether. Evidently, it’s not a good idea putting much more than 3.3V on there, since now we’re reverse feeding the regulator, something not all regulators are happy with:

• 3.40 V -> 1000 µA
• 3.35 V -> 500 µA
• 3.30 V -> 90 µA
• 3.25 V -> 90 µA
• 3.20 V -> 90 µA
• 3.10 V -> 84 µA

The conclusion seems to be: when using the AA Power Board in combination with a JeeNode, it might be better in certain cases to omit the regulator altogether if you’re aiming for minimal power consumption!

It’s not enough to short the regulator’s Vin and Vout, it really has to be taken out of the circuit. Fortunately, you don’t have to disconnect all three pins – just disconnect the ground pin (on the JeeNode v4..v6, that’s the one closest to the FTDI connector).

But if all you want to do is power the whole thing from some power source over 3.3V, such as a 3x AA battery pack or a LiPo battery, then all is fine… you’ll see that ultra-low 2.2 µA figure – as intended in this design.

Just beware of low voltages: weird things do happen!

Nifty stuff. Magic almost… if you take the water analogy, then it’s similar to pushing water up a mountain! Wikipedia has a schematic with the basic idea:

Think of the coil as a rubber band (I’ll use a gravitational force analogy here), then closing the switch is like stretching it from the current voltage to ground. Opening the switch is equivalent to letting it go again – causing the rubber band to contract, pulling the end back up and then exceding the original height (voltage) as it overshoots. The diode then sneakily gets hold of the rubber band at its highest point. The analogy works even better if you imagine a cup of water attached to the end. Well, you get the picture…

The trick is to repeat this over and over again, with a very efficient switch and a good rubber band, eh… I mean inductor. The way these boost regulators work, you’ll see that they constantly seek the proper voltage (feeding a storage pool at the end, in the form of a capacitor).

Enough talk. Let’s look at it with a scope:

What you’re seeing is not the output voltage, which is of course 3.3V, but the variation in output voltage, which is measured in millivolts. IOW, 45 times a second, the regulator is overshooting the desired output by about 20 mV, and then it falls back almost 20 mV under 3.3V, at which point the booster kicks in again.

Let’s load the circuit lightly with a 10 kΩ resistance, i.e. 330 µA current draw:

No fundamental change, but the horizontal axis is now greatly enlarged, because the discharge is more substantial, causing the boost frequency to go to 2.2 KHz.

With a 1 kΩ load, i.e. 3.3 mA current draw, you can see the boost working a bit harder to charge up, i.e. the slope towards ≈ 20 mV above 3.3V is more gradual:

Keep in mind that the difference is also due to yet more magnification on the horizontal time axis. The boost converter is cycling at 21.1 KHz now.

With a 330 Ω load, i.e. 10 mA current draw, the wavevorm starts getting a few high-frequency spikes:

The total regulation is still good, though, with about 25 mV peak-to-peak ripple.

Now let’s simulate what happens with the RFM12B transmitter on, using a 100 Ω load, i.e. 33 mA current:

Looks like the regulator needs more time to charge than to discharge, at this power level. Still the characteristic “hunting” towards the proper voltage level.

With a 68 Ω / 50 mA load, the regulator decides to use more force, losing a bit of its fine touch:

The scope’s frequency measurement was off here, it probably got confused by the high frequency components in the signal. Repetion rate appears to be ≈ 65 KHz. But now the total ripple has increased to about 70 mV.

That’s probably about as high as we’re going to need for a JeeNode with some low-power sensors attached. But hey, why stop here, right?

Here’s the output with a 47 Ω load, i.e. about 70 mA:

Whoa… that’s a ± 0.05 V swing, regulation is starting to suffer. I also just found out that the scope software has peak-to-peak measurement logic built in (and more). No need to estimate values from the divisions anymore.

Note that a 70 mA current at the end will translate to some 200 mA current draw on the battery – that’s the flip side of boost regulators: you only get higher voltage by drawing a hefty current from the input source as well.

Until this point, I used a standard 1.5V alkaline battery, but it’s not fresh and showing signs of exhaustion at these power levels (the output was a bit erratic).

To push even further, I switched to a fully charged Eneloop battery, which supplies 1.2 .. 1.3V and has a much lower internal resistance. This translates to being able to supply much larger currents (over 1 A) without the output voltage dropping too much. In this case, the change didn’t have much effect on the measurements, but I was worried that continued testing would soon deplete the alkaline battery and skew the results.

To put it all in perspective, here is the output with the same 47 Ω load, but showing actual DC voltage levels:

So you see, its still a fairly well regulated power supply at 70 mA, though not quite up to 3.3V, as it should be.

One last test, using a 33 Ω resistor, which at 3.3V means we’ll be pulling a serious 100 mA from this circuit:

Measuring these values with a multimeter gives me 3.16 V @ 89 mA, while the resitance reads as 32.7 Ω – there’s some inconsistency here, which might be caused by the high-frequency fluctations in the output, I’m not sure.

But all in all, the AA Power Board seems to be doing what it’s supposed to do, with sufficient oomph to drive the ATmega, the RFM12B in transmit mode, and a bit of extra circuitry. A bit jittery, but no sweat!

Update – With a 10 µF capacitor plus 10 kΩ load the limits don’t change much, just the discharge shape:

The same, at higher horizontal magnification:

Note that AC coupling distorts the vertical position, it’s still ± 18 mV ripple, even if the up peak appears higher.

The main change was to switch to a single global buffer for storing an outgoing Ethernet packet and for receiving the next packet from the controller. This removes the need to pass a buffer pointer to almost each of the many functions in the library.

Buffer space is scarce on an ATmega, so you have to be careful not to run out of memory, while still having a sufficiently large buffer to do meaningful things. The way it works now is that you have to allocate the global buffer in your main sketch:

This particular style was chosen because it allows the library to access the buffer easily, and more importantly: without requiring an intermediate pointer.

To make this work, you have to initialize the EtherCard library in the proper way. This is now done by calling the begin() function as part of your setup() code:

The ether variable is defined globally in the EtherCard.h header file. The begin() call also needs the MAC address to use for this unit. The simplest way to provide that is to define a static array at the top of the sketch with a suitable value (it has to be unique on your LAN):

Next, you can use DHCP to obtain an IP address and locate the gateway and DNS server:

The printIp() utility function can optionally be used to print some info on the Serial port.

If you are going to set up a server, then a fixed IP address might be preferable. There’s a new staticSetup() function you can use when not doing DHCP:

The gateway IP address is only needed if you’re going to access an IP address outside of your LAN, and the DNS IP addres is also optional (it’ll default to Google’s “8.8.8.8″ DNS server if you do a DNS lookup). To omit values, pass a null pointer or leave the arguments off altogether:

Just remember to call either dhcpSetup() or staticSetup() after the begin() call.

DNS lookups are also very simple:

The one thing to keep in mind here, is that the website argument needs to be a flash-based string, which must be defined as follows:

Note the “PROGMEM” modifier. See the Saving RAM space weblog post for more info about this technique.

This concludes the intialization part of the EtherCard library. Next, we need to keep things going by frequently polling for new incoming packets and responding to low-level ARP and ICMP requests. The easiest way to do so is to use the following template for loop():

The packetReceive() function polls for new incoming data and copies it into the global buffer. The return value is the size of this packet (or zero if there is none).

The packetLoop() function looks at the incoming data and takes care of low-level responses. The return value is the offset in the global packet buffer where incoming TCP data can be found (or zero if there is none).

As to what to do next: it really all depends on what you’re after. Check out the examples in the Ethercard library for how to build web servers and web clients on top of this functionality.

To get an idea of the code overhead of the EtherCard library: a simple web client using DHCP and DNS is around 10 Kb, while an even simpler one using static IP addresses (no DHCP and no DNS) is under 7 Kb. The fairly elaborate EtherNode sample sketch, which includes DHCP and the RF12 library is now ≈ 13 Kb.

IOW, lots of room for adding your own app logic!

Here’s a webClient.pde demo sketch which sets itself up via DHCP, then does a DNS lookup to find a server by name, then does a web request every 5 seconds and displays the first part of the result:

Sample output:

The total sketch is under 10 Kb, so there’s still lots of room to add the RF12 wireless driver, as well as a fair amount of application logic.

Who says a little 8-bit processor can’t be part of today’s internet revolution, eh?

On the bottom, a DC jack getting 12V power, on the right a cable with a DC plug powering an external USB disk.

The little board in the middle is sort of a breakout board for two SMD chips: a dual P-MOSFET and a low-drop -3.3V linear voltage regulator to power the JeeNode. The rest is boilerplate stuff, i.e. the JeeNode Experimenter’s Pack, a couple of resistors, and some electrolytic caps.

I’ve only tested it with a load of about 1A, but it should work up to 3A without any problem. What’s also nice is that as a high-side switch, it doesn’t really care what voltage is being used as power supply – anything between 3.5V and 16V should work just fine. That means this can also be used for 5V devices and even with devices powered off 1..4 LiPo-batteries. This simply fits between a DC power plug and its device – convenient!

The current consumption is 21 mA with the ATmega and receiver permanently on. Could easily be lowered a few mA by putting the ATmega in “idle” mode.

The current sensing capabilities are definitely working, but the resistance of the P-MOSFET is not quite 0.1 Ω: with a 390 mA current, I see about 90 mV across the MOSFET, indicating that its internal resistance when driven from a 3.3V JeeNode is more like 0.23 Ω. That’s on the high side (pardon the pun), because this would mean a 1A load will get about 0.23V less out of the power supply than it would with a direct connection – and 0.7V less when drawing 3A. Oh well, it’ll be ok for most devices, cheap power bricks don’t always supply exactly 12V anyway.

The question of course is how consistent this MOSFET resistance is. I suspect that there will be quite a bit of variation across different units. But that’s not necessarily a problem: we don’t really care about absolute currents, we just need to see how the device’s current consumption is relative to full power and idle modes, basically. And we can always calibrate the value with a multimeter or power resistor.

The other weak spot in all this is that the voltage levels measured with this setup are very low, and only cover a few percent of the ADC range. It would be nice to have a bit more resolution there.

Ok, let’s throw an op-amp into the mix…