Calunium: version 2.1

Calunium v2.1.
Click on the image for an annotated version.

This upgrade to Calunium v2 provides several minor improvements. There is the option to fit a Microchip MCP220 UART-USB converter instead of the FTDI connector. For development purposes the MCP2200 is much more convenient than an external FTDI cable or adaptor; operation at both 3.3V and 5V is supported. For low-power battery operation the MCP2200 uses too much power so the FTDI connector option has been retained.

I find I operate Calunium almost exclusively at 3.3V. I've not been able to find any real-time clocks in a dual-in-line package that operate at 3.3V and feature battery-backup. Suitable clocks are supplied in a SOIC or smaller package. I have therefore removed the DIP footprint option for the real-time clock. The space saved has allowed me to add optional load capacitors for the crystal so that a MicroChip MCP7941x real-time clock can be used. This clock has several benefits over the popular DS1307 (or its 3.3V equivalent, the DS1338). It is cheaper, it can compensate for crystal frequency errors, it has EEPROM storage, two alarms and it also has a unique identifier. This change goes against one of the original aims of Calunium, to use through-hole components to keep it accessible to the widest possible audience. However, considering the other interesting on-board peripherals (micro-SD socket, RFM12B and MCP2200) require surface-mount soldering skills I thought this a reasonable compromise to make. The original through-hole only designs are still available for those who really do not want to use any surface-mount components.

The final improvement is that the SPI clock signal is now routed with a ground plane between it and the real-time clock crystal.

For the full list of features please see the original Calunium v2 blog post.

Calunium v2 (top) and v2.1 (bottom) PCBs.
Click on the image for an annotated version.

RFM12B shield for Raspberry Pi

RFM12B shield for Raspberry Pi, with integrated in-circuit serial programmer.
Click on the image for an annotated version. 

I recently described the preliminary design of a RFM12B shield for the Raspberry Pi, which used an Atmel ATmega328 to interface between the Raspberry Pi's UART and the RFM12B's SPI interface. The design also included a buffered two-channel in-circuit serial programmer (ISP) using the Raspberry Pi's general purpose I/O. The first channel is for programming the on-board ATmega328 whilst the second channel can program external microcontrollers.

The boards have now been manufactured and the first one assembled and tested. The interface to the RFM12B and the built-in AVR ISP programmer both work as designed. I have been using the Arduino environment to compile and upload the firmware to the ATmega328. The microcontroller pin mapping is identical to the Arduino Uno although the activity LED is wired to D9 since D13 is normally in use by the SPI interface. The ATmega328 operates at 3.3V and is clocked by the internal 8MHz RC oscillator. No bootloader is needed. The Github repository contains boards.txt and programmers.txt files for use with the Arduino IDE, the standard Arduino core is used.

I have been using the first board to replace a Ciseco URF radio module. The firmware for the ATmega328 incorporates my transparent serial emulation layer. This provides a Stream object to which data can be read, and written (or printed), in just the same way as HardwareSerial and SoftwareSerial objects. The same emulation layer can then be used on remote Calunium, Arduino or JeeNode boards to provide a bi-directional data stream, allowing the user to interface to the RFM12B as easily as an XRF or XBee radio module. The emulation layer transparently uses acknowledgements and retries to provide a robust channel, which is an improvement over the Ciseco XRF and URF radio modules. Alternative firmware for the RFM12B shield is easily uploaded to provide different functionality.

ISP programmer

The avrdude configuration file contains details for two GPIO programmers; gpio0 is connected to the on-board ATmega328 and gpio1 is for programming external microcontrollers. By fitting a jumper to the JP1 header the external microcontroller can be powered from the Raspberry Pi's 3.3V supply. Be sure to observe the maximum current rating for the 3.3V supply and never fit the jumper if the remote microcontroller is self-powered. The 74LVC244 buffer ensures that MCUs operating at 5V can be safely connected. Typically the high output level from the 74LVC244 buffer will be recognised as a high but it doesn't meet the worst-case specifications when the external MCU is powered from 5V.

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. The RF12 transparent serial emulation layer is also available on Github and is released under the MIT license.

Errata

There is a connection missing on the schematic from the drain of FET Q2 to pin 5 (/RESET) on the external ISP header (X3). This connection is also missing from the PCB but can be easily fixed with a direct wire connection on the underside of the board.

Update

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.

Transparent serial emulation for the RFM12B radio module

Introduction

For the AuroraWatchNet magnetometers that I am developing I currently use the Ciseo XRF radio module. They are based upon the pseudo-standard XBee footprint, operate at 3.3V and provide a UART interface to the microcontroller. They are easy to use but I have found the range is not always sufficient, typically limited to 60 metres of free space plus one exterior wall/window. Another commonly-used radio module is the HopeRF RFM12B transceiver, as used on the JeeNode. The RFM12B also operates at 3.3V but features an SPI interface to the microcontroller. It is available as a 2mm pitch surface-mount module, or as a 12 pin 2mm pitch DIP package.

