Set clock on Arduino Yún

January 14, 2014

In my Arduino Yún project, I’d had the problem of sometimes writing to the log file before the clock had been set (so the log had the wrong date and time). To avoid this, I wanted to force the clock to be set as part of my Arduino sketch.

After poking about on the Linino side of the Yún, I figured it out.

You use ntpd, like this:

p.runShellCommand("ntpd -qn -p 0.pool.ntp.org");

I figured this out by ssh-ing to the Yún and using ps to see what processes were running. I figured I might be looking for ntp, so I used

ps | grep ntp

I don’t know why the command uses the 0. in 0.pool.ntp.org, but pool.ntp.org didn’t work, and the command I saw running in the results from ps used it.

XBee configuration software for Mac

January 11, 2014

I’m really glad that Digi has finally built a Mac version of their X-CTU software. XBees are fun, and it’s nice to be able to configure them without resorting to Windows via a virtual machine.

MoltoSenso is an alternative, but I couldn’t get it to detect my XBees.

Three XBee

Crazy Arduino Yun solution to a router problem

January 8, 2014

My father-in-law helps out with computer-related stuff at a coffee shop. They’ve been having WiFi troubles; the WiFi signal is strong, but they lose the internet connection. The solution has been to turn the router off and then back on; if they do that, things then work fine. He even installed a wall switch for this purpose, to make it easier.

He asked me whether I could build a device that would do this automatically. It sounded like an interesting project, and there’d be some useful things to learn in the process. Probably they should just buy a new router, but what follows here is a description of my crazy auto-router-resetter: my goal was to build an Arduino-based device that would check for an internet connection, and if the internet was down, use a PowerSwitch Tail (from Sparkfun) to shut off the router, wait 30 seconds, and turn it back on again.

Here’s a picture of the final product:

Arduino Yun project

Read the rest of this entry »

Electronics birthday party

April 29, 2013

For my son’s 8th birthday party, we had nine 8-year-olds over, and I prepared an electronics activity for the kids. We called it a “Science” party.

The central projects were based on these blinky circuits, one using a pair of 3904 NPN transistors and the other using a 555 timer.

We started with three very simple projects:

  1. Connecting a 9V battery to an LED using a resistor.
  2. Add a pushbutton.
  3. Add a potentiometer (dimmer).

We then moved on to the blinky with the 555 timer. Here’s a photo; the two LEDs flash alternately, with the speed controlled by a potentiometer:

Blinky with 555 timer

Here’s a photo of the fifth project, a blinky using two 3904 transistors. The kids didn’t get to this one.

Blinky with 3904 transistors

I’d originally intended to do the blinky with the transistors and then the one with the 555 timer, but the transistor circuit proved to be more complicated, so I left it to last, and I was pretty sure we wouldn’t get to it anyway, and we didn’t.

Setup

I ordered a bunch of parts from All Electronics, including a breadboard, LEDs, resistors, capacitors, battery snap, potentiometer, 555 timer, and 3904 transistors.

Here’s the parts list, which came to $8/kid.

(I got a few extra resistors, LEDs and another capacitor (for another $0.87/kid), because I wasn’t quite sure what I was going to do at the time I placed the order.)

We also got a 12-pack of safety glasses, and some mini composition books and pencils. The safety glasses weren’t really necessary, but the kids really liked them, and they seemed science-y.

I prepared a detailed handout (PDF here) with explanations of the different parts and breadboard diagrams for five projects.

I used dig-layout-creator to make the layouts. I’d originally been trying to use Fritzing, but the results weren’t too readable.

Each kid got a ziploc bag with all of the parts and two paper plates to lay them out. Here’s a picture:

Activity setup

I didn’t really explain anything. I just told the kids to flip ahead to the first project and try to set it up.

A bit of soldering

The potentiometer I got was nice and big, with a handsome knob, but it didn’t fit into the breadboard, so I had to solder wire to two of the leads for the kids to use it.

I should have gotten the kind that was intended for soldering, but I wasn’t thinking clearly when I placed the order.

I also had soldered solid wires to the battery snaps, so they’d be easier to insert into the breadboard. I also clipped a bunch of different jumper wires of different lengths and colors.

The soldering and wire clipping were a lot of work. But I could use the soldering practice, and I kind of like stripping wire.

Both my kids enjoyed distributing the different parts into the ziploc bags. In other words, they fought over who could do it and whether one had gotten to do more than the other.

