DIY Electronic Derailleur on Instructable

I’ve posted an Instructable showing how to build and install an electronic derailleur. If you like this project please vote on the Instructables page. A more complete and finished product including my bike computer is in the works.
For now the Arduino sketch, schematics, Fritzing diagram, bill of materials and CAD diagrams can be found on the github.


Open source Bluetooth 4 breakout board means no more Mi-Fi

Update: Project is posted on github
One thing I always need for my hardware projects whether I’m working on sensors for the home or a fitness device is a low power, cross platform and affordable wireless module. I’ve used HopeRF modules like the RMF22B for their affordability and low power capabilities, but because they don’t use any standard wireless protocol I’m forced to make adapters for endpoints like smart phones or computers. Wireless standards like ZigBee partially solve this problem, but off the shelf modules are expensive and still don’t help if you want to talk to a smart phone. One might think Bluetooth is the solution then, but in the past power efficiency and range were a problem if you were building a temperature sensor for example. Also, you had to be a certified Apple accessory developer if you wanted to make a Bluetooth accessory for the most popular smart phone in the market. Well, all of this has changed with Bluetooth 4.
Bluetooth 4 Low Energy is the latest incarnation of the Bluetooth standard, which most devices released this year will adopt. says,
Key features of Bluetooth low energy wireless technology include:
  • Ultra-low peak, average and idle mode power consumption
  • Ability to run for years on standard, coin-cell batteries
  • Low cost
  • Multi-vendor interoperability
  • Enhanced range
There are two reasons why you should be excited by this. First, this low energy mode means you can use Bluetooth in a range of new applications like home automation, wearable electronics or anything that needs to log data for long periods of time. Second, Apple has opened up their Bluetooth API so anyone can create a Bluetooth accessory for iOS 5 and later. Why did they do this? One reason might be they don’t have to worry about developers draining a users battery with a poorly made accessory with the new standard. I can’t think of any reason to use a different wireless standard for these reasons.
This brings me to my breakout board. This breakout board is the reference schematic for the Nordic nRF8001 done in Eagle originally done in Altium by Nordic. It is a simple wireless transceiver with an SPI interface with few passive components.
Why this IC? A quick search on the major electronic distributor websites shows there are a few manufacturers of Bluetooth 4 chips.
  • Blue Giga   ~$20 – $40
  • Cambridge Silicon Radio   ~$3
  • Nordic Semiconductor   ~$4
  • TI   ~$5
  • Panasonic  ~$15
  • RFM (same one iphone uses)  ~$40
Parts from Panasonic, Blue Giga and RFM provide ready to go modules, which explain their high price. RFM actually includes WiFi! Only TI, CSR and Nordic provide ICs. However, TI is a bit larger and expensive because it provides a complete system-on-a-chip with integrated 8051 processor while CSR makes you sign a NDA to get the datasheet. So I choose Nordic because of the ICs small footprint, open specs, affordability and simplicity. Sourcing the parts from it looks like a populated board should cost ~$12. Take a look at my BOM.
One thing you should keep in mind is none of these chips are backward compatible with older Bluetooth standards, but that should not be a problem by the end of 2012.
I plan to send out the board and order the parts this week. Hopefully I can also start working on firmware and a few demo smartphone apps. Until then checkout the source on Github.

Credit to Dr. Michael Kroll for the information about Bluetooth 4 and Mi-Fi. Check out his Arduino Shield.

nRF8001 Breakout board schematic

Weekend Project:

Update: Source code on Github
Introducing A way to share all of your likes and favorites from across the web. You can think of it like except with your ‘likes’ from various social networks embedded on a Pinterest style page.
Planned Improvements
Infinite scroll, more services, pop out images for a larger view, user thumbnails, personal pages, visuals for tweets with no links and instructions 🙂
Unfortunately, Facebook doesn’t provide a users likes without authentication, which defeats the purpose of having a public like list and Google Plus doesn’t have an API for retrieving +1’s yet.


OBD-2 Testing Update

I finished testing the OBD-II adaptor board this week on a Toyota Camry. As you can see in the picture the board had a few bad connections, but nothing that couldn’t be fixed with a few jumpers.

I was able to get a number of stats from the free Torque Android app like
  • Throttle position
  • Engine PSI
  • Collant temperature
  • Engine Load
  • A number of Diagnostic Trouble Codes
  • O2 sensor voltage
  • Revs
One interesting note I learned was the evaporative system test reported as incomplete, which Toyota supposedly repaired during my last visit!
Next up, test the remaining OBD-II protocols and bluetooth range. Expect a new revision in a few weeks.

OBD-2 Build Update

