Godox X receiver for Olympus FL-36 flash

I began with the principle that reverse engineering should always start with official documentation and manuals.

One of the newest transmitters is the X3Pro (https://www.godox.com/product-e/X3Pro.html).

The product page confirms what I already knew:

As expected, there is no Olympus support in the receiver device line.

Several pieces of summary information are scattered throughout the product pages and manuals. The devices support 32 different channels and up to 16 different flash groups. While noteworthy, this information alone was not particularly useful for protocol analysis.

However, I found several interesting details in the manual chapter about shooting modes. The so-called "All-shoot" mode allows multiple transmitters to share the same flashes with no extra configuration beyond the channel number. This indicates there is no device pairing or transmitter-specific encryption.

I also discovered a compatibility mode with the Sekonic L-858 light meter, which suggested I might find additional information in the Sekonic manual. That manual references the RT-GX Godox-compatible module, and chapter 5 contains a channel table with corresponding frequencies.

All electronic devices must disclose certain information to government regulators such as the FCC in the United States.

Another valuable source of information consists of YouTube videos and blogs where enthusiasts open devices and post photographs of their internal components.

Before purchasing any additional hardware or chips, I decided to put my HackRF One to good use. This software-defined radio can receive (and transmit) signals in the necessary frequency range.

I conducted my first examination using the Gqrx software-defined radio receiver.

Some adjustment of the sample rate and processing speed was required because the signals appeared to be quite brief.

The spectrum appears as follows:

The spectrum already reveals interesting information. The MSK Wikipedia article describes a relationship between the frequency peaks and the symbol rate:

The strongest peaks at the edges of the main spectrum block are precisely 250 kHz apart, which likely corresponds to the data rate.

With this information, I had sufficient knowledge to attempt building a receiver.

To confirm my findings, I constructed a simple decoder using GNU Radio. GNU Radio Companion makes it relatively straightforward to connect signal processing blocks and experiment with various radio modulation parameters.

Here is what I constructed (the final solution; blocks I used during the exploratory phase are left disabled):

I used file sink blocks to dump the raw bitstream (inverted according to the CC2500 datasheet) to a file and then searched for synchronization patterns.

Since there are no byte boundaries in the raw bitstream, this analysis was somewhat challenging. However, I could search for sequences of 10101010 (or the inverted version) to identify candidate messages.

I found a consistent byte pattern following the preamble: 1100001101101000 (0xC3 0x68).

I performed a simple analysis using bash to estimate message length. By varying the prefix length used by the uniq command for comparison and observing the number of matching messages, I determined that messages were relatively short (prefixes longer than 4 bytes showed insufficient repetition).

I implemented the decoder as a custom Python block that searches for the sync pattern. It successfully receives consistent byte sequences each time I press the test trigger button on the Godox transmitter.

I observed a clear pattern in the commands, though I noticed slight variations in the command set received with each attempt. The GNU Radio flowgraph could not reliably receive and decode all messages consistently, and my GNU Radio expertise was insufficient to resolve this issue. However, I am more proficient with hardware electronics.

I was reluctant to damage my new transmitter, but an opportunity arose to purchase a used Godox X1T-S transmitter at a very low price. According to its documentation, this model is compatible with the Godox X 2.4 GHz protocol, and photographs on the FCC website confirm it uses the same hardware design.

Having conducted reverse engineering projects previously, I had several tools available to assist with this analysis.

First, I had a hardware analysis rig. I 3D-printed a platform with probe needles based on the PCB Workstation with Nano-Probes design. My needles were somewhat cruder than the original design, but they proved adequate for this task.

Using the CC2500 datasheet to identify the control pins, I located them on the X1T-S PCB and determined the optimal probing points.

Fortunately, the device employs current-limiting resistors for all SPI-related traces, which served as excellent targets for the probe needles.

I connected this setup to a logic analyzer, configured the SPI decoders, and monitored the communication between the CC2500 and the main CPU.

The analysis confirmed my earlier suspicions. The frequency, bandwidth, and sync words matched expectations, as did the data bitrate. I also confirmed that packets are 4 bytes in length.

While the SPI probe rig worked well, it was somewhat unwieldy and prone to connection issues when disturbed. In short, the probe needles did not maintain reliable contact, I tended to bump the setup, and there were too many wires cluttering my workspace.

The time had come to build a dedicated hardware receiver. Unfortunately, fully functional CC2500-based modules are not readily available locally, and I lacked the patience to design and fabricate a module from scratch (including all the necessary filtering and RF components).

I found an online shop in the Netherlands with available modules and purchased several: tinytronics.nl. While probably not the most economical solution, it was the fastest.

I needed a microcontroller capable of handling the protocol’s speed requirements. My usual microcontroller choices were marginally too slow for the required SPI speed, so I selected an inexpensive RP2040 module. I implemented a simple receiver that forwarded all Godox protocol bytes over USB to my computer.

With the receiver operational, it was time to record and analyze various message types. I used the XProII transmitter, systematically selecting different groups, modes, and functions while observing the resulting messages.

Manual power settings, modeling lamps, and beepers were straightforward to decode. However, the trigger sequences proved more complex.

Although I present the Godox analysis first in this document, I actually analyzed both the Godox and Olympus protocols simultaneously to correlate timing relationships.

The test setup became quite cluttered during this phase. You may also notice I used a different RP2040 board (a Challenger RP2040 LTE Mk.II) in the photographs. I work on multiple projects and simply used available hardware before I finalized my selection of the final CPU.

To decode the trigger commands, I used the cabling from my Olympus analysis (described in a later section) and constructed a simple photodiode sensor—merely a photodiode that shorted a pull-up resistor to ground—which I attached to the flash head. I then used my logic analyzer to simultaneously record the camera commands to the Godox transmitter, the received radio commands on the CC2500 side, and the analog voltage levels from the photodiode.

The photodiode setup was not ideal; the flash generated significant electrical noise during capacitor charging, and the voltage drop during firing was smaller than desired. Nevertheless, it proved sufficient for identifying flash firing events.

During this testing phase, I also needed to determine how power levels are encoded. I systematically increased the manual power by 1/3 EV increments, recorded each message, and repeated this across the entire range (−3 EV to +3 EV). This revealed that Godox employs 1/10th of a stop resolution.

The following is a comprehensive list of all messages I identified and decoded.

Flash groups receive their configuration as 4-byte messages. The flashes do not send acknowledgements.

where group is 0xA, 0xB, 0xC, …​, 0xE for the standard 6 groups and 0xF, 0x1, 0x2, …​, 0x0 for the additional 10 groups.

Configuration can also be broadcast to all groups simultaneously. This is primarily used for TTL triggers, which I describe later.

Broadcast transmissions use a special group code of 0x50.

In addition to group-specific commands, global short commands exist. These trigger messages utilize only two meaningful bytes, although they are received into the same 4-byte buffer.

The various settings I identified are:

The Olympus hot shoe uses the ISO standard center trigger contact plus four additional smaller contacts positioned identically to Canon hot shoes (though with different functions).

Fortuitously, a Canon extension cable can be used for off-camera operation of Olympus speedlights, which would later allow me to intercept the protocol communication by opening the cable.

I began with simple multimeter measurements of each pin relative to ground.

For orientation, the following description refers to the side with the safety pin hole as the "top side." I conducted all tests with an aging Olympus E-30 DSLR to avoid any risk of damaging my newer camera bodies.

While the photograph shows the pin functions, I determined those later. Initially, I focused solely on electrical characteristics.

The bottom right camera pin measured 3.3 V with a short-circuit current of 313 µA, suggesting a 10 kΩ pull-up resistor.

The top right camera pin showed no voltage, but the corresponding FL-36 flash pin measured 5 V with 100 µA short-circuit current (indicating a 50 kΩ pull-up).

The bottom left pin and the center trigger pin exhibited identical characteristics: 5 V and 100 µA on the flash unit.

The top left power pin is present only on newer camera models. Older models provide only the communication and sense pins.

I cut open the extension cable to expose the inner wires.

I then attached a breakout connector (2×3 pin) to create a more reliable measurement setup and connected the logic analyzer probes to observe the communication.

This specific cable model (I have three identical units) uses the shield for ground and employs the following wire color assignments:

The camera communicates using a full-duplex asynchronous serial protocol at 20,800 baud with standard 8N1 configuration (8 data bits, no parity, 1 stop bit).

All signaling employs open-drain connections. The receiving side provides a pull-up resistor to its own logic high voltage, while the sending side pulls the line to ground to transmit a logic zero. This architecture applies to all signals, including the trigger.

Decoding the Olympus TTL protocol proved more challenging than the Godox protocol.

I collected hundreds of protocol exchange samples while systematically varying camera and flash settings. I methodically modified shooting modes, shutter speeds, apertures, flash head zoom positions, camera focal lengths, exposure compensation settings, and—critically—flash exposure compensation both on the camera and on the flash unit itself.

I also collected maximum flash power samples by recording TTL mode exchanges with the lens cap attached (producing completely dark frames). I tested this configuration across various apertures and zoom levels.

This flash power testing revealed the checksum pattern. The 0x03 command was brief, and modifying power levels consistently altered two "parameter" bytes rather than one. These two bytes invariably differed by 0x03. This was speculative reasoning, but it proved correct. I then applied the same hypothesis to the 0x87 command, which also matched. Extending this pattern to the 0x82 command required only moments.

Next, I attempted to locate power level information in the flash’s status responses. I discovered that the first pre-flash power consistently matched the lower 7 bits of byte 2, while the main flash power matched the lower 7 bits of byte 1 in the 0x82 command response. (This correlation took considerable time to identify.)

I repeated this analysis with the flash in high-speed sync mode and found analogous behavior, but using byte 4. The high speed sync mode triggers a long burst sequence and while the maximal reported power changes with shutter speed, the flash burst is always about 8 milliseconds long.

I also conducted power tests with the lens cap removed, using a gray cloth as a target. This revealed that camera-side flash exposure compensation can reduce flash power below the value stored in byte 2 (the first pre-flash value). This led me to conclude that the first pre-flash uses a fixed power level (likely 1/128 of maximum), though the flash is capable of even lower output.

Analyzing this substantial dataset required robust data analysis tools supporting computed columns, frequency analysis, filtering, and bit manipulation. While LibreOffice provided a reasonable starting point, VisiData proved far more powerful. I highly recommend it for anyone analyzing multiple datasets, particularly if you know Python.

The camera initiates all exchanges by transmitting what is likely a baud rate calibration byte: 0x55. It then sends a command byte, optional parameter bytes, and sometimes a checksum byte.

I have identified several commands that my Olympus cameras employ.

To control the flash programmatically, it must first be configured to one of the TTL modes (TTL or FP TTL).

The flash automatically switches to TTL mode upon receiving the Camera TTL information command (0x87) for the first time. It can also be manually set to TTL mode via the flash’s buttons, but only after the flash has already received TTL data from the camera.

Manual power control is straightforward. Whenever the receiver detects a manual power setting command (0xBC) from the Godox transmitter, I forward it to the flash using the Olympus 0x03 command. Power level translation uses the auto-detected maximum flash power (byte B1 from the 0x82 status response) and the known EV step sizes: 8 steps per EV for Olympus, 10 steps per EV for Godox.

The primary challenge in TTL mode is selecting the correct Olympus command (0x02 versus 0x03) for setting power. The Godox transmitter uses the same command (0xB9) for both pre-flash and main flash power settings. My current implementation assumes two pre-flash triggers will occur and uses the 0x02 command until two trigger commands (0xB4 0x01) are received. After the second pre-flash trigger, I switch to the 0x03 command for the main flash until the quench command arrives (0xD5 0x21).

High-speed sync presents a significant challenge. The XProII (and likely other Godox transmitters) does not transmit shutter speed information to the flashes. However, Olympus speedlights require this information to calculate the appropriate maximum power level (and possibly to configure HSS pulse duration and repetition rate).

This issue remains unresolved.

I attempted to map the Godox modeling lamp control to the Olympus focus lamp. However, I have been unable to make this function work, despite believing I have identified the correct command. The FL-36R simply does not respond to it.

Several features remain unimplemented. The two most significant are:

Even though I like Inspectrum when analyzing radio signals, it does not support the MSK modulation. So it gave me just another look at the spectrum.

Universal Radio Hacker is another great tool, but again, no MSK support. And even with the data decoded by GNU Radio I had better luck using my shell and Python scripts.

The aging DSLR was not actually capturing properly exposed images when connected to the FL-36R in TTL mode via the extension cable. This baffles me; I must have overlooked something. However, I only discovered this issue after several days of testing, as it had not occurred to me to examine the actual photographs. The protocol recordings appeared correct—they simply always commanded full power.

I spent several hours triggering the flash using the 0x03 command transmitted via Bus Pirate (using an SN74HC05N open-drain buffer for the CameraTx and Trigger signals) while recording pulse intensity with an older Sekonic flash meter.

I repeated these measurements while varying the subject distance.

The results were intriguing, but I could not determine the power level limits from this data reliably.

This was before I realized I could trigger the flash from the camera with the lens cap attached and correlate the measured power with the protocol bytes.