Anders Häggman

MAS.863 Portfolio

WEEK 9 // Input Devices

For the input devices week, I took on a challenge that was perhaps ill suited for me, considering my lack of experience with electronics, and I continued working on this assignment in parallel with the other ones for several weeks.

Even before the debugging stage, I spent days just making the board. Routing the board was quite difficult for me, and in the end I ended up using quite a few 0 Ω jumper resistors to make it all work. I spent hours researching flashes without becoming much wiser, and as a slow solderer, stuffing the board was arduous. Writing the code and debugging also took it's fair share of time, and so in the end it took me several weeks of work, and it's still not totally functional.

  • Level of previous experience:              
  • Time taken:                  +
  • Tools used:
    Eagle PCB Design Software  //  Roland Modela MX-20 Desktop Mill  //  GIMP  //  Soldering Equipment  //  Multimeter and Desktop Power Supplies
  • Got help from:
    Ben Nahill  //  Prashant Patil  //  Will Langford  //  Jean-François Duval  //  My friend Eric  //  Dana Gretton
  • Main learnings:
      For more complex parts, build it in stages, and test each stage to see that it is doing what you think it should.

For this week's assignment, I wanted to create a microphone trigger for my flash, to take pictures like this. The basic idea is that the object being photographed is placed in a dark environment, the camera shutter opens, and as a sound is heard the flash fires. (And sometime after the flash has fired, the camera shutter closes.) As the room or environment that the photograph is being taken in is dark, and since the ISO setting of the camera has been set to low sensitivity (something in the range of ISO 100-400), the only image captured by the camera is that of the moment when the flash fires. Some examples images of these types of photos can be found here and here.

* Photo credit: Kyle May [Photo slightly edited: Crop and desaturation.]
There are various types of circuits that can be made to achieve the required functionality, such as the circuits detailed here , here or here . There are also commercial sound triggers available, for an example, see here A , B or C . I decided to try and create a sound trigger myself, that accepts an input voltage anywhere between 6V - 30V, has a microphone that listens for sound and inputs a signal to the microcontroller where the sound frequency and volume are analysed, and if they exceed threshold values, a signal is then sent (with an adjustable delay) to the flash to trigger it.
The circuit on the right is almost the final design that I ended up with, although, I added an extra resistor connecting the opamp inputs.
When I began this project, I had a very poor understanding of how the external triggering mechanism on camera flashes work. It was clear that connecting the wrong type of flash to a camera could damage the camera, as some flashes created trigger voltages up to 350V, something many current DSLR's can't tolerate. However, it was unclear to me, if I needed to provide a voltage for the flash, or simply close the circuit on the external adapter of the flash. It was incredibly hard to find any detailed and clear information on the flash that I have (a Canon SpeedLite 580 EX II), and this was pretty much the most detailed information I could find. Even though small details were outdated, such as 'successor: not yet' (the SpeedLite 600EX-RT has since come out to replace the 580 EX II), the details I was interested in (trigger voltage), were items that don't change.

Full Tech Specs

Model Information

Brand:   Canon
Model:   580EX II
First introduction:   2008
Successor:   none yet

Output Specs

Guide number spec (35mm, ISO 100, in meters):   36
Guide number test result:   39
Manual power settings:   1/1 – 1/2 – 1/4 – 1/8 – 1/16 – 1/32 – 1/64 – 1/128
Flash duration (full power):   1/833
Recycle time spec (at full power):   5.0 sec alkaline
Recycle time test result:   3.8 sec alkaline, 3.0 sec NiMH


Flash foot material, type:   metal, standard ISO (Canon)
PC Sync Port:   yes
Optical Slave:   no
Other Trigger:   wireless TTL slave mode
Trigger Voltage:   4.49 V
Standby Mode:   can be deactivated

Flash Head Features

Swivel:   -180 to +180 degrees
Tilt:   -7 to +90 degrees
Manual Zoom Head:   (14) 24-105
Auto Zoom:   (14) 24-105
Bounce card / 2nd reflector:   yes / no
LCD Display:   yes

Power Supply

