Wireless ETTL flash conversion

Project Logs

Collapse

Godox support & bigger batteries
lion mclionhead • 07/06/2023 at 18:13 • 0 comments

The 250mAh died really fast, so in went 380mAh. It barely fit in the transmitter, with much coaxing. There might still be room in the receiver for a bigger battery.

The 15 year old 580 EX II finally died from some unknown semiconductor, transformer, or capacitor failure. It wasn't the tube this time. It no longer charged its capacitor above 5V. It was decided to replace it with a much cheaper Godox TT685 but still use the home made radio to control it instead of Godox's own radio.

The trick with the Godox is it has an aiming light which turns on when the ID pin is high. The wireless firmware needed to turn off ID when taking a picture. Sadly, the aiming light is very short range & has a parallax error at short range but it's better than nothing.

The leading idea for a superior aiming light has been firing the flash at lowest power, once per second, when ID was high. This would entail a new enclosure with another button. Expanding the receiver would be better than expanding the camera.

The modeling light trigger would have to coincide with the metering packets so it wouldn't conflict with the flash trigger.
Gremlins
lion mclionhead • 12/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 mclionhead • 12/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 mclionhead • 12/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 mclionhead • 12/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 mclionhead • 12/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 mclionhead • 12/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 mclionhead • 12/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 mclionhead • 12/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 mclionhead • 12/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.