Sony Lanc Protocol Master/Slave

[DaddyShizzle]

Hello,

I have a problem with the Sony Lanc Protocol.  Usually, a camcorder or even a broadcast 4K camera will be the Lanc Master and the Rec/Stop Lanc remote will be a Lanc slave.  My problem is that the Atomos Shogun external video recorder acts like a slave, and a standard Lanc remote will not work with it, because it is also a slave.  I need to find documentation or get help with writing code for the Master Lanc side of the protocol. There are tons of standard slave Lanc projects online, but nothing about the Master(camera) side of the protocol.  I need to make a Lanc remote that acts like a camera(master) so the Atomos Shogun will trigger record.

Any help will be much appreciated, thanks.

[aeg]

LANC, that's a blast from the past. My recollection is that coincident with every frame of video, the camera sends a LANC frame on the bus, with certain bytes (such as timecode) filled in. Other bytes in the frame, the remote is supposed to "fill in" with its commands during the camera's transmission. Sony had a manual "Protocol of Control L/Lf" (P/N 9-972-453-11 or *PROTOLF), but it is not very illuminating.

[scottapotamas]

I guess the difficulty depends on your familiarity with working with embedded peripherals and how you're electrically interfacing with the LANC bus from your micro.

LANC isn't necessarily per-frame as aeg mentions, the Panasonic cameras I've worked emit their frames on a 10ms interval for example.

In the simplest/easiest case while relying on loose timings being OK:

• Separate RX and TX UART capable IO pins connected to sense and 'drive' circuits should be enough
• The master is responsible for providing the start-bit, so you can just 'send' 8x 0x00 bytes at 9600 baud 8N1 to achieve this without much work.
• The camera's I've interacted with typically use a slightly longer (than normal UART) stop-bit/gap after each byte of approximately one bit duration, so if the peripheral supports that you should use it, or you might need a timer to coordinate the UART TX for each byte. You'll probably be fine without it though.
• Keep track of the byte 'index' you're sending and service the UART RX for the first 4 bytes to catch slave commands.
• You're already sending 0x00 bytes, but for the last 4 bytes you send your status etc. Flush/disable/ignore the UART RX when you're doing this.
• Remember that you need to send/read some number of repeated sequential frames to consider a command valid (typically 4).