Arduino – Engineer On The Loose

Hacking the Acurite 0077XW / 00592TX Wireless Remote Temperature Probe – Part 3 – capturing and decoding the data stream

Feb 262015

This post continues the tear down and reverse engineering of the Acurite 0077XW / 00592TX Wireless Remote Temperature Probe Part 1 & Part 2.

After tearing apart the wireless temperature base station and seeing the straightforward electrical connection between the radio module and the base station logic board, Part 1, and then picking apart the remote probe temperature data protocol, Part 2, I was ready to read the wireless data into a microcontroller.

Given that I want to receive the data from the probes wirelessly then I am going to need a wireless receiver. Also given that I purchased 3 probe plus base station combos just to get the 3 probes I have extra base stations I wont be using. The obvious answer is to pull the wireless module from one of the base stations.

The surgery was pretty straightforward. I desoldered a wireless module from the ribbon cable in the base station, cleaned the solder out of the holes, and soldered in a 4 pin header so I could plug the module into a breadboard.

I plugged the wireless module into a breadboard with an Arduino Pro Mini 3.3V and an oled display.

For this exercise ignore the oled display and the wiring on the backside of the breadboard. We are only interested in the four wires going from the Arduino to the wireless module. The red wire is 3.3 volts, the black wire is ground, the yellow wire goes from D on the wireless module to digital pin D3 on the Pro Mini, and the green wire goes from SH on the wireless module to digital pin D4 on the Pro Mini.

The squelch pin (SH) is an input to the wireless module and so is configured as an output on the Arduino.

The data pin (D) is an output from the wireless module and so is configured as an input on the Arduino.

Arduino pin D3 was specifically chosen as the data input as it is a change triggerable interrupt pin. The bit stream from the probe is captured by the Arduino by taking an interrupt on every level change of the data line from the wireless module and measuring the time from the last change in the data stream to this change. This allows the Pro Mini to measure the width of the high and low parts of each pulse and determine if the pulse is a data sync or data bit.

It is known that interesting pulses are close to 0.2 msec, 0.4 msec, and 0.61 msec long. Pulses that are significantly shorter than 0.2 msec or significantly longer than 0.61 msec are not interesting, are not part of the data stream, and signify the data stream is not yet in sync and Pro Mini should be looking for the data sync pulses.

It is known that the start of the interesting data, the data sync, is eight 0.61 msec pulses in a row. The data sync consists of a 0.61 msec high pulse followed by a 0.61 msec low pulse, with this combination repeated four times.

Since the Pro Mini interrupt pin is configured for change, every time the interrupt is called you can assume there is a change from high to low or low to high on the data line. If the Pro Mini measures the time between every interrupt and every sees eight 0.61 msec times in a row that indicates a data sync has been seen. If a data sync is seen the Pro Mini should immediately start measuring pulse times until 56 data bits, or 112 edges (interrupts) are counted.

Once the 112 high or low pulses are counted the data is filtered two pulses at a time to determine if a 0 or a 1 bit was detected. If the captured pulse stream is a 0.4 msec pulse followed by a 0.2 msec pulse a logic high (1) is recorded. If a 0.2 msec pulse followed by a 0.4 msec pulse is detected then a logic low (0) is recorded. All 112 pulses give the 56 bits or 7 data bytes of the data stream.

Once the data stream is recorded the bytes can be decoded as follows:

The first and second bytes of the data are the unique probe address. The upper two bits of the first byte are the probe channel indicator:

11 = channel A 10 = channel B 00 = channel C

The remaining 6 bits of the first byte and the 8 bits of the second byte are a unique identifier per probe.

[strike]The next two bytes are always 0x44 followed by 0x90, for all of the probes I tested (a sample of 6 probes).[/strike]

[update – see Part 4]
The upper nybble of the third byte carries the remote probe low battery indication.

When the remote probe batteries are fresh, voltage above 2.5V, the third byte is 0x44.
When the remote probe batteries get low, below 2.4V, the third byte changes to 0x84.

The fourth byte continues to stay at 0x90 for all conditions.
[/update]

