jeffmcbride.net

The year 2011 has been a year of strings for me. It started with the Section Quartet, via Pandora, and a whole slew of others (such as the Vitamin String Quartet) on Pandora stations. More recently, I’ve been playing the Break of Reality album “Spectrum of the Sky” a lot. A blog I follow pointed me to Zoe Keating’s amazing cello layering using a loop recorder. Finally, this week I saw these guys on The Colbert Report, went and bought The Goat Rodeo Sessions, and have been playing it since.

Not just strings either. But instrumental music in general has been on the rise in my playlist. Explosions in The Sky is the first to come to mind.

I’ve been working on some electronics and software to do precisely timed photography setups. One of the issues I encountered was that I seemed to have a lot of unpredictability in the delay between when I fired the shutter signal and when the shutter opened. I took some measurements to find out what range of shutter lag I needed to account for when calculating trigger times, and once I got setup it quickly became clear that there were two delay modes I was seeing: a short, very predictable delay, and a much longer and much more varied delay. It didn’t take much longer to realize what the difference was between these mode, and that this was what was causing my problems:

The D90 has a very predictable shutter lag; When it is ready to go. When the display is still active showing the image from the previous shot, there is a much longer shutter lag, and it varies a lot. So, when precisely controlled timing is required, you need to make sure the display is off before triggering. This can be done by either waiting for the shooting info display to turn off, or half-pressing the shutter button. In my setup, I wired the half-press and full-press together, because I didn’t think I’d have any reason to command a half-press. In the future, I think I will wire them both to be controlled separately, so that part of the sequence can be to send the half-press command early enough to ready the camera before sending the full-press shutter command.

The Setup

I controlled the camera via the remote shutter cable input. I had both the half-press and full-press wires connected together, so that both were shorted at the same time to the common wire with a FET. I used a microphone to detect the shutter, and connected both the trigger signal and the audio signal from the microphone to an oscilloscope to measure the delay.

The Results

When the display was still on, the shutter delay was around 210 ms. It varied a lot. At least 20 ms, probably more, but to be honest once I figured out what was going on I didn’t really record measurements for this case.

When the display had turned off, the delay was 70.2ms, +/- 0.5ms.

The capture below shows the sequence. The camera was set for 1/5 shutter time, or 20ms. I’m fairly sure that the first long sound is the mirror opening, and then the is a quick sharp sound which is the first shutter blade opening, followed 20ms later by the second shutter blade following it to block the sensor. The time between these two pulses varies as it should with exposure time.

As you can see here, the bulk of the shutter appears to be taken by the mirror movement, which takes around 40ms. It is possible that there is something else going on that the camera would have to wait for anyway, but I have to wonder why they don’t have a mode to hold the mirror open to begin with. Even in live-view, where the mirror is normally up, the D90 closes the mirror when you press the shutter button, then opens it again to take the shot. I’ve no idea why they would do that.

This weekend, I made another attempt at photographing fire, and this time got much better results. I have seen some really cool burning beverage photos on flickr recently, and I wanted to try one of my own. Conveniently, I have a whole bunch of martini glasses laying around. When I put one in front of a white background and illuminated the background, it looked awesome, and I knew I was on to something. A key difference from the previous flaming ice shoot is a change of fuel: I used white gas that I had for my backpacking stove instead of the vodka I used last time. It burns MUCH better. I was an idiot for trying to do this with vodka. I have feeling that when I go buy some lighter fluid and try that, I may find that I am an idiot for using white gas, because the camp stove fuel burns DIRTY. It leaves a sooty grime very quickly, and I was constantly cleaning the glass. I hope (though I haven’t tried yet) that lighter fluid will burn cleaner.

This is the setup in my living room:

You can’t see it in the setup shot, but on the floor behind the glass is an SB-600 flash, with a blue gel, pointed up at the white background. Except for the flames (which were surprisingly bright) this was the only illumination. Because the pop-up flash fires in order to trigger the remote SB-600, I had to tape a piece of glossy white paper over the pop-up. The paper stood out an inch or two in front of the pop-up, at a 45 degree angle. That way, the pop-up light was re-directed so it didn’t shine on the martini glass and reflect back to the camera, but the light from the pop-up could still reflect off floor, walls, etc enough to trigger the SB-600.

When I started friday night, the only thing I  had on hand for a table to put the glass on was a  piece of white foam board. This worked OK, but the fire reflections on the foam board kind of bothered me. So Saturday I ran some errands and bought both a black foam board, and a mirror. Both of these worked better than the white, but I really liked the shots with the mirror.

