Close
0%
0%

Wireless ETTL flash conversion

Convert a vintage flash to wireless with full ETTL

Similar projects worth following
593 views
0 followers

Cheap flash radio sets are manual only & very unreliable.

True wireless ETTL starts with a $110 Godox radio set.  The decision was made to try to do it with spare parts & save 1 day of rent.  Wireless ETTL is actually a difficult problem.  You can't sample all 5 pins & send it over the air.  It would take many megabits & microsecond latency.  The workaround is to simulate a flash connected to the camera & simulate a camera connected to the flash.  Between the 2, there's an abstraction of the pin signals.  The trick is implementing enough of the ETTL protocol to simulate the gadgets, error protection & precise timing.

This can form the basis of converting any manual flash to full ETTL.

  • Gremlins

    lion mclionhead12/22/2022 at 01:58 0 comments

    Receiver tends to die at random.  Changing channels doesn't get it back.  Could be the UART RX getting into a dead state. 

     It still sometimes appears to underexpose at 100mm F16 1/100.  Then the problem goes away on its own.

    To get the bugs to happen more, the batteries got buttoned up & the debugging headers got put away.

  • Channel selection

    lion mclionhead12/20/2022 at 19:33 0 comments

    This feature definitely required debugging headers.  The trick with channel selection is there aren't enough clockcycles to poll the button pin or increment a tick counter.  It needs its own loop inside an interrupt handler which runs when the button is pressed.  

  • Fudge factor #1

    lion mclionhead12/19/2022 at 04:47 0 comments

    All the exposures came out OK except for 100mm.  Something about that lens made it always over expose.  It sends much higher power over wireless than wired.  Having a way to expose the debugging header on the outside of the enclosure is essential.

    If it's stopped way down, it properly exposes because it sends maximum power no matter what.  If it's wide open, the exposure with 100mm is equally as overexposed as the other lenses.  It's computing a good power level, then adding a fixed offset, rather than always setting full power.  The minimum flash power is in the 0x60's.  If it adds the offset to a 0x40 value, the new value is still below the minimum.  

    After much tracking of packet values, the value of offset 6 in MANE_FLASH1 (ISO code from flash) actually causes it to overexpose.  This value is based on lens & ISO:

    200mm ISO 100,1600: 0x64

    100mm ISO 100,3200: 0x62

    50mm ISO 100,3200: 0x5d

    35mm ISO 100,400,3200: 0x5a

    28mm ISO 100: 0x36

    28mm ISO 200: 0x36

    28mm ISO 400: 0x3e

    28mm ISO 800: 0x46

    17mm ISO 100,200: 0x34

    17mm ISO 400: 0x3c

    17mm ISO 1600: 0x4c

    17mm ISO 3200: 0x54

    15mm ISO 100, 200, 400, 800, 1600: 0x54

    Only 2 lenses have variations by ISO.  It might also depend on shutter speed.

    2 way communication won't fix it.  It only occurs in MANE_FLASH1.  

    The options are copying every single code or just using 0x62 for all the lenses.

    It doesn't bode well for retrofitting a manual flash if every lens & ISO requires a different fudge factor.  100mm is the only one to require fudge factor 0x62.  All the other lenses specify different fudge factors, yet give exactly the correct exposure, wireless & wired, with fudge factor 0x62.  The camera must have a similar table telling it to apply fudge factor differently for every lens, manely ignoring it except for 100mm.

    With the 100mm working, it was finally time for some shots that were impossible with wired flash.  The next steps are making the packets repeat as long as possible & channel selection.

  • Enclosure #3

    lion mclionhead12/17/2022 at 23:58 0 comments

    After 1 week of prototypes, nothing converged on a good design.  Interfacing with a commercial part, the need for 2 mirror images, & filament deposition limitations made this one particularly difficult.  There was a slow trend towards better designs.  1 idea was to try to make the flash & camera side as common as possible.

    Flying leads above & below the mane board were arguably working out better than all the leads below the mane board.  The battery was more accessible with flying leads above & below the mane board.  There was more room if the mane board was between the switches & battery.

    The battery requires a splitter to go to the charger & mane board.

    The flash enclosure had to be wider just to have enough room to install farsteners from above.  The bottom has to be flat to sit on a tripod.  Electronicals in the flash enclosure went above the switches to leave enough room for the tripod screw.  The flying leads have to go up to the flash & down to the switches.  The height of the flash enclosure was dictated by the height of the m1.5 farsteners.  Those are irreplaceable so there's no desire to shorten them.

    Meanwhile, the camera enclosure has to be narrow, with farsteners installed from above.  The board in that one went above the switches, which entailed passing all the wires from the camera & passing the mane board between the switches during the assembly.  It was not as easy as having the mane board between the switches & camera.

    A lot of effort went into keeping the original Pixel parts unchanged.  Destiny has the original farsteners getting stripped & the original Pixel parts having to be modified to accept m2.6's.  This will involve drilling new holes & inserting a single big farstener from above the flash enclosure & below the camera enclosure into a single PLA standoff.  They won't be as secure as the 4 stock farsteners, but the good news is they'll get a lot more compact.

    There's still a mountain of software to write for configuring the frequency.  Exposure is still way off.  The battery leads need some rework to make them stronger.  The camera enclosure may get another redesign to move the board below the switches.  The flash enclosure seems acceptable.

  • Enclosure #2

    lion mclionhead12/15/2022 at 20:26 0 comments

    This was the lion  kingdom's 1st attempt at using plastic rivets to replace all the hot gluing.  Plastic rivets are truly hated in commercial products because they don't allow any servicing without destroying the enclosure, but not so when you can just print a new enclosure.  Plastic rivets take a lot less space than hot glue.  Many printed designs could use plastic farsteners that melt into position.

    The general idea is to have a tall & a short piece side by side.  Create an overhang over the short piece by melting the tall piece.  It requires a hoof tip at 300C.  The trick is to move slowly so a blob of plastic forms in front of the soldering iron & doesn't get pushed to the side.  If it's 2 PLA pieces, they can be fused together.  If it's a PLA rivet with an electronic part, you have to push the overhang over the part without getting too close to the part.

    An attempt was made at a PLA tripod head, threaded with a 1/4-20 tap originally bought for rethreading motors.  It went through PLA a lot easier than aluminum.  This showed promise for at least flashes.

    Removing the scotch from the camera side would require a nasty side mounted board carrier.  The flash side required a nasty board carrier & side mounting the board to clear the standoffs.

    The antennas would ideally both point straight ahead.  It's not worth building new boards with repositioned radios.  The flash side would have to get 2mm taller to not rotate the board but it would get narrower.  The 2 enclosures could have board carriers with forward facing antennas & no scotch.  Then, the switch assembly on both enclosures could be straight lined.

  • Enclosure #1

    lion mclionhead12/14/2022 at 06:07 0 comments

    It was a pretty slick, flat thing the same size as the wired adapter.

    Standoffs in the flash side prevented the board from going low enough to fit under the switches.  The object of the game is to remove the least amount of material from the wired adapter.

    The flash side could be taller.  It could also be wider so the switches straddle the board.  The board could be rotated to fit between the standoffs & the antenna would stick out sideways.

    Another problem with the flash side is attaching it to a tripod.  Scotching it together isn't strong enough.  It might need a clamshell which wraps around the stock adapter. It could also use the stock self tappers to screw together.

    The camera side had a bit more room.  The problem is getting the antenna into the tube while it's connected to the buttons.  It's going to need to pack really long wires into the enclosure.  It might require a bigger enclosure just to pack enough wire to service it.

    The antenna tube could be on a separate sliding thing after the board is installed.  There could be a small slit in the tube mount to slide the antenna in, then the tube could be inserted after the antenna.  

    The antenna needs to be slightly off center because of interference with a nub in the adapter.

    The switches aren't securely farstened.  They really need something clamping from above or the sides.  The LED is barely farstened because there's no way to get glue on the biggest surface.  The LED needs a horizontal surface on 1 side to glue on to.  

    The camera enclosure probably doesn't need to grow.  The flash enclosure definitely needs to grow.



    The camera side burns 75mA & the flash side burns 60mA so a 200mAh might be enough.  The transmitter desperately needs a power saving timeout to save on 15mA & to free up the airwaves.  The problem is starting the radio takes 5ms in which it can't do anything.  It would have to start after METERING1 & drop METERING2.  There is a way to use a timer to delay the radio UART in the background & get it to return to detecting packets faster.

    A similar timeout is needed to manage the ID pin, but ID pin is absolutely not used for anything.  It might make the debugging easier if it conforms some flash responses. The limiting factor for size is not the battery but the switches.

    A hard lesson learned is when using MHPS switches as power buttons, you need to have a guard to prevent them from turning on by accident & destroying the battery.  Unfortunately, this isn't possible when the power button is expected to be quickly toggled during normal use.  MHPS switches have still done better than sliding switches because they're resistant to dirt.

  • Exposure compensation

    lion mclionhead12/13/2022 at 07:07 0 comments

    Bidirectional communication would entail switching to receive mode after sending METERING2 for a certain amount of time & switching back to transmitting.  The receiver would switch to transmit mode a certain time after METERING2 & resend its status a few times.  There can't be any detection of packets during the reversed mode since there aren't enough clockcycles.

    METERING1 typically comes 90ms after METERING2.  MANUAL FLASH has been seen 14ms after METERING2.  PREFLASH1 has been seen 15ms after METERING2.  The time measurements are from the 1st byte of the previous packet to the 1st byte of the next packet.

    A certain amount of time is required to capture, transmit & replay METERING2 on the flash.  After METERING2, it would spend 5ms switching radio modes. 5ms would go to a window for receiving the status.  Another 5ms would go to switching radio modes again.  For 15 ms after METERING2, it couldn't receive any packets.  There's a good chance of it missing a FLASH packet.

    There's always the chance a METERING2 is never sent before the exposure but chances are high that at least 1 flash state would make it to the camera.  It most certainly requires 2 radios to be reliable.


    An easier but less capable solution is to simulate the mode on the flash.  Exposure compensation just adds a fixed offset to the power & shows a setting in the viewfinder.  All multi does is send MANUAL FLASH instead of MANE FLASH1.  Manual mode would eliminate the preflash delay but no lion has ever used an off camera flash in manual mode, let alone desiring lower latency.  2nd curtain sync just reverses the trigger signals.

    The trick is the flash times out after waiting for a trigger for 1 second, to avoid crashing.  2nd curtain sync & multi would entail waiting for codes without having any timeout.  These modes have never been used by lion & they could be implemented later if the need arose.

    Of course, there's always the desire for the most complete solution possible, just for shits & giggles, but we have to move on to the user interface, enclosure.  The biggest loss might be the icons in the viewfinder for the flash mode.  It's basically halfway between a Neewer which does nothing & the Godox which does everything.  It's just enough.

    It's impressive that Godox employees in China implemented enough of the ETTL protocol to support all modes on all flashes, but they paid for a license, had full documentation, & had unlimited money.  They might have 2 radios for 2 way communication but lions have never seen that in a consumer product.

  • Simulated Camera

    lion mclionhead12/12/2022 at 18:49 0 comments

    The receiver could be made with just a PIC, but it took an STM32 to prove it.  The mane problem is generating 0, 2, & 3.3V for CLK & D2.  That would take a resistor ladder & 2 GPIOs for each signal.  10 years ago, it wouldn't be worth it.  Today, mixed signal microcontrollers belong in a museum.

    The great challenge with this is error correction.  The decision was made to prioritize error protection above high speed sync.  It would repeat the trigger packets several times.  The problem with this is it doesn't allow using a voltage change as the trigger.  Instead of a voltage change signifying the triggers, it would use a certain number of of consecutive characters not part of the standard packets.  Then, there would be a timeout if it doesn't get any trigger characters.

    The latency of a 4 character sequence is going to be 400us at 100000 baud.

    Another optimization is compressing the packets.  1 idea was just sending all the differences from the ref packets, but that led to the mane flash packet being 2.1ms while the smallest packet is 1.4ms.  There's a lot of redundancy.  The mane flash could be compressed to 1.7ms.  That increases the mane flash repeats from 3 to 4.  Unfortunately, this requires a lot of logic & it it's more vulnerable to unforeseen protocol variations.

    Another idea is just increasing the baud rate to 200000.

    Besides the highest speeds, another thing getting dropped is manual mode. That was only ever used for photographing very fast objects & never off camera.  It would require moving data from the flash to the camera with a lot more logic.  If the camera doesn't know it's in manual mode, it delays for the preflash but it otherwise works.

    It takes 5ms to switch the radio between receive & transmit.  Even with ACKs, the reliability wouldn't improve since they would reduce the number of repeats. It wouldn't be possible to wait for an ACK & resend during the flash sequence.  Without an ACK, it can always resend.


    After much testing, it finally took its 1st pictures with the wireless flash.  ETTL 1/100s worked.  Manual mode worked, though it had a delay for a preflash.  Exposure compensation & multi didn't work.  The lion kingdom never used multi, but exposure compensation has to work, so it needs 2 way communication.

    High speed mode worked to the 1/4000 maximum with debouncing set to 4 characters.  High speed mode worked in ETTL or manual mode.  Triggers fired 250us late with a 4 character debounce & 150us late with a 2 character debounce.  It was surprising how correlated the delay was to the serial port speed.  The latency of a digital signal is microscopic compared to what a mechanical shutter considers fast.

  • Simulated flash

    lion mclionhead12/10/2022 at 23:31 0 comments

    The next step was simulating the flash for the camera. The journey begins with driving the DAC connected to D1 to simulate the "from flash" signal.  Apparently, it expects D1 to be held on the last bit for a while, then lowered for a while to signify busy, then raised as a form of flow control.

    Helas, the packets from the camera are not constant length as they were when using the real flash.  There are insertions, deletions, & transpositions.  It somehow knows the flash is simulated despite getting a byte for byte replica.  

    The real flash has variations in the length of its busy period but it actually looks like the camera has a minimum break between bytes.  It was confirmed to definitely wait for the CLK to go low & high by simulating very long busy periods.

    But more importantly, the real flash has transitions right on the falling edge while the simulated flash is right against the rising edge.  It's probably seeing data corruption from the simulated flash.  The simulated flash reads back its own data using its own delayed ADC so it doesn't see the data corruption.

    Then a lion realized it might be faster to flip the GPIO between analog & digital to get it to change between 2V & 3V faster.  This is only possible on the STM32 by enabling & disabling the DAC.  This did indeed buy just enough time to eliminate the glitches.  It actually went through the full metering & exposure with simulated packets.  More margin could be bought with overclocking.

    An electronically simulated flash was a big step towards wireless, converting a vintage flash to ETTL, & building custom flashes.  The next step is simulating the camera for the flash.

  • Timing & camera settings

    lion mclionhead12/09/2022 at 19:44 0 comments

    Got some more packets with timing values for key bits.

    8e/ff 8e/b5 de/4c 8e/e5 0d/ff 8e/a9 91/25 8e/a1
    2b/f8 2b/a5 00/2c 8e/b9 00/80 8e/bd 18/00 69/23
    23/99 ff/fb 02/ff 8e/f9 55/ff 8e/f7 7b/ff 8e/b3
    00/12 00/46 00/2f 00/f5 57/ff 49/ff 5c/ff 0f/ff
    00/be 8e/14 8e/bb 00/48 00/ff 8e/e6 3f/ff 10/ff
    00/ff 8e/b7 8e/38 8e/b8 8e/6d 8e/b4 8e/1d 8e/a8
    91/00 8e/a5 00/2d 
    X 0V 100uS
    
    X 3.3V 400uS
    8e/a5 01/2c 
    PACKET SIZE: 53 96000uS
    8e/ff 8e/b5 de/4c 8e/e5 0d/ff 8e/a9 91/25 8e/a1
    2b/f8 2b/a5 00/2c 8e/b9 00/80 8e/bd 18/00 69/23
    23/99 ff/fb 02/ff 8e/f9 55/ff 8e/f7 7b/ff 8e/b3
    00/12 00/46 00/2f 00/f5 57/ff 49/ff 5c/ff 0f/ff
    00/be 8e/14 8e/bb 00/48 00/ff 8e/e6 3f/ff 10/ff
    00/ff 8e/b7 8e/38 8e/b8 8e/6d 8e/b4 8e/1d 8e/a8
    91/00 8e/a5 00/2d 
    X 0V 100uS
    
    X 3.3V 400uS
    8e/a5 01/2c 
    PACKET SIZE: 53 24000uS
    8e/ff 8e/b4 8e/1d 8e/f2 c0/ff 8e/ff 8e/b4 8e/03
    8e/f2 a0/ff 8e/b0 8e/80 8e/b1 8e/04 8e/b3 00/12
    00/46 00/2f 
    PACKET SIZE: 18 64000uS
    00/b4 8e/23 
    CLK 0V 24000uS
    
    CLK 3.3V 30000uS
    
    PACKET SIZE: 2 30000uS
    7f/ff 8e/b3 00/32 00/46 00/2f 00/f8 3a/ff 8e/bb
    00/48 00/ff 8e/b7 8e/38 8e/b8 8e/6d 8e/b0 8e/88
    8e/b4 8e/1d 8e/f2 c0/ff 8e/b3 00/36 00/46 00/2f
    00/b4 8e/3d 
    CLK 0V 16000uS
    
    X 0V 20000uS
    
    X 3.3V 30000uS
    
    CLK 3.3V 40000uS
    
    
    PACKET SIZE: 26 40000uS
    7f/b4 8e/1d 8e/b3 00/12 00/46 00/2f 00/fc 88/ff
    c0/ff 1a/ff 2a/ff 85/ff 78/ff 
    
    8e/ff 8e/b5 de/4c
    8e/e5 0d/ff 8e/a9 91/25 8e/a1 2b/f8 2b/a5 00/2c
    8e/b9 00/80 8e/bd 18/00 69/23 23/99 ff/fb 02/ff
    8e/f9 55/ff 8e/f7 7b/ff 8e/b3 00/12 00/46 00/2f
    00/f5 57/ff 49/ff 5c/ff 0f/ff 00/be 8e/14 8e/bb
    00/48 00/ff 8e/e6 3f/ff 10/ff 00/ff 8e/b7 8e/38
    8e/b8 8e/6d 8e/b4 8e/1d 8e/a8 91/00 
    

    The timing values are uS since the last byte.

    The minimum time before a packet is 

    90ms before 8e/ff 8e/b5 metering

    20ms before 8e/ff 8e/b4 preflash

    20ms before 7f/ff 8e/b3 mane flash

    There's no delay between the mane flash 2a/ff 85/ff 78/ff & next metering packet 8e/ff 8e/b5

    This is actually a separate packet which occurs after metering repeat, power on, metering start:

    8e/a5 00/2d 
    
    X 0V 66uS
    X 3.3V 237uS
    
    8e/a5 01/2c 

    There's no delay before it & it doesn't always occur.

    There's up to a 60ms delay in the preflash packet before 00/b4 8e/23.

    Time between the preflash packet & preflash trigger CLK 0V is 20ms at minimum.

    Time between the mane flash packet & mane flash trigger CLK 0V is 16ms at minimum.

    Then the time between CLK 0V & X 0V is 1ms at minimum.

    X is held down for the duration of the shutter speed.

    For 2nd curtain sync, the trigger starts up reversed.  X fires 1st, then CLK is fired at the end of the exposure.

    MANE FLASH1 235uS
    7f/ff 8e/b3 00/32 00/46 00/2f 00/f8 26*/ff 8e/bb
    00/48 00/ff 8e/b7 8e/50* 8e/b8 8e/38* 8e/b0 8e/a2*
    8e/b4 8e/1d 8e/f2 c0/ff 8e/b3 00/36 00/46 00/2f
    00/b4 8e/3d
    X 0V 22704uS
    
    CLK 0V 1005237uS
    
    X 3.3V 1017336uS
    
    CLK 3.3V 1023915uS
    
    MANE FLASH2 225uS
    

    Eventually, the protocol was divided into 9 discrete packets identified by 1-4 starting bytes

    ?? b5 4c ff POWERON
    ?? b5 4c e5 METERING1
    a5 METERING2
    ?? b4 PREFLASH1
    b4 23 PREFLASH2 
    ?? b3 MANE FLASH1  
    b4 1d MANE FLASH2 
    b4 25 FAST FLASH
    bb MANUAL FLASH

    Shutter speeds of 1/200 & above introduce an extra b4 25 after MANE FLASH1 & show the high speed icon in the camera LCD.


    The next step was putting reference captures of all the packets in the firmware & beginning to parse the variable bits.  This was the beginning of yet another long slog through corner cases.

    POWERON:

    offset 15,38 FROM FLASH: exposure compensation

    18=-3

    15=-2 2/3

    13=-2 1/3

    10=-2

    0d=-1 2/3

    0b=-1 1/3

    08=-1

    05=-2/3

    03=-1/3

    00=none

    fd=+1/3

    fb=+2/3

    f8=+1

    f5=+1 1/3

    f3=+1 2/3

    f0=+2

    ed=+2 1/3

    eb=+2 2/3

    e8=+3

    offset 18 TO FLASH: focal length in mm  Max 255

    offset 38 TO FLASH: ISO code

    48=100

    50=200

    58=400

    60=800

    68=1600

    70=3200

    88=25,600

    8d=40,000

    offset 42 FROM FLASH: mode code.  These values are only for 90 deg.

    00=ETTL...

    Read more »

View all 17 project logs

Enjoy this project?

Share

Discussions

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates