MY Strobe Controller Blog

[KeithG]

I have been working on a scuba related personal project for a while and thought I would share some of my findings in a series of posts. Similar to the 67mm flip adapter thread I started a while ago, but this one will be much, much longer. My intent is to give regular updates (every few weeks?) as well as to respond to any reply posts that interest me. My intent is to present content at an introductory level where ever possible.

Bear with me. I am lazy. And maybe not very good at this...

-------------------------------

My problem is how to happily control my scuba camera strobes

And by Strobe I mean Flash. Don't ask me why, but scuba divers refer to an external camera flash as a strobe. Maybe you learned something today? Strobes are a very important scuba photography tool since it gets dark underwater. Very dark. Ambient light gradually reduces as you go deeper, but even worse, you lose certain colors. Things get green real quick. Strobes provide light and restore proper color balance. Google it to learn more.


Fish move. Often and quickly. Like squirrels. One technique I use underwater is continuous burst mode. I aim my camera, press the shutter and take a burst of pictures. As fast as the camera and strobe can go. Hopefully at least 1 shot will NOT feature fish butt. Depending on your camera gear, your burst speed can range anywhere from 1 frame every 5 seconds (painfully slow) to 1 frame every 2 seconds to 1 frame every second to 4 frames per second or even 20 frames per second. Burst speed depends how fast your camera AND your strobe can recycle and get ready for the next shot.


The recycle time of a strobe depends upon how much power it dumped and your battery charge level. Full dump means a longer recharge time. Low battery charge means a longer recharge cycle. Common consumer strobes are powered by 4 AA batteries (or equivalent) and generally recharge in 2 to 3 (or much longer) seconds. Partial dumps (less than full strobe power) means the strobe will ready for the next shot much sooner. Partial dumps are your friend when using continuous burst mode.

The recycle time of the camera depends upon several items. Some can be fiddled with. The camera must capture the image, process it and write it to memory card. I will ignore camera image performance. Do your own research. BUT: the onboard camera flash (yes the onboard flash is called a flash) can be an issue. If you are using optically triggered strobes (see next paragraphs), you must wait for the onboard flash to recharge before the next picture can be taken. Cameras generally have small batteries and low power onboard flashes. Without external help, this situation is not good for burst mode.

So we provide illumination help in the form of external strobes. The strobes need to be controlled by (or at least co-operate with) the camera so that the strobe discharge is synchronized with the camera shutter. Current popular technology relies upon an optical connection (fibre optic cable) to allow the strobe to act as a slave to the onboard camera flash. Old technology relied upon a physical wired sync cable connected to the camera hot shoe to fire the strobe. Optical control relies upon (and is limited by) the recycle time of the onboard flash. Sophisticated cameras realize the onboard flash is simply a trigger device (and not an illumination device) and support minimal flash power setting in order to increase the recycle speed. Non sophisticated camera don't. Wired strobes only depend upon the strobe recycle time.

So what's my problem? I bought a new camera. My new camera burst mode is worse than my old camera burst mode. Partly because my strobes optical trigger performance is poor. But the camera is also stupid.

My primary set of strobes are Sea & Sea YS110's. They support optical slave operation. But not very well. They are excellent as wired sync strobes. I used them via wired sync cables on my old camera and could achieve 4 frames per second in continuous burst mode.
I purchased a new camera in order to get better super macro performance. The hot shoe on my new camera (Canon G16) does not support continuous burst mode (more detail on this in later posts).

The G16 onboard flash does work in continuous mode, but not for long. After about 20 frames the camera pauses for 20-30 seconds. Likely a built-in flash overheat protection mechanism to allow the camera flash circuitry to cool down?

What to do...buy new strobes...fiddle with the camera...?

 

[KeithG]

My problem: trying to control scuba strobes from my new Canon G16.


I have ruled out optical control because my YS110 strobes work poorly in optical mode AND the G16 cuts out after about 20 onboard flashes in continuous burst mode. So now I am focused on wired sync control of my smart analog strobes via the camera hot shoe.


But I had a technology mismatch. The G16 hot shoe was capable of supporting either a dumb analog flash or a full featured Canon digital flash. The YS110 is a smart analog strobe, but capable of being operated as a dumb analog strobe.


Dumb is fine. My previous Sea & Sea camera hot shoe was dumb AND supported continuous burst mode. It would "fire" the strobe each time the camera recycled and captured a new image. It was dumb in that it would fire even if the strobe was not ready. The camera did not consider any feedback from the strobe. This worked fine since my strobes could cycle faster than the camera. No problems mate! Life was good.


The G16 hot shoe in analog mode is even dumber. Continuous burst mode is not supported in analog flash mode. The hot shoe X contact only fires once at the start of the burst in analog mode. Life is not so good. So analog control in continuous burst mode is a non-starter.