As my Calunium v2 microcontroller development board can be fitted with a RFM12B radio module I naturally wanted to compare the performance of the RFM12B and XRF. Initial testing of the Hope RFM12B gave a usable range of 150 metres of free space after transmission through one exterior wall/window. Some of the additional range is due to using the 433MHz version of the RFM12B compared to the 868MHz operating frequency that the XRF defaults to. The range measurements were not very scientific and further work is required before meaningful conclusions can be drawn regarding the comparative ranges. However these initial results have encouraged me to investigate replacing the XRF by the RFM12B, particularly as it is both cheaper and uses less power. A comparison of the basic specifications can be found at http://blog.homelabs.org.uk/wireless-connectivity/.

As I have already deployed a few magnetometers using the Ciseco XRF module I would like to to use the RFM12B as a serial device. This would enable the existing firmware to be used with minimal changes. It would also allow the possibility of having a single firmware support both XRF and RFM12B modules.

Serial emulation

I have created a serial emulation layer for the RFM12B by deriving a class (RF12_Stream) from the Arduino Stream class. Text or binary data can then be read from or written to the RFM12B in exactly the same way as the standard Serial port. Since it is a Stream object the Streaming class (which overloads the >> and << operators) can also be used with RF12_Stream. The RF12_Stream class automatically breaks up the data to be transmitted into short packets which are sent using the Jeelab RF12 library. ACKs and retransmissions are employed to prevent losing data from dropped packets. A packet number is included to prevent duplicated data, which could otherwise occur for the case when the ACK is not received and a packet is retransmitted. The class keeps track of the number of packets sent and received, and the number of retransmissions, data which may be useful to identify the optimal channel on which to operate.

The begin() function takes different parameters to Serial.begin() and it returns a logical value to indicate whether the RFM12B has been found on the system. The user is required to call the poll() function periodically so that outgoing packets are sent and received packets processed. These are the only differences compared to sending data to the standard Arduino Serial port.

Source code for the RF12_Serial emulation can be found on Github, https://github.com/stevemarple/RF12_Stream; it is released under the MIT license. An example sketch is included which echoes data between the Arduino serial port and the RFM12B. When compiled for the ATtiny84 this sketch is less than 8kB so I am hopeful it can be used on the RFM12B to Raspberry Pi expansion board designed by Martin Harizanov. AsyncDelay, https://github.com/stevemarple/AsyncDelay, and CircBuffer, https://github.com/stevemarple/CircBuffer, are also required.

Calunium uses INT2 for the interrupt from the RFM12B which is not supported by the JeeLabs version of the RF12 library so I am currently using a modified version. Source for this version is also available on Github, https://github.com/stevemarple/RF12. It is intended that RF12_Serial should work with both the original RF12 library and my version.

Single firmware to support RFM12B and XRF

By utilising the return value from the RF_Stream begin() function it becomes trivial to produce a single firmware which can support either the RFM12B or XRF radio modules. The trick is to create a Stream reference which is set to either Serial (for the XRF) or to rfm12b. The RFM12B_autoselect example sketch illustrates this concept.

How does it differ from RF12sio?

The RF12sio library overloads the << and >> operators so that packets can be constructed and processed easily. The user is still responsible splitting the data into packets. RF12sio is not derived from Stream so it is not possible to use the Stream pointer trick shown in the RFM12B_autoselect sketch.

Credits

Thanks to JeeLabs and JC Wippler for the RF12 library and to Arduino for the standard Arduino libraries.

How to use the Atmel ATmega1284 (non-P version) with tools that don't support it

I found out by accident there is now an Atmel ATmega1284 microcontroller, as well as the older ATmega1284P. The first I knew was when I tried to upload the bootloader and avrdude warned of a signature mismatch:

avrdude: Device signature = 0x1e9706
avrdude: Expected signature for ATMEGA1284P is 1E 97 05
              Double check chip, or use -F to override this check

Correcting the device didn't help, avrdude doesn't recognise the ATmega1284. That could be fixed easily by creating a custom entry in $HOME/.avrduderc. I didn't bother with that since avr-gcc doesn't support the ATmega1284. At this point I was slightly worried as I had ordered a large quantity of ATmega1284 instead of the ATmega1284P.

A work-around

Fortunately there is a work-around. The two microcontrollers are essentially identically except for some small electrical differences relating to power usage and the last signature byte. Therefore code compiled for the ATmega1284P will run on the ATmega1284. If you are using avrdude to upload just add the -F command line option to force the signature check to pass.

If you use the xboot bootloader you should have no further problems after installing the bootloader since xboot doesn't check the signature bytes. Users of the Optiboot bootloader are probably not so fortunate; I believe the signature is checked - I haven't tested it since I'm now using xboot on all of my Calunium development boards.

Magnetometer progress report

About AuroraWatchNet

