Scott's Blog

Microwave Reflectometer for Antenna Trimming

2012-01-18T14:03:00.000-08:00

I built a copy of the MIT/LL coffee can radar last year, but I'm just now getting serious about documenting my results. The coffee can antennas work fine if you build them exactly as described in the course notes, but I wanted to explore a bit more. Although I do have an antenna analyzer, it's only for the lower ham bands and won't help me tune up a 2.4 GHz antenna, so I built a simple reflectometer to look at the reflected power coming from the coffee can antennas. Here's the video.

HP 33C Repair

2011-09-14T18:16:00.000-07:00

I got this HP 33C at a garage sale (plus another one for five bucks total!) and there was a lot of corrosion damage on the inside.

They don't make them like they used to.

Some new NiCd batteries and quite a few jumpers to fix traces that corroded away were all that were required to get it running again.

All of the flex traces were hosed and quite a few flex-to-PCB connections were bad too.

Here's the working calculator brought back to life.

Never throw away tools. Fix them.

chipKIT Max32 board benchmarks and transistor trouble

2011-07-28T16:00:00.000-07:00

-- Update: Digilent got back to me and they are sending out a replacement board. Very quick and positive response. Way to go Digilent! --

I was planning on reviewing and the new chipKIT Max32 board and comparing performance to the Arduino Mega 2560, so I downloaded the modified Arduino environment and downloaded the blink demo to the board. Everything seemed to be OK, but there was no blinking light. This is pretty much the simplest program on the Arduino and all it does is toggle digital pin 13 high and low with a two second period. Most Arduino boards have a LED on pin 13.

Time to debug. Probing around, starting at the socket for pin 13, I saw that the digital line was toggling, but I was getting no LED action. Let's take a look at the chipKIT schematic. Here is the LED driver on the chipKIT. They use a transistor to drive the LED instead of driving it directly as on the Arduino.

The chipKIT LED driver for pin 13. They don't load down the I/O pin. Nice.

OK, so let's see what's going on over at the LED driver.

Q2! Where are you?

What a bummer. Q2 is missing! I sent a note off to Digilent's tech support and got a response in just a few minutes. I'm hoping that this is a one-off mistake and that they aren't saddled with hundreds of bad boards. Did somebody forget to load a reel? I wonder who is making the boards for Digilent.

Anyhow, how about some benchmark action?

Let's look at the time required to invert a 5x5 single-precision floating point matrix. The time for an Arduino Mega 2560 is 3.2 ms while the chipKIT only takes 260 us. That's a speed up factor of 12.3. Not too shabby.

My intention for the chipKIT board is to upgrade Tobor's brain for next year's Sparkfun AVC with minimal effort. I can drop a Tobor shield onto the chipKIT, keep all of the Tobor code unmodified, and add a ton of processing headroom. That's the theory, at least. Not all of the Arduino libraries are working on the chipKIT. Currently, (I think) I2C, interrupts, and servo need work.

Lock-in Amplifier

2011-07-08T22:15:00.000-07:00

I'm a big fan of lock-in amplifiers; I'm always scanning eBay for a good deal. Recently I got a pair of EG&G 5207 lock-ins. Both were busted. One seemed to have ended up in the auction chain due to some bad buttons and the other one booted up with error messages. I bought both cheap and was able to Frankenstein a working unit of of the two of them. The main issue was the sticky buttons on the good unit causing the control computer to be unresponsive. That was the unit I saved. All I had to do to get it working was to swap in the good switch array board from the unit with the bad computer. Lots of screws and standoffs, but it wasn't too bad.

Here's the organ donor:

I might be able to get this one working too. I'll have to fiddle with the CPU card on the far left.

The organ donor had cards in it for two frequency ranges: 0-20 kHz and 0-100kHz. I pulled the broadband card and put it into the working unit. Even better, the local reference oscillator card from the donor was moved over to the new unit too. So now I have nice single phase lock-in with two front ends optimized for audio and 0-100kHz inputs. I've got almost all of the available options in the good unit now.

How well does it work? I'm feeding a 90 kHz 1V peak-to-peak sine wave into the lock-in reference and signal inputs. The correct RMS voltage is 0.354 V. It's not too far off for a 24 year old instrument that I saved from from the junk pile. I haven't tested the GPIB or RS232 interfaces, but I bet they work too. I'm not sure how to calibrate the thing, and I'm not even sure I want to try. A few percent absolute accuracy is fine and I'll mostly be doing relative measurements anyhow.

All that's left to do is clean the front panel.

Plans? Well, I'm going to try building a phase-switched radio interferometer so I can do some radio astronomy.

I'm at Maker Faire!