The next two bytes are the temperature value. The temperature is encoded as the lower 7 bits of both bytes with the most significant bit being an even parity bit. The MSB will be set if required to insure an even number of bits are set to 1 in the byte. If the least significant seven bits have an even number of 1 bits set the MSB will be 0, otherwise the MSB will be set to 1 to insure an even number of bits.

The last byte is a simple running sum, modulo 256, of the previous 6 data bytes.

Code to capture and decode the bit stream can be found at my github repo.

I’ve created a spreadsheet ProbeX6.xls to paste the decoded data into to check the checksum of each transmission and decode the temperature data.

Decoded data from four different probes is shown here. The data is formatted as hex codes decoded and emitted by the Pro Mini followed by the same data in binary format, and then the calculated temperature.

One thing to keep in mind is that each probe requires a “correction factor” to convert from the probe reading to the correct temperature. After having such success with this portion of the project I went out and purchased three more probe / base station modules. I checked all six probes and each had a different offset to convert from sensor reading to actual temperature.

The next step is to pull the data into a RasPi and create a presentation layer to map temperatures around my house. The first part of this project, the reverse engineering and decoding of the 00592TX protocol was a blast. I expect the next phase of the project, the RasPi and data warehousing to be just as much fun.

I hope this series was helpful and if you have any comments, questions, or suggestions please leave a comment below.

Hacking the Acurite 0077XW / 00592TX Wireless Remote Temperature Probe – Part 2 – decoding the protocol

Tech 1 Response »

Feb 252015

This post continues the tear down and reverse engineering of the Acurite 0077XW / 00592TX Wireless Remote Temperature Probe [Part 1] .

Knowing that the signals between the logic board and wireless module are standard 3.3 volt logic level signals with tens to hundreds of micro-second long pulses it is time to pick apart the bit stream and see if I can make heads or tails of the encoded data.

With the signal identified as a digital serial data stream the obvious tool to turn to is a logic analyzer, ideally one with protocol decoding built in.

I own multiple different logic analyzers but my goto analyzer for anything but the widest or fastest signals is the Saleae Logic. I own one of the older models but it works like a champ. Analyzing and picking apart digital signals is child’s play with the Saleae software.

I soldered extension wires to the Ground (G), Squelch (SH), and Data (D) lines to make connecting the analyzer easier.

After a bit of picking and probing, and a bit of web searching, I was able to pull apart the bit stream and protocol used by the temperature probes to communicate to the base station.

The SH pin turns out to be the SQUELCH signal from the logic board to the wireless module. When the squelch pin is low the radio module disables data output. I assume the logic board uses the squelch pin to limit the data transmitted from the wireless module between display updates. The base station logic board unsquelches the radio module on a regular periodic basis, reads the incoming temperature data, decodes the data, and updates the display.

The D pin is clearly the data from the temperature probe. The waveform is relative stable when the probe is at a constant temperature and changes when the temperature at the probe changes.

Reverse engineering the data protocol was the more difficult part of the whole effort. I captured multiple bit streams and some patterns were immediately obvious. There was random looking data followed by a consistent pattern followed by a series of wide and short pulses. Eventually I figured out the random pulses at the start of data must be for radio synchronization between the transmitter and receiver. None of the “random” data at the start of the bit stream was consistent between any runs and I ended up simply chopping it off and ignoring it in the data stream.

After the random bits there is a low pulse of varying length followed by 4 data sync pulses. The data sync pulses are 1.2 msec long, 50% duty cycle with 0.61 msec high and 0.61 msec low. Immediately after the 4 data sync pulses are 56 data bit pulses. Each data bit pulse is ~0.6 msec long. A logic high (1) bit is encoded as a 0.4 msec high pulse followed by a 0.2 msec low pulse. A logic low (0) bit is encoded as a 0.2 msec high followed by a 0.4 msec low.

The data stream transmitted by the 00592TX remote temperature probe to the base station is formatted as follows:

The probe first emits a seemingly random length string of random width hi/lo pulses, most like to provide radio (RF) synchronization.

A random length low signal is inserted between the RF synchronization bits and the data sync pulses.

