Is this helpful for reducing noise from a servo at all?

How's it going folks?

This is my 2nd day playing with arduino, arduino coding, and coding--whatsoever.

I've posted it below like this because I've got cerebral palsy and this was easier for me to get done. This seemed like a logical way to reduce the damage. I know this one is particularly hard to read--so I'll work on making them presentable and legible--but is this true for your needs as well, regarding a non continuous rotation servo? Would it be helpful for me to explain everything I do as I go along, if I take the time to make this more infographic like? It's a great way to kill the downtime while I wait for the parts I learn to need to arrive, and it might be useful for others.

//These servers timeout quickly...

Here's the written bit: myservo.write(((x/(359/2))*180));

The other things I've noticed that what people are misinterpreting on the web regarding general "noise", are jittery, jerky motions. The delay is too low. delay(250) is 1/4th of a second. delay(20) is 1/50th! of a second. It's also possibly wearing on your servo oddly, due to the frantic suddenness of the stop. It must be making some sort of friction to overcome the acceleration. The shock is absorbed somewhere beyond the stopping point at least. The other thing might be that you're not syncing the refresh rate of the servo with the sync delay of the thing connected to it. At least I've noticed that with the gyroscope I was using.

Anyway, hope this might have been helpful, or at least interesting.

Yours, Jay.

I don't understand the background context that has led to your comments. What were you trying to do and what was not behaving as you wanted? Did you use a downloaded or example sketch and find it wasn't suitable?

Why do you say "The delay is too low. delay(250)"?

Assuming you are talking about the sorts of servos that are used in model aircraft there is no need to worry about accelerations or sudden stops. On the other hand, equally, there is no point in giving them different instructions at intervals that are shorter than the time it takes the servo to move.

Some servos are designed to move much faster than others - probably the more expensive ones. And you can also get servos with all-metal gear trains if plastic gears might break.

...R

Basically: No.

The servo isn't controlled by 1024 bits (which isn't a megabit, either) and the assumption that there is a non-integer number of bits per degree is completely spurious and is not anything to do with servo jitter or noise.

The servo is controlled by a variable length pulse which is usually in the range 1000 .. 2000 microseconds. The Arduino Servo library enables you to specify the pulse length directly, or by specifying the servo position in degrees and allowing the library to do the arithmetic to convert that to microseconds. The Arduino doesn't time the pulse particularly consistently because the output transitions can be delayed by other interrupts and this is one source of jitter. But there are other sources too - some servos are just prone to it due to mechanical backlash, stiction and the characteristics of the power supply.

ETA: Corrected the pulse lengths.

PeterH: usually in the range 1500 .. 2500 microseconds.

Well, more like 600 to 2400 microseconds, with 1500 being center. These numbers make sense if you consider that 2400 minus 600 equals 1800 units of theoretical precision limit-to-limit, which conveniently equates to 180.0° (using the last digit as a 'fixed' decimal).

In practical use, some servos have a hard time reaching a full 180° so most applications use pulses in the neighborhood of 1000 to 2000 microseconds or roughly 60° either direction of center (which is generally more than enough for an R/C plane control surface).

tylernt: Well, more like 600 to 2400 microseconds

I thought the generally accepted range was 1000 .. 2000us - but you're right that the figures I gave were off anyway.

Basic code for testing a servo.

// zoomkat 10-22-11 serial servo test
// type servo position 0 to 180 in serial monitor
// or for writeMicroseconds, use a value like 1500
// for IDE 0022 and later
// Powering a servo from the arduino usually *DOES NOT WORK*.

String readString;
#include <Servo.h> 
Servo myservo;  // create servo object to control a servo 

void setup() {
  Serial.begin(9600);
  myservo.writeMicroseconds(1500); //set initial servo position if desired
  myservo.attach(7, 500, 2500);  //the pin for the servo control, and range if desired
  Serial.println("servo-test-22-dual-input"); // so I can keep track of what is loaded
}

void loop() {
  while (Serial.available()) {
    char c = Serial.read();  //gets one byte from serial buffer
    readString += c; //makes the string readString
    delay(2);  //slow looping to allow buffer to fill with next character
  }

  if (readString.length() >0) {
    Serial.println(readString);  //so you can see the captured string 
    int n = readString.toInt();  //convert readString into a number

    // auto select appropriate value, copied from someone elses code.
    if(n >= 500)
    {
      Serial.print("writing Microseconds: ");
      Serial.println(n);
      myservo.writeMicroseconds(n);
    }
    else
    {   
      Serial.print("writing Angle: ");
      Serial.println(n);
      myservo.write(n);
    }

    readString=""; //empty for next input
  } 
}

PeterH:

tylernt: Well, more like 600 to 2400 microseconds

I thought the generally accepted range was 1000 .. 2000us - but you're right that the figures I gave were off anyway.

1,000 to 2,000 us is the official minimum pulse width range/control variation for R/C servos, but most servos will still respond to pulse values beyond the minimum. How much more 'over travel' is not a standard specification and the servo library is making an assumption by defaulting to 600 to 2400 usec.

A useful task for anyone wishing to use a specific servo in an arduino project is to test their servo for their true range to mechanical hard stops so that they can utilize the servo up to it's actual mechanical travel limit.

Lefty