A shot from the first set with white foam board:

Then, with the black foam board:

Then finally, with the mirror as table:

While I was shooting these, I really liked the blue. Then while processing the photo above, I tried getting rid of the blue by selectively de-saturating the image, and I REALLY liked it. So, now I’m a bit torn, but I think if I had to pick only one flaming martini image, this is it:

I set out to capture a cool fire and ice shot tonight. I didn’t have a lot of success with that; I think I need a better burning surface, and maybe a better fuel. However, I thought the melting ice made a cool animated gif! The last chunk of each cube really went out in one quick pop. Not sure why that is.

That’s a plate of vodka, in case you were wondering. I had several problems getting a decent shot:

1) The plate is kind of convex, so the vodka wanted to be on the outside, not with the ice. I really want the opposite.

2) The plate is not ideal for a background. I think I want a piece of glass on black background…maybe? ‘

3) Vodka just isn’t that great a fuel. It has to have sufficient quantity, and be warmed in order to burn at all.  Two bad it wouldn’t burn cold, because when I pulled it out of the freezer it was nice and syrupy and would actually stay where I poured it.

For a brief moment the thought, “Can I build a still out of what I have in my kitchen?”,  did cross my mind.

I’ve jumped on the e-reader bandwagon. I bought a kindle 3 a few months ago, and it was totally worth the $140. Compared to the traditional paperback, it has some downsides, but it also has some serious upsides. I guess I’ll start with the negatives:

Cons

1) Cost. First you have to buy the kindle, obviously. Then, sometimes you have to pay more for the books. There are often books which can be had for $4 shipping from third parties on amazon, for which you must pay $10 (or sometimes a bit more) to get the kindle version. On the flip side, if you do have to buy it at the new price, sometimes the kindle version is a bit cheaper, but not much.

2) Tactile navigation. Sometimes you just want to flip through a book: jump back 20 pages, read a second, then jump back 10 more, etc. Or, you just know by feel about where in the book something is, and you open and start searching. You lose this completely with the kindle. You can go the the table of contents and jump to a chapter, and you have the added ability to do a text search instead of random flipping, but sometimes you just want what I call tactile navigation.

3) Resale/lending. I can’t sell a book after I’m done with it, and I can’t really loan it to a friend. Amazon has just started a new loaner feature, but it is pretty restrictive, and only available on some books (as the publisher wishes). Basically, you can’t do it. Honestly, the only book I’m going to want to sell is the rare high value one.  Loaning is a bigger deal – I’ve already wished I could do this – but still not something I would do enough to really deter me.

Pros

1) Size. Some books are OK to carry around, some are big. More than one is almost always too much. With the kindle, any and all books fit into one slim package, which fits nicely into a cargo pocket, or is light in a backpack.

2) Convience. I never appreciated until I had it how nice it is not to have pages. You can set the reader down in front of you, without having to hold it open to your page. Outdoors when it is windy, there are no pages to get blown around. Page turns are just a button press (on either side of the device). There is never any excessive force required to open the book flat enough to comfortably read near the inner margins. I was surprised just how much nicer the kindle is to read.

3) Display. The e-ink display on this thing is awesome. I wouldn’t even consider an LCD display over this, color be damned. Easy on the eyes, comfortable in any lighting you could read a book in, never have to adjust screen brightness; it is also fine in sunlight. Not to mention the power savings. Interestingly, the display is never off. When you turn “off” the kindle, it just puts up a screensaver image until you turn it back on. You could remove the battery, and that screen will holds its display indefinitely with zero power. The only thing it really needs is color…but most books aren’t printed in color anyway.

4) Battery life. If you leave the wifi off, you can charge it every 3 or 4 weeks. You can travel with it, forget all about charging it, whatever. It is hard to run the battery out.

5) Dictionary. I’ll admit it: My vocabulary is so-so, and I don’t like having to find a computer to look up a word. With the kindle, I just put the cursor on a word I want to look up, and it searches for it in the installed dictionary, giving me quick access to the definition. I use this a lot. It’s handy.

6) Highlighting and search. Also handy is the ability to go back to interesting sections quickly. There are two ways I do this: a) Search the text or b) Save highlight sections. While reading, you can highlight a section, or add a note, and then recall those your notes/highlight sections later. It is kind of nice for someone with a bad memory, like me, to be able to finish a book, then look back at highlights to remind yourself of the interesting bits.

7) Preview.  It’s easy to download the first part of a book, and read that before buying it. This is probably as good a marketing technique for amazon as it is a convenience for me.

Overall, it has been great to have. I’ve played with the sony e-readers a bit, and they just don’t seem as polished. The browsing is not too hot, but it can work in a pinch, and it can even be useful for reading heavily text based sites..news feed, etc. You could also use it to look up a wikipedia page…if for some reason you don’t have your phone.

Hacks

If you do have a kindle, and are feeling a bit adventurous: Install this jailbreak for custom screensavers, fonts, etc.:

http://www.mobileread.com/forums/showthread.php?t=88004

I was playing a this silly flash game last night, when I decided that it was not much fun to play, but I wondered if the right algorithm could keep it going forever, and it shouldn’t be that hard to write an application to play it, right? I figured if I was bored enough to play flash games, I was bored enough to write an application to play flash games for me, and it would probably be more fun. So, I did, and here is where I ended up: Now I have the framework in place to play the game, but my first attempts at algorithms to play them failed miserably.

How

To play the game, I really only needed to do two things:

1. Do a screen grab of the flash app and interpret it into game state
2. Send mouse click events to the flash app

Like most tasks in C#, these were fairly straightforward, with a bit of googling, so I won’t go into details (I used Graphics.CopyFromScreen() for screen grab, and the mouse_event() API call for mouse input). The hardest part, actually, was getting the right screen coordinates to grab from. For this, I created a semi-transparent template form, with some shapes for the bubble positions on it. So, you just put up the template form (which is always on top), position it so it aligns with the flash app, and you’re good to go.  As for screen captures, I capture:

1. A single pixel on each of the “coming up” bubbles at the top-right
2. Four horizontal strips along each play line of bubbles
3. One vertical strip which covers the region the cannon can be in

I use the hue of a pixel to determine which bubble type (if any) it belong to.

Why

Because I was curious, really, and I thought it would be fun to try and find the optimum way to play. The game gives you a preview of the next 7 upcoming bubbles, way more information than a human can process quickly, and I figured if I made use of that I could do much better than the simple rules I could use in my head for playing. Unfortunately, so far, I have been proving myself dead wrong, and the simple heuristic rules, which use only the next color, and are basically how I would play myself, works much better than my other attempts. This is not cool. So, I invite anyone to come up with a better algorithm to play. The code is written in such a way that you just have to create a new class which inherits from  IBubbleAlgorithm, and provides a function to take the current game state as arguments and return the next lane to play on. Alternatively, if you have any ideas, but don’t want to code it, let me know and I may try it myself.

Algorithm 1: The Simple Rule

First, I did what I call the MatchColor Algorithm. It uses only the next bubble color, and pays no attention to the other 6 upcoming colors.

The rules are as follows:

1. If one or more lanes end in two bubbles of the same color as the next bubble to be played, play it on whichever of these lanes is the longest (already contains the most bubbles)
2. Otherwise, if one or  more lanes end in one of the same color bubbles as the next, play it on whichever of these lanes is the longest.
3. Otherwise, play on the shortest lane.

This works surprisingly well, especially when you run it at 10Hz. It is pretty much what I would do myself, but way faster.

Algorithm 2: Most Triplets Search

Next, I figured I would do an exhaustive search of all possible outcomes for the next 7 steps, and find the endpoint which resulted in the most triplets, and choose that branch of the tree for this turn. For each play, there are 4 options, to that leads to 4^7=16,384 possible outcomes to compute. After finding the outcome with the most triplets, work back up the decision tree to whichever lane in the current turn leads to that best case. This worked, surprisingly poorly. For one thing, it was slow, because I did it in a stupid way the first time around. I ended up recreating a lot of data structures for every step through the search, when I really didn’t have to, creating and destroying a lot of objects, which is slow. This will probably work better if I re-code it so it will run at 10Hz like the first algorithm, but I doubt it would be much.

Algorithm 3: Least Bubbles Search

After the second algorithm failed so poorly, I realized that I wasn’t really trying to get the most triplets, I was trying to keep the longest line as short as possible. So, I repeated the search (and re-coded it to use a single state data structure for a big speedup), but this time I found the final outcome with the shortest longest lane. This was a bad idea, because it means that it almost never wants to play on the longest lane, so it fills up the shorter lanes, at the expense of making triplets. So then I re-worked the “fitness” function for each outcome to be <total bubbles in all lanes> + <bubbles in longest lane>, trying to strike a balance. It still didn’t work nearly as well as the first, simple algorithm. Finally, I added a new term in, where I subtracted a 0.3 from the score for each lane that was left with two of the same color on its end (as way to differentiate otherwise equal scores).  No dice.