2011-05-21T13:54:00.000-07:00

Come by and see me!

Tiny Color Organ

2011-05-03T15:09:00.000-07:00

I'm working on some wearable, tiny color organ controllers for Maker Faire. Here's a prototype.

An Arduino Mini Shield color organ driver

Not bad for toner transfer. I did have to brutalize some of the board to fix some shorts. 12 mils is pushing iron-on technology.

Sparkfun AVC 2011 Report

2011-04-30T13:21:00.000-07:00

First of all I want to thank Sparkfun, the competitors, and all the spectators for making the day so much fun.

Tobor after the 2011 AVC. The Xbee got ripped off in the mass start.

I had gone to Sparkfun a few times in the weeks before the 2011 AVC trying to get Tobor back into racing trim and I had zero luck each time. The weather was downright chilly every time I went to test and that just added to my misery. In fact, Tobor had only made it around the course twice before. Once on the morning of the 2010 AVC and once during the AVC with the 2010 winning time of 1:55. I also had big hopes of adding five Maxbotix sonar range finders, but they reported all sorts of nonsense readings while I was at Sparkfun. Even when I pointed the sensors into the sky, I got readings of about fifty inches. I never figure that one out. In addition, one of the sensors decided to start emitting magic smoke for no reason during a test. That one is going back to Maxbotix for some forensic analysis. Of course, the Maxbotix sensors always seemed to worked great at home.

The night before the AVC I was there with a few other competitors in the SFE parking lot, including team AutoCrusher, but I just could not get Tobor to successfully complete a lap. During my best attempt, I got around three sides only to veer into the curb just before turn four, but that's when I notices that the green LED that indicates GPS lock went out. I also had some telemetry data from another run (Tobor logs run data onto a micro SD card as well as broadcasts the same data back to the laptop via a XBee) that indicated my GPS horizontal accuracy was rapidly increasing to several km! Clearly something was up with the GPS.

I went home in the dark very frustrated an even joked with Sarah that I wasn't even going to show up for the AVC on Saturday. I sat on the couch, had a few beers, and pondered the situation. On AVC day I got up at 5am, took a look at the snow falling outside, and went to the kitchen table to fiddle with Tobor for a few hours before the race. Sitting on the table I got a GPS lock in about 30 seconds, but if I touched or tapped the GPS unit, I lost lock. Ah ha! Then I took a look at the GPS connection to the DIY drones breakout board: the female connector on the uBlox GPS was pretty green from corrosion (it looks like the flux wasn't cleaned well) and it was clear that the connection between the GPS and breakout board was very flakey. I sprayed both connectors with flux cleaner and gave them a good scrubbing with a horse hair brush. Then I reassembled the GPS and breakout board and put a few drops of hot glue in between the boards. Now, when I tapped, tugged, or generally abused the GPS unit I kept lock. I was back in the game!

The hot glue GPS fix. The ublox connectors aren't robust at all. Last year, I just wrapped the whole assembly with a rubber band.

At the 2010 AVC, I had a run where the car "diverged" and went in circles. I assumed this behavior was due to some sort of interference from the wet pavement and the IR curb sensors, but it must have been the dodgy GPS connection. I saw similar behavior the night before at SFE.

Feeling a bit better about my chances, I woke Sarah up, took a shower, packed, and then we got coffee and headed down the hill to Sparkfun. There was about 2 inches of snow at our place by this point. I was almost hoping for snow at Sparkfun. Those sand tires might work well on the snow.

We got to Sparkfun early and I was able to get Tobor out for a test run. He almost made it around the building, but I had to pause my test run due to some folks on the course. Tobor’s overall performance was much improved, so I tweaked the waypoints and called it good. At this point, I still had not made it around the building fully autonomously. I left the bracket for the Maxbotix sensors on Tobor, but they weren't even hooked up. Intimidation purposes only.

I also had to poke some holes into the rear tires since the pressure and temperature change from Nederland to Boulder had actually caused the rear tires to buckle inward. I had hoped to do a recalibration on the odometry, but I had to let it slide.

Heat 1

I had set Tobor to have a constant throttle setting for heat run and the setting was just a bit faster than the setting I had used in Heat 1 in 2010. Things went well and I almost made it through the hoop, but the cow catcher hit on the left side of the car and I scraped by on the right side of the hoop. I got around in 1:22, but the last segment of the course was a bit too far north and Tobor charged the finish line by driving right through the crowd in front of the stands. If you look on the video you can see the cow catcher bouncing off of some poor spectators ankle. I thought I was in first place, and was confused later when I saw that Minuteman was actually in first. I never saw him pass me. I had to read Nathan’s blog entry on DIY Drones to find out that Minuteman was stepped on during heat one and he got a do-over because of judge interference.

