Background

LANC is a serial protocol available in most Sony and Canon videocameras. If you need additional info, Wikipedia has a good introduction on what LANC is.

The best low level definition of the protocol is available on this nice article

http://www.boehmel.de/lanc.htm

At the time I worked on this, there was no open source implementation of LANC available, so I used the opportunity to learn some of the Arduino features by implementing LANC with it. A few months later someone else published a LANC source code for Arduino, therefore there are at least 2 implementations available now for free to the Arduino comunity.

My implementation can be easily extended, and use standard Arduino code (i.e. it doesn't require any additional library nor C code).

Software

This article demonstrates a simple implementation in Arduino Diecimila with a few LANC commands (Play, Rewd, Record and Stop), but it is really easy to extend it to support more commands. In my case, I just needed VTR record mode, as it was disabled in my Sony European model (most vendors disable this feature in European low end camcorders to reduce Taxes).

Being a relatively simple serial protocol, I found rather difficult to implement it in the Arduino platform by just using the libraries available. The major problem is the lack of direct "timer" reading.

In other words, there is no simple way of reading a timer counter in Arduino to learn how many microseconds already spent the ATmega in a given code section. This makes really difficult to synchronize protocol timming with the microcontroller code. I understand this as a clear candidate to create a new library using C rather than Arduino IDE but I wanted to limit myself to the available Arduino features. The main reason is to somehow challenge the current Arduino offering and not go to the GCC tool chain.

Given the lack of a timer, I needed to learn how long it took for the ATMega to do certain things, to properly read the LANC signal at the right time. For that I used a logic analyzer (LA) and a few signals to mark internal activity of my code (such as when the start bit is detected, when the last data bit is read, etc) to guarantee the bit-banging is doing what is supposed to do.

As result, you can see the code basically do bit-banging on a basic premise of 104uS per bit, 8 bits per byte, 1 start bit and some "stop bit" which is not 104uS long but a bit more than that (apparently depends on the camera model). This repeat 8 times for 8 bytes total per frame, and this repeats 20 times every second for a PAL signal.

You may need to reverse engineering commands from your camera by triggering a manual action (such as Zoom IN) and then look into LANC pattern.

Take a look at the source code, it is self explanatory and contains an interesting section to help you reverse engineering your particular camera commands in case you need additional controls. There are some people out there using a potentiometer to control zoom or focus, that should be an easy addon to this code if you need it by leveraging an ADC input for that.

Source code available here.

Hardware

Hardware layer couldn't be easier.

LANC specification requires an open collector to drive the single wire serial connection. At the same time, we need to protect the signal entry for arduino so I clamp it to 5V with a zener.

There are a few I/O ports I used to blink leds or add button on. Check the code for that:

Conclussion

I understand Arduino is a platform for easy development. But interacting with a simple protocol such as LANC shouldn't be a problem for a platform like this, I would suggest the Arduino community to extend the software side with a few concepts that will help a lot in a task like this:

• Support at least 1 or 2 timers (ideally 16 and 32 bits). To make it simpler for the community, it shouldn't be the same timer used by PWM internally. Note: I recently saw new versions of Arduino added the micro() function which could help on this, assuming it is accurate enough, something I will test at some point.

• Support some basic form of debugging, including breakpoints. RS232 trace output doesn't work for everything, in this simple case it just take too long to dump some data over RS232 that you simply breaks the bit-bang timming. Therefore a way to set two breakpoints and measure the time between them will be of great help. I can use a LA for the same thing but many hobbists do not have a LA. Perhaps a dedicated memory map to easily track positions visited (as a simplified call stack) and then dump all via RS232 when required will definitely help.