Final change: I noticed that I often get multiple instances of the same score. At first, I was taking the lowest lane number of these. This seems to lead to a build-up of pieces on the top lanes because they had preferential selection. I changed it so that when two lanes had nearly the same score, the shortest lane was played on. Still no dice.

How To Run It

If you want to try it out, it is kind of fun to watch. If you want to try to come up with your own algorithm, it is pretty easy to add in if you know any C#.

To run it, open the flash game in your browser, and launch the app. First, you have to line up the template. Click on show template to pop-up the template screen, and drag it over until it aligns with the flash app. Unfortunately, the game will go to a pause screen as soon as it loses focus, so I’ve found it is easiest to first do a rough alignment of the template form, then click focus back to the browser window and move it underneath the template for fine alignment. You should see the image capture and color readouts in the “Screen Grab Diagnostics section on the application form. At this point, it is just grabbing data. It won’t try and play until you check the play checkbox. You have to close the template window first, otherwise it will intercept the mouse clicks.

To select the algorith, just use the dropdown combo box. If you want to add a new one, simply create a new class which inherits from IBubbleAlgorithm, and add it to the project. Any class types which inherit from this interface will be automatically found and instantiated, so it will show up as an option the next time you run. Of course, I’ve only tested this on two computers; it will probably fail on yours .

Things to Do

I’ve probably wasted enough time on this, but should I waste more, it could use:

• More validation of the algorithms. I think the control agorithms are running as they should, but it is still possible that it is a bug and not the algorithm at fault for  the poor performance.
• More validation and improved robustness of the screen grabbing. The flash app does a lot of animation, and when playing fast, these animation have not settled and I think sometimes cause bad interpretations of the screen grab.  Except for the new bubbles coming in from the left, I know where I played, so I know how to update line states without the screen grab. This could be used to improve robustness.
• Game simulation. Actually, I don’t care so much about the flash app anymore, and I could test algorithms better and faster by leaving out the flash game and generating my own game states. This would also allow monte carlo style tests of an algorithm.
• A more intelligent, forward looking algorithm that beats he stupid live-only-in-the present one. This has got to be possible.

Download

I’ve zipped up what I’m calling Version 0.1. It includes the Visual Express project, code, and the build executable, which will probably just run on any windows computer (if you trust me enough to run it, that is; if you know me, why would you trust me? And if you don’t, then really, why would you trust me? ).

BubbleLanePlayer_v0.1.zip

On the day we left Zion, we drove through the tunnel and out the east entrance. On the other side of the tunnel, we stopped to explore a frozen riverbed, and spotted a herd of a dozen or so Big-Horned Sheep.

I had read on an internet forum that Coral Pink Sand Dunes State Park was worth a visit. It’s fun to climb sand dunes, and they often make for nice scenes, so we figured we would head out of the park, stop by the sand dunes, and continue home from there. I wouldn’t say I regret going, but the dunes were not exactly spectacular, either. Kelso Dunes in Mojave, or the Mesquite Flat dunes in Death Valley are both a lot cooler places. For one thing, the dunes here were not very extensive. There were really only two peaks worthy of mention. Secondly, they were inhabited by off-road vehicles, with accompanying tracks and noise. When you walk in from the parking lot, there is a small section of sand fenced off, with a few openings. At the openings, there is a sign which doesn’t forbid walking around the dunes; it just says it may be dangerous, and suggests maybe you shouldn’t, or at least be careful. We decided to trust the kids on ATVs not to run us over and walked out to climb up the tallest dune. We climbed it. We watched the ATVs ride around, took some photos, then headed back towards the picnic area to make some lunch before heading to Vegas for the night.

After we left the park, we crossed over into Arizona. As soon as we did, the pavement ended. My first thought was, “Maybe we’re on the wrong track here?” But, no worries. The dirt was smooth, and 5 miles later the pavement re-appeared.

I spent Thanksgiving with Mary and her family at Zion National Park in Southern Utah. It was quite cold while we were there, and we had a really good time. It snowed the day before Mary and I arrived, so everything was still covered in a dusting of snow, and it was cold enough that wherever there was water to freeze, there was ice!

