AVR USB Programmer RX TX

I’m having a hard time getting the my Pololu Serial Transmitter (PST) and AVR USB Programmer to see the data coming from a digital controller. I know that the Programmer is working… It can send and read itself.

Okay so here is the scenario: I have a Lanc controller for a video camera, I’m needing to be able to read the data that comes from it. I’m using it to control a motor with a Baby Orangutan B-328.

The Lanc Controller that I’m using: varizoom.com/products/controls/vzrock.html
Lanc Controller Protocol: boehmel.de/lanc.htm

From what I have read the controller runs at 9600 Baud. Setting the PST to that and using the Programmer, I can’t seem to get any info from it. I have hooked the lanc connection to the RX and TX. I have even jacked the controller to a test board and to a video camera trying to watch the two communicate to each other, but still no dice. I have messed around with the baud settings too.

I do notice that there seems to be some kind of handshake that goes on. When I jack the lanc controller to the Programmer, the controller pulses a red light twice, then pauses and does it again… and so on. But when it jacks to the camera it only pulses once, hen controls the camera.

Thanks for any kind of help… dan.

In case anyone else is thinking of using this stuff on mac running parallels… It works perfect. running vista on a macbook pro.

Hi danny,

You need to connect the ground lines of any devices that communicate serially. Did you connect the programmer’s ground to the LANC’s ground?

Also, there was a problem with the RX and TX lines in the original programmer firmware which might be causing your problem. I hope to release the firmware upgrade on Jan 6, and I’ll let you know in this thread when it is released.


David, I have have another question about connections. The Lanc Jack has 3 wires.
Line1: +
Line2: -
Line3: Lanc Data

If I hook up my RX to Line3, the ground to Line2… Then which one should I hookup the TX to? Should I hook it to Line1? I’m concerned that I might fry something?

Thank you very much for the help.

You should leave TX disconnected. I think the LANC protocol is a one-way protocol, where the camera never sends any data back to the controller, so there would be no place to plug in the TX line on your controller. You should not plug the TX line to the line labeled “+” on your LANC controller because that is probably the power line. Also, you’re just trying to receive bytes with the programmer. You’re not trying to send any bytes yet so there is no need to connect the TX line to anything.


Thanks Dave, I really appreciate your help.

I found that when I hook the camera, controller, and the Programmer (RX to Lanc & share the ground) that I can read a bunch of the Hex code coming in… but it’s so much that it crashes the PST app with in one or two seconds…maybe I’m doing something wrong?? As I look though the info I can find that it’s repeating the same data… and none of it looks to be valid Lanc Protocol, or any variations from the controller when I use it.

The only reason that I’m even trying to watch the communication between the Camera and the controller is. When the controller is hooked up to the camera and the camera is power on the Controller blinks a red light two times, then blinks no more. But if it’s hooked directly to the Programmer the light blinks two times then waits about 2 - 3 seconds, then blinks again. Does this like it’s waiting for something. But I think your right it only sends data, it doesn’t receive any info.

Maybe I should just try hooking the lanc controller to my B-328 and see if it will just control my motor speed. I know what the hex should look like. I just want to make sure that I can see the data coming from the controller.

Thanks again for all of your help Dave.

I was wrong about LANC protocol: it is a two-way protocol. The LANC protocol description you linked to says,

That explains why the controller behaves differently when your camera is connected.

When you connected the programmer’s RX line to the LANC data line and ran the Pololu Serial Transmitter, you were seeing the command bytes sent by the LANC controller and the response bytes sent by the camera. Maybe this is why you didn’t recognize it.

It is possible to implement the bidirectional open-collector protocol on the Baby Orangutan but it could be difficult. So you should determine if you really need to send any responses. Maybe the LANC controller will send all the data you need even if it can’t detect the camera. The best way to determine this would be to connect the LANC controller to the Programmer without a camera present and look carefully at the bytes it sends to see if they contain the information you need. The Pololu Serial Transmitter program isn’t very good at reading fast streams of data from a serial port, so you might need to find a different program or write one using the freely available .Net framework and the SerialPort class.


Hey David, Sorry if I caused any beef. You may have seen in the long post going over my testing methods. I can’t seem to get the controller to send over the data with out some kind of response. Do you think it would be possible to use the programmer to send a response to the controller… though the one lanc port on the controller? Or should I just try to use the B-328P? Does it have the ability to do that?

Again David, I wasn’t trying to go around you to ask some one else for help. I was just trying to keep the questions relative to the categories. You have more helpful then you know… I’m sure you can tell I know nothing about this stuff… I have done a lot of programing and soldering in my life… just never were the two come together.



In the other thread where you posted the serial output from the programmer a lot of the bytes you received look like they were received at a baud rate that is 2x too fast. For example, the binary pattern for the byte 0xF8 sent on asynchronous serial, including the start bit and the stop bit, is:

0xF8 = 000011111
       ^       ^
       start   stop bit

Patterns like that are suspicious because the bits seem to be in identical pairs.

I suggest decreasing your baud rate by half (from 9600 to 4800) and seeing if the data starts making sense. Also, make sure your programmer’s ground is connected to the LANC’s ground if you haven’t already.

If you can’t figure out how to debug the serial output between the Baby Orangutan and the LANC controller and you’re not sure what baud rate to use, your project is going to be very difficult.

Regarding implementing one-wire bidirectional asynchronous serial communication with the Baby Orangutan:

The processor (ATmega48/168/328p) on the Baby Orangutan has a hardware UART that can receive serial bytes on PD0/RX and send serial bytes on PD1/TX. The Pololu AVR Library has a section called OrangutanSerial that allows you to use the UART. If you connect the LANC’s ground to the Baby Orangutan’s ground and the LANC data to PD0, you should be able to receive bytes just fine using OrangutanSerial (assuming you know what baud rate the LANC controller is transmitting at). You should do some experiments just trying to receive bytes from the LANC controller and make sure that works.

The difficulty is that you need to be able to send bytes on PD0, which is not supported by the UART or OrangutanSerial. Therefore, when you need to send a byte to the LANC controller, instead of using OrangutanSerial functions you need to do something special. Here is an (untested) function I wrote that disables the UART receiver, which allows you to use OrangutanDigital to control PD0. Then it sends a byte on PD0 at approximately 9600 baud.

function serial_send_on_pd0(char data)
    set_digital_input(IO_D0, PULL_UP_ENABLED);
    UCSR0B &= ~(1<<RXEN0);  // disable UART receiver
    // Send the start bit
    set_digital_output(IO_D0, LOW);

    // Send the data bits, least-significant first.
    for(unsigned char i=0; i < 8; i++)
        // Send one data bit
        if (data & 1) { set_digital_input(IO_D0, PULL_UP_ENABLED); }
        else { set_digital_output(IO_D0, LOW); }
        data >>= 1;  // prepare to send the next data bit by shifting char's bits to the right

    // Send the stop bit
    set_digital_input(IO_D0, PULL_UP_ENABLED);

    UCSR0B |= (1<<RXEN0);  // enable UART receiver

Whenever you need to send a response to the LANC controller, you would call the function instead of the sending functions in OrangutanSerial.


David you are a magic man… Does your family know that you are a super hero? I’ll start test this out later tonight. Thank very very much for the help.


1 Like