I am developing a simple, low-cost, battery-powered magnetometer for auroral alerts and citizen science. It is intended to be wireless to allow easy installation, a unique feature as far as I am aware. The magnetometer uses my own Calunium micro-controller board, which is an Arduino clone based on the ATmega1284P micrcontroller. Data is sent via a radio link to a Raspberry Pi base station which will then forward the data to AuroraWatch UK. I am hoping to deploy a network of such magnetometers in 2013 to enable AuroraWatch UK users to contribute data to improve the service. If you want to track the development then follow @aurorawatchnet on Twitter. 

The first AuroraWatchNet magnetometer is currently running in my garden. The environment is not ideal as I can see disturbances from cars and even the garage door being opened but it is convenient for testing and representative of what to expect from user-contributed data. I have been comparing the results from our SAMNET magnetometers with the AuroraWatchNet prototypes and generally the results are very encouraging given the difference in cost between the two systems. Now I can plot the AuroraWatchNet magnetometer data in the standard AuroraWatch UK style, using the same Octave code. Below is a comparison of today's plots. 

AuroraWatch UK

The data is taken from SAMNET's Lancaster magnetometer. The X axis is time and the Y axis shows the magnetic field strength in the direction of magnetic North (H component) in nanotesla (nT) relative to an unrecorded baseline. This exact plot appeared on AuroraWatch UK. We would normally expect cleaner data but our Lancaster site has recently been experiencing some interference.

SAMNET data from Lancaster, as used by AuroraWatch UK

AuroraWatchNet test magnetometers

The plots below correspond to the same time interval as the plot above. The first plot is from my garden magnetometer.

AuroraWatchNet data from near Lancaster.

The Y axis again records magnetic field strength but this time it is the absolute field. This magnetometer is operating in power-saving mode, turning off the sensor when not needed. This slightly increases the noise level but I hope will give one year of operation from two D cells.

Another AuroraWatchNet magnetometer has been deployed almost adjacent to the SAMNET magnetometer we already use for AuroraWatch. In this system the magnetometer sensor is continually powered, resulting in reduced noise levels. The alignment with magnetic North is only approximate. 

AuroraWatchNet data from the Lancaster University field station.

Conclusion

The AuroraWatchNet magnetometers are sufficiently sensitive and stable to make useful contributions for auroral detection and citizen science. My experience with the garden magnetometer suggests that in many cases performance will be limited by the noise at the site, rather than the magnetometer.

UART-USB converter for mixed 3.3V/5V operation

For some future projects I have in mind I would like to add a USB interface to my Calunium development board, rather than using the Sparkfun FTDI basic breakout board that I have been using. One of the key features is that it should work seamlessly with the jumper-selectable 3.3V or 5V operation offered by Calunium v2, which is most easily accomplished by a self-powered design; auto-reset is a bonus.

Microchip offer the MCP2200 USB interface in a choice of packages including a 20 pin SOIC package which is very convenient for home assembly of PCBs. I found conflicting information about the MCP2200 so I prototyped the above circuit to check that mixed 3.3V/5V operation was ok. VUSB (pin 17) is permanently connected to 3.3V so that the USB signalling levels are always correct. The VDD supply pin is connected to IOREF on my Calunium board, which is either 3.3V or 5V, depending on the position of the voltage selection jumper, ensuring that the logic levels for the MCP2200 match those used by the microcontroller. I also wanted to test whether the MCP2200 would auto-reset the microcontroller. The MCP2200 doesn't have a DTR output pin which is how modern Arduinos reset the microcontroller for uploading a new sketch. Fortunately the MCP2200 does have an RTS output, and as that was the method used by older Arduinos I connected that to /RESET via a 100nF capacitor.

After building the circuit and connecting it to my Ubuntu 10.04 Linux computer the MCP2200 was immediately recognised, I used the dmesg command to see this. Ubuntu automatically created the /dev/ttyACM0 device file, no configuration changes were needed at all. Using gtkterm I was able to toggle the state of the RTS pin. I then hooked up the circuit to one of my Calunium microcontroller boards and was able to upload sketches without needing to press the reset button, in both 3.3V and 5V operation modes. I haven't tested this from Windows but from what I've read on the Microchip forum I suspect it won't work due to deficiencies in the Windows driver.

The datasheet suggests that a ceramic resonator can be used instead of the crystal and load capacitors. I found it did work even though the resonator's frequency tolerance was 0.5%, not 0.25% as required by the USB specification. As I can't source any resonators which meet the specification I'll be using a 12MHz crystal.

The MCP2200 wasn't my first choice; the obvious part was the FTDI FT232RL, although I had reservations about working with an SSOP package. Further investigation revealed that 3.3V operation requires an external crystal, but to use one isn't straightforward. On first use the FT232RL must be powered from >= 4.0V and a custom utility (not openly supplied?) is needed to select the external crystal. The standard MPROG utility cannot be used for this. I am aware that the FT232RL could be powered from the USB 5V supply but I am not a big fan of powering devices simultaneously from both internal and external supplies. One of the future projects is to replace hardware which is powered from multiple sources and is very susceptible to damage from being powered up/down incorrectly.

In conclusion, this is a very useful USB converter for Linux users and for final designs. Windows users who wish to regularly upload new firmware via a bootloader may find it less useful.

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.