Calunium: version 2

Calunium version 2. Click on the image for an annotated version.

Features

• ATmega1284P microcontroller with 128 KBytes flash memory, 16 KBytes SRAM and 4 KBytes EEPROM, SPI and I2C buses and 2 UARTS.
• Shield-compatible with Arduino Uno revision 3, with extra I/O laid out to be compatible with Arduino Mega pins. Pin mapping is chosen for maximum compatibility with Uno.
• Jumper-selectable 3.3 V or 5 V operation; selected voltage is available at the IOREF pin to enable shields to operate at the correct voltage.
• I2C (SDA/SCL) mapped to dedicated SDA/SCL pins and the standard location used by the Arduino Mega but jumpers can be used to replace A4/A5 with SDA/SCL signals for compatibility with older Arduino shields.
• Second UART (D1, D2) signals also mapped to corresponding location on Arduino Mega (TX1, RX1).
• ISP header in standard location, allowing the Arduino ethernet/SD shield to be used.
• D13 LED connected via FET to avoid loading D13.
• Real-time clock (e.g, DS1307, DS1338, MCP7941x). Output square wave can be routed to D6 (INT2) or D15 (TOSC1, for input to timer/counter 2). Battery backup from CR2032 battery.
• Micro-SD socket for additional data storage. Uses SPI bus (D11, D12, D13), chip select is D22. If card is fitted then 3.3 V operation is required.
• Hope RFM12B radio module for communication. Uses SPI bus (D11, D12, D13), chip select is D14 and interrupt request is D6 (INT2, can be disconnected by removing a jumper). Requires 3.3 V operation; Calunium can be powered from 5 V provided that the RFM12B is not used.
• Power from USB or FTDI connector.
• Switches, connectors and USB socket located outside of the standard Arduino shield footprint so they do not interfere with shields and are accessible when shields are fitted.
• Auxiliary power connector; connect your own voltage regulator or boost converter. 5 V from USB (FTDI and/or USB connector) and 3 V from RTC battery also available on the connector. For easy prototyping add your own power adaptor.
• Auto-reset can be disabled by removing jumper.
• Pads to fit LM61 temperature sensor.
• Usable PCB-mounting holes.
• JTAG header for debugging/programming.

Bootloader

Either the Optiboot or xboot bootloaders can be used. My preference is for xboot as explained in a previous blog post.

About the name

As Arduino is an Italian project, this project takes its name from the Roman name for Lancaster, Calunium, where the design of this clone originates.

Open source

Hardware

The Eagle PCB design files for Calunium are available on Github and are licensed under the Creative Commons Attribution-ShareAlike 3.0 Unported License.

Software
Files to allow Calunium to be used with the Arduino 1.0 IDE are available on  Github and are licensed under the Gnu General Public License v2.

Peripherals pin mapping

Peripheral	Pin	Function
LED	13
Temperature sensor	A6 A7	Power Output
Real-time clock*	D6/D15	Square-wave output/alarm
microSD card	22	Card select
RFM12B radio module	6 14	Interrupt request Select

* Also uses I2C bus (20, 21).

** Also uses SPI bus (11, 12, 13).

Microcontroller pin mapping