I finally finished assembling the OBD-2 board yesterday. It has taken a while because I’ve been working on an exciting web app for hardware engineers, which will be launching in a few days. I will continue to update the schematics on github, but I don’t recommend building version 1.0. There are a couple of layout and footprint issues I want to workout first. Next up, testing.

Home Energy Prototypes

Web Interface Version 1 with a Google look and feel

In this post I’ll go over some of my prototype home energy/automation creations.

Wireless Temperature Sensor

Wireless temperature sensor with attiny45

This wireless temperature sensor has Sparkfun’s basic 315MHz wireless transmitter, an ATtiny45, LM335A temperature sensor and a 12mm battery holder. This device lasted a couple of weeks by disabling the brown out detector, enabling internal pull ups on all unused I/O and disabling all peripherals. It periodically wakes up and transmit the temperature to a hub with an ATtiny328.

Smart Meter Reader
Wireless Smart Meter reader with IR LED

Using an IR detector from Sparkfun to read the IR signals from the Smart Meter it is possible to measure power usage with a resolution of 1 watt-hour. Since my meter was outside I had to build and enclosure to keep the sunlight out. The newer Smart Meters apparently run a mesh network to report the homes power usage back to the power company, but the signals are encrypted. Still might be worth investigating because they appear to use Zigbee. I plan to try with my new Zigduino.

By separately turning appliances on and off and subtracting the before and after meter readings it is possible to get the power usage for each device. This is actually more accurate than current clamps because the smart meter is multiplying the actual voltage and current instead of the estimated voltage. For this reason current clamps can be inaccurate for inductive loads.

Here are some example readings from my house.
Fridge                    - 180W
HDTV TV + cable box       - 130W
Hot water heater          - 70W
Hall way spot lights full - 220W
Dryer                     - 5840W
Large stove high          - 3000W
Toaster oven              - 1000W
Notebook charge           - 65W

Wireless Power Bar

220VAC @ 20A relay and current clamp

This was part of a wireless power bar, which is at the breadboard stage. This containes an ATmeaga168, Hope RFM12B wireless module, current clamp, 220 VAC relay,  which connected to a power bar. The web interface would display the power usage of the power bar and the state of the relay. The state is controllable via the web interface.

Wireless Thermostat

Wireless Thermostat with ATmega328
Blue thing is the temperature and humidity sensor

The wireless thermostat is probably the most important part of this build. It has one relay to control each part of the HVAC system: heating, AC and fan. Like the previous devices it has a Hope RF module for communication and an ATmega328 for control. I replaced the LM35 temperature sensor for a module with a digital interface and humidity sensor. The AVR runs a simple PID controller to moderate the house temperature, but a more sophisticated control methods is definitely needed. In the future it should have safe guards to protect the HVAC from overwork especially when overshoot occurs. This current version works OK, but I am hesitant to continue testing on my house. The best solution would be to build a test chamber like the folks at Nest did.

Nest’s thermostat test chamber
(via Wired article)

Wireless Hub and Garage Door Opener
Two devices, which I have no pictures for are the wireless hub and the garage door opener. The wireless hub contains an ATmega328, Hope RF module and a usb to serial converter. It’s job was to act as a bridge between the physical devices and the computer. The garage door opener contains a reed switch to determine if the garage door was open and an IR led beam to detect if a car is in the garage.

Web Interface Version 1

Web Interface Version 1 with a Google look and feel

The initial version of my web interface was written in the Google Web Toolkit (GWT) as an experiment after I attended the Google IO conference. If you are not a fan of Javascript and want to get a dynamic web app working fast GWT may be a good choice. The difficulties appear when you need features GWT doesn’t provide like a fancy JS plotting library. It is also complicated to setup your own server so you probably have to use App Engine. The downside of this is technology lock-in.

The chart is the same one used by Google Finance with a few limitations. The biggest being dynamically updating the chart without refresh. For example, sending 2 years of power data with thousands of points will either kill the browser or take forever to load. A better way would be to reduce the resolution and just get the big picture. It’s possible to hack this together, but there is no API call to refresh the data as the user zooms in without reloading the widget, which produces and annoying flicker.

This version featured:

  • Electricity bill based on time of use price
  • Realtime cost per hour
  • Power and temperature history
  • Thermostat controls (far right)
  • Power bar switch and power usage (button that says light)
  • Garage door controls and state info
  • Parking info
Version 2
For the next version I wanted to improve the web interface and provide granular power usage.
Current Meter
To begin I created another board with a Hope RF module, an ATmega168 and this time added six 3.5mm jacks connected the the AVR’s analog input. The current clamps are the same as before except some are rated for 100A and other 15A. I use the 100A for circuits with large appliances like the stove.

Power meter in a Sparkfun box

Wireless power meter with
6 current clamp
Current clamps installed in breaker panel

