Psycho Andy, I've seen another thread you created about that. Let me summarize:
1. FCC vs CE in the transceiver
There are two different implementations of lightbridge link used in Ph3 Pro/Adv:
- Analog Devices transciever + Altera FPGA - used in OFDM board v1 for the drone part and GL300a/b radio controller
- Artosyn transciever + Artosyn dedicated processing chip - used in OFDM v2 and GL300c
Sources:
o-gs/dji-firmware-tools
o-gs/dji-firmware-tools
While the Artosyn transciever is suspiciously similar to AD, there are also differences:
- both chips use the same SPI interface to configure internal options
- both have internal registers, of which one stores the transciever attenuation
- some of the registers have different addresses in each chip, and the attenuation value represents a different powe level in both chips
Source - reverse engineering firmware modules using symbols from here:
o-gs/dji-firmware-tools
2. FCC vs CE in the lightbridge control
The lightbridge pipeline is controlled by STM micro-controller, on both the OFDM board and GL300 main board. The STM uCs have firmware:
- m1400 for the controller within GL300
- m0900 for the controller within aircraft
These uCs are sending SPI instructions to transceivers, including one to configure attenuation, based on packets they receive from other parts of the drone. The packets are in so-called DUML format.
Source:
o-gs/dji-firmware-tools
3. FCC vs CE in the DUML
From FW analysis, it is known that there are DUML packets which make STM uCs set the transceiver attenuation. Some people did work to get details about these packets, but this was never investigated to the end.
Source:
Power zone (FCC/CE) in GL300a/b/c RC Firmware · Issue #10 · o-gs/dji-firmware-tools
So conclusions:
a) it is possible to just replace all attenuation levels set by the firmwares to a constant value equal to minimum attenuation. Not really hard for the Github guys. Though I'm not sure I would be comfortable in flying a drone with such brute-force changes.
b) it is possible to investigate the DUML packets further - capture them from a running drone, and then analyse to get an understanding about which chip makes a decision about power zone.
This is as far as I got. Contact the Github guys for an update.
For more background info, check out my description of the video pipeline here:
Camera to fried gimbal board bypass.