# Does clock rate change with power supply voltage?

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:

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

delayMicroseconds(bitDuration);
delayMicroseconds(bitDuration);
delayMicroseconds(bitDuration);
delayMicroseconds(bitDuration);
delayMicroseconds(bitDuration);
delayMicroseconds(bitDuration);
delayMicroseconds(bitDuration);
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!

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.

Your diagnosis of your symptoms make little sense. The 328 chip on your nano is always powered by +5vdc, either directly from the USB power, or from the on-chip +5vdc regulator output if you are applying +9vdc to the Vin pin. The clock rate to the chip is determined by the frequency value of the external crystal, 16Mhz in the nano's case, it doesn't change with voltage source selected.

Lefty

Thanks, Lefty. Your explanation is consistent with what I thought that I knew. However, I am struggling to explain the facts in another way.

When I power the Nano using 5v regulated power from the USB interface, or from a wall-wart putting out below about 6v, I receive a stream of LANC commands that makes sense given what others have posted about the LANC protocol. When I power the device using a 9v battery or the same wall-wart with its output voltage above 7v, I get a stream of nonsense. Given the sensitivity of my code to those delays, which are in turn dependent on the clock rate of the processor, I was speculating that a change in the clock rate was the source of my problem.

Jon

This is quite a mystery and my guess is it's hardware related. Are you using the Vin pin for anything? Can you give us more details about your hardware configuration/schematic/hookup?

--
The Gadget Shield: accelerometer, RGB LED, IR transmit/receive, speaker, microphone, light sensor, potentiometer, pushbuttons

Well, I glad that I'm not the only one who thinks this is strange. I am using the Vin pin. It is connected to the output of a SPST switch, the other terminal of which is connected to the positive terminal of the 9v battery. Otherwise, Vin is not connected to anything. I am working on a cleaned up schematic of what I built and will post that later today. I had earlier thought that I had a mysterious power consumption problem that was causing the voltage regulator to overload, but I measure only about 25 mA being pulled from the battery, which I believe is well within the limits of the voltage regulator based on the spec sheets.

Jon

Could it be that your circuit is depending on being earth grounded via USB or the wall wart? Doesn't seem too likely. One way to check is to hold the shell of the USB cable connector against the shell of the USB connector on the board when powered by battery to see if your system suddenly starts working.

John,

Good thought, but the device still fails when I run it from 9V power WITH the USB connected. I do that to use the serial monitor to look at the data that is being read.

Here’s a very quick (sorry) hand drawing of the circuit. It corresponds pretty well physically with what I built. I hope that it’s readable.

Jon

You probably just forgot to draw it, but did you connect the 9V battery ground to the system?

Perhaps consider a series resistor on D3. Any chance that's shorting out or is sourcing excessive current? That would explain strange hardware behavior.

--
The Rugged Motor Driver: two H-bridges, more power than an L298, fully protected

RuggedCircuits:
You probably just forgot to draw it, but did you connect the 9V battery ground to the system?

Perhaps consider a series resistor on D3. Any chance that's shorting out or is sourcing excessive current? That would explain strange hardware behavior.

--
The Rugged Motor Driver: two H-bridges, more power than an L298, fully protected

That is a very confusing and incomplete drawing. Lots of possible wiring problems are possible, but it's unclear what may just be a drawing problem Vs what you actually built. Without knowing what's connected to the jacks/connectors it's hard to trace back current paths, etc. Also you don't show a connection from the negative terminal of the 9vdc battery to the arduino, is that a drawing error or not?

Lefty

Yes, the negative terminal of the battery is connected to ground near to the emitter of the NPN transistor. I forgot to draw it. Thanks for bearing with my poor schematic capture capabilities.

I also thought that I had an unintended connection someplace that was causing a large current draw. So I started over with a fresh prototyping board and built the whole thing again, reusing only the switch. I improved the layout a bit so that there were fewer things close together to test my soldering skills. The behavior of both boards is precisely the same. Each works using USB power, and each works using a DC power supply (a wall-wart) connected to the battery terminals as long as the supply voltage is less than about 7 volts. The power supply that I have is switchable, but not continuously variable, so I can't pinpoint the voltage at which the circuit first fails.

I'll try the series resistor on the D3 input. Thanks.

Jon

As many of you suggested, I was chasing the wrong issue. It turns out that despite EVERYTHING I have read about the LANC protocol, my particular Sony cameras (the old VX2100 and a newer HVR-Z5U) produce a LANC signal that swings between +3v and 0v, not between +5v and 0v. So, I was trying to read a 3v signal with a digital pin. I wasn't able to nail this down until I gained access to an oscilloscope.

I am guessing that the LANC signal was right on the hairy edge of detectability using a digital pin and this confused me into believing that my project was working when powered by the USB and not working when powered by a 9v battery. I am now using a simple transistor to convert the 3v LANC signal to a 5v signal that is reliably read using a digital pin. This has the side benefit of inverting the LANC signal, which eliminates the need to do so in my code.

Thanks for convincing me to think about my project more carefully.

Jon