The winds looked good this morning, so I headed out hoping for fair winds. The winds were a little light when I got out to the NAS, so I stopped by the Naval Air Museum and dropped off a print of the attached photo. I toured around the museum for about an hour after that– it’s a great place full of really neat stuff and photos. Docents are super nice and incredibly knowledgeable about the base and their military history.

After that, went out to see if the winds were good. The wind was just high enough to get the kite in the air, but it kept dropping out every few minutes to just about nothing. The wind starting coming up a little, but I decided to give it a few minutes. After a quick trip to a coffee shop, the wind was waaay up. Like 15mph with gusts to 20mph. The kite I’m flying — building a higher wind kite soonish — has a top end around 15mph. I tried to trim it up for the higher winds, but it was just too unstable. Probably could have continued tweaking it, but decided to just call it a day.

Turned out to be a good decision, since the winds just kept building. Tomorrow is lighter winds, but a chance of rain. My best bet looks to be around sunrise, so we’ll see what we can do.

Having good weather data turns out to be a really important part of planning a KAP outing. You need steady winds, at the right rate. Here in the Bay Area, we have microclimates galore, so while it may be windy at the airport, it might not be windy where you’re going.The Real-Time SF Wind Models work wonders. However, they’re updated 45-55 minutes after the time they are modeling. This is good if you’re heading out right now. I really like intellicast for it’s forecasting, but I’ve been wishing for more data than tomorrow’s “Winds W at 5 to 10 mph.”

So poking around the NOAA’s weather website I came across the point forecasts. Point forecasts let you place a marker in a particular location, and it’ll give you the weather forecast for that location. This is cool, however even cooler is the forecast graphs. These give you 96 hours of forecast data, and only the data you want. For instance, I really want to see temperature, wind, sky cover, and precipitation potential for Alameda Point. Well, that’s this link. Cool, eh? Includes gusts as a separate line above the winds, so you can have a pretty good idea if you’re facing steady 14mph winds, or 14-18mph gusts. Flag indicates the direction the wind is coming from, north is the top of your screen.

Clearly someone at NWS has been reading Tufte.

Looking through last weekend’s photos, I discovered something funny– the shutter never worked while the camera was pointing to my left.  The pan/tilt response was slow, but there were no shots in that direction.  The culprit, I think, is antenna placement.  The antenna is located in that blue box there, and if you look at the post immediately previous to this, you’ll see that box sitting on the left side of the rig.  If the camera is pointed to my left, the camera, frame, and the circuit board are all between me and the rig.  If I were reasonably close to the rig, that wouldn’t be a problem, but out near the limit of the rig’s range, it starts to be a problem.

So, this is my initial thought on how to solve this problem.  A little adjustment to the velcro, and it’ll be just peachy, with the antenna pointing downwards.  This means if I’m directly below the rig I won’t get good reception, but anywhere else I should be okay.  Heading out tomorrow morning (no wind predicted) to check this theory and do an actual range test.

I’ve finally finished the work to be able to convert my rig between an 800g film camera that’s electronically triggered and a 150g digital camera that’s servo triggered. Total weights on the rigs are 1250g for the film and 650g for the digital.

Okay, probably not the *final* bits — but I recieved the last couple parts I was waiting on for the KAP rig.  The radios I had been using (Xbee Series 2) were a little cumbersome, mainly because they required a PAN coordinator.  Super cool if you were doing a mesh network of sensors or robots or other things like that, not as useful for the point-to-point network I was working on.  My fault, I didn’t read the spec sheets close enough.

I had started with the series2 mainly because they had an extra 20m of range on the series1, I think I’ll live as-is.  The biggest hurdle was that the firmware for the coordinator was a little different, and of course the radio that’s in need of being reflashed is the coordinator, and I don’t have the hardware setup to flash the xbee.  So I’m hanging on to these radios in the expectation that I will end up creating some sort of mesh network for some random project.  (Possibly a weather station on my house)

So I ordered a couple xbee series 1 radios, which showed up this morning via USPS, along with another linear regulator and a couple of dip switches.  The last bits are all hooked in, configured, and working.  The radios out of the box talk to each other, but it’s by using the default PAN ID and broadcasting.  I wanted a more restrictive setup, so I changed the PAN ID, upped the bitrate to 115200 and set the destination address to be the other radio’s serial number.  The other big thing with the xbee series 1 radios is that I can buy them from anyone.  The series 2 radios just hit the market, are only now in distribution (but only with the router firmware).

A handy command when setting up the radios for this sort of “real time” application is ATRO0 — this sets the packetization threshold to 0 bytes, so it sends out packets of single bytes instead of waiting until it has a few to send.

I also found that the reciever side doesn’t see bytes while it is taking a picture.  I think the bytes overflow the buffer or something during the various delay loops in the shutter() command.  The workaround?  Send out current mode and rotational stop commands periodically to make sure it doesn’t get stuck spinning around in circles.  This also has the feature of allowing there to be a “timeout” counter that will wait some amount of time (5 seconds, currently) to switch the rig into autokap mode if there isn’t a beacon signal from the controller.  This timeout is disabled when the rig is in film mode (dip switch 2 is on).

At long last I have the film rig pretty much complete. I’m awaiting fairer skies and one final part from Mouser before calling the project complete. I’ll be adding a removable shutter servo for the smaller digital camera I have, but I have an electric release for the film camera.

I have the code cleaned up to a point that I can share it. There’s schematics and board layouts in Eagle, too. I think my controllers are pretty special purpose to my particular ideas of how to do KAP. However, the code and concepts could be generally applied to anyone developing for these sorts of things. I would like to thank Tom Benedict for endless help, and the endlessly useful Orangutan Lib

N.b., that this code is not complete to the point that someone not already well versed in programming for AVRs could figure this out.

UPDATE: This code now works!  Timeout failover to autokap is turned off, but the autokap switch works.

Baud rate has been upped to 115200 from 9600 to fix an overflow problem.

And without further ado:

• Kiteside controller code
• Kiteside controller board
• Landside controller code
• Landside controller board
• Bill of Materials

You’ll need some more parts (like wire, solder, programming cable, etc.), but that’s the hardware. Feel free to drop me a line if you have questions.