I am working on an application based on a Nano. The device is intended to read LANC control signals passing between a LANC (Sony/Canon serial protocol) controller and a video camera and to send a trigger signal to a separate video recorder when the operator hits the REC/STOP button on the controller. My device works perfectly when using power from the USB port or from an external power supply that is near 5v. However, my design is intended to be powered by a 9v battery and when I test using that configuration it fails. I have now determined that the LANC commands are not being read properly, likely because of a timing issue, when using 9v power.
Thus my question: does the clock rate of an Arduino change in some reasonably predictable way when you change the power supply from near 5v to something higher like 9v? I have some delays in my code that I can play with to try to get the timing back to where it should be, but I feel that I'm just guessing about what the new delays should be without at least some hint about how the clock rate has likely changed.
Alternatively, is there a relatively simple way that doesn't require a 'scope or a logic analyzer for me to run some tests to see how the clock rate is changing?
Here is the snippet of code that I suspect is failing when I change the power supply to 9V:
void readLancCommand() {
lancByte0 = zeroByte; //zero out each byte before reading. Not sure that this is necessary, but it works
lancByte1 = zeroByte;
lancByte2 = zeroByte;
lancByte3 = zeroByte;
lancByte4 = zeroByte;
lancByte5 = zeroByte;
lancByte6 = zeroByte;
lancByte7 = zeroByte;
while (pulseIn(lancPin, HIGH) < 5000) {
//"pulseIn, HIGH" catches any 0V TO +5V TRANSITION and waits until the LANC line goes back to 0V
//"pulseIn" also returns the pulse duration so we can check if the previous +5V duration was long enough (>5ms)
// to be the pause before new 8 byte data packet
//Loop till pulse duration is >5ms
}
//LOW after long pause means the START bit of Byte 0 is here
delayMicroseconds(104); //wait START bit duration
delayMicroseconds(52); //wait until the middle of bit 0 of byte 0
//Read the 8 bits of byte 0 and set appropriate bits of the byte variable
//Note that the command bits come in in reverse order with the least significant, right-most bit (bit 0) first
lancByte0|= digitalRead(lancPin);
delayMicroseconds(bitDuration);
lancByte0|= digitalRead(lancPin) << 1;
delayMicroseconds(bitDuration);
lancByte0|= digitalRead(lancPin) << 2;
delayMicroseconds(bitDuration);
lancByte0|= digitalRead(lancPin) << 3;
delayMicroseconds(bitDuration);
lancByte0|= digitalRead(lancPin) << 4;
delayMicroseconds(bitDuration);
lancByte0|= digitalRead(lancPin) << 5;
delayMicroseconds(bitDuration);
lancByte0|= digitalRead(lancPin) << 6;
delayMicroseconds(bitDuration);
lancByte0|= digitalRead(lancPin) << 7;
lancByte0 = lancByte0 ^ 255;
delayMicroseconds(10); //assures that we're in the long "stop bit" at the end of each byte
while (digitalRead(lancPin)) { //waits while the pin remains high
}
// Repeat the code above for each succcessive byte of the frame
Thanks for your time; and credit to Ariel Rocholl and Martin Koch for the code that reads LANC commands!