The probe then sends 4 data sync pulses of approximately 50% duty cycle and 1.2 ms period. The sync pulses start with a high level and continue for 4 high / low pulses.

The data bits immediately follow the fourth low of the data sync pulses. Data bits are sent every ~0.61 msec as:

Logic High (1) bit is encoded as ~0.4 msec high pulse followed by ~0.2 msec low

Logic Low (0) bit is encoded as ~0.2 msec high followed by ~0.4 msec low

The 00592TX sends the 4 sync pulses followed by 7 bytes of data equaling data 56 data bits.

Four (4) high and low pulses in a row, 0.61 msec high, 0.61 msec low, constitute a data sync.

The remaining 56 bits of data, or 112 edges, are measured and converted to 1s and 0s by checking the high to low pulse times.

The first and second bytes of the data are the unique probe address. The upper two bits of the first byte are the probe channel indicator:

11 = channel A 10 = channel B 00 = channel C

The remaining 6 bits of the first byte and the 8 bits of the second byte are a unique identifier per probe.

The next two bytes are always 0x44 followed by 0x90, for all of the probes I tested (a sample of 6 probes).

The last byte is a simple running sum, modulo 256, of the previous 6 data bytes.

The sync pulses are high for 0.62 ms and then low for 0.62 ms.

Four sync pulses in a row constitute a sync condition.

A logic 1 bit is 0.4 msec high pulse followed by a 0.2 msec low.

A logic 0 bit is a 0.2 msec high pulse followed by a 0.4 msec low.

A sync pulse plus data stream looks like this.

In part 3 of the series I will go through capturing the data stream with an Arduino and decoding the captured bits.

Hacking the Acurite 0077XW / 00592TX Wireless Remote Temperature Probe – Part 1 – hacking the hardware

Tech 6 Responses »

Feb 252015

Were I live, up against the foothills just east of the Rocky Mountains, the temperatures can vary wildly in a single day, 40F degree swings are common and 60F+ degree swings are not unheard of. For a while now I have been wanting to measure and record the temperature variations inside my house in response to temperature swings outside the house. I want at least one temperature probe outside, another in the attic, one in the lower level on a north wall, one in each of the kids rooms, just to see if it is as cold as they complain it is, and maybe one in the garage. I’m talking about at least six probes. They should be wireless for ease of installation and the ability to talk to a remote base station where I can record the temperatures. I want to record the temperature over time so I need a computer interface of some kind. A web page displaying the results would be nice. Maybe push the results to an online data warehouse. Opportunities for fun are endless.

All of the pieces to build a system like this are readily available from the usual suspects, sparkfun, adafruit, ebay, dx, etc. Figure a temperature sensor, micro-controller, wireless module, battery case, wiring, etc. at each location, times six. I can find a temperature sensor for about fifty cents, Arduino mini for five bucks, wireless module for a buck fifty to three bucks, a case and miscellaneous parts for another two bucks, say a round $10 USD per node. Probably a RasPi for the base station, another $45 at least with power supply, case, and wireless receiver. And then I would have to put it all together and blah blah blah, I never got around to it.

The other day I was at Walmart and stumbled on a pile of wireless remote temperature base stations and probes in the clearance bin.

When I flipped the package over I noticed the probe uses 433 MHz wireless to communicate with the base station. I know a lot of low end consumer wireless devices sourced out of China use a wireless module separate from the core logic of the device. Decoupling the wireless functionality from the core functionality makes a product more amenable to delivering to a worldwide market. Different parts of the world have different regulations on wireless transmissions so modularizing the wireless link allows it to be swapped out for different markets with minimal design and manufacturing changes.

If the core and wireless functions were separate there was a possibility I could sniff the communication lines between the two and decode the data protocol. Once decoded I should be able tap the lines and record the received temperature data with an Arduino or RasPi.

A base station plus probe was on clearance at just under $10 USD, I quickly picked up three. If the probe and base station were designed like I expected $10 seemed like a steal, I couldn’t even build the probe for $10, let alone have the base station along with it.