Pin	Arduino Uno (Atmega328P)	Calunium (Atmega1284P)	Arduino Mega2560 (ATmega2560)
D0	PD0 (PCINT16/RXD)	PD0 (PCINT24/RXD0/T3)	PE0 (RXD0/PCINT8)
D1	PD1 (PCINT17/TXD)	PD1 (PCINT25/TXD0)	PE1 (TXD0)
D2	PD2 (PCINT18/INT0)	PD2 (PCINT26/RXD1/INT0)	PE4 (OC3B/INT4)
D3	PD3 (PCINT19/OC2B/INT1)	PD3 (PCINT27/TXD1/INT1)	PE5 (OC3C/INT5)
D4	PD4 (PCINT20/XCK/T0)	PB0 (PCINT8/XCK0/T0)	PG5 (OC0B)
D5	PD5 (PCINT21/OC0B/T1)	PB1 (PCINT9/CLKO/T1)	PE3 (OC3A)
D6	PD6 (PCINT22/OC0A/AIN0)	PB2 (PCINT10/INT2/AIN0)	PH3 (OC4A)
D7	PD7 (PCINT23/AIN1)	PB3 (PCINT11/OC0A/AIN1)	PH4 (OC4B)
D8	PB0 (PCINT0/CLKO/ICP1)	PD6 (PCINT30/OC2B/ICP)	PH5 (OC4C)
D9	PB1 (OC1A/PCINT1)	PD5 (PCINT29/OC1A)	PH6 (OC2B)
D10	PB2 (SS/OC1B/PCINT2)	PB4 (PCINT12/OC0B/SS)	PB4 (OC2A/PCINT4)
D11	PB3 (MOSI/OC2A/PCINT3)	PB5 (PCINT13/ICP3/MOSI)	PB5 (OC1A/PCINT5)
D12	PB4 (MISO/PCINT4)	PB6 (PCINT14/OC3A/MISO)	PB6 (OC1B/PCINT6)
D13	PB5 (SCK/PCINT5)	PB7 (PCINT15/OC3B/SCK)	PB7 (OC0A/PCINT7)
D14	-	PC7 (TOSC2/PCINT23)	PJ1 (TXD3/PCINT10)
D15	-	PC6 (TOSC1/PCINT22)	PJ0 (RXD3/PCINT9)
D16	-	PC5 (TDI/PCINT21)	PH1 (TXD2)
D17	-	PC4 (TDO/PCINT20)	PH0 (RXD2)
D18	-	PC3 (TMS/PCINT19)	PD3 (TXD1/INT3)
D19	-	PC2 (TCK/PCINT18)	PD2 (RXD1/INT2)
D20	-	PC1 (SDA/PCINT17)	PD1 (SDA/INT1)
D21	-	PC0 (SCL/PCINT16)	PD0 (SCL/INT0)
D22	-	PD4 (PCINT28/XCK1/OC1B)
D23	-	PD7 (OC2A/PCINT31)
A0	PC0 (ADC0/PCINT8)	PA7 (ADC1/PCINT7)	PF0 (ADC0)
A1	PC1 (ADC1/PCINT9)	PA6 (ADC0/PCINT6)	PF1 (ADC1)
A2	PC2 (ADC2/PCINT10)	PA5 (ADC2/PCINT5)	PF2 (ADC2)
A3	PC3 (ADC3/PCINT11)	PA4 (ADC3/PCINT4)	PF3 (ADC3)
A4	PC4 (ADC4/PCINT12)	PA3 (ADC4/PCINT3)	PF4 (ADC4/TCK)
A5	PC5 (ADC5/PCINT13)	PA2 (ADC5/PCINT2)	PF5 (ADC5/TMS)
A6	PC6 (ADC6/PCINT14)	PA1 (ADC6/PCINT1)	PF6 (ADC6/TDO)
A7	PC7 (ADC7/PCINT15)	PA0 (ADC7/PCINT0)	PF7 (ADC7/TDI)

Bill of materials

A bill of materials for Calunium v2 is available from Google docs.

Changes from Calunium v1

Summary of changes from Calunium v1.

Arduino 1.0 headers included

The revised Arduino headers have been included. This adds dedicated I2C connections and an IOREF pin whose purpose is to indicate the I/O voltage level.

Jumper-selectable 3.3 V or 5 V operation

The microcontroller supply voltage is easily selected by a single jumper setting.

Improved reset circuit

A reversed-biased diode has been added in parallel with the reset pull-up resistor to prevent overshoot of the reset signal which can cause erroneous behaviour.

Option to use surface-mount real-time clock