Lots of assistants

My wife, my father, my father-in-law, one of the guest’s dad, and I were helping the kids. We had an assistant for every two kids, and that made a big difference.

I think everyone got the first three simple projects to go without any trouble, but the fourth project, the blinky with the 555 timer, proved frustrating for many.

A couple of kids gave up and pulled all of the parts out of their breadboards before I had a chance to go over and troubleshoot. (And it’s tricky to look at someone’s layout and figure out what is wrong.)

One of the kids that I was helping had several problems: the 555 IC was backwards, one of the LEDs was backwards, and one of the resistors wasn’t in the right place. I fixed all that, and it still didn’t work. Finally I discovered that the jumper from pin 3 on the IC to the battery was missing.

One girl did do the whole layout herself, hooked up the battery, and it worked perfectly on the first try. That was nice to see.

The rest of the party

The party was planned to be 90 min. The first 30 min the kids played outside. They were running around like crazy, actually; we wondered if they would be able to settle down and work on the electronics. But they did come in and concentrated nicely on the breadboards for 30 min, and then went off to play some more, giving us a chance to clean up (organizing all of the goodies into bags, with fruit snacks, to take home) before the cupcakes (four dozen for 10 kids is the right amount).

Room for improvement

The party was successful. I think the kids enjoyed playing with the electronics. I wish I’d gotten them all to do the blinky successfully, but I’m happy that at least some did.

I had a couple of example layouts for the kids to look at, but just one of each of the 4th and 5th projects.

If I were to do this again, I would:

  • Have a couple of examples of each of the projects, for the kids to look at.
  • I clipped the leads on the capacitors rather than peeling them off the tape, making them hard to work with. I should have left them with longer leads.
  • Use an easier-to-solder potentiometer.
  • Maybe just toss the 5th project completely.
  • Include wiring diagrams in the handout, in addition to the breadboard layouts.
  • Put the parts explanations at the back of the handout.
  • Have more explicit and complete instructions, at least for the first three projects.

Arduino robot book

October 31, 2012

O’Reilly has a new book, Make an arduino-controlled robot.

It seems really useful, covering a lot of the questions that I have about my own robot.

And it covers the exact robot kit I’ve been using, from DFrobot.

Arduino/Xbee garage door indicator

September 23, 2012

A month or so ago, I created a garage door indicator using arduino and XBee: LEDs in my bedroom indicate whether my garage doors are open or closed. I was inspired by this project, though I didn’t want to get into the garage door opener itself, to remotely open or close the doors. I’d also been reading about thefts from garages in the neighborhood, and we do tend to leave one of garage doors open now and then, sometimes over night.

Remote sensors

To sense whether my two garage doors are open or closed, I use two magnetic contact switches (like this one, but I’m using the ones that came with my Make: Electronics Components Pack 2b). These are just encased reed switches: they switch on/off based on the proximity of a magnet. The magnet needs to be within about 3/4 inch.

I use a Series 2 XBee and a breakout board from SparkFun (to attach the XBee to a circuit board) to send information about the status of the garage doors to another XBee in my bedroom. The two magnetic contact switches are connected to digital input pins on the XBee, and the XBee is set up to send the status of the two pins every two seconds.

Here’s a picture of the interior of the remote:

And here’s the exterior (I used a project box I purchased from Radio Shack):

And here it is installed:

Indicators

A second XBee is attached to an Arduino (via an XBee shield from sparkfun). It listens for the open/closed status from the remote XBee and turns on one of a pair of LEDs for each door: red for open (bad) and green for closed (good). Since I have one large garage door and one small one, I use 10mm LEDs for the large door and 5mm LEDs for the small door.

Here’s the original version of the indicators, breadboarded (though with all 5mm LEDs, using a pairs of LEDs for the large door and single LEDs for the small door…the 10mm LEDs hadn’t arrived in the mail yet):

For the final version, I used a cigar box, which I thought would look nicer on my dresser than a plastic project box. I added a lot of bells and whistles. The trickiest part was that the walls of the cigar box are rather thick, and so you have to counter-sink the parts a bit, as they are generally designed for the thinner plastic walls of a project box. And if you counter-sink something, you have to use care in whether to drill the big hole or the small hole first (do the big hole first), and you have to get the size and depth right in the first place; you can’t go back and counter-sink after you’ve drilled the smaller hole.

Here’s the interior:

In addition to the red/green LEDs for the open/closed indicators, there’s a yellow LED to indicate that the XBee is getting a signal, a power jack, an on/off switch, a potentiometer (with a cap) to adjust the brightness of the LEDs, a photoresistor (light sensor), and a button to switch between using the pot or the light sensor to determine the brightness of the LEDs. The light sensor works really well, so I’m really just using that. I’d originally planned to attach the pot directly to the LEDs, but in the end I have everything connected to pins on the arduino and I just use software to read the button/pot/light sensor states and control the LEDs’ brightness.

Here’s the exterior of the indicator box:

Actually, those pictures are before I’d quite finished: the pot is just sitting inside, and I’d not yet added the button or the light sensor.

Here’s the completed interior:

Here’s the completed exterior. The photo sensor is on the top, toward the right rear. The pot and button are on the left side.

A few issues

Power jack

I drilled too big a hole for the power jack in the back. I guess I didn’t measure properly. But the toggle switch came with a metal plate that I wasn’t going to use and which worked perfectly to cover over my mistake. And it’s on the back, anyway. (One side of the plate is labeled on/off, but the other side is blank and so worked nicely.)

Upside-down XBee becoming detached

The remote XBee, which is hanging upside down in the garage, tended to become detached. I strapped it to the circuit board using a zip tie:

Stuck reed switch

One of the reed switches tends to get stuck, and so one of the garage door indicators has a tendency to say it’s closed when it’s really open, and this is the smaller garage door which tends to be the problem one and is really the whole reason for this project!

It took a while to figure this out. At first, I thought that the XBee was over-heating (it was really hot at the end of July), and so I drilled some holes on the side of the project box. But that didn’t help.

I then tried swapping the XBee pins for the two doors. (I should have tried that first!) The problem was still with the particular garage door, so this indicated that it was not the XBee but the reed switch for the small garage door.

I then flicked the reed switch with my finger, and that did it. And every time since, when the indicator stops working, if I give it a quick tap, that fixes the problem. So it’s clear that the reed switch is getting stuck with the circuit closed.

I’m ordering another reed switch, to replace it. For now, I’ve switched the connection to the reed switch from the “normally closed” connection to the “normally open” connection, and then revised the software to match. (Update: Changing the wire connection on the reed switch from “normally closed” to “normally open” didn’t seem to help, so I switched it back, but then swapped the reed switches between the two doors, so that the bad one is on the large door, which we seldom leave open accidentally.)

I also need to install some sort of screen inside, covering the holes I’d drilled, thinking that the electronics were overheating. I don’t want bugs or spiders to get inside.

Code

Here’s the code for the project. (It’s within my XBee repository.)

Data logging shield: update

July 24, 2012

I ran my fridge data logger a bit longer, with the following results; not too different from the previous results.

I’ve posted the code and data at github, including the R code to make the above plot.

I ran the data logger for a couple of days, but it seemed that the battery went mostly dead after just one: the date and time started getting reset as 165/165/165 165:165:85 and then it seemed that the arduino went off and on, so that it would start writing to a new file. I clipped off all the messy bits to make the figure above.

Here is the clipped file, and here is the longer file with some of the messy bits.

Data logging shield

July 11, 2012

I bought the data logging shield from adafruit, as well as the 6 x AA battery holder, so I could try out their refrigerator logger: logging the light and temperature of my fridge, to see how the temperature fluctuates and how much the temperature rises when the door opens.

First, I needed to do some soldering. I hadn’t soldered in a while, so I first put the jack on the battery pack. I’ve done a bunch of these, and Lady Ada has a clear tutorial, but I botched this rather badly.

  • When you do the black wire, on the outer tab, you need to put the solder on the inside rather than the outside. I got too much on the outside and wasn’t able to screw on the plug cover.
  • Cut it off and put on a different one, but realized afterwards that I’d used a 2.5 mm plug instead of a 2.1 mm plug. The larger plug fits into the arduino, but it’s a bit loose and so the connection is unreliable.
  • Cut it off and tried again, but forgot to put the plug cover on the wires first.
  • Cut if off and tried again, and finally got it. The wires are a bit short, but the battery pack works.

I moved on to soldering together the data logging shield. Lady Ada’s instructions are, as always, superb and easy to follow. It all went together easily.

