Byte transfer method is SPI like, but without a CS (chip select) signal. When examining only the byte transfers, an acknowledge scheme can be seen - either to indicate reception or busy signal (idea from internet, not tested if it is ack or busy, can be both too).
TODO:
Describe RESET and WAKE conditions.
DATA:
I have tried to interpret data both ways, but the MSB first gives some understandable results (lens identification).
Samples:
As the communication is full duplex synchronized, usually the response for a command comes at least a byte later. I have tried to group the stream into blocks, but some values might be parameters, not commands. Some commands, however, show a distinctive pattern (marked bold), which is repeated every time those commands appear.
Timing:
The first 16 bytes are read in burst, then cca 24+24 by small sized blocks (could be that the camera is multitasking to other things so it is not burst like). Later, some 24 byte burst appear each 50ms (20Hz). Each other of these burst is same, therefore both samples given only once, but they are repeated like 74 times. The next different communication appears when the camera is switched (immediatly) off, or no action is taken and the system goes to low-power mode - again indicated by different samples.
LENS ID:
Identification codes easily available in internet, the map of apertures is in Magic Lantern's lens.h file. Zoom range given directly, probably 16bit integers.
TODO:
Describe RESET and WAKE conditions.
DATA:
I have tried to interpret data both ways, but the MSB first gives some understandable results (lens identification).
Samples:
As the communication is full duplex synchronized, usually the response for a command comes at least a byte later. I have tried to group the stream into blocks, but some values might be parameters, not commands. Some commands, however, show a distinctive pattern (marked bold), which is repeated every time those commands appear.
Timing:
The first 16 bytes are read in burst, then cca 24+24 by small sized blocks (could be that the camera is multitasking to other things so it is not burst like). Later, some 24 byte burst appear each 50ms (20Hz). Each other of these burst is same, therefore both samples given only once, but they are repeated like 74 times. The next different communication appears when the camera is switched (immediatly) off, or no action is taken and the system goes to low-power mode - again indicated by different samples.
LENS ID:
Identification codes easily available in internet, the map of apertures is in Magic Lantern's lens.h file. Zoom range given directly, probably 16bit integers.
Ich hätte so fürterlich gehrne eine version von dem redrockmicro :