Heat 2

I bumped the speed up significantly at the start and finish of the course, and only slightly for the portions of the course between turns one and four. I also moved waypoint #2 (the one right after the hoop) one meter to the East and waypoint #4 south a bit to keep Tobor out of the crowd on the home stretch. This run went well (I don’t know my actual time), but I missed the hoop again. This time on the East side by just a few inches.

After heat two I noticed that the Sparkfun judges had awarded me the 30 second deduction for going through the hoop. I was running, so I didn’t see what happened, but my family told me that Tobor had, in fact, gone wide to the East. I told the judges about their error and they joked about an additional 20 second deduction for honesty.

Heat 3

I knew that Minuteman’s time was going to be hard to beat, so for heat three I increased the throttle command to maximum. I had never run Tobor this fast before, but the navigation system seemed to be working amazingly well. I even took off the inert Maxbotix gear to cut down on drag! On run two, I don’t think the curb avoidance system had to do much work at all. I also moved the waypoint #2 half a meter back to the East. I figured that I would get the hoop bonus by successive approximations.

During the wait for run three, I was kicking myself for not installing the bigger motor. The Tamiya Grasshopper comes standard with a Mabuchi 380 motor. This motor was great for getting a longer run time back in the day when RC cars ran NiCd batteries since the 380 draw a lot less current that the standard 540 motor. Nowadays, folks run brushless motors, so Tobor is at a huge disadvantage when it comes to maximum possible speeds.

Here's my speed boost for next year. It's not even one of the "race-tuned" models.

There was nothing I could do except cross my fingers and wait. Heat 3 came and started out great. Minuteman was running faster than Tobor, but he missed the hoop and Tobor made it through. The rest of Tobor’s run was flawless. Minuteman clipped one of the concrete islands and didn’t complete the heat.

I couldn’t believe it, but Tobor beat Minuteman’s time by only one second. You couldn't script better drama!

Tech

Here's the under-the-hood shot of the rat's nest. The Arduino Mini monitors channel three on the RC so I can switch to manual control if the Arduino Mega crashes. The openlog stores all the sensor and state data. The gyro is buried under the Mega and the magnetometer is up front away from the steering servo. Two regulators generate the extra current needed for the Sharp IR sensors and GPS. It's all wired up with wire-wrap and point to point.

This year the curb avoidance system was greatly improved by replacing the three long distance Sharp GP2Y0A700K IR sensors with the more reasonable Sharp GP2Y0A02YK0F IR sensors. The IR sensor from last year had a minimum distance that was just too large and Tobor could end up in an oddball nonlinear limit cycle near curbs. It sort-of worked, but was very suboptimal. I also changed their angle so they looked ahead quite a bit more. I also removed the third straight-ahead looking sensor, since I never came up with a good heuristic to integrate that reading with the other two. In addition, I replaced the old curb avoidance scheme which just fed the range sensor readings into the steering servo with a first order low-pass filter set to a time constant that was about equal to the left-right transit time of the steering servo. This really smoothed out the curb avoidance and rejected sensor noise pretty well. I also added a removable pot bank to the car so that I could adjust system gains without reprogramming Tobor. Unfortunately, I had such poor luck testing, this was never really used. That cow catcher I added seemed to be a good idea. It prevents the car from catching a tire on an obstacle and at high speeds, and curb scrapes are recoverable.

The navigation system in Tobor 2011 is the same one I used in 2010. I think that flaky GPS connection was the root of all of my problems and Tobor could have gone three for three in 2010 had I fixed it then. I didn’t even change any of the numbers in the noise covariance matrices!

Here's the state vector for Tobor. This gets updated at 20 Hz.

Tobor runs a six state Extended Kalman Filter at 20 Hz. The sensors either provide four or six measurements depending on if new GPS data is available. Since the ublox GPS runs at 4 Hz, most of the update only fuse dual wheel odometry (two numbers), the gyro (one number), and the magnetometer (one number). Every fifth update uses a bigger H (observer) matrix and GPS gets fused in. That observation has six elements. The EKF uses single precision floating point arithmetic and there are no optimizations. It’s a textbook implementation and I do a matrix inverse 20 times a second. I use the reported horizontal accuracy from the GPS in order to form the GPS covariance. That way is the GPS accuracy degrades, the sensor fusion is still “optimal.” Surprisingly, the time to do the data logging is a significant portion of the loop time. The serial.print() function on the Arduino is pretty slow and I output human readable data. A binary format would free up some processing time to add more states. The Arduino Mega is required for the extra serial port and the RAM to hold the big matrices.

