Controlling lens externally

Wifi, USB, GPS, Grips, Mics, Ext Power, Lens, Flash

Controlling lens externally

Postby azkay » Wed Oct 23, 2013 11:41 pm

Hi, I've been looking at pinouts and such and saw a few posts of Canon users using microcontrollers to control lenses without using the camera which is what got me into looking at controlling a lens without a microcontroller or camera body.
I was reading something last night about a guy using Audacity and the line in on his computer for debugging IR signals and playing them back through the 3.5mm jack on a phone or whichever else device, basically saving the raw output of the IR commands (wav, etc) and playing them back connected to an IR LED or whatnot.

Anyway, I'm rambling so:

What I want to do, figure out how to control the lens.
I was looking at the pinout and trying to trace it back to somewhere I could solder to (my soldering is pretty terrible, so I want a point that isn't tiny).

Image

Following the contacts on the lens takes me to there and from looking at the cable, pin 1 (5v) goes in to the connector there. It looks like the connector goes off to those 5 solder points, but me with my lack of knowing what I'm doing could be completely wrong. What do you think?

tl:dr;
Where can I solder to intercept whatever is being sent between the body and lens to record

EDIT::
Oh and on another topic, I've been seeing people mention this dandelion chip but I haven't been able to find how it works, it seems you just "attach" it to the lens? What exactly does it do? How does it do it? It doesn't seem to be connected to anything except the mount
azkay
 
Posts: 2
Joined: Wed Oct 23, 2013 11:24 pm
Been thanked: 0 time

Re: Controlling lens externally

Postby coderat » Thu Oct 24, 2013 3:29 am

About soldering points, some basic info is in WIKI http://nikonhacker.com/wiki/F-Mount. You will need high frequency sampling on your line-in, may be start with 96KHz. Google for other info.

Dandelion chip is commercial project: it is a free programmable data chip for lens for F-mount. You glue it on your lens, but it is basically only communicating with camera body and telling that lens is here, and answer with lens data like focal length, max apperture.

Best regards,
coderat
coderat
Core Developer
 
Posts: 2283
Joined: Fri Apr 26, 2013 10:21 am
Been thanked: 450 times

Re: Controlling lens externally

Postby w0nderbyte » Sat Oct 26, 2013 12:43 am

Hi,
don't know how far u got on readin. You will only be able to focus the lens, apperture control is mechanical even on the latest lenses. Only the PC-E have an electronic apperture.
WB
w0nderbyte
 

Re: Controlling lens externally

Postby lain » Tue Oct 29, 2013 2:52 pm

This is something I have been playing with as well, since I am working on a camera design and would like to use Nikon lenses with it even though their aperture control is still mechanical.

At present I'm working on gathering more information about the lens protocol itself by gathering lots of data. I'm just improving my data capture setup, moving from sniffing the lines at the D5100 mainboard to tapping into the lines in a macro extension tube with AF support. Using the extension tube means I can sniff an unmodified camera and lens, so I can also test on my D800.

Some patents mentioned in another topic on the forum gave a great starting point and explained the signalling used.

Electrical:
It is a 3 wire, 5V protocol with signals H/S (meaning handshake, also called R/W and In/Out), Data, and SCLK (Clock). SPI is used with SO and SI tied together to form Data, and then when one side expects to receive data it leaves SO in Hi-Z state so it does not interfere with the sender's serial output.

Looking into the camera body with the camera upright, the pins are lettered A thru H (or 1 thru 8 as is used on the wiki). B is H/S, C is SCLK, D is Data.
Also I believe E and H are motor drive signals, 90 degrees out phase to determine direction. These are used for AF based on my testing, but I need to scope them a bit more to be 100% certain what's going on, but repair manuals and whatnot strongly suggest that is the case.

Series resistors are used in case there is a conflict where both sides transmit, which seems possible with some new changes to the protocol -- old patents say a lens shall send byte 0xFF in response to unknown commands, but some newer commands have data phase going from camera to lens. In such cases, the camera and lens may attempt to transmit simultaneously, so series resistors prevent overcurrent on the output pins when one is high and the other is low.

The clock line is always driven by the body and it idles high. It operates at 142kHz or very close to that.
Data transitions on the falling clock edge, valid on the rising edge.
The handshake line is open-collector, pulled high by resistor.

There is a "power-down" state where no communication takes place. This state is identified by H/S high, Data and SCLK low. There seems to always be a command sent before entering this state, and a certain sequence of lines going high/low to bring the lens out of this state and back to normal communcation. This is different from the bus idling between commands, where SCLK is normally high.

Protocol:
Communication is always initiated by the camera body from what I have seen.
The camera pulls H/S low (I refer to this as "asserting H/S") for a fixed period of time -- I think this is about 125 microseconds, but not sure, could firmware people take a look? :pray: -- then releases H/S (it goes high). The camera then waits for H/S to go low again.
As soon as the lens sees H/S is low, it asserts H/S and keeps it asserted to indicate it's ready and waiting for a command. They can both assert H/S simultaneously because it is open-collector, so they are both just pulling it low, neither ever drive it high.
In my testing, the lens always asserts H/S before the camera releases it, so H/S remains low for the duration.

Upon seeing H/S is low after releasing it, the camera knows the lens is ready and it clocks out the command, which is one byte. Data is always sent as one byte. No single transmission is ever greater than one byte. The bus always idles between bytes.

When the lens is done with the command, it releases H/S.
If the command involves data transfer, the lens releases H/S after it knows which command it is, then asserts H/S when the data byte is in the transmit buffer ready to go (if lens -> camera), or when the buffer is empty and ready to receive the next data byte (if camera -> lens). The camera then toggles clock to send/receive one byte. Direction of transfer is determined by the command alone as best I can tell, I haven't seen any indication that a bit in the command determines direction.

If the command instructs the lens to perform an action, the lens will not be ready for another command until the action is complete. Therefore: if the command involves data, H/S will be asserted longer after the last byte while the action is performed; if the command does not involve data, then H/S is asserted longer after the initial command byte. Put another way: the lens performs the action on the last byte (which may be the command byte!) before returning to idle, and it will not release from that byte until the action is complete. This provides an easy way to discern reads from writes by timing analysis, since the lens MCUs are slow and take a relatively long time to release H/S in all cases I have seen.

Anyway, I can clean up all the above and add it to the wiki at some point with pretty pictures of data captures and so on. I've written a simple tool to parse captures from the logic analyzer into a list of all commands and their corresponding data. It works, just needs some refinement and then I plan to capture LOTS of data from many lenses and build a comprehensive listing of all commands seen and the data they have been seen with, including how many times each unique command+data combo was seen, etc.

Hopefully that data will be useful to those of you working on the firmware, and I'm hoping firmware folks can help me figure out what some of the commands mean as well :drool:

I wrote this quickly and I haven't had breakfast yet, so sorry for any errors!
Oh, interesting anecdote: one of Nikon's patents covers commands for Power Zoom, though I don't believe any Nikkor glass has such a thing? But that patent also talks about AF commands I don't think I've seen in use... I see different commands used to control AF.
User avatar
lain
Developer
 
Posts: 189
Joined: Fri Mar 29, 2013 3:42 pm
Been thanked: 111 times

Re: Controlling lens externally

Postby Simeon » Tue Oct 29, 2013 6:30 pm

Thanks for the info dump lain, I'm sure leegong will be super excited as soon as he reads this. as it was trying to dump the lens comms commands that brick my D5100. I'm sure he'll be super interested in the commands, even if just to share them privately.
Simeon
Core Developer
 
Posts: 2626
Joined: Wed Nov 30, 2011 6:12 am
Location: Christchurch, New Zealand
Been thanked: 620 times

Re: Controlling lens externally

Postby leegong » Tue Oct 29, 2013 6:55 pm

lain ,
Thanks so much for your great works , :text-thankyoublue:
To be honest , i 'm really super excited when i read your post (Simeon is right) .

Best regards,
Leegong
leegong
Core Developer
 
Posts: 2143
Joined: Mon Mar 19, 2012 12:21 am
Location: Hangzhou , China
Been thanked: 553 times

Re: Controlling lens externally

Postby leegong » Wed Oct 30, 2013 12:36 am

Hi , lain ,
In D5100 FirmWare , two I/O ports are used for lens communication besides serial interface.
1)PI3 , camera body always set PI3 low before it wants to send command to lens, after completes lots of setting ,
then camera set it high .
2)PJ7 , it's used to generate interrupt , upon interrupt is triggered , the interrupt handler
sends one byte to lens , so if there are many bytes to be sent to lens (one byte for command code,
several bytes for extra parameters) , PJ7 should be triggered many times .
3)each bit in commands and parameters for lens is inverted then sent to lens.
4)it seems that 0xFF (not negated)is always sent to lens before camera is going to send command byte.