It wasn’t too clear what the LEDs were for, but when I got to the instructions about the light/temp logging, it became clear. You use jumpers to connect them to digital pins 2 and 3 (green will be 3 and red will be 2): note the two short yellow wires in the top right of this picture. Then you do whatever you want with them. (In the light/temp logging sketch, they use green to indicate that a reading is being taken and red to indicate either an error or that data is being written to the SD card; see the walk-through of the code.)

There was one other thing that wasn’t clear: the shield came with a 6-pin ICSP header, but it isn’t mentioned in the assembly instructions, though it does appear in the picture of the shield, next to the two jumpers for the LEDs. I soldered it there but I’m not sure what it would be used for. (As mentioned at the adafruit forum, it’s for programming the arduino via ICSP rather than USB; I don’t think I’ll be doing that.)

Lady Ada used the prototype section of the data logging shield to permanently solder the sensors. I instead put extra long headers in the shield, so that I could easily plug in jumper cables and attach sensors via a breadboard. I also put a single pin of extra long header in the 3V spot on the shield.

Here’s the assembled stuff:

It was super easy to follow the code; I had no trouble getting it all to work.

Here’s the shield in the refrigerator:

I’d planned to leave it in for 24 hours, but I pulled it out after 16 hours so that I could make a plot of the results.

Here’s a plot I made (in R) of the temperature over time. The dots at the bottom indicate when the door was opened; red dots indicate the door was open for more than 10 seconds.

The temperature is mostly below 40 degrees, as it’s supposed to be. I was surprised to see it dip so far below freezing. Just before noon, I left one side of the refrigerator door slightly ajar (a not uncommon mistake in our house). I went into work last night and stayed absurdly late; I opened the fridge when I got home, at a bit after 2am.

I’ll add R code and a sketch of the circuit later. I ended up using the light/temp logging sketch from adafruit without changes, so there’s no need to include that.

Given our tendency to leave the refrigerator door ajar, maybe I should create a temperature-based alarm. No; I think the batteries would cost too much.

Ethernet shield

July 8, 2012

After a long delay, I’m back to playing with electronics.

I bought an arduino ethernet shield from dfrobot (cheap, because it’s the old version that doesn’t have an SD card slot). I got it to work fine with the arduino Ethernet library. The only tricky bit was the MAC address: I tried using a random one, and the arduino would hang at Ethernet.begin(mac). But for some reason if I switched the initial hex digits to 00, then it worked. I ended up just adding 01 to the MAC address for my laptop.

After trying out the very simple examples that come with the arduino Ethernet library, I hooked up a temperature sensor to it, got an account at cosm.com, and used the CosmClient example to log temperature data for my living room for a day. It was a bit too easy, so I don’t feel particularly accomplished. And the precision of the TMP36 temperature sensor I used (from the Sensor Pack 900 from adafruit) is rather crappy. It’s attached to an analog input and gives temperature in 1° increments.

I’m not sure what I’m going to do with the ethernet shield, but it seems like it’d be cool to be able to turn lights on and off via the web.

I ordered the data logging shield from adafruit, because I wanted to log the temperature inside my refrigerator, as Lady Ada had done. (I guess I should have just ordered the proper ethernet shield, which would have included ethernet and SD card access!)

The code for my little temperature logging project is on github.

Music shield triggered by PIR sensor

March 17, 2012

I recently got a Seeeduino music shield, and I spent last night and a bit today trying to get it to be triggered by a PIR sensor, so that the music would turn on when there’s movement and turn off when there’s not been movement for 5 seconds.

It took a bit of tinkering and studying. Initially, I could just get it to turn on with movement and then run through a full song. But today I was finally able to get it to work.

The music shield library has rather ugly code with a lot of extraneous commented-out lines and little documentation. But it is rather easy to follow and to get working. Most importantly, it was quite easy to do the modifications to handle the PIR sensor information. I did need to make a change to the actual library, which is less than ideal, but it was only a couple of lines.

The file player.cpp contains a function AvailableProcessorTime() that gets called repeatedly in order to handle user interface events. Then there’s a global variable playStop that indicates whether the player should be playing (playStop == 1) or stopped (playStop == 0). So I just needed to add a line to check the sensor and change playStop accordingly.

What I did was create a generic user-defined function,

void userInterruptFunction(void) { /* ... */ }

that gets called within AvailableProcessorTime(). The user would need to be sure to define that function, but it could be left empty, or it could be used (as with my code) to check a sensor and then change a setting.

The code for my project is at my github page.


Follow

Get every new post delivered to your Inbox.