So let's do a quick review of the control of analog strobes based on the Nikonos protocol (I am not aware of any digital protocol scuba strobes). The strobe raises the X contact to 5 volts when it is fully charged and ready to fire. The camera shorts the X contact to ground when the shutter opens. If TTL is employed, the camera shorts the Q contact to ground when proper exposure has been achieved which instructs the strobe to stop discharging. Once the strobe has recharged it raises the X contact to 5 volts to indicate it is ready to start over. In dumb analog control the camera only has an X contact (it ignores the Q contact) and causes the strobe to perform a full dump on each shorting of the X.


The G16 does support continuous burst mode for compatible digital flashes. But this depends upon the flash knowing Canon's digital eTTL protocol supported via a proprietary Cannon hot shoe interface. There is a small number of compatible flashes. None are waterproof.


Time to investigate Canon's digital eTTL protocol?

 

[KeithG]

The Nikonos analog TTL protocol is relatively simple and has been reverse engineered by a number of scuba strobe manufacturers. The X contact is used to start the strobe dump and the Q contact is used to stop it. That's about it.

But it is rather limited in what it can accomplish. Advanced everyday things like zoom head flashes can not be supported. The answer to this problem is "digital". Different camera manufacturers developed their own camera-to-flash digital protocol. A quick skim of this Canon patent might help to give you an idea of the potential complexity of the digital protocols.


These protocols are closely guarded trade secrets. The camera manufacturers do not publish any details or respond to enquiries. This makes it very hard for a third party to produce a compatible flash. Have a Nikon camera? Buy a Nikon flash. Have a Canon camera? Buy a Canon flash.There are a few third party manufacturers ( Yongnuo is an example) that have reverse engineered portions of the digital protocol. This normally results in flash products that are not full featured and may not work with all camera models.

The following image depicts a modern Canon digital hot shoe. It has different contacts than a Nikon digital hot shoe.

So what do the various contacts do?

A web search turns up very little relevant hits. After sifting down through the results I discovered the following gold mine of information authored by Bill Grundmann way back in 2009. Bill wanted to do something similar and had worked out some of the basics. He has a series of blog posts that cover his investigation into things like the electrical interface, contact use and the digital protocol. His work was based upon some earlier work that is no longer accessible on the web. I also found a page which provides information on the hot shoe contacts.

One thing Bill noted is that his protocol findings differed from the results of the earlier work. He was finding both new and altered messages. It makes perfect sense that as time progresses, new messages would be created to support new features. It also makes sense that some features may be camera / flash specific.

So with Bill's work as a starting point, all I had to do was create an eTTL decoder...

 

[KeithG]

The path was clear. If I wanted to control my underwater strobes from my G16, I would need to create a magic decoder box. It would translate between Canon eTTL digital protocol and Nikonos analog TTL protocol. Simple in concept: digital goes in, analog comes out.


This is a problem calling for a microcontroller solution! Easy enough, There are several readily available hobby boards to choose from. Seems like a perfect excuse to spend some time and money playing with technical gadgets.


I quickly realized that the prime considerations were size and packaging (and then maybe power...). From a packaging perspective I had 2 choices

• Create an external water proof container for the decoder
• Jam the decoder inside my camera housing

Let's ponder the external container option for a moment. Creating a waterproof container that will survive the immense pressures exerted on it by the extreme depths of the oceans is actually trivial: a baggy full of oil is sufficient. The oil does not compress, so there are no pressure concerns. The baggy is "water proof" so it will keep salt water out of the innards.(I learned this from my Uwatec dive computer, thin plastic shell, oil and electronics inside.) Unfortunately my current world was more complex. The controller requires power. This generally means a user replaceable battery. Which means I need to be able to open and reseal the container. There is also the issue of the wired strobe connections. For practical purposes you need to be able to detach the strobes from the decoder and the decoder from the camera. The most practical solution for this is using industry standard Nikonos style bulkhead connectors and cables (and I already own a bunch of them). I also projected that I would want some kind of control switches. Water and pressure proof ones.


Constructing an external decoder housing seemed daunting. One option would be to re-purpose an existing housing. And they exist! Sea & Sea has several (out of production) models of TTL converters. These beasts are analog to analog decoders. They are hard to find and the owners believe they are gold plated ($400 USD). Ikelite also made an external strobe controller. Much harder to find. I think I have seen 2 on eBay in the last few years. (I might discuss external TTL converters in future posts?)


So I decided to go internal for my decoder.


This eliminated all waterproofing issues as well as the cost / complexity of bulkhead connectors. I have already installed a Nikonos style bulkhead connector in my housing and have cables to connect to my strobes.

Size now became the issue. The controller and all its gubbins had to fit inside my housing, tucked around the camera somewhere. This imposed a rigid set of real physical constraints. I needed a very small microcontroller board. Off the shelf, since I am lazy.