Here is the base station and probe out of the packaging. My first impression is good. The buttons are clicky, the probe looks reasonably robust, the display is big enough to be useful.

Removing the battery covers reveals that the probe takes 2 AA alkaline batteries and the base station 3 AA batteries. There is also a backup battery under a cover in the base station to keep time when the main batteries are being changed.

Under the battery cover in both the base station and the probe is a slide switch labeled A, B, C. I’m assuming the switch allows you to have up to three base stations and three probes in the same radio range.

Now was the moment of truth, time to open them up and see what the radio infrastructure looks like. First remove the two screws under the batter cover, shown just above. Next remove the three rubber feet from the bottom of the probe and remove the three screws found there.

Pop off the base plate and then pry the shell in two.

Flipping open the base station revealed the gold! There is clearly a wireless module mounted at the top of the unit, with the blue antenna wire leading out of it and running around the inside of the case.

As an added bonus the wireless module is completely separate from the logic board. The two boards are connected by a four wire ribbon cable.

Even better, the cable between the boards is labeled, SH, D, V, G (click the image to enlarge). V and G seem obvious, D is probably data, SH could be anything but a reasonable guess might be chip select or data available.

Popping open the probe revealed a similar construction, a wireless module near the top of the unit connected to a logic board with four wires.

Putting batteries in the unit caused it to power up and within a few minutes it was displaying the temperature. Everything seemed to be working, the remote sensor was being read by the base station, it was time to start probing around to see what I could see.

Step one is check the power, get an idea of what we are working with. As expected with three alkaline batteries the voltage going to the logic board was around 4.5 ~ 4.8 volts DC.

I confirmed connectivity between the ribbon cable ground (G) and the battery ground, that one seemed obvious and was.

Next I probed the V pin between the logic board and the wireless module, a reasonable guess is the V pin is voltage into the wireless module. The V pin turned out to be a solid 3.25 volts, let’s call it 3.3 volts because that’s what it probably is supposed to be.

Next thing to do was unscrew the wireless module, unwrap the antenna, and get a better look at the board.

A macro shot of the main chip on the wireless module revealed it to be a MICRF211, a 3V 433.92 MHz Receiver,

MICRF211 datasheet 1

MICRF211 datasheet 2

The next step was to probe the lines with an oscilloscope and see what the signals between the wireless module and the logic board looked like. This was where the rubber meets the road, if the signals were anything crazy the pain to condition and decode them might not be worth it.

Only one way to find out, start poking and probing and see what you see.

I started with the SH line.

It turned out to be pretty boring. It was clearly a gate or data available line. Nothing very interesting. The voltage was right around 3 volts.

Time to probe the D line and see if it was more interesting.

Probing the D line was way more interesting, something was happening here. The reasonable theory is this is the data being transmitted from the probe to the base station. The signal level is again around 3.3 volts, so no special conditioning required here. The fastest pulse found was on the order of a few micro-seconds, not slow, but not crazy fast either, something I could get a hold of with an Arduino.

Putting both traces on the scope at once clearly shows the gating or data ready behavior of the SH line overlapping the D line.

Now that I know what is in the case and what the data signals look like between the logic board and the wireless module the next step is to decode the data stream and see if it looks like something I can read and decode with everyone’s favorite microcontroller.

Part 2 of this post can be found here.

Acurite 00754 / 00771W / 00772W / 00773W / 00774W / 00592 / 00592TX

Drawbot update

Tech No Responses »

Feb 092014

Not a huge amount of progress on my drawbot but I’ve stumbled across a couple interesting ideas I want to capture as part of this build stream.

I have printed a gondola and a couple spools. I printed this gondola and it looks good.

It holds a sharpie marker great, tight with just the right amount of tip poking out. It has good mount points for the cords and a place to put some weights on the bottom. The problem is, and I didn’t think about it before printing it, there isn’t a way to mount a pen lifter servo. I could probably rig something up that would work fine, but I’d rather have a designed in solution. So I’ll likely be printing a new gondola soon. This gondola will probably work fine for a TSP single line art but I want a pen lifter so I can do pointillist style images.

