I connected two arduinos via serial, attached a servo to each and included an FSR to send pressure information to the servo on the other board. I kept noticing an occasional drop in the servo, so I attached an oscillator to the servo's signal line and noticed something interesting.
I modified the servo.h file so that the servos are always at rest at 544ms, the low end of the 544-2400 range. Then I noticed that every few seconds or so the signal would pop to 644ms, exactly 100ms, when at rest. I also noticed that when I used the FSR to send angle commands the 644ms signal would appear again, this time drawing the servo down to that level for a brief moment, too short to go all the way, but noticeably moving the servo down. What would be the likely cause of a signal that goes to 644ms?
My best estimate is that sometime the interrupt service routine of the Servo library get delayed by another ISR or your code disables interrupts from time to time. If that happens right when the Servo pin needs to be turned off, you get the additional pulse length. Going by the length of the delay, I don't think it's the timer tick from millis(), I wouldn't be surprised if the delay is due to an ISR in your communication library.
To analyse and fix that you will be dumped very quickly into the gory entrails of the libraries you're using. Sometime you can fix it, in other situations you'll be out of luck. But it will be messy.
Thanks for this insight. I have been wondering about interrupts as well. I'm willing to jump into the gory details of the servo library. Where would I find it? I use the default Serial.begin command, so would it be the SoftwareSerial library?
I've noticed that every several seconds (maybe 10 or so) I will hear a very small twitch in the servo connected to the arduino. I had beed curious about it, but didn't it didn't really cause any issues.
as far as I can tell that twitch comes from the interrupt attached to Timer0 to update millis() when it fires at an unfortunate moment. But the delay is rather small.
For the bigger jumps, I don't really know what kind of interrupt function you have. If your sensor is read via one, I would start looking there. The ISR used by Serial is rather short and simple, not much worse that the one for Timer0.
If you identified the problem, you might be able to allow interrupts during your other interrupt function by declaring the ISR as ISR_NOBLOCK or you issue a sei() command right at the beginning. Before doing this, better check if you don't mess up your sensor reading in favour of a stable output.
even if the signal was small if it were interpreted as a degree I would imagine you would see something like the constant device command to go to 644ms?
I figured out a quick fix that doesn't impact what I'm doing. I measure the 644ms as being basically around 10 degrees, so I simply wrote code to ignore anything from 9-11 degrees. It worked perfectly. No more hopping back to 644. Granted I didn't fix the root of the problem, but the hack allows me to move forward for my purposes.