I was vaguely familiar with the Arduino project so I looked there first. And was horrified at the size of the boards. They were huge! A quick check of some other common hobby boards revealed the same largeness. On reflection, it made sense. These were general purpose hobby boards that were designed for people to tinker with. They needed to be large enough to provide a wide range of sensor connections.


So I investigated further and discovered the Sparkfun Pro Mini Board. Game on!

 

[KeithG]

Time to learn how to program an Arduino! How hard can it be? In my early years I was involved in real time process control and embedded controllers. I even created a patent for weighing garbage. So this was familiar ground, just repackaged and modernized for the hobby crowd. Bonus! Makes my life easier.


The main attraction with the Arduino world was multiple models of boards that all shared the same base functionality and development tools. For prototyping I purchased an Arduino Uno. It is designed to be the hobby starter board. It is. Good stuff.


Next step was to prove that I could make the Uno do something special. All I needed was an IDE and I would be off to the races. Simple.


But I got confused by a shiny pebble distraction. My web searches turned up an Arduino based software oscilloscope. Awesome. I may need one of those. Off I went and downloaded a bunch of stuff, figured out it was "too new" for the OS on my old laptop that I had dragged out of the closest for this project. So I reverted to older software, finally got it working and THEN discovered I was playing with Processing not Arduino. Oops.


Start over.


This time I grabbed the proper IDE and was off to the races in a few minutes. It was advertised as Eclipse based so I was expecting a plugin that I could add to one of my existing Eclipse IDEs. Not so. It is a standalone app built on Eclipse. Not an a plugin, it provides its own look and feel and has lost a bunch of features that I was used to. Not perfect. But workable.


The UNO IDE provided a library of sample "sketches" that I was able to download and exercise on my UNO board. The simplest demonstration of my new found power was to hack the Blink example. I made an LED flash differently. I was also able to display debugging output to a monitor window. I was elated! Upon reflection, this accomplishment was trivial when compared to the task ahead of me.


I also had to take care of some housekeeping issues. After creating a series of unique files for each custom version of Blink I realized I really needed my standard IDE ecosystem that the UNO IDE seemed to exclude. I needed a proper source code control system. A workable compromise was to use a copy-paste transfer from UNO IDE into my Eclipse CDT tool so that I had standard source code control (SVN for this project) and other advanced IDE features like code formatting and cross file search.


Now it was time to get to the business at hand: hook my Arduino to my Canon G16...

 

[KeithG]

The easiest way to investigate the Canon eTTL protocol was to eavesdrop on the conversation between the camera and a flash. This approach would allow me to observe a real working system. I needed to learn about the Cannon eTTL protocol supported by my G16. There was some reference material available on the web but they all cautioned about model differences and misunderstood features. So a sniffer was the way to go.


This required a couple of things I did not have:

• a means to connect my Arduino to the hot shoe contacts
• an appropriate flash

Getting access to the hot shoe contacts meant tearing something apart. No guarantee it would go back together afterwards. So cheap is best. eBay yielded a Canon hot shoe compatible flash extension cable. About $20. I placed my order with the supplier in China and waited.


The flash was easy: rent one for a week from my local camera shop: Henry's. All I had to do was make sure I obtained the proper flash. I took my G16 into the retail store and tested it with a number of different flashes. The low end 270EX II did not support continuous burst mode. Time to go upscale. I ended up with a 430EX II flash, $400 retail. Or $40 a week to rent.


I had my ducks in a row. Time to get to work on my Arduino sniffer.


Based upon the prior work and a few hints in the Canon patent, I suspected that Canon used the industry standard Serial_Peripheral_Interface (SPI) as the digital interface. And the Arduino also supports SPI. This is a simple electrical protocol used to support bi-directional data exchange between a master and a slave device. Only 3 pins are required: CLCK, MOSI, MISO.


This seems to good to be true. It was. No free lunch. First obstacle was that the voltage levels were off by a few volts - some external circuitry may fix that? After some additional [-]fiddling[/-] research I ultimately determined that the Arduino SPI hardware was unsuitable for use as a sniffer. It was not designed to eavesdrop on 2 different data signal lines. It was designed to receive as a Slave device or drive as a Master device. It could only "eavesdrop" on 1 side of the conversation. IF I could get it to work, I could only sense either the camera data or the flash data. Not both.


This meant that my only remaining option was to monitor the 3 digital lines via low level bit bashing. My next step was to create a bit bashed sniffer program.

 

[KeithG]

And a visual interlude...

I needed to forge a pair of optical connections for my ancient S&S YS50s. Thank you Delta Hotels...

I tossed the first 10 (way too thin) candidates until I came upon a very fine pen cap from Delta. 2 swift side cuts later on the pen cap with my Dremel tool gave me a pair of S&S fibre cable compatible connectors. A bit of superglue later the Delta Hotel connectors where stuck to a pair of YS50's.

