As the holiday approaches, it seems like making some kind of blinkenlights project would allow some fun hacking, but also be within the spirit of the holiday. I encountered the idea of “CheerLights” during my morning surfing. The basic idea is to create a global network of colored Christmas lights, all of which change color simultaneously as they receive update notices via the Internet/twitter.
The project makes use of GE Color Effects lights, which are cool because they are individually addressable RGB leds on a single control bus. I don’t think this project really makes adequate use of that feature, but it’s still pretty cool. The author uses an ioBridge (which he is the creator of) which seems like a very cool gadget, but which is pretty expensive ($120). I could probably write a little gateway between my home server and the Arduino via Xbee, which would be quite a bit cheaper.
Pretty neat idea though, and getting me thinking of a Christmas project…
I didn’t get a lot of electronics hacking done, but I found myself again playing with capacitive sensing. I found this interesting article on the EE Times website:
It also pointed me at the following pretty cool Youtube! vid by the folks at Nerdkits:
My experimentation thus far has been mostly confined to using the CapSense library for the Arduino. This library is pretty simple to use, but it has a number of quirks that make it somewhat cumbersome for the uses that I had for it. I’m currently working on a “better” (for my purposes) version. Stay tuned.
I was driving around various Silicon Valley electronics and surplus stores (like HSC and Anchor Electronics) and decided to stop in at Microcenter. I remembered that they supposedly were beginning to stock items from Sparkfun and the Maker Shed. And, indeed they do! I found a Serial LCD module from Sparkfun that I thought might be fun to have, so I got one:
A couple of quick caveats though:
The module has absolutely no documentation in the box. A quick bit of searching revealed the datasheet for the device, and that was helpful (although not the clearest that I’ve seen). If you are familiar with HD44780 devices, you’ll have no problems.
The pigtail they ship with it connects to the JST connector, and uses stranded wire. Not the best thing to plug into breadboards and the like. I soldered some female headers onto the unpopulated connector, and that worked out better.
It doesn’t appear that you can load custom characters over the serial interface like you can with the traditional interface. Bummer.
Still, it was dead easy. If you want a simple module to do some simple display tasks with only three wires, it works just fine.
Lee mentioned that the there was a way to change the analog reference used on the analog inputs to the Atmel AVR to an internally generated 1.1V, which would give me a lot greater resolution (about little over 1mV per step). Indeed, a little quick searching yielded that it was not only true, but dead simple: the Arduino provides an “analogReference” call. If you simply call it in your setup() routine with the argument INTERNAL, you’ll get a 1.1V reference.
To test it out, I did another run, pretty much the same as before, but illustrating the values read after changing to the internal 1.1V reference. Again, I began with the diode in air, then pinched it, released it, pinched it, then released it, then placed it next to a cold can of Diet Coke I had sitting next to me.
Seemed to work pretty well!
Kragen mentioned that the Atmel also had in internal temperature sensor as well. Indeed, it appears that you can simply do an analogRead(8) to access an internal “virtual pin” that links to an internal temperature sensing node. (On the Arduino Mega boards, the pin will be a different one) Read about it more here. I’m currently just using an old ATMega168 which doesn’t seem to have that capability, so I haven’t tested it. It appears that the sensor is noisy and uncalibrated, but it might be useful in some applications. When I dust off one of my more recent boards, I’ll give it a try.
I had an application where I wanted to detect temperature. No big deal, lots of good temperature sensors exist. But of course, I don’t have any of those. Rather than order something from sparkfun, I thought I’d just try to see what I could do with the stuff I had on hand. What I had on hand was about 100 1N4148 diodes that I got for about a penny a piece.
The idea is that the forward voltage of diodes is temperature dependent. For every degree Celcius the diode increases, the forward voltage should drop by 2mV. So, I decided to test this idea. I configured the analog input pin 0 on my Arduino to be an input, and then activated its internal pullup resistor. I then wrote a program which averaged a bunch (1000) of readings in an attempt to get a stable, relatively noise free signal.
I logged the values beginning at room temperature, then held the diode between my fingers, and then released it a couple of times. Here’s a graph of the resulting data values:
You can see that when I grab the diode, the forward voltage drops rather quickly, but when I release, the signal returns to the original value, somewhat more slowly. Room temperature in my house is around 70 degrees (21 degrees C) and body temperature is 98.6 is about 37 degrees C. The difference would then be about 16 degrees C, and we might expect a difference of 32 mV, but I experienced a difference of only about 16mV. At least part of this can be attributed to the fact that your finger temperature isn’t actually that close to 98.6.
This simple experiment demonstrates a couple of problems: the values returned by analogRead() are noisy, and quantization error is significant. The analogRead call returns a 10 bit number, which means that each bit is about 4 mV, or about 2 degrees C. We could use an operational amplifier to multiply the voltage to make it easier to read, which might help. Consider that an experiment for the future.
I’ve been playing a great deal with Arduinos lately, and have acquired a couple of Xbees to experiment with wireless. But Xbees, cool as they are, are kind of expensive for many tasks where a much simple RF link could suffice. Today, I ran across the JeeNode, which is available as a kit from Modern Device for just $22.50, and that includes a 915Mhz RF link. You’ll need an FTDI cable to program it, just like any other low cost Arduino. Pretty neat!
I’m pretty much near the end of where I wanted to be for the Arduino/Gameduino project: all the major functions that I originally wanted to include are in and working. I’ll be doing a video about it shortly, so I’ve begun to think about what my next project could be. While doing this project, I found an older Arduino NG, and thought it was a shame that I wasn’t using it for something. I also found some old ATtiny13 Atmel chips, and thought those might be pressed into service. Perhaps there was some project I could do that would use both?
Indeed there is.
If you look under the “Examples” menu on your Arduino software, you can find an entry for ArduinoISP. With this, you can turn your Arduino into a programmer that can program other Atmel chips, including really tiny members of the AVR family like the ATtiny13. Why would you want to do that? Well, cost for a start. Arduino clones are cheap, but they aren’t that cheap: you can get the cheapest clones for about $15 or so. But if all you are going to do is flash an LED, or monitor a couple of switches, or read a temperature sensor, that seems like a lot. You can get ATtiny13Vs (nice, they can be powered down to 1.8v) for about $1.91 from digikey in quantity one, and about $1.20 if you buy 25 of them. Cheap! Not quite 555 timer cheap, but pretty close. Anyway…
I thought it might be nice to try to do this. I had some ATtiny13s that I bought a while ago and never did anything with, and an old Arduino NG (previous generation, uses the 168 chips with only 16K of memory). I found this great set of instructions:
And a few minutes later, had programmed his example “blink” program into my own ATtiny13. Check it out!
So, what can I do with such a thing? I think I am going to try to make a “flickering LED candle” for a halloween pumpkin. I have some of those powerful Cree LEDs, and a little PWM flicker program on one of these chips will make a nice effect. Stay tuned!
Addendum:
Make magazine had a project earlier that showed how you could program slightly more powerful chips (the ATtiny45 and ATtiny85) using the Arduino environment. That’s possible because they have enough space to run shrunk versions of the Arduino libraries.
For the ATtiny13, you need to be even more cagey: you compile with either avr-gcc directly (bypassing the Arduino libraries) or use an assembler like avra.
I had an idea for a project that doesn’t require a full Arduino: a small 8 pin processor would work just fine. But how to program them? It turns out you can use an Arduino as a programmer. Check out the instructions:
Sadly, I only have the ATtiny13’s lying around: you need a bit more flash space to use the Tiny Arduino library. Still, pretty neat, and getting the slightly larger devices only costs about $2.25 each, quantity one from digikey.
Addendum:Here is another sketch that turns the Arduino into a programmer that can be used with AVRdude. I’ve written some simple programs using avra: perhaps it is time to dust off those skills…
I was going to tidy up my breadboard layout for the satellite tracker I’ve been working on, and I thought it might be nice to use some software to test out various layouts. It also has the side effect of documenting the circuit, at least minimally. I decided to give Fritzing a try, which is compatible with my low attention span and skill level.
Here’s my first attempt: it doesn’t include the rotary encoder that I put on the board, because it appears I’ll have to setup a custom component to make it work. But as far as it goes, it’s not bad. They already had the Sparkfun RTC clock board that I used, and I just reused a generic 8 pin IC for the AT24C1024B that I wired onto the I2C bus. 5V supplies are all red, grounds are black, and yellow and green are the serial data and clock signals respectively.
When the project is complete, I’ll make the fritzing file available.
In seeking some more details on the inner workings of the Wire library for the Arduino, I chanced across this rather informative link on the Arduino Playground website:
Of particular interest to me was the description how requestFrom worked. It doesn’t just issue the request: it calls the low level twi_readFrom() command to read the bytes requested from the I2C device. Thus, in the case that troubled me before, the bytes are guaranteed to be there.
Or are they? What if you ask for too many? The documentation says the I2C slave will NACK the read request. Well, what happens there? Let’s see what the code looks like…
The twi_readFrom() call is from the underlying avr_libc library, which seems every bit as inscrutable. I haven’t dug deep enough to know for sure, but I suppose it is possible for twi_readFrom to return a value less than the number requested, or even zero in case of a NACK. In that case, the code that I was complaining about would still “work”, although it would call Wire.available() repeatedly (length times) to no avail, and leave the buffer empty.
It’s also good to note that the routine silently trims requests to match an internal buffer length. In theory, the AT24C1024 can write 256 bytes at a time, but the internal buffer lengths are set to 32.
Check out this two line fragment from the read function:
for ( c = 0; c < length; c++ )
if (Wire.available()) buffer[c] = Wire.receive();
Is anyone else struck by the fact that it is, well, just wrong? The I2C device is expected to be sending "length" bytes. This loop checks to see if a byte is available, and if it is, then sticks it in the buffer. But what happens if it is not? Then the index increments, and when we try again, any particular byte we write will be placed at a strange location in the buffer.
The only way this code makes sense is if Wire.available() never fails. If it does, then it will leave an empty slot in the output array.
I'll have to step through the Wire library source to make sure, but this seems wrong to me. I'll let you know what I find.
Yesterday, I got delivery of my Xbee modules from sparkfun, and decided to try to see if I could do something with them. My ultimate goal is to use them to connect my satellite tracker to a PC which is hooked to the Internet so that the tracker can automatically receive updates to orbital elements and the like. But for the evening, I decided to just see if I could get them to work at all.
An Xbee shield, for piggy backing an Xbee onto the Arduino. I should have read the product description carefully: you’ll need to add some headers to actually connect it to an Arduino board: luckily, I had a proto shield I hadn’t assembled, so I swiped those, and then ordered some spare ones from sparkfun.
(Instead, you could just have ordered this retail package and gotten all of the above, including the headers you need.)
Okay, you’ve got all that in front of you, what do you do? Well, you solder the headers in place. I plugged the new headers into another shield, put the board on top, and then quickly soldered the 28 connections. A quick inspection revealed my normally fair soldering had left a cold joint or two, which I touched up.
What next? Configuration! I plugged an Xbee into my Xbee Explorer, and configured it. About half the tutorials I read downloaded the Xbee configuration utility X-CTU, but as I started that, I realized it was over 48 megabytes. Pffft! Just to set a few bits in the microcontroller? Other utilities mentioned that you could use something like the old Hayes “AT” command set to configure them using just a terminal program, so that’s what I did.
I fired up PuTTY, told it to talk to the serial port, and turned on echo. I then configured the 16 bit ID for the module by typing “ATMY1234”, the 16 bit destination by setting “ATDL5678”, and the network id by “ATID1111,”. Each entry echoed “OK”. I then typed “WR” to write the results to EEPROM on the Xbee.
I then extracted the first Xbee module and plugged it into the shield. I then programmed the second one, but instead told its ID was 5678 (ATMY5678) and its destination was 1234 (ATDL1234). I programmed the same network ID and wrote it to the Xbee module.
Okay, now what? Well, I left PuTTY running on the PC with the USB Explorer. I powered down my satellite tracker and detached the current maze that connects to the breadboard containing the RTC, and then plugged in the Xbee Shield. I then reconnected the RTC clock and powered on the new stack.
No smoke. No fire. Lights blinking. Clock seems to work as before.
And staring over at the PC, the status messages that previously had appeared via the serial monitor are now going out over the wireless to an entirely different PC. Success! First try!
My use case was very simple: I really just wanted to eliminate a wire in the simplest way possible. Xbee is very easy to configure to do that. In fact, you can develop your entire sketch for the Arduino without any concern for Xbee at all: just use the serial port. In my case, I want to create an application (probably in Python) to periodically fetch elements and feed them to the tracker at intervals). I can use PySerial to talk directly to the Arduino, and not worry about the wireless at all. When I’ve got that all debugged, I just plug in the Xbee shield, plug in the Xbee explorer to the PC, and everything works exactly the same (no software changes at all).
Of course, my use case is pretty simple, and Xbee can do a lot more. It can (for instance) monitor a set of analog/digital pins, and automatically beacon them to another xbee module, all without any microcontroller at all. Or you can configure a couple of pins as output, and signal them. There are various broadcast modes you can use. Cool stuff.
If you want to deploy and Arduino + Xbee together, there might be a cheaper way to go: the Arduino FIO. (I have one of these from osepp.com.) Cool thing is that they have an Xbee socket mounted underneath it, and include a battery charge circuit so you can attach a lithium polymer battery to it, and charge it via the mini-USB connector. Not so cool? The USB plug isn’t for programming: you’ll need an FTDI cable to program it (which is a bit of expense up front). It also doesn’t have the standard Arduino footprint, so you are out of luck if you want to use standard shields. Still, I think I can find some use for it.
Satellite Tracker Update: I think I have a slow memory leak somewhere. After running for several hours, my tracker simply halts. By printing status messages, I found that it wasn’t the Gameduino which was locked, it’s the Arduino. I’ll instrument it a bit more carefully and do some debugging. I might also institute a watch dog timer reset to blunt the problem. Stay tuned.
Addendum: If you need some additional help, you might try using Jeremy Blum’s Arduino tutorial videos, which shows the process step by step. I watched these a couple of days ago, and while I didn’t refer to them again while setting this thing up, I essentially followed his exact steps, including the use of PuTTY. Jeremy also did an awesome appearance on the ZombieTech podcast. He’s a very talented guy.
The great thing about doing a real project like my satellite tracker is that it makes you learn a lot, in a whole lot of different areas. In other words, it’s good exercise! And thus, it is good when you discover something doesn’t quite work right: you have another opportunity to learn.
Well, today, something wasn’t working right.
Every three minutes, the “active satellite” dot would pass one of the balls on the track. The “track dot” would then get recalculated to the time 2 hours in the future. But I noticed that occasionally, that dot would appear somewhere wrong: a point clearly off the track. It’s of course possible that I had a bug. But I also remembered that this didn’t happen before I placed an LED on the square wave output of the DS1307 real time clock chip I have wired in.
That got me thinking: could some kind of power glitch be occurring that’s causing an error when the program reads the time from the I2C bus? So, I pulled the LED out, and left it running. It’s an hour and a half later, and the glitch has not reoccurred. Interesting.
So, I got to thinking. I didn’t bother putting in any pull up resistors on the I2C bus (laziness, and lack of understanding about how important they are). I realize that the I2C bus is open drain: either the master or the slaves can pull the line down, but perhaps the LED adds enough capacitance to keep the signals from returning to high quickly, which causes a communication error? I suspect it might be informative to check out the signals on my oscilloscope. Stay tuned, but any gurus can go ahead and tell me what’s going on in greater detail, or pointing me to materials that will spoon feed me the necessary knowledge.
Addendum: Stuck in a pair of 10K pullups, my glitch did not reoccur. I should hook it up to a scope and see the difference it makes, but for now, I’ll just consider the problem fixed.
There is a lot to like about the Arduino, but I can’t help but think that the existing library system removes some of the power that the AVR could supply in its effort to handhold new users. I’m not the only one: the guys over at makehackvoid.com have written a new set of runtime libraries that are more efficient to help. I haven’t had a chance to use these in a projects, but I’m leaving this bookmark here so when I get around to it, I’ll consider it.
I need to think up a better name for this project. Calling it the “Arduino/Gameduino Satellite Tracker” is just too damned cumbersome for words.
Progress was slow today. I woke up around 4:00AM with a sore throat and a miserable cough. A quick trip to the urgent care clinic when it opened reassured me that I didn’t have strep throat, but I do have some kind of upper respiratory infection going. Lots of rest today. I did spend a couple of hours listlessly programming and watching the Tigers/Rangers game though, the main result being I now plot the position of the sun on the map:
While the text at the bottom still says “ISS”, the satellite being tracked is actually AO-51. As you can see, it is a polar orbiting satellite, and reaches much greater latitudes than the ISS.
I’ve been trying to remodularize the original Plan 13 code in BASIC, and that has made me go through the code and restructure it a bit. The solar calculations in Plan 13 are actually a bit odd: it goes through the trouble of converting the sun’s orbital elements into the same epoch as the satellite you are watching, mostly so you can reuse the “T” variable. It’s actually quite a bit simpler to just use the sun’s orbital elements directly, and that means the sun can be a completely independent object.
I’ve also got a bit more hardware on the way. I decided I wanted to store a fairly large number of satellite elements, so I ordered some AT24C1024 serial EEPROMS with a capacity of 128Kbytes. I can easily chain up to 4 of those together, to store 512K which should be more than enough.
I’ve also got some Zigbee radios coming, so I can send new orbital elements and synchronize the time easily from my desktop. (It’s mostly an excuse to play with Zigbee, but it will make for a nice setup).
After the clinic this morning, I stopped by Fry’s in Walnut Creek and found that they carry OSEPP’s clones of the Arduino. I’d rather spend my money at Sparkfun, but it’s nice to have a local supplier for those moments where immediate gratification is essential. I bought one of their OSEPP FIO boards, which have sockets in place for Zigbee modules. What I didn’t realize is that these boards aren’t programmable over USB: I’ll have to get one of those FTDI serial boards. For now, it will sit in its plastic case until I have need of it. It is cool that the FIO is actually cheaper than the Zigbee shield that I ordered. I’ll figure out some reason to use one.
I’ll shoot another video once I get multiple satellites loaded and some improvements in the user interface.
Addendum: It dawned on me that one way to test my solar calculations was to run them at the same time every day and see if the sun traced out an Analemma, the figure-eight shaped curve that you might have seen on a globe and given very little thought to. What’s cool is my simulation shows this effect pretty clearly.