I've not been able to find a suitable alternative to the DS1307 which can operate at 3.3 V and which is available in a dual inline package. The alternatives are only available in SOIC8 or smaller packages. To support 3.3 V operation a combined DIP/SOIC8 footprint has been used.

Ceramic resonator option instead of crystal

The crystal footprint has been revised to allow a 3-pin ceramic oscillator to be fitted as an alternative to a crystal. Omit the 22 pF loading capacitors when using a ceramic oscillator.

Improved analogue power supply circuitry

Analogue power supply follows the advice given in the data sheet.

Temperature sensor now powered from logic output

The optional LM61 (or similar) temperature sensor is now powered from D7. This change has been made for low power operation; I had been fitting an LM61 to other shields instead of using one on Calunium so that it can be powered off when not needed.

V-USB removed

I've had no success with the V-USB interface so the necessary circuitry has been removed. If you have had any success please let me know how to make it work! The USB connector remains as a convenient 5 V power connector.

RFM12B shield for Raspberry Pi: Preliminary design

Raspberry Pi interface to the RFM12B radio module, with integrated ISP programmer. The cut-out is to enable the PCB to fit inside the Multicomp Raspberry Pi case.

Current status

Earlier in the year I posted a design for a wireless gateway for the Raspberry Pi. It featured interfaces for the Hope RFM12 and XBee (or Ciseco XRF) radio modules. Also included was an in-circuit serial programming (ISP) programming interface for Atmel microcontrollers. I later refined the ISP interface to include some protection for the Raspberry Pi by adding a buffer and FET switch. I have not yet tried accessing the RFM12B directly from the Pi but other people have had problems, mainly it seems because of the time-critical interrupt handling. I'm sure this problem will eventually be solved once the Eve Alpha boards become widely available. Martin Harizanov solved this problem by adding an Atmel ATtiny microcontroller to bridge between the UART interface on the Pi and the SPI interface on the RFM12B. I bought a bare PCB that did this from the Open Energy Monitor shop. I tested the RFM12Pi Raspberry Pi Expansion board communicating with one of my Calunium v2 development boards, everything worked. Martin chose the ATtiny84 microcontroller which has just 512 bytes of RAM. I would like to have a solution which more closely mimics the Ciseco XRF module that I am currently using, which has a 240 byte buffer. One reason for needing a larger buffer is that the radio protocol I am using supports over the air firmware updates, with the new firmware sent in 128 byte blocks. If I am to implement something with 240 byte transmit and receive buffers I will need a microcontroller with more than 512 bytes of RAM.

Preliminary design

Based on my previous work and inspired by Martin Harizanov's implementation I have designed a RFM12B shield for the Raspberry Pi with integrated ISP interface. The microcontroller on this board is the popular ATmega328P, as used in the Arduino. Including the ISP interface has considerably increased the size of the PCB but this is a price I am willing to pay. The board is intended to be used as part of the AuroraWatchNet magnetometer network and the ability to remotely update the firmware will be very useful, especially since I can already perform over-the-air firmware upgrades on the battery-powered Calunium node. Surface-mount passive components could be used to reduce the PCB size but this would be contrary to my goal of making the AuroraWatchNet magnetometers easy to build for novice constructors.

The 74LVC244 buffer has two 4-bit line drivers, allowing two independent ISP interfaces to be included. The first is for the on-board ATmega328P microcontroller, the second is wired to a standard Atmel ISP header to allow an external microcontroller to be programmed. It means that the ATmega1284P used in the remote Calunium of the AuroraWatchNet magnetometers can be programmed initially, or recovered in the case of an over-the-air firmware upgrade mistake.

I hope to have some circuit boards made in January 2013 so if you spot any mistakes please let me know as soon as possible!

Open source

The Eagle PCB design files for the RFM12B/ISP shield for Raspberry Pi are available on Github and are licensed under the Creative Commons Attribution-ShareAlike 3.0 Unported License.

Using Xboot with Calunium

