If you don’t know already, I’m a big fan of Edward Tufte, who is an informational designer. One of his big tenets is the concept of “informational density” — basically the art of cramming as much data into a graph and keeping it readable. Graphics in USA Today are generally the opposite of this, but above is my example. The data that is important to be precise (wind speed and direction) is precise, the other data (humidity, temperature, air pressure) are on there, but normalized to the graph. They are more useful as a trend indicator and less useful in their specifics.

Above is about 12 hours of data. The red dots indicate the instantaneous wind speed reading, the grey filled line is the average wind speed at the reading, the grey dots are the wind direction. Cyan line is pressure, blue line is humidity. Black line with cyan fill is air temperature.

The upper graph includes no smoothing (just the data from Weatherbug) — the lower graph I’ve smoothed the average wind speed to make it less spikey and the temperature and pressure lines to make them less steppy. I’ve kept the direction info and the instantaneous wind speed unsmoothed since they carry more real information.

(Weather data powered by WeatherBug, via their API access.)

and

This is the beginnings of the summer wind season in the Bay Area, which means you can generally select when you want to go KAPping, as long as it’s in the afternoon, and you will probably have good wind. The first graph shows the wind & gust data for three days. In the afternoons, typical gusts are about 2-3 kts, while the max gust was 5kts from a pretty breezy 15kts anyway. You’ll notice the wind picks up and settles into a westerly direction a little after lunch, then stays that way until after sunset.

This effect is shown incredibly strongly correlated in the second graph– while the minutiae of the wind speeds in the morning and even in the afternoon vary significantly day to day, the wind is always strong enough for KAPping, and the direction is incredibly consistent.

This pattern has just started the past week, so we will see if it keeps up. Will probably get disturbed by a front moving through in a week or two.

Yep — it’s summer. Or at least mostly.

At least the winds think so. This is an overlay of the last three days observed winds at Alameda Point. I faded the older days to give some differentiation between the days, but you can see the trend. About 1pm, the wind picks up from the west and blows until sunset around 8-10mph.

Hopefully this’ll hold through the weekend.

Maxstream, now Digi, makes two versions of the Xbee radio modules.  Series 1 are 1mW or 60mW modules (depending on regular or Pro) with 100m or 1600m range.  Series 2 are 2mW or 50mW (120m/1600m).  However, their software is quite different.

Series 1 modules are peer-to-peer, they join a PAN and ship the data around, all the firmware is the same.  Series 2 modules are coordinator based mesh networking– one of the modules is the PAN coordinator, with different firmware.

Anyway — I had originally bought two Series 2 routers and one Series 2 coordinator.   For some reason, the coordinator died.  I finally got around to creating an interface to let me reflash the firmware on them, and now have working 2mW radios.  The trick is that you actually need a lot more serial protocol than is frequently presented — I got Sparkfun’s FT232RL breakout board, which includes the DTR and RTS pins needed to interface to it.  I also picked up their xbee breakout board.  A little soldering, and all is well.

I’m running the X-CTU software in parallels on my mac, and for some reason the standard guard times of 1000ms just weren’t working, I brought it up to 1200ms and it was able to talk to the radios just fine.  Reflashed the firmware (and a bit easier configuration to boot) and all is well.

Second bit of things is the configuration for a point-to-point config:

• Choose your own PAN (you never know when someone will be messing with an xbee in your neighborhood)
• For something like a controller, set Packetization timeout to 0 — otherwise you’ll end up with a random timeout between when you send your bytes and when they get sent.  This isn’t a problem if you’re always sending data, but if you’re doing something realtime you’ll want Packet to 0.
• By default, the Series 1 radios broadcast, Series 2 Routers send to the Coordinator, and the Coordinator broadcasts.
• Unless you really need broadcast messages, just have each radio send the packet to the other radio, using the 64-bit serial number printed on the bottom of the xbee.  You can set the radio to have a “common name” if you need to programatically change which radio it’s talking to (or replace a radio module without reprogramming all of them), but with only two end points, I think it’s just easier to use the 64-bit number.

This is the concept diagram for a tiny controller with 12 pins — one side has two servo connections, one for pan one for servo. It’ll take 2.7v to 5.5v (a slight variation in hardware would get me 1.8v to 5.5v). The basic idea is that you can either just plug it into the power, and it’ll start autokapping (nothing fancy, just a pan and a shutter) or you can hook a button into it, and when you push the button it’ll trigger the servo and stop being in the autokap mode.

The idea here is to have a controller that’ll either work for the bamboo pole, or for the ultralight autokap rig.

The really cool part with this design is that the programming pins on the AVR are all presented on the pins, so you can reprogram it without taking it apart.

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.

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 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).