The current version of this board only supports 6 current clamps so I attached them to the most power hungry appliances: the stove, dryer, ground floor, top floor, fridge and AC.Installation was fairly simple. Just switch off power coming from the mains. Remove a couple of screws to get the front panel off. Attach the clamps to one side of a wire and route the clamp wires through an existing hole in the case. Put the front panel back on and turn on the power.

Web Interface Version 2

To incorporate the new electronics I decided to move to Pyramid and Javascript. Pyramid is the new and improved Pylons project with a bunch of other combined technologies. It’s a bare bones framework that allows you to drop in your own database, template system and UI libraries. Don’t worry it still comes with useful things like user authentication, url traversal and more. If you want a more complete framework try Django or Ruby on Rails. That’s probably why they call it “Rails”.

For serial communication I’m using PySerial, which does the job well. To receive dynamic updates on the web page like the opening of a garage door I’m using SocketIO and Gevent. Gevent provides asynchronous functions, which wait on events in the physical world in this case. This way the server can do other things like take more requests. SocketIO provides socket like functionality to the web browser so when an event does occur on the server side the user can be notified immediately. I highly recommend this tutorial from Alexandre Bourget to learn how to build a website using these tools.

To reproduce Google’s Finance chart I’m using an awesome JS plotting library called Flot. I adding controls for each plot, a plot overview with controls to zoom and server side code to reduce the data points for large ranges. This might be useful for others so I’ll build a sample app and post on Github soon. Checkout the screen caps below.

Web Interface version 2 – breaker panel power historical plots
Web Interface version 2 – realtime power plots
Web interface version 2 – Temperature and humidity plots
(those large spikes are bad data)

Future Plans
The 3 things I would like to improve are the wireless modules, web interface and the hub.

  • Replace Hope RF modules with an ATmega128RFA1 with integrated Zigbee for more functionality and simplicity.
  • Add user accounts to the web interface and clean up the JS code.
  • Develop a hub to connect the devices to the internet. Working on a small Linux board based on the i.MX233.
  • Do another revision of the electronics and iron out the bugs


Bluetooth OBD-II Adapter

Update: Here is the git repo

A couple of weeks ago my Dad and I were trouble shooting the cause of a check engine light on our 2000 Toyota Camry. Using an off the shelf OBD-II reader we got a warning about the EGR system. After trying every test in the book we came up empty and finally had to take it to Toyota. They found a sticky relay that was beginning to fail, which was hard to diagnose because the light would only come on after ~30Km of driving. If we had a way to monitor signals in realtime this problem might have been easier to solve. This is why my OBD-II board was created.

The board is basically the reference schematic for the STN1110, which converts many OBD-II physical layers into RS232. The bottom of the board has a bluetooth module from Deal Extreme. The plan is to connect a smartphone or tablet to the device and log data.

Similar devices exist on the market, but I couldn’t find any cheap ones that have the STN1110. Scantool offers a 3.3cm x 1.5cm module for $70, but that seems a bit expensive for a $10 chip.

Scantool’s module

The STN1110 is supposedly faster than the Elm327, which is good for realtime data logging. It  supports the following protocols:

  • SAE J1850 PWM
  • SAE J1850 VPW
  • SAE J1939
  • ISO 9141-2
  • ISO 14230-4 (KWP 2000)
  • ISO 15765-4 (CAN)
  • ISO 11898 (raw CAN)
My board is 5cm x 5cm, which means the pcb can be manufactured by Seeed Studio‘s for $10. I’ll post the schematics on git hub in the next couple of days.

Bike Computer V0.1 Build

Back: Electronics

I’ve built the first prototype of my bike computer and have been developing the firmware for a couple of weeks now. Everything except the temperature sensor, accelerometer, servo headers, and Li-ion fuel gauge have been populated.

There have been a few minor electrical bugs like forgetting resisters for the ISP programmer, but nothing too difficult to fix for the next prototype. The bigger problems have appeared in the software world. First, I’ve filled all 32K of the ATmega memory mainly because of lengthy sensor configurations, USB libs and FATFS. Second, RAM has become an issue when processing things like NMEA strings or drawing complex graphics. I’ve realized there is no point in having a vibrant TFT LCD screen if the 16MHz ATmega can only achieve low refresh rates, which is why I’ll probably switch to some ARM processor for the next prototype. Maybe I’ll go with the STM32F4 series.

  • ATmega32U4
  • 2 servo outputs to control an electronic derailleur
  • 3 axis accelerometer – MMA7260Q
  • GPS – Linx rxm-gps-sg
  • Altimeter – BMP085
  • Micro SD card
  • LIPO Charger – MCP73871
  • Fuel gauge – MAX1704X
  • 2.4′ x 2.0′
  • Electronic derailleur controller (electronic erailleur details)
Planned improvements
  • Heart rate monitor & pulse oximeter
  • LCD touch screen
  • Accurate measurement of energy output (maybe calibrate for each user instead of curve fitting)

Programming the STM32F4 DISCOVERY with the Bus Blaster

In my last post I talked about how to set up a toolchain on OSX. In this post I will show you how to program and debug the Discovery board using open source hardware and software.

The Discovery board supports ARM’s new two wire SWD serial debug port and 6 wire JTAG port. ST provides programmers and software to program their chip, but as usual no Linux support. Their dev boards also include a USB to JTAG translator called ST-LINK which has Linux support thanks to texane over at github. There has been discussion there about adding support for the STM32F4 and it appears one fork has been made for this purpose. At this point support seems spotty and programming takes longer than it should so I’ll show you the alternative.

Bus Blaster and OpenOCD
Warning: OpenOCD does not fully support the CortexM4 yet and this method may damage your hardware. I am not an expert OpenOCD user. Use at your own risk.

The Bus Blaster is an open hardware JTAG debugger made by Dangerous Prototypes, which you can get for about $35 at SeeedStudio. Any debugger compatible with Open On-Chip Debugger (OpenOCD) should work fine for these instructions.

Download OpenOCD version 0.5.0 here.
Extract and run the following configure script. You may want to change your install directory.

cd [OpenOCD]
CC=/usr/bin/gcc-4.2 CPP=/usr/bin/cpp-4.2 CXX=/usr/bin/g++-4.2 LD=/usr/bin/ld ./configure --prefix=/opt/local/ --enable-ft2232_libftdi
sudo make install

Download the STM32F4 Demo
Update: You will have to change LDFLAGS, CC, LD, … in the makefile to reflect your system.

git clone
cd STM32F4-Discovery_FW_V1.0.1/Project/IO_Toggle
Connect all 6 JTAG pins from the Bus Blaster to the Discovery. The Bus Blaster has labels on the PCB.
JTAG pinout Discovery board
TDI is located on pin PA15 on header P2 of the Discovery board.
Plugin the Bus Blaster to your computer. Power the Discover board via the mini USB, but NOT using a computer. The computer may cause unwanted signals sent through the JTAG pins.

Unload any FTDI kernel modules so they don’t conflict with OpenOCD

sudo kextunload /System/Library/Extensions/FTDIUSBSerialDriver.kext/

Run OpenOCD

cd STM32F4-Discovery_FW_V1.0.1/openocd_config
openocd -f openocd.cfg -f stm32f4x.cfg

You should see something like this

Open On-Chip Debugger 0.5.0 (2011-10-30-17:32)
Licensed under GNU GPL v2
For bug reports, read
Info : only one transport option; autoselect 'jtag'
2000 kHz
2000 kHz
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
Info : max TCK change to: 30000 kHz
Info : clock speed 2000 kHz
Info : JTAG tap: stm32f4xxx.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : JTAG tap: tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)
Info : stm32f4xxx.cpu: hardware has 6 breakpoints, 4 watchpoints

1 Tap is for the CPU and the other is for the floating point unit.

Programming and Debugging with GDB
With OpenOCD waiting for commands open another terminal and run GDB for arm. All commands use the ocd directory as their working directory.

(gdb) target extended localhost:3333
(gdb) # reset and halt the chip
(gdb) monitor halt
(gdb) # load symbol files
(gdb) file demo.elf
(gdb) # load demo.elf into RAM
(gdb) load demo.elf
Loading section .isr_vector, size 0x188 lma 0x8000000
Loading section .text, size 0xc5c lma 0x8000188
Loading section .data, size 0x38 lma 0x8000de4
Start address 0x8000d6c, load size 3612
Transfer rate: 6 KB/sec, 1204 bytes/write.
(gdb) # run the program. hit Control-C to stop
(gdb) continue

(gdb) # run your favorite gdb commands
(gdb) br main.c:71
(gdb) continue
(gdb) list
(gdb) info registers

Writing to flash
So far we’ve only copied our code to SRAM so when the chip is reset the program no longer exists. To write our program to flash we will need to us the flash write_image command, which you can learn more about here.

In GDB the monitor command passes commands straight to OpenOCD. Make sure OpenOCD is running and start GDB.

(gdb) target extended localhost:3333
(gdb) monitor halt
(gdb) file demo.elf
(gdb) monitor flash write_image erase demo.hex 0 ihex
(gdb) continue

This works with the demonstration hex file provided by ST, but I haven’t gotten it working with my build system. My guess is a problem with the linker script.

It seems to get stuck in  HardFault_Handler() at stm32f4xx_it.c:61. If you have any ideas let me know in the comments.

What needs to be done

  1. Figure out the flash problem
  2. Add full support for the STM32F4 in OpenOCD