I also printed out some spools, the ones I mentioned in my earlier post, the ones makerblock recommended I shouldn’t use. They printed fine and I think I can glue them together to avoid the coming apart and unspooling problem. But they aren’t ideal, for a lot of the reasons makerblock pointed out. They press fit onto the motor shaft, no set screw, they are kinda narrow so you get cord build up changing the spool diameter. They looked good on paper but after printing and holding them in my hand I can see some of the issues makerblock pointed out. So I’ll be printing new spools.

On to the interesting part. I found a link on youtube to a guy who made a drawbot using the Eggbot hardware. So far I haven’t found any more details but at least someone tried, and succeeded, at this before.

Second, and I think more cool. I stumbled across a video for building a drawbot on the cheap. This guy uses some super cheap stepper motors, less than $5 USD each with motor drivers, simple 3D printed spools, and cup hooks for cord guides. No motor mounts, he just screws through the motor mounting tab into the wood drawing surface. Doing a quick BOM using the cheap motors and drivers, a super simple bare bones arduino clone, 3D printed spools, cup hooks or eyelets for guides, a cheap wall wart power supply, and a hand made or 3D printed gondola I think you could make a drawbot for less than $50 UDS, maybe less than $35 with some searching.

To me this is a super exciting way to introduce robotics to newbies. The drawbot itself is cool, people just seem to like watching the drawing appear physically. The cost is pretty cheap, it seems within the range of a learning or science project, and it’s super simple to build. I think a high school or middle schooler could easily assemble a simple drawbot in a day. Build up some kits and sponsor a build a drawbot day at your local school.

Drawing board, melamine coated shelf board from HD
Stepper motors with drivers
A cheap arduino clone, preferably already assembled to avoid soldering
Cables and wiring harness, preferably already assembled for plug and play
3D printed spools and gondola
Cup hooks and screws
Some fishing line
A sharpie marker

The software would need to be developed to drive it but that problem is being worked. I think this is a cool idea that could be pretty interesting for young wanna-be nerdlings.

Search DealExtreme for stepper motors, I’ve found some motors with drivers for less than $4 USD each.

Software for the Sparkfun LED bargraph breakout kit

Tech No Responses »

Jan 302014

One of the cool things about buying a widget from Sparkfun, or Adafruit, or Pololu is that almost invariably there is some reference software posted with the product to get you off the ground immediately.

For the Sparkfun LED bargraph kit the reference code can be downloaded from the product page or directly from Sparkfun’s github repo.

The reference software comes with examples that demonstrate multiple ways of driving the LEDs. Here are a couple videos demonstrating the setup and Sparkfun’s demo code putting the bargraph breakout through it’s paces.

This is with no additional coding. Build the LED bargraph display, wire it up to the Arduino SPI, download the Sparkfun bargraph demo library, upload the example code, and sit back and watch the light show.

A different project I am working on needs a display with the feel of an analog VU style meter. I need to monitor a continuous variable and display feedback to a user of the variables relative value between it’s min and max. It was a short step from Sparkfun’s demo code to a display just like I need.

I wrote some quick demo code to read an analog input and map the read values to a set of LEDs on the bargraph display. I forked Sparkfun’s github repo for the bargraph kit and added my additional example code. You can pull the analog input to VU meter display demo from my github bargraph repo.

Here are some videos showing the setup and display of a read analog value in bar and dot modes.

This is exactly the style of display I was looking for and I think this package is going to work nicely.

Sparkfun LED Bargraph breakout kit

Tech No Responses »

Jan 282014

I’m in the middle of a project that would benefit from an analog style display. Something to visualize an approximate value, within a min and max range, simply and clearly.

I like to browse Sparkfun’s inventory when I’m looking for new or interesting widgets. They are hometown boys (at least if your hometown is Boulder, CO), they make a range of interesting products, and being local it is easy to order and pickup parts the same day. And it turns out Sparkfun makes a nice LED bargraph breakout kit that looks like just what I’m looking for.

Fully assembled the display is supposed to look like this