Wheel encoder details. The encoder wheels are laser printed and glued to thin model airplane plywood. They've lasted through two wet AVCs! The sensors are the analog Pololu models and I square-up the signal with a Schmidt trigger. There is no provision for going backwards. If you have to back up, you've already lost.

I’ve got an identical EKF implemented in Matlab and Tobor logs all the sensor data as well as the state output of the EKF running on the Arduino. As a result, I can re-run any course offline and tune the filter and sensor calibration. For example, driving the car open loop around a known course and stopping exactly where the car started generates sensor data that I can feed through the Matlab copy of the EKF. Running the EKF with GPS turned off allows me to run a second optimizer that adjusts the calibration factors on the wheels (left diameter, right diameter, and separation) in order to minimize an accuracy metric that measured the difference between the start and end points. Last year, the data showed that the rotation angle from the differential odometry was good, but not great. The fusion of gyro data and odometry, however, was pretty impressive. I never spent any significant effort on using just odometry for distance and the gyro for angle. This approach, however, is basically what Minuteman is did. Tobor also fuses a magnetometer into the state estimate, but I’ve got the sensor noise covariance turned way up so local variation in the magnetometer reading don’t affect that state too much, but over longish times, the magnetometer and GPS track give Tobor an accurate estimate of heading.

Before each run I reboot Tobor and drive in a few circles. I’ve got an adaptive calibration running on the magnetometer and it takes about four circles to get a good calibration. I also drive in a straight line for about ten meters in order to get a GPS track to fuse into the heading. By this point, the EKF state has converged to a good estimate of location and position.

Another key point is that the Tobor state vector is augmented with a gyro bias term. Temperature calibrations can work, but they are just the wrong way to approach the problem. Tobor has plenty of other sensors that give information about angular rate, so you just let the EKF generate an optimal estimate of the gyro bias term as well.

Once you have a good state vector, control is easy. The steering servo is driven by a proportional control term that is given by the difference between the vehicle heading angle and the computed heading to the next waypoint based upon the cars estimated position. There isn’t a need for more complicated control since the steering servo angle sets heading rate and that gets integrated by the car kinematics to give heading angle. Once the state vector says Tobor is withing a certain distance of the waypoint, the waypoint index is incremented. The waypoints on Tobor wrap around, so the car should, in theory, keep going around the course until the batteries die.

Throttle is open loop. There is no need for fancy PID speed control since Tobor had to run at full throttle anyway just to be competitive this year. The only reason to add an I term is to get the steady state error down, but this doesn't matter since the speed control on these bots isn’t calibrated. You only need D if you can’t get a good enough response time with K alone. Throttle control is just step on the gas.

Some numbers

Tobor's best time was 55 seconds and Minuteman was only a second behind. Working from my waypoints, the distance around the course is about 270 meters and based on our times Minuteman and Tobor were both doing almost 11 MPH on their best runs.

Since Minuteman runs in a dead reckoning mode, the starting angle is very important. Each miliRadian of error in its starting alignment results in about a foot of error over the course. That’s a foot of error for every 0.06 deg. Not to bad, but alignment is definitely important.

Finally, the winning speeds this year were about 1.2 m/s, so you only get a GPS update every 30 cm. That's not so bad, but you need odometry to fill in the blanks. Odometry is very accurate over small distances, but errors grow with time. GPS is bad over short distances, but long time averages are great. Synergy.

I’ll be going through the data logs from the runs and posting tracks soon.

Digital Color Organ Update

2011-04-28T21:02:00.000-07:00

Here's a quick video showing off the new color organ. Come see it (and me) at the Bay Area Maker Faire!

Sparkfun AVC 2011 Video

2011-04-26T00:03:00.000-07:00

I'll post a wrap up on the 2011 AVC soon, but here's a quick video I made from the footage we gathered.

The mass start is epic. I'm hoping that Sparkfun has better footage of Tobor threading the needle. I lost track of how many flipped bots there were in the first few seconds.

Low Pass Filter

2011-04-18T20:10:00.000-07:00

So my obstacle avoidance last year was a total last minute hack. This year, I left things to the last minute again, but I still have time to replace a major hack with something that's at least reasonable. The jittery steering when obstacle avoidance is turned on is due to the fact that I'm feeding the scaled sensor values directly into a steering offset. Noise in the sensors ends up as noise on the steering servos. And the sensors are pretty noisy.

I've implemented a simple first order system to smooth out the obstacle avoidance error signals and it seems to work well. The other thing I'm adding is a bank of pots on the outside of the car. I'm going to use them to adjust some of the system gains so I can run the car, stop it, turn a knob, and re-run the car. I'm hoping that this will increase my iteration rate so I can dial in on a collection of gains that work. Once I have it working, I'll take the pot values and hard code them into the car. The more system tuning I can do without re-compiling, the better.