Xboot is a bootloader for Atmel ATmega and Xmega microcontrollers and can be used as an alternative to the popular Optiboot. It's not quite as small as optiboot (4KB compared to 2KB) but it does offer one very useful advantage - it has an API which enables flash reprogramming by the application. Compiling the bootloader is mostly straightforward, follow the instructions included with Xboot. There are two additional points to watch. Make sure you copy the desired configuration file from the conf directory to the xboot directory. You may need to set the shell to bash when invoking make; I did this with the following command:

make SHELL=bash calunium_12MHz.conf.mk

The original source is available from Github, my fork contains configuration files for Calunium.

Using xboot with avrdude is easy, just be sure to select the avr109 bootloader protocol. You can also program from the Arduino IDE. You will need an entry in boards.txt like:

cal1284p_xboot_12.name=Calunium 1284P (PCB, 12MHz, XBoot, 115200 baud)
cal1284p_xboot_12.upload.protocol=avr109
cal1284p_xboot_12.upload.maximum_size=126976
cal1284p_xboot_12.upload.speed=115200
cal1284p_xboot_12.bootloader.low_fuses=0xFF
cal1284p_xboot_12.bootloader.high_fuses=0x92
cal1284p_xboot_12.bootloader.extended_fuses=0xFF
cal1284p_xboot_12.bootloader.path=xboot
cal1284p_xboot_12.bootloader.file=calunium_12MHz.hex
cal1284p_xboot_12.bootloader.unlock_bits=0x3F
cal1284p_xboot_12.bootloader.lock_bits=0x0F
cal1284p_xboot_12.build.mcu=atmega1284p
cal1284p_xboot_12.build.f_cpu=12000000L
cal1284p_xboot_12.build.core=arduino
cal1284p_xboot_12.build.variant=pcb

Application firmware updates

A security feature of the Atmel ATmega and Xmega processors is that an application cannot modify the flash program memory, only code executing from within the bootloader program space is permitted to do so. By compiling xboot with ENABLE_API set to yes the bootloader will export functions which can write to a temporary storage area located in the upper half of the user firmware area. The application can then call these bootloader functions to write a new firmware image to this temporary area of flash memory. On reboot xboot will copy the temporary firmware image to its correct location and then execute it. The process includes a cyclic redundancy check to prevent against writing corrupted firmware images. This approach is robust since flash reprogramming does not occur until the MCU has downloaded all of the new firmware. The disadvantage is that only half of the application space is available for the actual application; with the ATmega1284P this may not be a major problem.

I'm using the firmware update API to allow over-the-air updates to my AuroraWatchNet magnetometer and it works perfectly. The new firmware is copied in blocks of 128 bytes inside a message which has been signed with a HMAC-MD5 authentication code. After each second block has been received the 256 bytes are copied to one page in the temporary flash area. I'll probably add an option to perform firmware updates from the microSD card which is included on Calunium v2.

The only important points to note are that the CRC passed to xboot must be the one computed from the firmware image sent (not the one received!), and that xboot calculates the CRC over the entire temporary area. If the new image is smaller than the temporary area you'll need to erase the temporary area before copying so that the remaining space is in a known state. Unprogrammed bytes will be 0xFF. Be sure to calculate the CRC including the effect of these unprogrammed bytes otherwise the CRC xboot calculates will not match and it won't copy the firmware.

Bootloader of choice

I'm really pleased with how well xboot seems to work and I like how easy it is to add new configurations. I've just started using it with the internal RC oscillator running uncalibrated; I had to reduced the baud rate to 38400 where the frequency error is much less (see datasheet). Based on my experience so far this is definitely my recommended bootloader for the ATmega1284P.

AVR/Arduino ISP programmer using the Raspberry Pi GPIOs

ISP programming of Calunium Arduino clone using Raspberry Pi GPIO. Click on the image for an annotated version.

Introduction