The kit consists of a carrier pcb, four 8 bit serial to parallel shift registers(74HC595), some current limiting resistor packs, decoupling caps, and three 10 position LED bargraph displays. The Sparkfun kit comes with a Green, Yellow, and Red bargraph.

The Green to Yellow to Red transitions follow the typical Ok, Warning, Danger pattern. A reasonable choice by Sparkfun given no insight into their customers final designs.

When I picked up the kit I had a different application in mind. Rather than the standard transition from ok to danger I wanted more of a VU meter or power level type of display. For my application a single color for all three bargraphs makes more sense. It turns out Sparkfun sells the LED bargraphs in Blue, which is what I wanted. Each of the four colors of bargraph, Green, Yellow, Red, and Blue, are drop in replacements for the ones in the kit so you can mix and match to get the color or color ordering you want.

Eventually I want to mount this display in an enclosure with the LEDS showing and the pcb hidden. If the board is built as you would expect, all of the components firmly seated against the PCB before soldering, the LEDs do not sit very high above the shift register ICs. That means when the display is mounted either the enclosure walls need to be thin or else the LEDs will be set back in the enclosure wall. It turns out the LED bargraphs come from the factory with pretty long legs, probably around 5 mm. If you solder the LED bargraphs with the legs just through the PCB the front of the LEDs will stand off of the PCB about 12-13 mm and a good 6-7 mm above the ICs. That should give plenty of space to mount the PCB and have the LEDs mount flush to the front of an enclosure.

The kit is easy to assemble and the instructions are complete and easy to follow. The resulting display has a nice look and is easily programmed to display a variety of patterns. The kit can be assembled in under an hour and assuming you have an Arduino laying around and some jumper wires you can be displaying blinky patterns in less than 15 minutes more.

Atmel AVR based robots, Redbot, 3pi, Zumo – getting the build environment ready

Robots 1 Response »

Jan 162014

Download and install a build environment

The Sparkfun Redbot, Pololu 3pi, and Pololu Zumo robots are all based on the Atmel atmega328p processor. All three have a wealth of libraries and supporting software. All three support at least the two most popular methods of creating code for the AVR processors, Arduino and avr-gcc (Windows and Linux). The two Pololu robots also support the Atmel Studio build environment.

Downloading and installing the Arduino environment is pretty straight forward. Download for your environment, unzip or untar, run. Not much more to it than that.

Atmel has taken over the support of the avr-gcc tool chain and hosts the builds for Windows and Linux. Installing the tool chains for Windows and Linux are documented on the Atmel site.

Get the supporting libraries

All three robots have additional supporting libraries; Arduino style for the Redbot and Zumo, Arduino, Atmel Studio, and straight avr-gcc style for the 3pi. Both vendors, Sparkfun and Pololu, provide links to download their libraries. Pololu supplies prebuilt installers for different versions of their libraries. Both companies also provide source on Github; Redbot / Zumo / 3pi. For the Zumo you want both the Zumo Shield library for Arduino programming and the libpololu-avr library for direct avr-gcc programming.

I prefer to go straight to the source and download the libraries fresh from Github. All of the libraries provide a “Download Zip” link to download a compressed bundle straight to your desktop. After you have the downloaded bundle you can uncompress and install it. I prefer to use GIT directly, under Windows and Linux, and clone the repositories directly to my desktop. Whichever method you use you will eventually have copy of the libraries on your local machine.

To clone the repositories locally under Windows I use the git bash shell from git-scm, under Linux I use git. If git is not installed on your flavor of Linux use your distro’s package manager to download and install it.

Install the libraries

The Redbot and Zumo Arduino libraries need to be installed where the Arduino environment can see them. Arduino provides tutorials on installing 3rd party libraries so I wont repeat that information here. Pololu also provides ample documentation on installing their libraries, for all three environments, Atmel Studio, Arduino, and raw avr-gcc.

For the Pololu 3pi robot I am using raw avr-gcc. The steps I used to install the Pololu libpololu-avr library are:

1 ) Insure you have the avr-gcc tools installed

From a command line run avr-gcc –version
If the program is found move forward, if not, return to installing the avr-gcc tool suite.

