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.

RN-XV+SD shield

RN-XV+SD shield. Click on the image for an annotated version.

In my quest to make a low-power magnetometer for AuroraWatch UK there are two additional periphals needed: a Wifi connection for real-time data transfer and an SD card for configuration and data logging. I wasn't happy with any of the existing XBee or SD shields. Many of them use resistor-divider networks which prevent dual 3.3V/5V operation (very useful for development), and those which do use logic-level shifters seem to ignore the problem of mixing 3.3V devices with 5V ones.

In response to this need I designed my own shield. I investigated several Wifi modules, but the main contenders were the XBee wifi module and the similar RN-XV module made by Roving Networks. Although I like the idea of the SPI interface that the XBee module offers in the end I chose the RN-XV, partly because it was cheaper but also for its better availability. Both modules use the same pseudo-standard XBee footprint so to some extent either could be used, although the circuitry is designed for the UART interface and GPIOs of the RN-XV. I also included the circuitry for the PNI MicroMag3 module. This is outside the main shield area so as to be located away from the metal casing of the SD card and away from the Wifi module, which could cause interference. To test for temperature effects an LM61 temperature sensor can be used. Unlike the optional one on Calunium this is powered from a logic output for ultra-low power consumption. The shield is designed for Calunium, but will work with full functionality on the Arduino Mega2560. It will also operate on a standard Arduino but flow control and some of the GPIO features of the RN-XV are not available.

Fitting everything onto a 80 × 100mm PCB (the largest size possible in the free version of Cadsoft Eagle) was difficult so I chose to use surface-mount components. The many jumpers are included to make the board as flexible as possible. I sent the Gerber files to Iteadstudio for manufacture. For maximum yield I used very conservative 0.012" trace widths and 0.012" minimum separation, with 0.024" ground-pour isolation. The magnetometer circuitry is easily removed from the schematic and board design if it is not needed; on the manufactured boards the magnetometer section can be removed with a guillotine without affecting the rest of the circuitry. The cut-out is carefully arranged to avoid obstructing the reset button and the USB and JTAG connectors on Calunium.

RN-XV+SD shield on Calunium.

Eagle PCB design files available under the Creative Commons Attribution-ShareAlike 3.0 Unported (CC BY-SA 3.0) licence.

Calunium: PCB version

Calunium. Click on the image for an annotated version.

Calunium is an Arduino clone based on the ATmega1284 microcontroller. Initially a strip board design was created to test the concept. Following the success of the strip board version I decided to create a PCB version. Initially I hoped to include Wifi networking, an SD card and a real-time clock. It soon became apparent that including this many peripherals was not possible with the desired footprint using the free version of Cadsoft Eagle. The final version includes a real-time clock. Wifi networking (using the Roving Networks XV Wifi module) and storage using an SD card is provided by a shield designed specifically for Calunium. The RN-XV/SD shield will be described in a future blog post. The pin mapping of the PCB differs slightly from the strip board version; the Arduino software takes care of the differences provided the correct board type is selected.

Features

• Shield-compatible with Arduino Uno, with extra I/O laid out to be compatible with Arduino Mega pins. Pin mapping is chosen for maximum compatibility with Uno.
• I2C (SDA/SCL) mapped to standard location as used by Arduino Mega but jumpers can be used to replace A4/A5 with SDA/SCL signals for compatibility with Arduino Uno.
• 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.
• Direct USB interface using V-USB, for firmware updates without requiring FTDI cable. Can be disabled by removing jumpers. Not yet tested.
• Real-time clock (DS1307). Output square wave can be routed to D6 (INT2) or D15 (TOSC1, for input to timer/counter 2). Use either CR2032 or CR1220 battery depending upon battery holder fitted.
• Power from USB or FTDI connector.
• Switches, jumpers, connectors and USB socket 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. 5V from USB (FTDI and/or USB connector) and 3V from RTC battery also available on the connector. 3.3V operation is also possible.
• Auto-reset can be disabled by removing jumper.
• Pads to fit LM61 temperature sensor.
• Usable PCB-mounting holes.
• JTAG header for debugging/programming.
• Eagle PCB design files available under Creative Commons Attribution-ShareAlike 3.0 Unported (CC BY-SA 3.0)  licence.
• Arduino files for Calunium are available on Github.

Interfacing 3.3V devices to 5V Arduinos

Frequently 3.3V devices need to interface with 5V ones, for instance when connecting an SD card to a 5V Arduino microcontroller board. There are many tutorials about device interfacing which discuss various simple methods of level translation, such as this Sparkfun one. Usually the focus is on protecting the 3.3V inputs from 5V devices but on the SPI bus consideration should be given to protecting the outputs too because there could be 5V devices sharing the SPI interface with 3.3V devices. Unfortunately the simple methods frequently don't account for this possibility. Here is a way to interface 3.3V and 5V logic safely. This approach also the advantage that it can be used to make shields which will work on both 5V Arduinos (e.g. Uno, Mega2560) and 3.3V ones such as the soon-to-be released Arduino DUE. To demonstrate the concept the circuit diagram for an SD card interface is shown below.

SD card interface for 5V microcontroller (PDF).

The 5V signals are safely converted to 3.3V using a 74VLC244 octal buffer powered from 3.3V. I chose this device because the data sheet states its inputs permit 5V logic levels when powered from 3.3V. It is also available in a DIP package which is very convenient for prototyping. The output enable lines of the '244 are permanently grounded (enabled). For SPI slave devices you can share the 3.3V versions of MOSI and SCK control lines with all 3.3V devices. You'll need separate chip select buffers for each device.

The 3.3V logic level output to the microcontroller (MISO) is buffered through one gate of a 74HCT125 quad buffer. The active-low output enable is tied to the chip select line so that when the SD card is not selected the output of the '125 is put into the high-impedance state. This will also occur should the jumper be removed, which is the reason for the pull-up resistor. The 74HCT125 is powered from 5V, so there is no problem when 5V SPI slave devices are also in use.

I used the above circuit to successfully connect an SD card to a 5V Arduino Mega2560. It is also included in a combined Wi-Fly and SD card shield design that is almost ready for manufacture.