Mosquino rev2, micropower / energy harvesting Arduino variant - feedback wanted!

[system]

Hi all,
This is an updated design of the Mosquino board, first announced on the old forums. There is some more background on the project and its rationale here.

If anyone has interest in a very low-power Arduino-compatible for battery powered datalogging, solar / thermal / other environmentally powered projects and networks (or like to point out others' mistakes ;-), please have a look at the schematic attached and let me know what you think!

This version has not been built or even laid out yet, but the physical pin placement hasn't changed from the first version. It fixes several things / bugs that annoyed me about the first draft though.

(FIXED) Onboard power supply will allow input voltages up to 14V; no more Zener diode leakage at reasonable voltages.
(FIXED) Eliminated FET voltage drop when using the onboard regulator at lower voltages (3.3 - 4V).
(FIXED) INT1/INT2 signals now correctly routed to shield bus headers.
(NEW) POWER_GOOD signal now provided by onboard supply.
(NEW) POWER_FULL signal added to external power shield; used for alerting the application that excess / waste power is available. POWER_GOOD / POWER_FULL now in a wired-OR configuration and can be overridden by the external power shield.

Here is a quick overview of what's going on in the circuit (follow along with the schematic attached, clockwise from left):

USB / Power Entry: Direct wire (spring loaded) terminals for attaching arbitrary power sources such as solar cells, piezos, Peltier devices or battery packs. Mini-USB port for power and computer I/O / programming.

Power Shield Header: Allows connection of a small shield-like power module for specific 'unusual' power sources. The shield receives the user-supplied power and returns regulated (direct to CPU) or unregulated power (uses board's onboard regulator). The shield can optionally supply POWER_GOOD and POWER_FULL signals for intelligent power management. Power shields can be stacked if supported (e.g. power conversion + battery module). Current power shields include piezoelectric / buck regulator and thermoelectric booster that operates on as little as 2degC thermal difference.

Power supply: Combines power supplied by regulated/unregulated sources and USB; isolates sources to prevent backdriving any source. Input on VUNREG is regulated to 3.3V by a low-leakage, low dropout regulator (2-3uA typ.). Input on VREGIN is passed directly through and should achieve minimum sleep currents well under 1uA.

Load Disconnect (VUNREG only): Completely disconnects power from the circuit until voltage has risen within the ATmega's legal operating range + some hysteresis (to prevent chattering). This prevents low-current or slowly-rising power sources from never getting "over the hump". Provides early warning via the POWER_GOOD signal before disconnect.

USB-Serial: Same FT232 chip that provides USB connectivity on the Duemilanove, but only powered when USB cable plugged in.

Realtime Clock: Arguably the most important part for low-power projects! <1uA part allows event scheduling and waking the CPU via INT2 pin, so the user can avoid long software delay loops.

Shield GPIO / Common I/O: Much like the Sanguino it's based on, this board diverges from the stock Arduino pinout. Rationale: 1) Very few existing shields are designed with serious low-power operation in mind, so using them with this board would fairly defeat the purpose; 2) This board's users probably have more unique needs than a stock Arduino, so emphasis is on perfboard-friendly for custom stuff 3) you probably want to do more than 1 thing at a time. (e.g. sensor AND logging AND transmit) to form a useful system. The headers are split into 3 sets of 8 GPIO + a common set of power and bus signals (SPI, I2C, INTx), so up to 3 standardized mini-shields can coexist without stacking.

Tested + working shields so far:
MicroSD
Bistable graphics display

Next:
Low power TDMA wireless (ANT AP2)

Please let me know your thoughts / suggestions and any mistakes that jump out at you, before I make the boards

mosquino.pdf (98.2 KB)

[48X24X48X]

Tim,
Love your work on Mosquino. You should release it for sale!

[system]

Hopefully this one will be release-ready I don't have plans to hand-make hundreds of them in my basement or anything (been there, done that, it sucks), but I wouldn't mind running it by adafruit or sparkfun (or the arduino team to see if any of them are interested in producing them in volume.

'Til then, it'll be on my google code respository soon - the dorkbotPDX batch PCB service is a pretty good deal for small volumes! The bistable displays might be hard to get, but pretty much everything else can be click-and-buy ordered online.

[48X24X48X]

I use dorkbot too for prototype but not for small volume, purple color issue maybe.

[system]

That must be a new development! The boards I got for v1 were a very nice blue.

Did a bit of testing the other night on a low-power boost converter, using an old solar walk light (solar cell + AA-size NiCd battery). Looks like these things could make a very nice unattended ground sensor / networking platform on the cheap. The solar cells are pretty low voltage and only put out a few volts peak (full sun) into the 1.5v battery, much less in indirect sun conditions, but the L6920-based booster starts up around 0.6v typical. So far the booster runs overnight (no load, 3.3v out) on a small supercapacitor at 1V or so. A more scientific test is ongoing - by tomorrow I should have an estimate of how much actual power was used - but it's shaping up to be a good use for old NiCd/NiMH solar lights that no longer hold enough charge for their original purpose.

[48X24X48X]

You are going to make the power pack separate from the main board right?

While I was working on WSN back then, we usually have this configuration: Buck > Battery Charger > Buck-Boost.
The buck section was meant for the solar panel or some external 12 V SLA battery. The battery charger is for the Li-Ion and the buck-boost to maintain 3.3V. Obviously using this configuration provides more juice of current but the quiescent current is not amazing like sub 10 uA. It was something around 50-100 uA. I haven't really tried on those very low voltage energy harvesting stuff and definitely would like to see the outcome from your side!

I think low power design is challenging from the hardware point of view. But what is lacking is probably a more organized light weight Arduino compatible library without exposing too much of AVR bare metal style of controlling the power (what power state, how long to stay low power, wake up source, what to shutdown, what to stay power on).

[system]

48X24X48X:
You are going to make the power pack separate from the main board right?

Yeah, everything apart from a basic LDO/UVLO is on a small interchangeable daughterboard.

48X24X48X:
While I was working on WSN back then, we usually have this configuration: Buck > Battery Charger > Buck-Boost.
The buck section was meant for the solar panel or some external 12 V SLA battery. The battery charger is for the Li-Ion and the buck-boost to maintain 3.3V. Obviously using this configuration provides more juice of current but the quiescent current is not amazing like sub 10 uA. It was something around 50-100 uA. I haven't really tried on those very low voltage energy harvesting stuff and definitely would like to see the outcome from your side!

Sounds very interesting; I'm very curious to know about your WSN projects. It's something I want to experiment with in this project...when I get time But why would your networks have both a SLA and Li-Ion batteries? or is the 12V battery more of a charging station that is not consistently present?

48X24X48X:
I think low power design is challenging from the hardware point of view. But what is lacking is probably a more organized light weight Arduino compatible library without exposing too much of AVR bare metal style of controlling the power (what power state, how long to stay low power, wake up source, what to shutdown, what to stay power on).

Yeah, that will still be the hard part... especially for me as a relative c++/Arduino noob (still digging out of this PIC assembler hole). Help/advice in this area too is appreciated Hard to say where the right balance between performance and usability will be struck - something as simple as providing wrappers for some peripheral functions that will set up the PRR correctly before use, keep track of the current clock divider setting (switch back for timing-critical functions, e.g. Serial.print...) and encourage the user to use the RTC instead of delay loops would probably go a long way for the time being. I have a feeling those who are already familiar with more advanced power managed modes know what they're in for (and probably don't think of Arduino as their first platform choice for such applications...)

[48X24X48X]

Yeah, everything apart from a basic LDO/UVLO is on a small interchangeable daughterboard.

That's the way to go! We used to have everything in a single board (ala Micaz and TMotesky era) and they give you less flexibility and sometimes you won't even know were the leaking uA goes to.

Sounds very interesting; I'm very curious to know about your WSN projects. It's something I want to experiment with in this project...when I get time But why would your networks have both a SLA and Li-Ion batteries? or is the 12V battery more of a charging station that is not consistently present?

I was working with mostly geo-technical and structural health monitoring sensors. And a lot of these sensors are powered up using 12V still. And in the network, when we were forced to use a router, the SLA usually comes into the picture together with a solar panel.

Yeah, that will still be the hard part... especially for me as a relative c++/Arduino noob (still digging out of this PIC assembler hole). Help/advice in this area too is appreciated Hard to say where the right balance between performance and usability will be struck - something as simple as providing wrappers for some peripheral functions that will set up the PRR correctly before use, keep track of the current clock divider setting (switch back for timing-critical functions, e.g. Serial.print...) and encourage the user to use the RTC instead of delay loops would probably go a long way for the time being. I have a feeling those who are already familiar with more advanced power managed modes know what they're in for (and probably don't think of Arduino as their first platform choice for such applications...)