2 ) Build the Pololu Library

The Pololu library make file by default builds all of the flavors of AVR libraries for all of the Pololu products that use the library. For the 3pi you only need support for the 168 and 328p libraries.

New 3pi robots are based on the Atmel AVR 328p processor. Older 3pi robots were based on the 168 processor. The example program makefiles still reference the 168 library. At this point it is easiest to keep both the 168 and 328 libraries. Over time it makes sense to migrate to the 328, if you have a newer 3pi robot, but for the sake of expediency build both libraries for now.

Edit the libpololu-avr/Makefile and remove the building and installing of unneeded libraries.

In a command window in the libpololu-avr directory make the libpololu libraries. Simply type make in the libpololu-avr directory. The build process should eventually yield two files called libpololu_atmega168.a and libpololu_atmega328p.a. These are the 168 and 328p libraries containing the functionality provided by the Pololu library.

3 ) Copy the libraries and include files

Next you need to make the libraries and required include files visible to avr-gcc. You can either modify the example make files as you create or re-use code to point to your local versions of the pololu libraries and include files or you can copy the library and include files to the avr-gcc default path. Pololu recommends copying the files into the avr-gcc path.

See the pololu/libpololu-avr/README.txt file:
== Manual installation ==


If you have the source repository of the library instead of a binary

distribution, you will need to build the library (.a) files by running

"make" and also copy all the files in the "src" subfolder into the

"pololu" subfolder.
Next, copy libpololu_*.a into your avr-gcc "lib" subfolder.
Finally, copy the entire "pololu" subfolder into your avr-gcc

"include" subfolder.

You are now ready to use the Pololu AVR library.

Use the make show_prefix to discover the avr-gcc paths used in your install.

– Copy the library files, libpololu_atmega168.a and libpololu_atmega328p.a, into the avr-gcc lib directory.
– Copy the pololu directory, libpololu-avr/pololu, not just the files in pololu, the pololu directory and the contained files, into your avr-gcc include directory.
– Copy the contents, including any sub-directories, of the libpololu-avr/src directory, into the newly copied pololu directory in your avr-gcc/include path. In this case copy the “contents” of the src directory, not the src directory itself, into the avr-gcc/include/pololu directory.

Test your install and build the demo code

If all of the above worked you should be able to change into the libpololu-avr/examples_templates/3pi-demo-program and type make.

Now that you have a hex file you need to upload it to your robot.

I use avrdude directly from a command line. Using the Pololu AVR programmer the command looks like:

If everything worked cleanly you should have a fully functioning build and deployment environment ready to write new code.

FTDI programmer for the Arduino Pro on the cheap(er)

Tech No Responses »

Dec 312013

The Arduino Pro comes with a bootloader installed, meaning it is plug and play ready to work with the Arduino environment. All you need is a way to hook it up to upload new firmware.

The Pro is a stripped down version of the Arduino UNO. One of the stripped parts is the USB to serial programming interface. Programming the Pro requires either an ISP programmer or a USB to serial translator.

The Pro brings out the standard green to black FTDI cable programming header and Sparkfun recommends their FTDI programming cable (5V) for a plug and play experience. That is all well and good but a FTDI cable is pushing a cost of $20 USD (Sparkfun’s 5V and Adafruits 3.3V). You can buy FTDI breakout boards with the same pinout for a little less, around $15 USD (Sparkfun, Adafruit). That’s better than $20 but still more than twice the cost of other options.

If you are willing to wait for the shipping from China (or you order ahead) you can get a FTDI breakout for less than half the price of the Sparkfun or Adafruit breakouts. The iTeadStudio FOCA breakout has a couple of nice features over the Sparkfun and Adafruit breakouts, and one glaring hassle. First the good, the FOCA interfaces with either 5V or 3.3V systems with the flick of a switch. The FOCA also has an XBEE footprint allowing it to be used as a USB to XBEE interface (compare to Sparkfun’s USB to XBEE board at $25). All in all a pretty nice package for $6.50 USD (as of Dec 2013).

iTeadStudio FOCA

