- 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
- Blue Giga ~$20 – $40
- Cambridge Silicon Radio ~$3
- Nordic Semiconductor ~$4
- TI ~$5
- Panasonic ~$15
- RFM (same one iphone uses) ~$40
Credit to Dr. Michael Kroll for the information about Bluetooth 4 and Mi-Fi. Check out his Arduino Shield.
|nRF8001 Breakout board schematic|
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.
- Throttle position
- Engine PSI
- Collant temperature
- Engine Load
- A number of Diagnostic Trouble Codes
- O2 sensor voltage
|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.
|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.
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 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 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
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.
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)
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
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.
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)
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.
- 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)
- Heart rate monitor & pulse oximeter
- LCD touch screen
- Accurate measurement of energy output (maybe calibrate for each user instead of curve fitting)
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 make 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 https://github.com/nabilt/STM32F4-Discovery-Firmware.git cd STM32F4-Discovery_FW_V1.0.1/Project/IO_Toggle make
JTAG pinout Discovery board
Unload any FTDI kernel modules so they don’t conflict with OpenOCD
sudo kextunload /System/Library/Extensions/FTDIUSBSerialDriver.kext/
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 http://openocd.berlios.de/doc/doxygen/bugs.html 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: stm32f4xxx.bs 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.
arm-none-eabi-gcc (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) 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.
arm-none-eabi-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
- Figure out the flash problem
- Add full support for the STM32F4 in OpenOCD