CuPID v2 RF HAT : Pi B+, Pi 2 & Moteino in Action


The Board:
Our CuPID HAT build, from beginning to end.
Our CuPID HAT build, from beginning to end.
The Final Product:
Our CuPID, fully built. Also included here is our SPI LED indicator board, connected by SPI to the HAT SPI header.
CuPID v2 Features:
  • DS2483 1Wire bus master
  • 8P8C (RJ45-like) breakouts:
    • 8 Pi GPIO
    • 8 Analog Inputs from Moteino (328P), shared on pins with GPIO
    • Pi SPI, I2C1
    • 1Wire bus
  • I2C and SPI breakout headers (SPI compatible with CuPID indicator board)
  • Footprint for R4 or R5 Moteino RF Arduino clone
  • Serial interface connection for Pi/Moteino communication
  • 8 shared IO: Pi GPIO <–> Moteino (328P) Digital/Analog IO (state communication, mutual IO)
  • 4 Moteino DIO breakouts, two with pull-ups for I2c if desired
  • HAT EEPROM board and vendor information
CuPID v2 Pinout
CuPID v2 Pinout


What’s a CuPID? See here for a little background, or poke around the site here


The venerable Raspberry Pi, fueling frugal hackers’ dreams since its introduction, has been updated twice in the last year, with major improvements:

Rasperry Pi B+:

The B+ brought improved power management and increased power capacity, along with access to more of the broadcom 2835’s GPIO pins. Two USB ports were also added, along with a facility for on-board EEPROM to identify add-on boards via two dedicated i2c pins.  Physically, the 2×13 26-pin header was swapped out for a 2×20, two mounting holes were added, the existing were relocated for a square mounting grid.

Along with standard physical size standards, identification and configuration via EEPROM data, was built into a standard, called the HAT.  Today, we are going to build one.

Raspberry Pi 2

The RPi 2 swapped out the BCM2835 chip for a BCM2836, increasing the speed to 900Mhz with quad-core (from 700Mhz single-core), for a cited 6x improvement. This is obviously dependent on what you are doing … the memory was bumped up 2x to 1Gb from 512MB, which offer an inarguable performance improvement.

The most amazing part of this is that all of the above was added in a pin-compatible and (for the most part) completely backwards-compatible fashion. Awesome stuff.

The CuPID, v2

So how will we adapt? Technically, the v1 CuPID does fit onto the B+ and the RPi 2 without modification, but the location of the pins doesn’t exactly match compared with the main Pi board, so we don’t end up with a board that matches up perfectly vertically with the Pi. Besides, we want to break out all that yummy IO and set up EEPROM, so of course we had to make a new board. Hence, the CuPID v2.

RF Standard

Don’t get us wrong: we love the breakout on the base Pi for all the important functions of a Pi: GPIO, I2C, SPI, 1Wire, but we are super-invested in the idea of wireless sensing, everywhere. We have been documenting our affair with the Moteino line of arduino clone, RF-enabled devices in our series of remote monitors and controllers. An necessary piece to tie all of these together is the gateway: a Raspberry Pi with an RF receiver that talks to all of our nodes. For this reason, in the CuPID rev 2 board, we include a footprint for a Moteino. It does the following:

  • Powers the Moteino
  • Connects the Pi and Moteino serial interfaces
  • Attaches Moteino analog inputs to the COM2 and COM3 ports’ GPIO interfaces. This makes analog inputs available on the ports!
  • Breaks out four DIO 3-6 for external devices, such as I2C and SPI displays. These are all available DIO on Moteino. Two pull-ups are provided in case I2C is desired (on D3 and D4)
1Wire is universally compatible

We previously set our 1Wire in a way that made sense for our IO layout, but have modified it slightly in the newest revision. The new pinout is compatible with existing RJ45 pinouts, for example in use on the DS9490R USB, as well as iButtonlink adapters and devices. The new pinout makes our IO 100% compatible with all existing devices made by Dallas/Maxim and iButtonlink, using owfs.

EEPROM included

A new feature of the new Pi standard is an EEPROM chip that tell the Pi what hardware is in place and what default configurations should be to ensure compatibility with the hardware. The new CuPID HAT has an EEPROM that identifies the hardware. No defaults are modified.

What it looks like

Here’s a good picture of our board and everything needed to build it.

Our CuPID Hat, and everything needed to make it.
Our CuPID Hat, and everything needed to make it.

Compared to the original CuPID, v2 has fewer components, and most important is much, much easier to assemble. Gone is the micro USB surface mount connector, and all can be hand-soldered. The only surface mount components are the EEPROM and DS2483, which require careful installation, but the rest are through-hole and very manageable.

When we have it together, it looks like this, with and without the RF unit. You can see the standoffs we use to attach it to the Pi and also affix it to the bottom of the enclosure:

Built board, with and without RF unit.
Built board, with and without RF unit.

Finally, we mount the board into the enclosure. Nothing fancy here, except a handful of standoffs and some countersunk screws that we mount to the back of the enclosure. We mount the HAT to the Pi, and insert it into the enclosure. Another huge improvement, both with the B+/RPi 2 and the HAT, is how solid the mounts to the enclosure are. It’s really quite robust.

Hardware and board prior to mount and after insertion into our enclosure.
Hardware and board prior to mount and after insertion into our enclosure.

Now, it’s business as usual! Time to fire her up.

Until next time,



The above makes use of the open source libraries available on github, including sketches, python and all web libraries:

Explanation and installation here:

Running Hamachi on Snappy Ubuntu Linaro

This is recorded here in case the source link (written for a Beaglebone) goes down. Hamachi is rad. That’s covered elsewhere.

Unfortunately, the armhf source from LogMeIn Hamachi does not work on the new shiny ARMv7 Raspberry Pi 2. Woe are us. Realizing that the Beaglebone has the same problem, namely that it’s running an Ubuntu distro compiled for ARMv7, I figured that someone would have solved this problem. And they have. They blogged about it at the link below. I’ve reproduced the applicable content here for posterity.

1. Update

apt-get update

2. Install packages (and package requirements).

apt-get install –fix-missing –no-install-recommends lsb lsb-core aptitude libc6-armel libc6-armel-cross linux-libc-dev-armel-cross

3. Make a directory to hold the downloaded packages.

 mkdir /root/packages

4. Change to the new package directory.

cd /root/packages

5. Download the armel libs.

aptitude download libstdc++6-armel-cross libgcc-4.7-dev-armel-cross  libgcc1-armel-cross libgomp1-armel-cross libc6-dev-armel-cross

6. There is no gcc-4.7-arm-linux-gnueabi-base package for this version of Ubuntu. Force Install the armel libs we have.

dpkg -i –force-all *.deb

7. Tell the system where to find the libs hamachi needs. Edit the /etc/ and add this path at the bottom.


8. Update the library cache.


9. Download the hamachi package.


10. Install

dpkg –force-architecture -i logmein-hamachi_2.1.0.86-1_armel.deb

11. Enjoy!


HAT EEPROM Read/write, configuration for RPi B+, RPi 2

This article is more of a mental note than anything, and perhaps something others will find useful. I spent a couple hours with my strongest google-fu, some hardware, and better things to do than getting a memory chip programmed.


The new Raspberry Pi B+ and it’s younger brother, the Raspberry Pi 2, have a breakout of the second i2c interface available on the Broadcom 2835 and 2836 chips. The interface is available on pins 28 and 29. While technically you could access it on previous versions, there weren’t jumper pins, and it was, well, harder. Still, even here the installation seemed unnecessarily complicated, if for no other reason than the information was spread across eighteen forum posts with a nearly broken forum board search feature.

Device Trees

The new RPi kernel uses what are referred to as Device Trees that load modules selectively at boot. This is in contrast to the previous versions, which used a blacklist to selectively disable devices. We won’t get into the pros and cons of this approach versus the other, but needless to say, when folks in userland upgraded their kernels, all of these things — SPI, I2C, etc, — stopped working. Big f**king oops for usability, guys.

Enable the I2C buses

Go to the file /boot/config.txt. At the end, find the lines (or add them yourself, that say:


Make sure they are uncommented. In order, these will enable i2c-1, i2c-0, and SPI. You have to be careful with i2c-0, as it can interfere with your GPU, specifically your camera. You have been warned.

Now, after the above, give it a good reboot. Now, when you give it an ls /dev,  you should get entries that look like:


You are now most of the way there! Now, one note before we move on: If you have used i2c devices before, you know that the convenient utility i2cdetect will typically list out all devices on the bus for you very nicely. Note that this is NOT the case for memory devices on i2c-0. If you take the device on i2c-1 that happily reads address 50 and put it on i2c-0, it will not respond. The script below, however, will tell you whether or not you have an EEPROM on your bus.

Reading/writing your EEPROM

Ok, well if your device doesn’t announce itself like other i2c devices, how do we read and write it? Good question. First, download the EEPROM utilities from the git repo:

Next — remember that in order to write to your EEPROM, you will need to make sure that the write-protect pin is either floating (defaults to pulled-down), or has been jumpered to ground. See circuit here:

Finally, build yourself some binary data images by editing settings text file and using eepmake.c, and drop it onto your EEPROM using, which you can also use to check your work. The docs on this stuff are good, so I won’t waste time repeating that info here.

Happy HATting !


P.S. If and when we figure out how you’re supposed to access the stuff in userland, we’ll let you know!!