There are also certain things that the Arduino core powers them up and uses which needs careful attention too.

[system]

Hi all,
Mosquino now has a Google Code repository. Boards for the rev2 (incl. some power and I/O shields) are finished and going onto a batch order tomorrow

I'll wrap these up into official 'downloads' once I build one and see that it works, but until then you can download the files using a Mercurial client or the Source tab. EAGLE files and gerbers are in the 'hardware' repository (click the 'Repository' dropdown list).

Newly added: 0.6V micropower boost converter power shield and LiPol battery stackable power shield.

I'll give another update when these boards arrive!

[system]

@Drmn4ea .....

Great job!

I'm waiting for your first results!

Would connect the FT232R VCCIO to CPU VCC!

This ensures correct USB Operation, if the board is supplied with VREG <> 3.3V or will be used with MCP1703 with Voltages between 1.8 and 5.0 VDC . All other devices will operate conforming their specs inside this range. Only the FT232R does NOT!

Greetz

[system]

@skywalk

Plugging in USB to this board will always supply 5V (regulated to 3.3V) and bypass all other power supplies/shields, so I don't see it as much of a problem for the standard configuration. I can see your point if you want to replace the onboard 3.3V LDO with another voltage. But then my concern is that the FT232 will be sinking current from VCC continuously when the CPU is powered.