On Friday, Mary, her father, and I hiked up to Angel’s Landing. This is probably a really awesome hike any time of year (although I bet it is ridiculously crowded at peak season). With the snow and ice when we were there, it was the most fun I’ve had on a trail in a while. First the trail goes through a canyon, and then up two sets of steep switchbacks. Then you double back on the ridgeline above. This is where it gets awesome. It is a fairly technical trail with a lot of scrambling along a sometimes narrow ridge.  However, there is  a chain installed along all of the sketchy parts, so it really isn’t that bad. With the ice, it was still a bit of a challenge in spots even with the chain (just enough to be a lot of fun, as long as you are in reasonable shape, and not terribly scared of the heights).

The first really interesting part of the hike was at “Walter’s Wiggles”. This is the second, and the steepest, set of switchbacks, which take you up to the ridgeline. For us, they were completely covered over with snow and ice. The best part though was actually on the way down. On the way up, it was passable. By the time we had come down, it had re-frozen, and was super slick. The whole canyon was filled with hilarity. I thought it would make great inspiration for a mario kart track. The canyon echoed with people laughing, owws!, and general chatter. A group of kids was having a great time sliding down each segment. One of them was a strong supporter of the “penguin style” belly slidel. Adults were falling constantly, some stoically insisting on getting back up and walking again (until they fell again), and others just giving in and sliding down. It was all out comical.

After getting up the wiggles, there is a bit of up and down along the ridge line, out to the landing. There are some flat part, some steep parts, and a lot of good views!.

This is taken while climbing of the last bit of ridge, looking back along where we came:

Now I will leave you with a quick video clip of the wiggles:

I get about zero actual comments here, but about one spam posting a day. None of these  see the light of day, but I see them, and recently I’ve noticed a trend toward flattery in blog spamming. For example, I’ve recently received these friendly comments:

“Incredible, that’s definitely what I was scanning for! This article just spared me alot of work. I’ll make certain to put this in good use!”

“congrats on having a successfull amazing lookin blog.. I wish I could write like you man.. seriously”

“Hello this post is nice and good. Can you tell me any related articles?”

“Very entertaining post – Might be aged news, but it was news to me.”

“Valuable blogpost and awesome design you got here! I would like to thank you for sharing your ideas and time into the stuff you post!! Thumbs up”

Or, there are these gems:

“Good day in your opinion are north korea and south korea going to be at war”

“Thanks to the author for taking his clock time on this one.”

I’m really not sure what that last one is supposed to mean. I guess it is computer generated. Oh how I miss the good ‘ol days of “Want to make her happy? Click here to grow your member in just 2 weeks!”.

If you know me at all (or have read this blog much), you probably realize that I’ve developed a bit of an interest in photography. I don’t call myself a photographer, because I think that either means “person who takes photos” or, perhaps, “Person who makes a living taking photos”. In the case of the former, the term is pointless; do YOU know anybody who doesn’t? In the case of latter, well, I don’t.  But I like having good pictures to document my life, I like learning the technology, and I like to play with new gear. Anyway, to get back on topic, I’m also an engineer, a good part of my job involves digital imaging, and I am never satisfied with the technical info I can glean from product manuals. They just don’t tell you, even remotely, how they work. So sometimes I just have to do a bit of reverse engineering to figure out how things really work.

One of the really cool things about today’s photo gear is the ease with which you can control remote flashes. Nikon calls their flash system CLS, for Creative Lighting System. Basically, you can put remote flashes “out there” somewhere, and control them using the pop-up flash on the camera body. They do the same type of “through-the-lens” (TTL) metering that is done with an on-camera flash, and they’re power levels can be set from the camera. It’s pretty cool, but I found myself asking, “how does it work?” There are at least two things, besides curiosity, which prompted me to ask this: a) I was looking for remote triggers (optical slaves) for non-nikon flashes, but could not make sense out of what would work with CLS and what might be falsely triggered by the “pre-flashes” involved, and b) I could not find any consensus in internet searches as to whether the commanding flash fires during exposure or not. Furthermore, if I could understand the system enough, maybe it would be worth just building my own optical slaves.

There is a surprising lack of solid technical info on the internet about these things (but a good supply of well-intended, but ultimately misinformed, pseudo-technical explanations). The one good source I did find (only after running my own tests, incidentally) is here.  Fortunately, I have ready access to the tools needed to measure this sort of thing, so I took some time and collected some data, so I’m going to present that data here so it is available to whoever else may find it useful.

