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):

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:MicroSDBistable 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 :-)

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.

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.

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).

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?

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...)

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.

Quote

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.

Quote

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.

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).

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!

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.)

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).

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 :-)

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 IICould you please give hints or point me toward a tutorial ?TIAJRS

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.