E-mount electronic protocol reverse engineering

bostwickenator wrote: Geez I think I need to start writing a monthly progress report or something so I don't keep missing things. It's such a sprawling project it's hard to keep all the bits straight. I'll go back and review what we got from the MC-11.

LOL. You're definitely not to blame for that one, I'm 90% certain that observation from leegong predates your involvement by many months, if not more than a year.

Can't believe I started this back in 2015 or so... Obviously I've taken some VERY long breaks in between!

Yongnuo have a firmware update for their adaptor, don't know if it's helpful to you guys :

http://yongnuoebay.com/gw/yn_adatper_EF_FE_II_fm_V04.zip

Found on :

http://www.hkyongnuo.com/e-detaily.php?ID=471

I'd really love if we could work on the protocol in a document it's more maintainable. https://docs.google.com/document/d/1iw54nzrF0bzQgLINpcP9F8Odd0N5cd7LjlwCDPTNZK0/edit

Markdown works for me I'll transfer the content of that doc into a new Markdown files and start a GitHub organization for this project we can host the common files in.

Just download Sigma E-mount 35mm F1.4 LensFirmware and 50mm F1.4 LensFirmwareV2 ,
decrypt them successfully.
But no idea about MCU model number yet .   

QuietOC wrote: Entropy512 wrote: New discovery: SEL24105G + A7M3 uses a whole PILE of new messages, and frequently sets the message type to 3 (instead of the usual 1=normal and 2=init). The 24-105G is one of the newer 20 FPS lenses. It is likely that Sony updated the communication. https://support.d-imaging.sony.co.jp/support/ilc/products/ilce9/continuousshooting/en/index.html#c_lens

Yeah, it would be very interesting if the new messages are ones that define whether or not async is seen.

One thing I want to start doing is tracking the "E-mount version" seen in EXIF for various lenses/bodies - and also what messages and fields are/are not seen for a given version. (Also where that version information lies during the initialization sequence...)

owenn01 wrote: Okay - I'm not scared of asking this question: one learns though asking the dumb question others fear to ask: What , in simple terms, is this all about; and where does this take you in terms of either a finished activity/product/action etc? It all looks very interesting (and technical!) - but what will it deliver for you? There - asked it and not even a tiny bit embarrassed    Thanks and best regards, Neil PS. Don't forget - keep it simple for me!!

I think it varies between the various people involved, but it happens that there's a common interest of understanding E-mount protocols and even having some reference implementations of it.

In my case - I've been unhappy with the state of EF adapters for ages. It's my opinion that we could be doing MUCH better than we are now. Look at what the MC-11 has achieved for SGV lenses. Things that could be done "better" though:
1) Officially support AF-C. Funny thing is, this is one of the only cases where the MC-11 works well and it's officially unsupported!
2) Make AF-S better - MC-11 was driving many lens motors at full speed which breaks native AF-S (hunting and overshoot). It got better with a firmware update at the long end of the 17-70, but the wide end is still way too fast. User tuning would be a huge benefit, or at least clear and concise documentation of "lens X has been attempted to be tuned but we hit the limits"
3) Officially support non-SGV lenses with native functionality. Metabones sort-of does this, but has the position for certain important features of "this doesn't work because we don't know the optical formula of the lens". Thing is, such aspects of the lens CAN be profiled in the field. Look at how the lensfun distortion/CA database is populated for example. There are documented methods for determining exit pupil distance (which is likely the critical item for off-center PDAF). The MC-11 proves that storing a table of "additional lens data" is feasible for an adapter. The problem for an adapter where this information is "baked in" with each firmware release is that the table would be huge - so why not have it populated with a tuning tool and only containing the lenses a user owns/uses?

As to whether I'll ever get there - who knows. I've got a lot of other projects I work on, and those pesky EF spring contacts are Bad News for someone as inept as I am on the mechanical side of things.

bostwickenator (Alex)'s "E-mount film body" project makes the rounds every once in a while. There are some fun challenges there, it remains to be seen whether E mount lens motors are repeatable enough for this to actually work, or if they're designed to fundamentally be part of a closed-loop AF control system and won't work well open-loop. I know he has a Voigtlander manual lens, for that lens just having aperture control would be a big deal and would probably work well on his body.

I think leegong has in the past been involved with projects that amount to trying to have the equivalent of CHDK on non-Canon cameras. It's hard to tell, pretty much if it's a camera product and has firmware, he's shown interest in picking it apart. :)