As a fully-featured Linux computer there are many external programmers that can be used with your Raspberry Pi to program the Atmel AVR range of microprocessors. It's also possible to use the general purpose input/output lines (GPIOs) found on the Raspberry Pi to implement an ISP programmer with minimal extra hardware. I say "with minimal extra hardware" because although it can be done with no extra hardware I recommend adding a buffer and FET to protect the Raspberry Pi. You might reasonably wonder what is the point if extra hardware should be used since external USB programmers can be bought cheaply from Ebay. However, if you are going to add an extension PCB to your Raspberry Pi anyway, for instance to communicate with a remote Atmel processor, then including an ISP programmer makes sense and adds very little cost.

AVR ISP programming interface

Most of the Atmel AVR range can be programmed using an ISP interface which resembles the SPI bus. For this description I'll assume that the SPI pins are reused for this purpose but you should check the datasheet to make sure this is true for your part. The RESET pin is used as the active-low chip select pin, SCK is the clock signal, MOSI is the input data pin and MISO is the output data pin. If the directions seem odd remember that the microcontroller is acting as a SPI slave in this scenario; with that in mind the names make perfect sense. The ISP programmer then communicates with the microcontroller, sending commands to read or write flash memory, EEPROM, fuses, and/or locks. Avrdude supports many different programmers which can be used for this task.

Raspberry Pi ISP programmer hardware

The simplest interface on the Raspberry Pi is to use four GPIO pins and bit-bang the SPI commands. I don't recommend this however. After programming has finished the SPI interface on the microcontroller could revert to master mode where SCK and MOSI become outputs. Connecting two logic outputs together which could be at opposite logic levels is not wise. For a safer interface I used the circuit below.

Schematic diagram of ISP programmer. Also available as full-size image, Eagle schematic or PDF.

On the target microcontroller the RESET signal is typically connected to a 10 kΩ pull-up resistor, often with a reset switch pulling to ground. The 2N7000 FET provides an open-drain interface which safely connects the Pi to RESET, even if the reset switch is pressed whilst the programmer is connected. Compare this to the case of directly wiring a Raspberry Pi GPIO; pressing the reset switch could short a high-level output directly to ground. Ouch. The 100 kΩ pull-down resistor connected to the gate of the FET ensures it is normally off (and thus RESET is high) when the reset GPIO pin is an input, such as after programming. The 100 kΩ resistor connected to RESET acts as a weak pull-up in case no pull-up resistor is connected to the microcontroller (e.g., for easy programming on a solderless breadboard). In the circuit above a jumper can be fitted to power the target microcontroller from the 3.3 V supply on the Raspberry Pi (care, maximum current 50 mA).

To protect the remaining Raspberry Pi GPIOs I have used a 74LVC244 buffer. The active-low OE (output enable) allows the outputs to be disconnected when the microcontroller is not held in its reset state. I chose this part because it operates at 3.3 V but safely tolerates 5 V on its inputs, and also 5 V applied to the outputs when they are in the high-impedance state.