Time for bed.

Sunday AVC Trouble

2011-04-18T13:08:00.000-07:00

Sarah and I drove down to SFE HQ on Sunday afternoon. I was hoping to spend most of my time optimizing the new obstacle avoidance system that uses three Maxbotix LV-EZ4 sensors along with the Sharp IR range finders from last year. Unfortunately, the trouble started as soon as we got there.

First off, my Mac didn't go to sleep when I put it in my bag for the trip down the hill, so it was toasty hot when I pulled it out. I gave it a reboot and it seems to be fine.

Then I started putting the lid back on the bot and loaded up some test code. I smelled burning electronics and sure enough, there was a tendril of smoke rising from one of the Maxbotix sensors. I cut power and checked everything. Nothing seemed wrong so I replaced that unit with a spare and everything seemed to work.

That component just above the ROHS label got pretty hot. As a bonus, you get to see the ultrasonic transducer. I'm guessing that the little dish on top of the piezo element sets the beam width.

When I got home I shot an email off to Maxbotix and they are going to do a replacement for me and try and figure out what caused the problem. So far they have no idea about what would cause things to fry like that. Quick response!

Anyhow, I started off with an attempt to repeat last years run using the same code, parameters, and waypoints. I might have made it around the building if all the cars were gone, but it was not an impressive test. Turing on the sonar system just resulted in jittery steering.

Finally, I gave up and decided to do an open loop drive around the course. One lap hugged the inside and the next lap followed the outside edge of the clear course. Here's what the output of the Kalman filter looks like.

Position estimates form the car's Kalman filter. Red dots indicate locations where the car velocity was zero.

