LANC codes for still cameras

Recently (approximately one year ago) I started building LANC controller for stereo camcorders and still cameras. The work is now finished and LANC device is now in testing phase. After testing period I'll publish the SW and HW on my web pages. Here are only two pictures of my HW design (just to show that I'm not joking :-):

   

Before publishing the complete code and electronic schemes, I'd like to give the codes for controlling still cameras, since I have received several questions regarding LANC codes for still cameras.

Here is the conversation between me and another guy who was trying to control his SONY DSC-V1 camcorder (at the bottom of this site you can find his working code written in C programming language):



Q:

Hello. I saw your message at the Steve's Digicams forums talking about LANC protocol.

[http://www.stevesforums.com/forums/view_topic.php?id=49434&forum_id=44&highlight=lanc]

I am also interested in the subject. I am trying to control my Sony DSC-V1 camera using the ACC-Terminal port. As far as I know, you can use the LANC protocol to do that. All the information I have been able to find was about camcorders commands, but I also discovered that there are differences between camcorders commands and still cameras commands. ...


A:

I have developed my system on Atmel ATmega8 chip, so the code is different.
The problem with still camera codes is that you have to "listen" to the third byte in LANC frame (first two bytes are command codes). When your uP finds out that the third byte is some specific byte, it should answer and change that byte in the next three LANC frames (1 LANC frame consists of 8 bytes - first two are commands).
The procedure should be as follows:
When you detect 29 (I don't know if number 29 is critical at all) "empty" 3rd bytes (0x00) in LANC frame, you should send the command 0x0E00 (first two bytes) to camera. After that listen to the third byte from the camera. When you detect code 0x47 3 times (the third byte), you should place command 0x43, then 0x53 and then 0x53 to the third byte (in the next three frames). After that search for code 0x57 3 times, then immediately place the same commands (0x43, 0x53 and 0x53) to the third byte consecutively (in the following 3 LANC frames). After that you have to search for the code 0x47 3 times (again the third byte in LANC frame) and immediately place the mentioned commands on the third byte in each consecutive LANC frame. ... etc.

The LANC frames should look like that (see Table 1):

Table 1. Received and transmitted bytes from/to DSC-V1.

Note that bold values are the values SENT TO DSC-V1. Other values are the values RECEIVED FROM DSC-V1. 


...

I have given the lanc codes (first two bytes) I was aware of in the forum:

Wide = 1E96 (lower speed??), 1E9A (higher speed??)
Tele = 1E94 (lower speed??), 1E98 (higher speed??)
Shut off = 1E5E (instead of 185E for camcorders)
Pre-trigger = 1E52
Shoot = 1E5A (take picture)

Note that if you are not sending any instruction to LANC port, you still have to place instruction 0x0E00 to LANC frame. This instruction means: do nothing, but note that I am here... :-)

Q & A:

Q: Thank you very much for the information. I will study it immediatelly, so I
think I will have to ask you sometimes. Only one question (by the moment
:-P), have you tried to do the same with the ELM624 chip? would you send me
your code to see inside or is your propierary code? and, would you update
your web page with this information?

A: I haven't tried to do that. I'll put the code and HW config. on my web, but not before I publish the most relevant data in one conference proceedings. The reason? ...

Q & A:

A: Before starting to answer you I have to say that the attached file are actual signals (codes) measured when remote RM-VD1 is attached to SONY DSC-V1.

Q: After you switch on the controller, you should have to wait for 29 empty
frames. Then send 0x0E00 command and listen to the third byte. Well, at the
trace you sent me you read four times the value 0x47 (0xB8) instead of
three. What is the reason? Because after that you always read three times
the values (0x47 or 0x57 and send the other three codes).

A: I think that I waited only three times in my code, but I have to check it. However, you can wait four times at the beginning (just in case).

Q: Did you have to send the command frame more than once to the camera? When
you send command 1E94, you send three times the same frame, but then you
send some more times the 1E98 command.

A: Almost always you have to repeat the command more times. The command has been repeated only three times, since I changed to the next command almost immediately. Don't worry. It doesn't matter.

Q: As I can see, you still send the 0x43, 0x53, 0x53 values to camera in the
third byte even though you are sending a 1E94 (for example) command on the
first two bytes. Is that correct?

A: Yes, this is correct! Otherwise (if not "managing third byte continuously") I am 99.9% sure that it won't work.

Q: Well, so the protocol to send commands to the camera will be as follows (correct me if I make any mistake):

1. Switch on the controller. The camera is switched off:
2. Attach the controller to the camera. The camera is still switched off.
3. Turn on the camera. The "listening" protocol starts.
4. Wait for 29 empty frames.
5. Start sending the 0x0E00 command.
5.1. When three (or four) B8 values received, send 43, 53, 53
5.2. When three A8 values received, send 43, 53, 53.
6. Go to 5 If there is not any command to send.
7. Send command code on bytes 1 and 2 (how many frames with the same
command?). Continue the listening protocol over byte 3.
8. Go to 5.

A: Exactly!

A: 7. How many commands? Usually it is enough to send 3-5 bytes. You can try and see.

Q: Well, I think that after sending a command to the camera you should start
sending again the 0x0E command, but when? How long do I have to wait until I
start sending the 0x0E command again?

A: When command is finished (e.g. when wide-angle button is de-pressed), you should IMMEDIATELY send 0x0E. Don't make a mistake by sending 0x00 instead!

Q: Do not worry about the code. I think I could manage with all the information
you are giving me. When are you going to the conference? Good luck with it.
I will not publish anything of that on any web until you go to the
conference or publish your data at your web page.

A: Excellent! I'll have my conference (workshop) in October. However, the proceedings will be ready in November (there will be no pre-prints at all). So I'll have to wait until the end of November.

Q: And the last question. How did you discovered all of that? Did you use the
RM-VD1 Sony controller to see what was happening?

A: Yes (see the first sentence).

Q & A:

Q: Ok. Here is are the beginning frames where I found the four B8 lines. But there is no problem if I have to wait at the beginning for four frames instead of three. The values are highligthed in red. 
The code will be a little more complicated, but otherwise it should be OK. 
Ok, so I would repeate the command four or five times.

A: Yes, if you want to start pre-trigger or shooting. Otherwise (for tele or wide commands) you have to repeat the command continuously to reach desired tele or wide setting...

> >1. Switch on the controller. The camera is switched off:
> >2. Attach the controller to the camera. The camera is still switched off.
> >3. Turn on the camera. The "listening" protocol starts.
> >4. Wait for 29 empty frames.
> >5. Start sending the 0x0E00 command.
> > 5.1. When three (or four) B8 values received, send 43, 53, 53
> > 5.2. When three A8 values received, send 43, 53, 53.
> >6. Go to 5 If there is not any command to send.
> >7. Send command code on bytes 1 and 2 (how many frames with the same
> >command?). Continue the listening protocol over byte 3.
> >8. Go to 5.
>
A: Exactly!

Q: It was quite simple.... ;-P

A: Just one comment :-) In point 5 it would be better to write the following: 5. Start sending the 0x0E00 command if you don't have any other command to send.

Q: Ok. So I would send the command in four or five frames. An then I will return sending the 0x0E command.

A: See two answers above.

Q: Ok, I think I would still need some help, specially when I start with the implementation. I think I will use a PIC. I have some code for controlling a camrecorder using a PIC, so it will help me with timing (I can send it to you if you want). I think that the hard work is done, due to the LANC protocol for still cameras is such a hidden thing. I will order the LANC protocl spec from Sony. I hope I could find there codes, timing spec and almost everything, but I do not know if it is up to date. Anyway, I can send you a copy if you are interested to. I also have a LANC spec but all the codes it has are valid for camcorders. There is timing information also and I can send you the pdf doc if you want.
It is not an easy thing to find information about LANC codes for still cameras. I do not know why.

Q: I have also found some projects for LANC controllers, but I was specifically interested in the codes for still cameras (even though my controller controls both - still and video cameras). If you get the protocol from SONY, I would be very happy to get the protocol.

Q & A:

Q: About timing limitations. What kind is the DSC-V1, NTCS, don't you? So, you said you use 5 ms for PAL and 15 ms for NTSC timing between the frames?

A: I don't know, but I suppose that LANC signal frames are in sync with video out signal chosen (so it can be 20ms or 16.66ms). I think that I have 20ms between the START of two consecutive frames.
I am using the following limitations:

A: 5-15ms between the start bit of the 8th byte and start bit of the 1st byte of the next frame
1-1.5ms between start bit of the previous and start bit of the next byte 
1 bit is approx. 104us (1s/9600baud) long.
I figured out those timings from
http://www.boehmel.de/lanc.htm

A: I am just checking if the next start bit comes within the given time limits. If not, something is wrong and I stop communication.

Q: I think I would use 1.2 ms between bytes and 10 ms between frames. Is this correct? Will it work successfuly?

A: You cannot do this. In fact you have to wait for start signal which comes FROM the camera. You have to listen to the camera signal until you find start bit. THEN you can place your code on the line.
But haven't you told me that you are using ELM624 chip? In this case you don't have to worry about timing... Just send the codes. Maybe I am wrong?

And NOW the CODE:

Q: I am quite happy. At last I have finished my controller. The problem I told you yesterday was that I did not initialize a counter after using it. I have fixed this bug and everything works fine. It took almost 3 seconds to take each photo. 
Q: Well, here is my code. I still have to add a lot of comments. This is only a test version, so it does not check any input to decide whether to take a photo or not. It just take the photo after reading the three A8 bytes. But I think that the interesting part is all that manages with LANC bit checking and synchronization. After reading the 8 bytes of the LANC frame, I perform all the status managing procedures: check for B8 and A8 bytes, send BC-AC-AC sequence, send the 0E command,....

See other modifications & 3D video