The open-drain FET inverts the state of its input. In theory it should be possible to configure avrdude to account for this but I could not make it work with the patched GPIO support so I used a spare gate in the 74LVC244 to form a logic inverter. The circuit described above should be safe to use even if the target system operates at 5V (but don't fit the shunt to the jumper). I've not tested it, so make your own judgement! You should also note what whilst it should be safe, it isn't guaranteed to be reliable; typically the high output level from the 74LVC244 buffer will be recognised as a high but it doesn't meet the worst-case specifications.

GPIO pin mapping

Signal	GPIO	P1 header pin number
RESET	8	P1-24
SCK	11	P1-23
MOSI	10	P1-19
MISO	9	P1-21

Although the SPI has been implemented by bit-banging the pins chosen are the SPI pins on the Raspberry Pi P1 header.

Credits

Gordon Henderson for providing the patched avrdude compiled for the Raspberry Pi, see http://project-downloads.drogon.net/files/.

Radoslav Kolev who submitted the patch to add linux GPIO to avrdude.

Update

This design has been incorporated into my RFM12B shield for Raspberry Pi which contains a two-channel AVR ISP programmer. One channel is used to flash both the on-board ATmega328P, the other channel can be used to program external devices.

I've added a description of how to install and use the patched version of avrdude, http://blog.stevemarple.co.uk/2013/03/how-to-use-gpio-version-of-avrdude-on.html.

Wireless Gateway for Raspberry Pi

Wireless gateway for Raspberry Pi. Click on the image for an annotated version.

Introduction

A wireless gateway for the Raspberry Pi is presented. The gateway will connect remote clients to the Raspberry Pi and the internet. I plan to use these to connect a network of magnetometer sensors to improve the reliability and availability of the AuroraWatch UK network. The gateway can also be used to program Atmel AVR microcontrollers, as used in the magnetometer sensors.

Design Goals

• Footprint for XBee, Ciseco XRF, or similar radio module.
• Footprint for Hope RFM12B radio module.
• AVR ISP programming header.
• Maximum board size 50 mm × 50 mm (to use cheapest Iteadstudio PCB fabrication option).
• All unused digital I/O brought out to pads for easier extension, prototyping and hacking.

It is intended that all hardware directly interfacing with the gateway will use 3.3 V signal levels.

Features

The board has footprints for both RFM12B and XBee (or similar, such as the Ciseco XRF) radio modules and since they use different interfaces and GPIOs both can be used simultaneously. There is an FTDI connector to the Raspberry Pi's UART; this is shared with the XBee so both cannot be fitted at the same time. Only the minimum required set of digtal I/Os for each module have been hard wired. The RFM12B /CS input and /IRQ, and XBee /RESET, can be connected via jumpers. The remaining digital I/Os from the RFM12B, XBee and even the FTDI connector can be used by adding link wires to the desired Raspberry Pi's GPIOs on the second header footprint. If not needed then a pin header can be fitted to allow another expansion board to be stacked on top of the wireless gateway. The maximum current draw from the P1 connector's 3V3 pin is 50 mA. To enable higher power radio modules to be used the wireless gateway includes a built-in 3.3 V voltage regulator (250 mA limit)

Connecting to the gateway

To connect to the Raspberry Pi wireless gateway you might also be interested in Calunium, my shield-compatible Arduino clone based on the ATmega1284P. The latest version will include space for an RFM12B radio module.

Build it

At the moment the design is preliminary and untested. Eagle PCB design files are available under the Creative Commons Attribution-ShareAlike 3.0 Unported (CC BY-SA 3.0) licence. The files will be updated as the design progresses.

Warning!

The Wireless Gateway for Raspberry Pi is intended to be used with 3.3 V devices only. Using it with 5 V devices (e.g., Arduino) will very likely damage your Raspberry Pi.

Calunium v2.0: Preliminary design

View schematic and PCB as PDF.

Preliminary version

I'm planning to release an improved version of Calunium, my Arduino clone. Before finalising my design I'd like to have some feedback from other ATmega1284 users and would-be users. I make no promises that your suggestions will be included but I value any constructive feedback you give.

Summary of changes

Arduino 1.0 headers included

The revised Arduino headers have been included. This adds dedicated I2C connections and an IOREF pin whose purpose is to indicate the I/O voltage level.

Jumper-selectable 3.3V or 5V operation

The microcontroller supply voltage is easily selected by a single jumper setting.

Improved reset circuit

A reversed-biased diode has been added in parallel with the reset pull-up resistor to prevent overshoot of the reset signal which can cause erroneous behaviour.

Option to use surface-mount real-time clock

I've not been able to find a suitable alternative to the DS1307 which can operate at 3.3V and which is available in a dual inline package. The alternatives are only available in SOIC8 or smaller packages. To support 3.3V operation a combined DIP/SOIC8 footprint has been used.

Ceramic resonator option instead of crystal

The crystal footprint has been revised to allow a 3-pin ceramic oscillator to be fitted as an alternative to a crystal. Omit the 22pF loading capacitors when using a ceramic oscillator.

Improved analogue power supply circuitry

Analogue power supply follows the advice given in the data sheet.

Temperature sensor now powered from logic output

The optional LM61 (or similar) temperature sensor is now powered from D7. This change has been made for low power operation; I've been fitting an LM61 to other shields instead of using one on Calunium so that it can be powered off when not needed.

V-USB removed

I've had no success with the V-USB interface so the necessary circuitry has been removed. If you have had any success please let me know how to make it work! The USB connector remains as a convenient 5V power connector.

To do

There a few things to do that I can't at this stage:

• Add white silkscreen areas on underside of the PCB for writing the serial number and crystal frequency.
• Clean up silkscreen text.

Anything else?

There is approximately 0.7" × 1" unused space on the PCB. What should be included that is currently missing?

• SRAM/FRAM?
• Ciseco XRF module? Probably not enough space for the jumper settings I'd like to include, and planned for another board.
• Add a 5V regulator connected to Vin? Without a separate power connector (too bulky and infrequently used?) I'm not sure it is very useful.

The Eagle PCB design files for Calunium v2 are available on Github and are licensed under the Creative Commons Attribution-ShareAlike 3.0 Unported License.

Options for powering Calunium

Calunium with 3.3V prototyping power adaptor fitted. Click on the image for an annotated version.

Why there isn't a 5V regulator

One of the reasons why I designed Calunium instead of using the Arduino Mega2560 was the inefficient linear power regulators on the Mega2560 prevent low-power battery operation. I considered various high-efficiency low-dropout regulators (the MCP1702 series is a favourite) but decided that as there are so many possible power options (for example, USB, NiMH, alkaline or lithium polymer batteries or solar cell) I would omit the 5V regulator and include a dedicated power connector. I expect that any embedded use of Calunium will require an additional circuit board and that is the best place to locate power supply circuitry appropriate to that particular use.

3.3V or 5V operation

One of the key features I wanted was to allow either 3.3V or 5V operation. By using the auxillary power connector Calunium can easily be powered at 3.3 or 5V. To make protyping easier I've added the appropriate regulators to two small pieces of stripboard, either of which can be placed directly onto the auxillary power connector. Depending on which stripboard is connected the microcontroller operates at either 3.3V or 5V.

Calunium power adaptors for prototyping; 3.3V (top) and 5V versions. Click on the image for an annotated version.

Selectable 3.3V or 5V operation

For selectable 3.3V or 5V operation omit the onboard 3.3V regulator. Also omit the polyfuse so that there is no danger of connecting the 5V from the USB or FTDI connectors to the microcontroller or peripherals. USB power is still available on the auxillary power connector. Fit a 12MHz crystal, at 3.3V operation 16MHz is outside of the safe operating area for the microcontroller but 12MHz operation is within the specifications. For the lowest power operation omit the LEDs and 2N7000 FET.

3.3V operation

Link the 3V3 and 5V connectors and provide 3.3V to both of them. Note that the DS1307 requires 4.5 to 5.5V for proper operation. The only suitable replacements for the DS1307 that I've found are surface mount SOIC8 packages (eg DS1338, MCP79410, MCP79411, MCP79412) which then requires a SOIC8-DIP adaptor. A newer revision of Calunium is planned which will contain both SOIC8 and DIP8 footprints for the real-time clock.

5V operation

Provide 5V to the 5V connector, from either the USB power supply (V_USB) or an external supply. If the 3V3 rail is used then an external 3.3V regulator must be provided; some shields (the Ethernet shield and my RN-XV+SD shield) have their own 3.3V regulator anyway since the standard Arduino board can only provide 50mA to the 3.3V rail. If the 3.3V regulator is powered from the 5V supply a low-dropout regulator will be required.

Coin cell operation (3V)

The onboard CR2032 or CR1220 coin cell is normally used for battery backup of the real-time clock. To use it as a power source for the microcontroller follow the instructions for selectable 3.3V or 5V operation and then connect the V_BAT connector with the 3V3 and 5V connectors. Note that coin cell operation is only suitable for very low power uses. Fit an 8MHz crystal to ensure the microcontroller operates within its specifications.

External power

If an external power source is used, such as a 9V mains adaptor, the input supply can be connected to V_IN for distribution to the shields.

Future improvements

When Calunium was designed it wasn't clear how 3.3V operation should be implemented, particularly when shields are used. I took the approach of providing 3.3V to the 5V rail and ensuring my RN-XV+SD shield could operate at either voltage. Following the release of the new Arduino Leonardo boards with their extended connector featuring IOREF a better approach is possible: keep the 3.3V and 5V rails at the designed voltages and power shields from the IOREF connector. This is the approach I am taking with the next version of Calunium as it enables voltage selection to be made using a single jumper.

E-mail delivery times observed by AuroraWatch UK

Following a comment by one of the AuroraWatch UK followers on Facebook I decided to analyse the AuroraWatch UK email statistics to investigate the variations in delivery times between email providers. It's important to understand that AuroraWatch UK doesn't make predictions but sends out alerts when geomagnetic activity exceeds preset levels. Prompt email delivery is therefore essential for AuroraWatch UK and its email subscribers.

The table below lists the top 30 email domains by number of AuroraWatch UK subscribers. For each domain the worst-case delivery time observed is given.

Domain	Number of subscribers	Worst-case delivery time	Comments
blueyonder.co.uk	725	00:05:16
mmail.co.uk	341	00:05:17
lancaster.ac.uk	114	00:05:18
live.co.uk	325	00:05:19
o2.co.uk	189	00:05:20
tesco.net	250	00:07:48
btconnect.com	141	00:07:51
lineone.net	189	00:07:53
talktalk.net	476	00:07:54
mac.com	226	00:07:54
me.com	167	00:08:45
bigfoot.com	102	00:09:18
hotmail.co.uk	2144	00:13:15	Edit: Similar delays to Yahoo observed in February 2014.
tiscali.co.uk	819	00:13:26
googlemail.com	1138	00:14:08
gmail.com	5064	00:14:13
ntlworld.com	1226	00:14:16
supanet.com	97	00:15:25
orange.net	119	00:15:26
fsmail.net	113	00:15:28
virgin.net	669	00:15:33
msn.com	359	00:15:34
hotmail.com	6317	00:15:53	Edit: Similar delays to Yahoo observed in February 2014.
sky.com	482	00:19:09	Uses Google Edit: as of 2014 uses Yahoo!
aol.com	2727	00:39:47
talk21.com	324	01:19:12	Uses Yahoo!
btopenworld.com	492	02:44:05	Uses Yahoo! Edit: as of 2014 uses CP cloud, delays much reduced.
btinternet.com	3870	02:48:59	Uses Yahoo! Edit: as of 2014 uses CP cloud, delays much reduced.
yahoo.com	1319	05:29:17
yahoo.co.uk	2634	05:31:11
Total	32433

Statistics are based on the AuroraWatch red alert sent 2012-03-09. Failed delivery emails (no such address) are excluded. The worst-case delivery time is computed as the difference between the time of the first delivery attempt and last successful delivery, to reduce the effect of the AuroraWatch UK mail queue. The total number of email addresses on the list was 47486; the first 30 most popular domains cover 69.83% of the subscribers.

Note that it takes a finite amount of time for the AuroraWatch UK email server to work its way through the email lists. It is not meaningful to make comparisons between email providers for worst-case delivery times of less than 20 minutes since the measured performance is highly-dependent on the order the AuroraWatch UK server processed the email addresses. Longer delays are caused by email providers temporarily rejecting legitimate emails for defence against spam. Yahoo's performance is hit particularly badly by their choice to employ this practice.

The original spreadsheet is available on Google documents.