Batteries Used:   4 x AA
External Power Source:   Battery Pack CP-E4

Canon TTL

E-TTL(II):   yes
E-TTL(II) wireless slave:   yes
E-TTL(II) wireless master:   yes

Other Flash Modes

Stroboscopic Mode:   yes
Auto Mode:   yes

TTL Features

AF Assist Light:   yes (triple beam)
Exposure Compensation in TTL Mode on the Flash unit:   -3 to +3 EV
Rear Curtain Synchronization:   yes
High Speed Synchronization:   yes
Sensor Size Detection (DX, FX, etc):   yes
Modeling Light:   yes

Initially, I misunderstood the working principle of the flash, and thought that I had to supply the 4.49V trigger voltage to the camera, and designed my circuit to do that. However, when I used a benchtop power supply to apply 4.49V across the flash terminals, nothing happened. I manually fired the flash (there's a button you can press) to check that the batteris were charged and the flash was otherwise OK, and it fired fine. I was somewhat confused, and decided to try just completing the circuit without providing a voltage. During all this time I was quite concerned, and asked different people for their opinions and expertise regarding the risk of breaking the flash. There was a lot of information on-line about how a mismatched flash can break a camera, but there was little information on if I might accidentally break my flash by hooking it up wrong. After some playing around with a multimeter and talking with other students in the lab, I found out that the flash itself has a 4.49V difference between the positive and negative terminals, and that when it flashes it pulls down the voltage across the terminals to 0V, and only flashes when the voltage drops from 4.49V to 0V (in other words, it does not flash repeatedly if the voltage is kept at 0V by completing the circuit, or when the circuit is disconnected and the voltage difference goes back to 4.49V).
No one seemed to be very confident in knowing how the flash actually works, and what is going on inside, so I was still somewhat concerned. I reasoned, that as long as the current flowing through the flash is low enough, I won't break anything. (PS. If anyone has a good understanding of how the flash circuitry works, and how one might accidentally break it, please let me know.) I therefore soldered together some wires and resistors, to check if the flash would trigger even at low current levels.
I taped two wires to the flash, to make testing easier. One to the inner positive pin of the Prontor-Compur (PC) terminal, and one to the outer (ground) shell. I then connected the resistors to the wires. I started with the 10 MΩ resistor (which I thought would trigger the flash) but nothing happened. It seems that some current has to flow. So I worked my way down...
...from 10 MΩ, to 1 MΩm to 100 kΩ, to 10 kΩ, to 1 kΩ...   *  F - L - A - S - H  *    So now I knew that the flash would trigger somewhere between 10 kΩ and 1 kΩ. I then went up to 5 kΩ, which did not trigger the flash. I tried 2.5 kΩ (2 x 5 kΩ in parallel), which also, did not trigger the flash. I then went to 1.67 kΩ (3 x 5 kΩ in parallel), which triggered the flash. I figured this was close enough. I now knew the flash would trigger with a 1.67 kΩ resistor, but would not trigger with a 2.5 kΩ resistor in the flash circuit.
Next step was to figure out how the PC-cord was wired. I was assuming that the outer shell of the PC end (which connects to GND on the flash) would be wired to the sleeve on the 3.5mm audiojack, and that the center pin on the PC end, would be connected to the tip of the audiojack. I checked this with a multimeter, and confirmed that this was indeed the case.

As a post script, if I were to buy a 3.5mm audio to PC-connector cable now, I would probably spend a few dollars more and get one with threads on the PC end. The smooth connector that I have is quite terrible and easily slips off the PC-terminal on the flash unit. Since I went cheap on the cable, I will probably have to use a rubber band to make sure the cable stays on the flash during use.
As a side note, I initially used this reddish / copper coloured wire to test the flash and nothing happened. I finally took a multimeter to the wire and realized it was coated with a thin layer of plastic. I ended up using the wire with the thick plastic coating, that I just stripped where I needed to make contact with the wires. Also, here you can see the PC terminal of the flash up close.
After confirming that I could trigger the flash through the PC terminal, I set about to create the circuitry that I would need. My hope was that I would be able to adjust the threshold values for sound volume and frequency, adjust the delay between the sound and flash triggering (something which many people adjust simply by placing the microphone closer or further from the source, and have it work with varying power supplies. I made several pages of doodles with the help of the TA for this week, and tried to figure out what the needed components were.
This is the final board design that I decided to mill. A larger resolution image of the traces can be found here, and larger version of the schematic can be found here. Since I only had one 3.5mm audio jack connector, and very limited time, I did not see it as a good use of my time to try and learn how to add new components into the Eagle fab library. I therefore just looked at the datasheet for the audio jack, and drew in squares for the pads in the correct locations. I used a tight grid (0.01 in) to place the pads, and just rounded up to the closest 0.01 in. The 'PC-to-flash' resistor that is placed outside the board was just used as a placeholder for the flash connector, so that I could create the schematic and route the wires for the board.
From previous experience, I knew that I may need an extra board at some point, so I decided to make three in one sitting, to save time on tool changes. So I milled out the traces for three boards, and then began to cut the holes and outlines. It was late, and I was tired, so I wasn't paying enough attention to what I was doing and forgot to invert the image that I had. The result was that the mill cut on the 'wrong side' of the cutting line, making the holes too big, and the outer circumference too small, ruining my board. One down, two to go. I inverted the image, but noticed that there was not enough room on the edges of the picture for the mill to fit all the way around, so I had to increase the canvas size of the image so that there was enough white space around the circle for the mill to fit all the way around and to cut out the circle properly (it would have left tabs connecting my board to the sheet that I was cutting it out of). I made sure the second cutout path was correct by first cutting air. It was hard to be sure if the holes were in the correct place since the tolerances are so small, but the outline seemed fine, so I trusted the inner holes would be OK as well, and come out the way I had designed them. I cut out the second board, and it seemed to come out fine. As I was cutting the holes on the third board it came loose as it had cut the outline first (I don't know if the fab modules allow the user to choose the order of the cuts, but I was unable to figure out how one would do that). The third board was luckily not destroyed, but the holes are certainly not round.

So, at the end of the day, I had one destroyed board which flew in the trash, one board with non-circular holes, and a third board that was almost good (on closer inspection the holes were not totally round in this one either, but they were close enough). There was discussion during class about boards coming loose, and the solution being to clean the bed, but I had just cleaned it before beginning to mill. I had previously not had this issue, so I suspect the issue was that I put down a new sacrificial layer which I did not mill flat (as Prof. Gershenfeld had suggested during class that this was unnecessary). As far as I can tell, the only difference this time around which could explain the board coming unstuck was the fact that it was taped down to copper, whereas earlier it was stuck to the board material (as the copper had been milled off the top surface of the sacrificial layer). It seems strange that the copper would be less sticky, but perhaps the un-milled board was not straight enough for a good adhesion? Or perhaps the double sided tape we are using is just bad / old. As a sidenote, the reason for the holes is that I am envisioning the board being connected into its holding case with snap connections.
Some early designs for the case. The microphone will be located in the middle of the 'pod'. The design on the left: an aesthetically pleasing round 'puck' that can only be placed flat (microphone pointing up). The middle, triangle, concept can be placed flat (similar to the round puck), but it can also be placed at an angle, by laying it on one of its sides. All three sides have a slightly different angle, so depending on which side the microphone is placed on, it could either point straight up, or at an angle (three different angle options) towards the anticipated source of the sound. The concept on the right attempts to combine the two earlier ones, with the round aesthetic, but a single cutoff side allowing the user to place it at an angle, in addition to simply straight up.

The microphone sound trigger did not end up working in the end, and I am still debugging the problem. My current assumption is, that the basic circuit diagram is incorrect, which would not surprise me. As the design was over my capabilities, I had to ask for help, and as the same person was not always available, the circuit is the result of my own attempts, with additions from three different TA's, two friends and a classmate. With an input voltage of around 8V, the microcontroller is only receiving a bit over a volt. The microcontroller needs between 2.7V - 5.5V, as seen in the datasheet.   The work continues...