For this version an arbitrary regulated voltage (1.8 ~ 5V) can still be supplied through the power shield interface safely - in this case the board will switch over to 3.3 when the USB connection is active. (And VCC can be safely driven with 5V externally for e.g. bootloader programming with the power shield removed.)

[system]

It's aliiiive!

My freetime has been thoroughly zapped lately, but I finally managed to get the first one built and bootloaded. So far only 'hello world' and a sleep test have been run on it, but everything seems to be working so far Tomorrow (err...today) I should be able to take it into lab (where the GOOD multimeters are) to verify PGOOD/PFULL/UVLO functions and sleep current consumption.

See attachments for pics of the finished board / bootstrapping from a Duemilanove (you probably need to be logged in to see attachments).

[system]

Hi all,
There is now an official first release of the Mosquino mainboard, software and several support boards (available at the Google Code project's downloads section). The hardware under downloads is tested and to the best of my knowledge fully functional, although not all of the software core features (e.g. PWM) have been formally tested yet.

Sleep current consumption is about 2uA from a regulated (3.3V) supply, and approx. 6uA from an unregulated one. There are ways to reduce these further, but that should be good enough for most normal users Peak undervoltage current is about 80uA for unregulated supply and 0.3mA for regulated. These will be reduced in future versions, but again, I don't see them being a big problem for most users.

All my electronics / Arduino stuff is packed in boxes for the next couple weeks due to home remodeling, but after that, more test results, shields and software to come... soonish

[system]

Hi,
Thanks for your wonderfull design.
I guess i successfuly managed to assemble a board, but I can't burn the Arduijo boot loader on a fresh MC. I have AVRISP Mark II
Could you please give hints or point me toward a tutorial ?
TIA
JRS

[system]

You built the current Mosquino version? Cool!

Did you run into any trouble with assembly? I tried to keep it as easily hand-solderable as possible (no parts smaller than 0805 / SOIC, with the exception of that USB chip there's just no good way around at the hobbyist level) but I'm wondering if there's anything else I can do to make it easier.

I'm not familiar with AVRISP - so far I've only burned bootloaders on using another Arduino via the 'ArduinoISP' sketch, and it's been mostly smooth sailing. What is the message that you get?

Some things to check:

Is the power switch on? (Silly, but I have to ask - I've tried to program it while powered off myself)

Does the crystal attached to the ATMega start up? (This may be hard to check without a scope - but they ship with the internal oscillator selected, so it shouldn't matter unless this chip has been successfully programmed at least once, and set to use the external crystal)

Is the RESET line (if any) from the programmer connected? On older versions of the mainboard, there wasn't a spot to connect it, so you'd have to e.g. touch it against a pin on the ATmega. In newer versions there is a RESET pin header near the reset switch.

Hope this helps!

[system]

Tim,

Thanks once again for your excellent work on this.

I've made the board but not attempted bootloading or anything yet. I thought I'd share the biggest problem I've had with assembly and that is the xtal oscillator X2 for the DS1337 real time clock. It seems that either the pad dimensions are too small, or due to the fact that the pins are under the component and not on the sides, that it's almost impossible to reach for soldering, as it just fits directly over the pads. So, I'm not 100% sure it's connected on both sides.

Connecting an oscilloscope probe across the xtal would probably damage it due to the probe capacitence, so I guess the only way to find out would be to get everything loaded and try to run a program that utilises the DS1337.

[system]

You're right, that part is tricky to solder. This is good feedback - I don't always notice because I've been doing it for so long

Probing the crystal shouldn't damage anything, but depending on the probe capacitance it may stop oscillating as soon as the probe is applied, so seeing a 'flatline' would not necessarily mean it was dead (if working, it would come back when power-cycled or maybe just left alone for a bit). I've been able to probe this and see it running (YMMV), but I've also seen probing stop similar watch-crystal circuits.

What I find helpful to solder parts like this is to place it off the pads slightly (e.g. toward the DS1337 or toward R16) so that there is enough pad peeking out to get the iron tip onto. More specifically, I place a bit of solder on ONE pad, heat it with the iron top and while it is liquid, slide the part into place ("mostly" or halfway onto the pads, if the iron tip isn't very small). This guarantees at least one side is soldered, then, solder added to the 2nd pad should flow underneath the part and produce a solid connection there too.

[system]

Tim,
Good soldering tip. Aside from that I've got another problem with uploading a sketch:

I've bootloaded the new ATMEGA644 using an Arduino Duemilanove w/ ATmega328, I think successfully (???) since I got a "Done burning bootloader" message, but when I try to upload the standard Blink example on the Mosquino board I get the error:

avrdude: stk500_getsync(): not in sync: resp=0x00

Windows recognises the board ok and assigns a new COM port. The RX led flashed a few times when uploading. I've selected the Mosquino 1.0 board in the IDE and the right serial port, so I don't know whether it's a boodloader problem, bad serial connection or what. I've tried 2 USB cables and get the same error.

[system]

I think I've discovered the reason for the error

avrdude: stk500_getsync(): not in sync: resp=0x00

It's a power supply problem: The voltage supply Vcc to the ATmega is only 1.465V (needs to be 1.8-5.5 to power the chip). I guess something is either fried or bad placement. May have to scrap it and start again...

[system]

Hopefully it isn't necessary to scrap the board... with the schematic open you can probably trace power from the USB port down to Vcc and narrow down the source of the problem. E.g. is there ~5V on both the upstream and downstream side of fuse F1? (It will have high resistance if tripped, causing the downstream voltage to sag.) Does it change when the power switch is turned on/off? (suggesting the issue is downstream of the power switch, on Vcc)

(Note the FT232 and Tx/Rx LEDs are powered directly from VUSB, so they will still blink if the power switch is off - this has gotten me before!)