My test setup consisted of two IR phototransistors, connected to an oscilloscope. Because I wanted each sensor to be isolated and read only the power output of one of the flashes while ignoring the other, the phototransistors I had were far too sensitive. To solve this, I ended up wrapping two layers of copper tape around them (I was surprised to find just how transmissive copper tape is in the near IR band). I then positioned the sensors about an inch in front of each flash.

To summarize my findings:

• The communication is all one way. The signal is sent from the commander flash by pulsing the flash with ~50-100 microsecond firings.
• There are always at least two command sequences. The first I’m calling the “channel sequence”, and the second the “firing sequence”. The first one seems to be a function of the channel (1, 2 or 3) and the groups being commanded (A,  B, C). The second sequence contains the firing commands (e.g. output level) for all groups being commanded (CLS can command up to 3 groups).
• When using only manual mode (where the output power for each group is set ahead of time on the camera) these are the only two data sequences. When using TTL metering mode, the channel sequence is sent, and then each group is commanded to fire a monitor pre-flash by another pulse sequence (The camera measures the amount of return light it sees from this monitor pre-flash and uses that information to determine the proper flash power level). If the return measured from the first monitor pre-flash is not strong enough, the camera will fire another burst to request a second, higher power, monitor pre-flash.
• After the firing sequence is sent, which tells each flash group what power level they should fire at, there is a delay (around 50ms), and then the commander fires one quick flash to trigger the slaves to fire. This means that the on-camera flash ALWAYS fires at a low level while the shutter is open, even if it is commanded to be off. In most cases, the power is low enough to not affect the photo. If the camera is close to the subject, or if the subject is very reflective (try shooting at a piece of glass, for example), you will see the commander flash. For this situation, nikon sells an IR pass filter which will block the visible light from the flash, while allowing the infrared light to pass through to trigger the flashes. Your lens has an IR blocking filter, so it will not affect the exposure
• For Manual mode, the firing command is very straightforward to interpret. Each firing level is assigned a binary value, starting at 0 for 1/1, 1 for 1/1.3, etc. I had hoped that the firing sequence would be the same for TTL mode; but it is not. The commands are completely different when in TTL, and I’m not sure how to interpret them.

In the following scope captures, the green trace is the slave flash, and the yellow trace is the pop-up commander flash.

This first captures shows the most basic sequence, with one flash group set to manual mode. You can see the channel sequence, followed by the firing sequence which says, basically, Group A, fire at power level 1/1, and then after a 55ms delay, the commander flash goes off (followed only a microsecond or two later by the remote flash).

The next to captures show the flash being fired in TTL mode. In the first case, I put a target up close to the camera and flash, so it got a strong return. In the second, I removed the close target so that the camera was shooting more like 15 ft away. In this case, it requested the second higher power monitor pre-flash.

The next capture shows the channel sequence, which is the first burst in the above captures. The first three pulses designate which channel is being commanded. I believe the rest of the pulses say which groups will be commanded. What is interesting here is that, for the first three pulses at least, it is not as simple as, “if a pulse is fired during this bit time, it is a one, if not it is a zero”. Instead, the time between pulses is varied. In one case, the time between pulses is about 140us, in the other it is about 200us. Channel 1 is short-long, Channel 2 is long-short, and channel 3 is long-long.

Finally, this capture shows the “firing sequence”, from several man mode test cases, to illustrate the binary counting. Man mode commands are fairly easy to figure out. When multiple groups are used, the firing sequence is extended, with each additional group firing level specified in the same way. Those with a bit of binary counting experience will see that at the end of each of these sequences is a counter, increasing by one each power level.

I guess that is enough for now. I have a bit more data, and can capture more as necessary, so feel free to drop me an e-mail if you want to discuss any of this further. My main take-away here is that implementing an optical slave that is “CLS tolerant” should be trivial: Wait for a pulse, then wait for 40ms or so without a pulse, restarting the wait counter anytime another light pulse is detected. After 40ms of “dead time”, the next pulse will be the fire command. But more interestingly, implementing one that will take its power level commands in manual mode from the camera should not be difficult, which means I could buy an $85 chinese flash and control it as a CLS manual slave, if I could just figure out how to control the power output of the Yongnuo flash electrically (I have reason to believe this can be done using a pulse width on the shoe connection). The value of this may be questionable since I could A) just buy the cheap flash and set its power manually using the buttons on the flash or B) buy a $200 nikon SB-600 and get full CLS compatibility without the hassle, but it would certainly be more fun to do it myself.