Best reagrds,
Leegong
leegong
Core Developer
 
Posts: 2143
Joined: Mon Mar 19, 2012 12:21 am
Location: Hangzhou , China
Been thanked: 553 times

Re: Controlling lens externally

Postby lain » Fri Nov 01, 2013 9:15 am

EDIT: Meant to reply here.
User avatar
lain
Developer
 
Posts: 189
Joined: Fri Mar 29, 2013 3:42 pm
Been thanked: 111 times

Re: Controlling lens externally

Postby astronomer » Tue Nov 05, 2013 5:27 pm

Circuit Diagram from the lens side
AF-S 80-200F2.8D

It seems the pin 8 and 5 are connected to serve as a whole. Not as GND described in some forum for the battery.
User avatar
astronomer
Developer
 
Posts: 722
Joined: Fri Apr 06, 2012 10:06 am
Location: US
Been thanked: 293 times

Re: Controlling lens externally

Postby lain » Tue Nov 19, 2013 4:34 am

I updated the F-mount wiki page to add some information which would be very relevant for folks trying to control a lens externally.

In short, pin 6 (previously Vbat) is actually a regulated supply around 6.2V.

Testing several lenses on each body, I saw the following results:
For D800 with 11.1V nominal battery grip (measured 11.8V before and after test), the camera gave 6.18V.
For D800 with only the 7.4V battery inside, again 6.18V was seen. The battery was measured as having a full charge of 8.4V before and after the test.
For D5100 with the 7.4V battery inside (measured 7.65V before and after), pin 6 showed 6.22V.
For F5 with 8x AA's (not measured independently, but showing full on the LCD), pin 6 showed 6.00V.

