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

Two little graphics here:

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.

Just some musings on some things I worked out:

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.