I stopped at each course corner, places where curbs stick out, and the two lamp posts (near the lake and turn #1 and the one in the northeast corner of the parking lot). From the size of the red blobs, you can get an idea of my Kalman filter performance (or lack, thereof). I think it could use a lot of improvement. Take a look at the track on the right side of the graph: the inside track crosses over the outside track!

I'll have to go back and do a few more runs where I log the sensor data as well as the estimator state output. I think I can improve things.

Finally, there were quite a few other teams there testing. Nobody had much time to chat because we were all too busy chasing bugs. I'm looking forward to trading stories at the Dark Horse after the AVC.

A New Color Organ

2011-04-13T20:24:00.000-07:00

Just a teaser. I got some junk color organs on eBay and I used one of the cases to hold a string of 36 RGB LEDs in a 6x6 array.

It looks pretty good. I'll be taking this one to Maker Faire too!

Sonar Interference

2011-04-12T16:48:00.000-07:00

In my last post, I showed the basic layout of my five new sonar sensors. I was hoping that I could run the three middle sensors sequentially, and ping the two side sensor simultaneously, but I was seeing a periodic error in the sensors that I'm assuming was due to beating between the two banks. I'm going to take a step back and only run the three middle sensors for now.

In order to avoid any interference, they need to run sequentially, so I get an update rate of 20/3 Hz. That's not great since my main steering loop runs at 20 Hz. We'll have to see how well it works.

Obstacle Avoidance

2011-04-10T20:05:00.000-07:00

I've been way (way!) too busy lately, so as usual I'm leaving things to the last minute. Here's an update on my Sparkfun AVC 2011 plans.

I'm entering the same car as last year, but with some upgrades. On the steering front, I'm going to spend some more time tweaking my navigation system. Last year, I got a six state extended Kalman filter up and running on an Arduino Mega and it worked great. I fused gyro, magnetometer, differential odometry, and GPS. Having multiple sensors, with different error behavior, telling you the same thing is key. Odometry is very good for short distance, GPS is good for big distances. The gyro beats the magnetometer over short time scales, but the magnetometer along with the GPS and differential odometry cancel gyro drift.

This year, I'm keeping the same code, but I'm doing more testing and tuning.

I may also switch to non-paddle tires to improve the odometry, but I love sand tires. I'm also worried that the trip from Ned (8500 feet ASL) to Sparkfun (~5500 feet ASL) may mess up my odometry calibration because the tire pressure will change. I'll have to check that and do a quick cal on race day.

As far as obstacle avoidance goes, that's where I'm investing most of my time. Last year, the rain seemed to mess up the effective ness of my three IR range sensors. I'm not sure why (glare? specular reflections?), but the only heat where I made it all the way around the building was the first, dry attempt. One other attempt went very haywire due to IR sensor problems and one heat where I upped the speed (and added some last-minute cardboard blinders) hit a a curb head on. Just a foot to the right would have resulted in a much faster completion time.

So this year I'm adding five Maxbotix ultrasonic range sensors. The three center sensors are intended for barrel avoidance as well as preventing head-on collisions. The two side sensors will keep me centered in the course.

Top view of the current sonar arrangement. Angles are currently set by intuition. I'll eventually set them to just overlap the beams at my (to be determined) obstacle-keep-away distance.

Front view. Angles and locations will change.

Field testing starts tomorrow. I'm going to take new waypoint measurements at Sparkfun. Last year I was nudging that third waypoint around to avoid that curb. I'm also going to add more waypoints on the day of the race to optimize my course given the obstacle locations.

Finally, I've got business travel right before the race day. Same as last year.

Vintage Heathkit Multimeter

2011-04-07T17:28:00.001-07:00

I found this Heathkit multimeter with Nixie tubes at JB Saunders the other day and it still works after 38 years!

Bug collection

2011-03-22T20:45:00.000-07:00

I found my high school bug collection the other day. Actually, I found what was left of it. 27 years old!

My dad made the box for me. Oak!

I broke a leg off this bug so I had to carve a fake one out of a toothpick. A little black Testors paint and that bug was museum quality! The prosthesis must have broken off.

555 Contest entry: The Sleep Stopper

2011-02-28T15:34:00.000-08:00

Here's my entry in the 555 design contest. I wanted to make a very minimal circuit for the contest and only use stuff I had laying around. This is what I came up with.

After being in the dark for a few minutes, the piezo buzzer starts up and emits a really irritating tone, but it turns off almost as soon as light hits it. Hide this in a lamp or light fixture before somebody goes to bed!

Here's a video description:

I originally built this circuit on a breadboard, but wanted something nicer for the contest (and easier to hide) so I made a quick toner transfer PCB. Not my best work: the ground plane is broken into two pieces, hence the black jumper.

Yeah, the cap is big.

When I added my name on the board, I broke the ground plane into two parts.

How it works:

R1, R2, and C3 and the 555 form an astable multivibrator that drives the piezo buzzer (I used JP2 for the footprint to save time). Basically C3 chargers through R1 and R2, but once the voltage gets to about 2/3 Vin, the flop flop in the circuit is reset and that discharges C3 through R2. Once the voltage drops to about 1/3 Vin, the flip flop is set and the cap starts charging again.

Meanwhile, pin 4 on a 555 is a master reset pin and pulling it low will hold the flip flop low. So it needs to be high for the circuit to oscillate. C1 is the big electrolytic cap (2200 uF). It charges slowly through the voltage divider formed by R3 (20 Meg in my example) and the CdS cell (about 1-2 Meg in the dark). Once C1 charges to about 0.6 V, the buzzer starts. It needs to be dark for this to happen. When light hits the CdS cell, the resistance drops to about 100K so C1 rapidly discharges and turns the buzzer off.

So long as Vin X R5/(R3+R5) > 0.6 the circuit will work as described. Increase R3 and make C1 bigger for a longer turn-on delay. Ideally, you want somebody to go to sleep before the buzzer turns on.

A lot of circuits you find online use pin 4 to make a light or dark activated buzzer, but I could not find any existing circuits that use this configuration to generate different turn on and turn off time constants.

Here is the schematic in Eagle. I'm not a fan of the 555 part layout in the library.

Hot Water + Cold Air

2011-02-01T17:35:00.000-08:00

It got down to -20F last night, but it was only -8F at lunch when I made these videos. Not much wind, so it was actually pleasant in the sun.

Drill Bits!

2011-01-25T09:00:00.000-08:00

I've gotten into making my own PCBs so I had to get some drill bits. The folks over at drill bit city are really nice and I picked up a good assortment of new and used (cheap!) carbide bits. I even got some router bits just in case I want to get into CNC PCB manufacture.

I expect to break a lot of bits.

Maybe I should have made an unboxing video?

What you get in the PCB starter kit.

Hover Power

2011-01-24T13:52:00.000-08:00

The Sparkfun AVC 2011 is coming up and this year I might enter a hovering robot. Quad rotors are all the rage now, but I'm not into high disc loadings. So I'm thinking about entering a robot that hovers on one rotor and uses control vanes to cancel the rotor torque and maneuver. This configuration is unstable, so I'll have to close a few control loops. Once you get a stable platform, the navigation is simple: You just pick waypoints far enough away from the Sparkfun building and a do carrot and stick control law. Simple.

Anyhow, how much power does it take to hover? Momentum disc theory to the rescue. The result is (derive it yourself. It's easy!)

T is thrust, rho is the density of air, and A is the rotor area.

Here are some curves for 1 kg and 0.5 kg vehicle.

I'll double these numbers and pick a motor. It looks like a 300 W motor and prop bigger than 8 inches will do the job. Something like this motor fits the bill nicely. Notice that the motor is rated for 333 W and 3D aircraft up to 2 lbs. That's consistent with my numbers.

LaTeX and Blogger

2011-01-22T17:00:00.000-08:00

After a few minutes of searching around, I found a quick way to get LaTeX onto this blog. Although, it seems like Wordpress is the way to go if I want to get serious.

Here's a preview: $P_{hover} = \sqrt{\frac{T^3}{2 \rho A}}$

Crap! That script uses MathML and that doesn't work with Safari. Back to the drawing board.

Arduino Color Organ Shield

2011-01-14T20:25:00.000-08:00

I've finished my new Ardunio Color Organ shield and it works great. The PCB fab was pretty easy for my second try at toner transfer.

Here's the finished product:

I had no 200k resistors handy.

No soldermask means it's ugly and the prototyping area vias only show up on the bottom.

Quick and dirty, but it's better than a breadboard.

It's a lot sturdier than the breadboard version:

I'm probably going to get some nice PCBs made. Let me know if you're interested in a kit!

Holiday Creations Xmas Light Guts

2011-01-13T15:48:00.000-08:00

Here are some photos of the innerds. I'm not sure how much help they'll be.

Very handy labels.

Five LEDs!

All the action happens under that potted blob.

More Holiday Hacking

2011-01-12T18:48:00.000-08:00

McGuckin Hardware had Christmas lights on closeout the other day and I picked up five boxes of these lights for $2.50 each! They seem pretty similar to the GE lights, but I don't have the controller. These are just extension strands.

Here's what I've learned:

1. The ribbed wire on these lights is POSITIVE unlike the GE strands where the ribbed wire is negative.

2. Hooking the strand up backwards draws upwards of 2 Amps.

3. They don't respond to the same protocol as the GE lights. I get some random flickering, but no joy.

Does anyone have a controller for these lights or more information? If I had a controller I could snoop the lines with a logic analyzer. The protocol has to be somewhat similar the one used by the GE lights. Contact me!

Controlling GE Color Effects lights with the Ardunio

2010-12-06T16:41:00.000-08:00

Here's the code. Power up the lights first and then the Arduino so that the lights get enumerated properly.

The ground wire (has ridges) from the strand is connected to GND on the Arduino and and the center wire is connected to digital output 4.

Enjoy

 // GE Christmas light control for Arduino  
 // Ported by Scott Harris <scottrharris@gmail.com>  
 // scottrharris.blogspot.com  
   
   
 // Based on this code:  
   
 /*!     Christmas Light Control  
 **     By Robert Quattlebaum <darco@deepdarc.com>  
 **     Released November 27th, 2010  
 **  
 **     For more information,  
 **     see <http://www.deepdarc.com/2010/11/27/hacking-christmas-lights/>.
 **  
 **     Originally intended for the ATTiny13, but should  
 **     be easily portable to other microcontrollers.  
 */  
   
 #define xmas_color_t uint16_t // typedefs can cause trouble in the Arduino environment  
   
 // Eliminate the .h file  
   
 #define XMAS_LIGHT_COUNT          (36) //I only have a 36 light strand. Should be 50 or 36  
 #define XMAS_CHANNEL_MAX          (0xF)  
 #define XMAS_DEFAULT_INTENSITY     (0xCC)  
 #define XMAS_HUE_MAX               ((XMAS_CHANNEL_MAX+1)*6-1)  
 #define XMAS_COLOR(r,g,b)     ((r)+((g)<<4)+((b)<<8))  
 #define XMAS_COLOR_WHITE     XMAS_COLOR(XMAS_CHANNEL_MAX,XMAS_CHANNEL_MAX,XMAS_CHANNEL_MAX)  
 #define XMAS_COLOR_BLACK     XMAS_COLOR(0,0,0)  
 #define XMAS_COLOR_RED          XMAS_COLOR(XMAS_CHANNEL_MAX,0,0)  
 #define XMAS_COLOR_GREEN     XMAS_COLOR(0,XMAS_CHANNEL_MAX,0)  
 #define XMAS_COLOR_BLUE          XMAS_COLOR(0,0,XMAS_CHANNEL_MAX)  
 #define XMAS_COLOR_CYAN          XMAS_COLOR(0,XMAS_CHANNEL_MAX,XMAS_CHANNEL_MAX)  
 #define XMAS_COLOR_MAGENTA     XMAS_COLOR(XMAS_CHANNEL_MAX,0,XMAS_CHANNEL_MAX)  
 #define XMAS_COLOR_YELLOW     XMAS_COLOR(XMAS_CHANNEL_MAX,XMAS_CHANNEL_MAX,0)  
   
 // Pin setup  
 #define XMASPIN 4 // I drive the LED strand from pin #4  
 #define STATUSPIN 13 // The LED  
   
 // The delays in the begin, one, and zero functions look funny, but they give the correct  
 // pulse durations when checked with a logic analyzer. Tested on an Arduino Uno.  
   
 void xmas_begin()  
 {  
  digitalWrite(XMASPIN,1);  
  delayMicroseconds(7); //The pulse should be 10 uS long, but I had to hand tune the delays. They work for me  
  digitalWrite(XMASPIN,0);   
 }  
   
 void xmas_one()  
 {  
  digitalWrite(XMASPIN,0);  
  delayMicroseconds(11); //This results in a 20 uS long low  
  digitalWrite(XMASPIN,1);  
  delayMicroseconds(7);   
  digitalWrite(XMASPIN,0);  
 }  
   
 void xmas_zero()  
 {  
  digitalWrite(XMASPIN,0);  
  delayMicroseconds(2);   
  digitalWrite(XMASPIN,1);  
  delayMicroseconds(20-3);   
  digitalWrite(XMASPIN,0);  
 }  
   
 void xmas_end()  
 {  
  digitalWrite(XMASPIN,0);  
  delayMicroseconds(40); // Can be made shorter  
 }  
   
   
 // The rest of Robert's code is basically unchanged  
   
 void xmas_fill_color(uint8_t begin,uint8_t count,uint8_t intensity,xmas_color_t color)  
 {  
      while(count--)  
      {  
           xmas_set_color(begin++,intensity,color);  
      }  
 }  
   
 void xmas_fill_color_same(uint8_t begin,uint8_t count,uint8_t intensity,xmas_color_t color)  
 {  
      while(count--)  
      {  
           xmas_set_color(0,intensity,color);  
      }  
 }  
   
   
 void xmas_set_color(uint8_t led,uint8_t intensity,xmas_color_t color) {  
      uint8_t i;  
      xmas_begin();  
      for(i=6;i;i--,(led<<=1))  
           if(led&(1<<5))  
                xmas_one();  
           else  
                xmas_zero();  
      for(i=8;i;i--,(intensity<<=1))  
           if(intensity&(1<<7))  
                xmas_one();  
           else  
                xmas_zero();  
      for(i=12;i;i--,(color<<=1))  
           if(color&(1<<11))  
                xmas_one();  
           else  
                xmas_zero();  
      xmas_end();  
 }  
   
   
 xmas_color_t  
 xmas_color(uint8_t r,uint8_t g,uint8_t b) {  
      return XMAS_COLOR(r,g,b);  
 }  
   
 xmas_color_t  
 xmas_color_hue(uint8_t h) {  
      switch(h>>4) {  
           case 0:     h-=0; return xmas_color(h,XMAS_CHANNEL_MAX,0);  
           case 1:     h-=16; return xmas_color(XMAS_CHANNEL_MAX,(XMAS_CHANNEL_MAX-h),0);  
           case 2:     h-=32; return xmas_color(XMAS_CHANNEL_MAX,0,h);  
           case 3:     h-=48; return xmas_color((XMAS_CHANNEL_MAX-h),0,XMAS_CHANNEL_MAX);  
           case 4:     h-=64; return xmas_color(0,h,XMAS_CHANNEL_MAX);  
           case 5:     h-=80; return xmas_color(0,XMAS_CHANNEL_MAX,(XMAS_CHANNEL_MAX-h));  
      }  
 }  
   
   
   
 void setup()  
 {  
  pinMode(XMASPIN, OUTPUT);  
  pinMode(STATUSPIN, OUTPUT);  
  xmas_fill_color(0,XMAS_LIGHT_COUNT,XMAS_DEFAULT_INTENSITY,XMAS_COLOR_BLACK); //Enumerate all the lights  
  xmas_fill_color(0,XMAS_LIGHT_COUNT,XMAS_DEFAULT_INTENSITY,XMAS_COLOR_BLUE); //Make them all blue  
 }  
 
   
 void loop()  
 {  
  digitalWrite(STATUSPIN,1);  
  xmas_fill_color(0,XMAS_LIGHT_COUNT,XMAS_DEFAULT_INTENSITY,XMAS_COLOR_RED);  
  delay(100);  
  digitalWrite(STATUSPIN,0);  
  xmas_fill_color(0,XMAS_LIGHT_COUNT,XMAS_DEFAULT_INTENSITY,XMAS_COLOR_BLUE);  
  delay(100);  
 }