The pin showed noticeable droop during AF and VR operations, maybe down to 5.5V, but I didn't check it thoroughly.

I discovered all this while testing lenses without a camera body (I'm working on an Arduino library for controlling Nikon lenses). I was attempting to test the claim of faster AF performance with higher battery voltages, when one of my lenses started drawing over an amp from the bench supply during an AF operation when running from 14V. It promptly stopped AFing altogether, and I unplugged it. Luckily it still works fine, otherwise I would've had my first insurance claim on my photography gear :oops:

EDIT: For what it's worth, the voltage given to the lenses didn't make any difference in AF performance. They simply drew less current with higher input voltage, which is characteristic of having a switching converter inside to generate any necessary motor drive voltages. I also sent "02 1b" to the lens for CMD 0x40 -- I don't know what this does yet, but I know the D5100 normally sends "02 1a", and the D800 sends "02 1b", so in case it has any effect on AF performance, I gave it the value used by the D800.

Given that the (cheap non-Nikon) battery grip I use with my D800 can easily put out 14V on a full charge, I was confused. After all, at a glance it did look like battery voltage was hitting those pins, at least on the D5100. But I did early tests for that with a low battery, so 6.2V seemed normal, if a bit low. Some poking around with a multimeter later and wow did I feel stupid for subjecting a few of my lenses to higher voltages :eusa-shifty:

None of this precludes the possibility of bigass lenses requesting higher voltage via some sort of command, but I've seen no evidence of this yet. But then, the biggest lens I own is the Sigma 50-500 OS, which is still a lot smaller than, say, one of these ;)
User avatar
lain
Developer
 
Posts: 189
Joined: Fri Mar 29, 2013 3:42 pm
Been thanked: 111 times


Return to External Hacks

Who is online

Users browsing this forum: No registered users and 1 guest