The image below shows the gubbins after I cut them off the pen and before I stuck them on the YS50s.

20160102_230541_1_ - ScubaBoard Gallery

 

[ScubaMarc]

If you are building something maybe a different way to to approach g16 flash issue is to build a led hot shoe. Your strobes do not need the same light intensity of the g16 flash, the led can surfice. Also the led should have no problem in burst mode. The only issue I can see is why has no one done this.

 

[KeithG]

If you are building something maybe a different way to to approach g16 flash issue is to build a led hot shoe. Your strobes do not need the same light intensity of the g16 flash, the led can surfice. Also the led should have no problem in burst mode. The only issue I can see is why has no one done this.

Good ideas! Thanks for your feedback. But my world sometimes sucks.

When I started this adventure my primary set of strobes were a pair of YS110s. They have poor optical trigger behaviour (hence the quick introduction of the YS110a?). I had already given up on optical triggering and went wired. I already modified my DX-1g housing to provide a manual only Nikonos style bulkhead connector: find place with sufficient internal clearance *, drill big hole, install bulkhead. Profit. The camera (Ricoh GX100) was only capable of providing a generic analog X hot shoe. This setup worked well within it's limitations. No TTL. Manual strobe operation, but up to 4 frames per second.

I had a system that worked okay within its limitations - which were really okay.

I then upgraded to a new camera in order to get better compact camera (super) macro performance. It did, but introduced some strobe challenges. My new camera (G16) and SubSee +10 lens could get better (larger) images, but I had to toss all ability to perform burst mode.

* My biggest surprise in the early days of this project was how hard it was to find a location in the camera housing that allowed the placement of a Nikonos style bulkhead. My first exercise on a DX-1G housing was easy. The Meikon G16 housing was a challenge.

---------- Post added January 5th, 2016 at 02:53 AM ----------

If you are building something maybe a different way to to approach g16 flash issue is to build a led hot shoe. Your strobes do not need the same light intensity of the g16 flash, the led can surfice. Also the led should have no problem in burst mode. The only issue I can see is why has no one done this.

Canon hates me. Well, not me personally. I am not that important.

My first real disappointment was to learn that the G16 only supported burst mode via (certain) digital strobes.

My old DX-1G (Ricoh GX100) camera played dumb and cycled the X hot shoe analog contact every shutter activation. My fancy new Canon G16 asserted analog X exactly once. Burst mode was only supported Digitally.

 

[KeithG]

Arduino Bit Bashing Canon eTTL Protocol

I needed to be able to sniff the digital data exchange between a Canon G16 camera and a 430EX II flash. Prior work had determined that the Canon digital eTTL protocol interface was VERY close to SPI. Mostly. Except for signal voltage levels. I had already determined that the Arduino SPI interface was not suitable for sniffing.

My ultimate goal was to discover how the Canon eTTL protocol supported burst mode flash control - so that I could mimic that small part of the protocol. The camera was smart enough to detect the presence of a Canon flash and then control it via digital commands.

So I was forced back to basics. Fortunately Bill Grundmann had already started down this avenue and provided a sample bit bashing program. I used this code as a starting point and then many late nights expanding the program. It basically relies upon detecting change of state of the 3 SPI signal lines. An interrupt service routine is hooked to the CLCK line which then samples the current state of the 2 data lines. Low level brute foirce programming. Very timing dependent.

One of the first issues was inconsistent behaviour of the sniffer program. It took several experiments and large amounts of head scratching to discover that bit bashing and slow blocking operations did not mix well. The obvious culprit was the standard debugging output via Serial.print. This depended upon serial interrupts. Some basic timing calculations revealed that the camera / flash data exchange operated at a higher data rate than the debug output. A dumb debug output dump of all traffic was doomed to failure. The camera - flash exchanged more data than the debug monitor could dump.

The next clue to success was based upon a general observation of the SPI interface. It was bi-directional, but not really full duplex. There was a single clock signal controlled by the Master. The Master (camera) and Slave (flash) both transmitted at the same time. Under control of the Master driven clock. The Slave can not initiate data exchange. This meant the data exchange was highly constrained. The Master could transmit a command to the Slave at any time. The Slave could not initiate a data transmission. The Slave was also constrained to transmit data at the same time as the Master, before it had received current information from the Master. These constraints result in a very chatty protocol.

Examination of the data revealed that the flash tended to continually spew status messages at the camera. This made sense since each multi-byte data exchange was initiated by the camera. The flash has not yet read the information from the camera, but is required to provide data back to the camera. So the flash often transmitted a standard "general status" message. This meant that in a steady state, with no button pushes on the camera or flash, the digital interface was constantly spewing data back and forth.

Next step was to figure out what it all meant (or at least learn enough so I could trigger my strobes).