Now for the hassle part. The pinout of the FOCA is NOT a direct crossover to the “standard” green to black programming pinout on Sparfun’s and Adafruit’s FTDI cables, and of course the pinout on the Arduino Pro.

The pinout on the Pro is green to black being reset/dtr, TX, RX, power, cts, gnd.

Sparkfun Arduino Pro

The pinout on the FOCA is power, TX, RX, gnd, dtr/reset. Not a straight across plug and play.

FOCA Pinout

Fortunately for half the price it is pretty easy to make an adapter cable. I happened to have a 6 pin to 6 pin inline cable with crimped on connectors which made it easy to move the pins around.

The pins are held in place by little plastic fingers that can be easily lifted back with the tip of an Xacto knife or dental pick, allowing each pin to be slid out of the connector and moved to a different position.

A quick shuffling of both ends of the connector, to move green to one end and black to the other end on the Pro side, and to line up power, gnd, TX, RX, and reset on the FOCA side and wa-la, a FTDI programmer for under $7.50.

Sparkfun Arduino Pro 328 – 5V/16MHz Buzzer

Tech No Responses »

Dec 292013

I picked up an Arduino Pro from Sparkfun during their cyber monday sale. The Pro is a stripped down version of an Arduino UNO for about half to a third the price. It is missing quite a few features so if you are just starting out a standard Arduino is probably a safer bet. If Arduinos are old hat the price point is pretty attractive, I picked mine up for just under $9 USD.

The Sparkfun Pro has a round footprint in the middle of the board that turns out to be meant for installation of a buzzer, specifically the Sparkfun 12mm Buzzer. This little buzzer drops right onto the board, but other than a comment from Sparkfunion Robert there is no documentation on how to mount or use the buzzer.

It turns out the Buzzer recommended is really a tiny speaker. A mag coil driving a tiny disk. The two pins connected to the mounting holes connect to the Arduino digital pins 4 and 5. It doesn’t seem to matter which direction you mount the buzzer. I happened to mount the buzzer with the words arbitrarily “up”, which resulted in the “+” side of the buzzer “down”. Down being connected to D4 and Up connected to D5.

Sparkfun Arduino Pro

Driving the buzzer is relatively simple, you just set one of the pins, D4 or D5, to an output, pinMode(4,OUTPUT) or pinMode(5,OUTPUT), and drive the other pin, 4 or 5, with a changing signal. The recommended buzzer is basically a speaker and so the input needs to be modulated to generate a sound.

The simplest code to generate a 1 second, 1 KHz tone is:

void setup() { pinMode(5,OUTPUT); tone(4, 1000, 1000); } void loop() { }

The built in Arduino example toneMelody can be easily modified to play out the buzzer.

First open the toneMelody example:

Arduino toneMelody

Modify the bolded lines and upload the sketch to the Pro:

==========================================================================

#include "pitches.h"


// notes in the melody:

int melody[] = {

  NOTE_C4, NOTE_G3,NOTE_G3, NOTE_A3, NOTE_G3,0, NOTE_B3, NOTE_C4};
// note durations: 4 = quarter note, 8 = eighth note, etc.:

int noteDurations[] = {

  4, 8, 8, 4,4,4,4,4 };
void setup() {
  pinMode(5,OUTPUT); // set the "other" buzzer pin to an output
  // iterate over the notes of the melody:

  for (int thisNote = 0; thisNote < 8; thisNote++) {

    // to calculate the note duration, take one second 
    // divided by the note type.
    //e.g. quarter note = 1000 / 4, eighth note = 1000/8, etc.
    int noteDuration = 1000/noteDurations[thisNote];

    tone(4, melody[thisNote],noteDuration); // output the tone on the "+" pin
    // to distinguish the notes, set a minimum time between them.

    // the note's duration + 30% seems to work well:

    int pauseBetweenNotes = noteDuration * 1.30;

    delay(pauseBetweenNotes);

    // stop the tone playing:
    noTone(4); // turn off the tone

  }

}

void loop() { // no need to repeat the melody. }

==========================================================================

The Arduino Pro buzzer playing the toneMelody example sounds like this: