I got the same explanation on the Teensy forum using a lot less words <cheesy ascii art omitted>

I think he's trying to say that I'm verbose.  If I were that kind of smart aleck, I'd feel compelled to point out that I managed to demonstrate the same behavior with a few hundred fewer lines of code. 

But, I'm not a smart aleck, I'm a curmudgeon.  So I won't mention it.

This issue would be a lot easier to understand if the code were a whole lot simpler.  In the interests of simplifying it, here's the "Blink Without Delay" sketch from the examples in 1.5.2, without most of the comments:

Code:

const int ledPin =  13;         // the number of the LED pin
int ledState = LOW;             // ledState used to set the LED
long previousMillis = 0;        // will store last time LED was updated
long interval = 1000;           // interval at which to blink (milliseconds)

void setup() {
  pinMode(ledPin, OUTPUT);      
}

void loop()
{
  unsigned long currentMillis = millis();
  if(currentMillis - previousMillis > interval) {
    previousMillis = currentMillis;  
    if (ledState == LOW)
      ledState = HIGH;
    else
      ledState = LOW;
    digitalWrite(ledPin, ledState);
  }
}

If this line

Code:

   previousMillis = currentMillis;  

is deleted, here's what happens:  

• The value of previousMillis is always 0.
• The conditional evaluates as true when the millis() returns a value of 1 or greater.  That may happen the first time through loop(), or later, but not more than 1 millisecond later.
• After that, the value of currentMillis will always be greater than 1, at least until millis() rolls over to zero, about 50 days from now.
• The conditional will always evaluate as true, and the LED state will be inverted every time loop() executes - very often indeed.

Visually, the LED will appear to be on continuously, at a lower brightness than it has when it's actually on continuously.  Testing this code, that's exactly what I see.  When the line is part of the program, the LED blinks on for about a second, off for about a second, and repeats, as expected.

A slower execution speed isn't an unintentional artifact of the "blink without delay" code - that's its purpose.  Slower, and with reasonably precise timing.

I won't be poring over your "adapted 3D Bresenham algorithm" to figure out how it works.  But, based on the data that you present, I'll bet that the time interval that you're measuring and reporting corresponds to about 256 calls to rgbFade().  If that's so, then I'd interpret your data like this:  At I2C speeds of 100kHZ and lower, the delays associated with the I2C operations take longer than a millisecond, and they're limiting the execution speed; at I2C speeds of 400 kHz or more, I2C operations take less than a millisecond, and the intentional delays implemented by the "blink without delay" code, as you call it, become the limiting factor.

An easy way to test this theory is to change the value of interval to, say, 1, and see if the intervals make sense as you change the I2C speed.  I'd bet that all of the speeds that you listed would give you intervals of 512 milliseconds.  

... am I using this incorrectly ... ?

If you didn't want to wait 1 millisecond between calls to rgbFade(), then I would think, "Yes," and that you probably didn't want to use the "blink without delay" code at all.  

Figuring out what the OP wants to know is a lot work.

would you plz give an example of such circuit! because i still don,t have the arduino and i wanna make sure before i buy it. thanks

I think he's asking for a gain-and-offset circuit using an op amp, but I can't be sure.  Here's another place to start: 
http://www.ti.com/general/docs/lit/getliterature.tsp?literatureNumber=sloa097&fileType=pdf
The document says, "The design requires no theory and very little math."  If it can hold to that promise, it ought to be just right for this application.

According to this post - http://arduino.cc/forum/index.php/topic,129765.msg994153.html#msg994153 - the Due's DAC can deliver a voltage between about 0.55 V to about 2.75 V.  The low limit is 1/6 of 3.3 V, and the high limit is 5/6 of 3.3 V.

i want to command a wheel chair. i need to give the main card 2 values, the max one is 3.9v , what can i do now!

You can start here - http://www.eng.yale.edu/ee-labs/morse/compo/sloa058.pdf - and develop an op-amp circuit to add gain and offset to your signal.  Note that you'll need a rail-to-rail op-amp if you intend to power it from a 5 V supply.  If you use a general-purpose op-amp, without the rail-to-rail feature, you'll need a positive voltage of something more than 5 V; if you need to get close to ground, you'll also need a negative supply.

Last year, TSA tagged my Uno and my homemade LED shield in my carry-on bag at the Oklahoma City airport.  An agent asked to see them.  I warned him that they were bare circuit boards, and that there was a chance he could prick his finger, so he asked me to remove them for him.  He explained that he was certain that the devices weren't dangerous, and that he just wanted a look at them.  He asked a lot of questions about how they worked and what I did with them, made me spell "Arduino" out loud, and sent me and my gizmos on my way.  I think he was an electronic hobbyist.

On the plane, I've connected an Arduino without attracting attention by putting the board in my shirt pocket.  Oddly, nobody thinks twice about a guy on a plane with wires running into his pockets, particularly if there are headphones involved.  I wouldn't try it with the board in view, though.

OK, I found it.  See the schematic.

Phantom power drives the hot and cold leads with +48 VDC, with 0 V on the shield.  It's important, form a theoretical viewpoint, to make sure that hot and cold are electrically identical.  The intent is that any noise that a long circuit picks up will be impressed equally on the hot and cold leads, since they take the same path.  At the mixer, or amplifier, or whatever, only the difference between the hot and cold leads gets amplified, so the common-mode noise is, again theoretically, eliminated. So, the circuit has to be symmetrical with respect to the hot and cold leads. 

It also can't draw more than a couple of milliamps without violating the rules. 

The electret wants to see a lower voltage - like maybe 2 to 10 VDC - and a not-unreasonable resistance in series. 

The resistors in the circuit reduce to an equivalent of a 6.7 VDC source with a series impedance of about 6K1.  The voltage is typical for an electret; the impedance is probably a bit higher than is typically used.  The voltage divider feeds the electret across the transformer, and the electret delivers AC to the high-impedance side of the transformer, and that puts the low-impedance signal on the hot and cold leads.  The matching transformer does a couple of things:  it matches the relatively high impedance of the electret circuit to the low-impedance audio system, and it converts the single-ended circuit of the electret to the balanced circuit of the audio system.  In the schematic, the electret should be connected to the high-impedance side of the transformer.

As for packaging, the whole thing fit inside one of these:
http://www.shure.com/americas/products/accessories/microphones/microphone-problem-solvers/a95u-line-matching-transformer  That was handy, since it had the right connector on each end, and a matching transformer already inside.  Three resistors and a little capacitor fit inside with no trouble.  I recall that it wasn't particularly easy to get into the enclosure, and it was especially tricky to get in without damaging it too much.  I definitely voided the warranty in the process.  Later, when that item disappeared, I used a cheaper matching transformer, and I built yet another unit inside an unshielded plastic case - I didn't expect much from that one, but it worked as well as the others.  The whole thing didn't seem to be terribly sensitive to the quality of the components.

Purists will hate this circuit, because there's a galvanic connection across the matching transformer.  In principle, I don't like that either, but it worked very sweetly for me.  I played it for years, in several venues and on several systems, and it always sounded fine and delivered adequate output.  Beware, though - the electret, as you might expect, fed back like a banshee.

I recall that I spent a long time figuring all this out - a lot longer than the circuit merits, in retrospect.  I recall that I got an unacceptable level of power frequency noise on the first try.  I got rid of it by wrapping the electret in aluminum foil, laying the foil across the grounded wire that supported the capsule, and heat-shrinking them together.  That eliminated audible noise.  I don't recall any other problems in construction.

Your mileage may vary.  I might well have gotten lucky with the electret.  I'm not sure that I had any right to expect it to perform as well as it did.

When I see this question, I suspect that you're trying to use 48VDC phantom power, from a mixer or something like that, to power an electret.  I've done that, and it worked quite well.  If that's what you're trying to do, or something like it, say so, and I'll try to remember how the gizmo worked.

Your code looks OK to me.  I suspect that there's something wrong with the wiring, or that the LEDs aren't compatible for charlieplexing.

Can you post a schematic?  For your edification and ours, you needn't draw a schematic with 20 LEDs.  Please consider showing us what your circuit would look like if you were driving six LEDs with three pins - it'll be easier to draw, and easier to analyze.

Also, please tell us the forward voltage of the red and green LEDs. Get it from the the datasheet for your RGBs, if you have one.  If not, then please hook up a spare RGB in a breadboard with a resistor in series - maybe 200 to 330 - and measure the forward voltage of the red and green LEDs.  If you don't have a spare, then light a red LED in the array and measure across it, and then light a green one and measure across that one, too.  Report the results.  For charlieplexing to work well, it's important that the forward voltage of the LEDs be reasonably uniform.

... see whether the noise was caused by the sample data or an artifact of the Arduino output process?

Indeed, that's a possible explanation.  In the OP's wav file, I hear background tones that shift by an interval of about a fourth, with a shift frequency of a one-second order of magnitude, while the froreground tone sounds to be almost constant.  I don't readily think of a process that generates such an orderly kind of noise.  I'll admit, though, that I can't do Fourier analysis like that in my head.  There may be any number of ways that the background tones could appear, that are beyond me just now.

I'm content to wait until the inductors are delivered, and see what the five-pole Chebyshev filter yields.

PWM ... can be ended by digitalWrite(). It would also be ended by analogWrite(0) or analogWrite(255).

Indeed.  I can't vouch for digitalWrite(), having never tried it.  But analogWrite'ing 0 or 255 would do it.  In fact, it would be interesting to see if things change between analogWrite(0) and analogWrite(255) - one drives the output close to ground, and the other near Vcc - I'd want to bet that analogWrite(0) would yield a quieter output.  Or, you could just comment out all the analogWrite()'s altogether.

Remember, you've got a whole lot of digital activity going on in the Arduino and in the PC, and even in the sound card.  All of that activity influences Vcc, however slightly, and that influence won't typically be harmonic with your output signal, making it easy to hear.  My favorite theory right now is that you're hearing audible components of power supply noise, influenced by all that digital activity.

As to whether the breadboard could be a problem:  It's not much of a noise source in itself, though it might pick up some ambient electromagnetic fields.  I think it's more likely that using the breadboard means that you use long, loose wires to connect the components.  I've seen the performance of a number of analog projects improve when I replaced pre-cut jumpers with cut-to-length telephone wire.  Loops of wire act like antennas, and, probably worse, have a higher impedance than short wires or printed-circuit traces, leading to small but noticeable voltage drops across them.  

You might get improvement by using single-point grounding.  Bring a ground from the Arduino to a convenient spot on the breadboard, and then run every other ground to that same point.  We sometimes want to think of every ground as being exactly the same; however, when we run a ground from one device to another in daisy-chain fashion, we accumulate current - and hence unwanted voltages - in the chain of conductors.  I've seen analog circuits improve, sometimes considerably, when I reminded myself to do this.

Finally, I encourage you to use power-supply decoupling capacitors very close to any analog components that draw power from the supply, like the amplifier IC, if you don't have them already.  I'd recommend an electrolytic and a ceramic capacitor in parallel - maybe a 10 uF and a 100 nF.  Texas Instruments' datasheet for the  LM386 quotes a power supply rejection ratio of 50dB, but mentions that the test is performed with a 10 uF bypass capacitor.  I can't quite do the math just now to figure out whether 50dB of rejection is really good enough for this application.  Bypass capacitors might not help much, or they might make a huge difference, depending on the actual source of your unwanted signal.

The reality is that you're trying to get very good analog performance from a digital circuit.  That's not typically as easy as we'd hope - you have some work ahead of you.

... I think I'm overthinking this ...

You're overthinking it?  I'm defenitely overthinking it, and it's not even my project.

You haven't said whether the power to your analog section is the same supply that runs the Arduino.  Is it?

OK, I hear two things:  some hiss, and some soft, changing musical tones.  The tones seem to alternate from something less than a whole tone below the foreground note to maybe about a minor third above it.  The pattern seems to repeat.  Those tones are very faint, though, and I could be wrong about their pitches.

I'll suggest that you try recording a couple of seconds of audio four ways, as an experiment:
1) With the Arduino connected, and running its program, with the output pin's mode set to output, but with the PWM turned off
2) With the Arduino connected, and running its program, with the output pin's mode set to input, with the PWM turned off
3) With the Arduino connected, but with its power supply disconnected, and
4) With nothing connected.  You may have to plug in a cable to the sound card to convince it that something's there.

if you're feeling especially curious, you could try letting the PWM run, and connecting the output to a different, quiescent digital output, and then to a quiescent digital input, and see what happens then, too.

I won't ask you to post those files, because that amounts to a whole lot of data.  But, I'll ask you to listen to them, to find out whether those effects are showing up without the PWM operating.  I'm thinking that they may artifacts of the programs running on the Arduino or the PC, or of the power supply. 

The Arduino's power supply will likely have switching components, and they may switch in a fashion that makes some audible artifacts on the output signal.  Remember - the digital signal isn't perfect; excursions on it's power supply will affect the output voltage.  Those excursions may come from the power supply itself - probably a PC's USB port; from short-term variations in the power supply voltage caused by current drawn by the Arduino; or from the PC power supply that drives the sound card you use to record.  I note that the sound card you're using is external, but I'm not sure that means that its power supply is isolated from the PC. Is it USB-powered?

The hiss that you hear may be filterable, but the tones are right in the range that your low-pass filter has to let through.  It seems unlikely that you'll be able to filter them out, while leaving the actual output audio signal unaffected. 

No need to post files.  We'll rely on your ears.

I'm delighted to hear that there's improvement.

I've been unable to identify the extraneous sounds you're talking about.  I may hear a bit of hiss in the background, but I'm not sure that that sound is what worries you.

The wav file looks great.  If you want improvement on that, it's possible that a better filter will help; it's also possible that it won't.  I can't predict.

You may want to look into using op amps to develop a multi-pole filter.  Inductors are hard to find in precise values, and they continue to be a annoyingly non-theoretical.  One of the favorite aspects of op-amp filters is that you can implement a two-pole filter without using inductors.  Texas Instruments publishes a program that will do the laborious math of filter design.  You can find it here: http://www.ti.com/tool/filterpro.

[P]

Here's a method of calculating brightness levels that appear to be equally spaced.  It may be a bit late in the thread's life for this.  

Stevens' power law  - see it here: http://en.wikipedia.org/wiki/Stevens_power_law - gives a method of determining the relative perceived intensity of a stimulus - in this case, brightness of an LED - as a function of the physical magnitude of the stimulus.  Here's the general form:
P = k * S^a
where P is the perceived intensity, S is the magnitude, and k and a are constants that depend on the type of stimulus and the units of measurement.  The value of a is less than 1 for brightness and loudness; greater than 1 for electric current through fingertips.

The value of a isn't well-characterized, though.  For light intensity, it might be around 0.33, but the actual value will depend on the ambient lighting, color, the color and brightness of the background that it's seen against, and, to some extent, which one of us is looking at the LED.  It'll take some experiments to find an acceptable value.

Dealing with k is easier - in fact, we can forget about it.  Here's why:  the units of P, the perceived brightness, are arbitrary.  They're generic "perceived brightness units," and they don't correspond to any real physical quantity.  So, we can pick the units of P so that the value of k is exactly one, and then we can forget about k.  We'll also select the units of S as PWM ticks - the time-averaged illumination resulting from a PWM code of 1.  The amount of light that comes from the  LED varies nearly linearly with this quantity, so it's a reasonable unit to use.  And, doing so makes the math a lot easier.

To do the experiments, we can pick an a, and calculate an array defining n equal steps.  First, we calculate the maximum perceived brightness in arbitrary units:  
P_max = S_max^a
S_max is the code that corresponds to the maximum brightness at which you want to operate an LED.  It could be anything, but it's easy to select 4095, since that's the maximum brightness code your LED driver IC will accept.  Then, for n=0 to N, where N is the number of steps, calculate S_n like this:
S_n = [P_max * (n/N)]^(1/a)
or, in C, rounding the output codes to integers:

Code:

levels[n] = int(pow(Pmax * ((float)n/(float)N), 1/a) + 0.5);

The wiki article suggests that a is between 0.33 and 0.5.  My experiments say that might be true, but they also say that equal step-size is tricky to identify.

At the end, we have an array of codes that will ostensibly yield an equal change in brightness for each step.  That's true if you believe that Stevens' power law accurately describes perceived brightness.  Not everyone does.  The alternative is the Weber–Fechner law - http://en.wikipedia.org/wiki/Weber-Fechner_law - which describes a curve that's logarithmic, rather than a power function.  The math is about the same, except that it uses exp() rather than pow(), but the experimentation is harder - it requires you to find a stimulus magnitude that results in a perception of zero, and that stimulus magnitude can't itself be zero.  My rough tests suggest that a PWM code of 1 yields a perceptible brightness, so I think that we'd just be guessing about it.  The power law seems to be reasonably well-accepted, so it'll likely yield acceptable results.

Looking at the .wav file with Audacity, I think that the waveform is clipped, and slew-rate-limited.  Looks like there's trouble on the analog side.  I don't think that you've gotten the project to a point where it will really help much to add a complicated filter on the output.  I'd suggest fixing it as best you can before you go to that effort.

Here's what I undestand about your project, based on what you've told us so far:

• Looking at what I think is your code - from the link you included with your original post - it appears that your output data range from 0 to 254.  That corresponds to a time-averaged output voltage ranging from 0 to nearly 5V, or almost full-scale for a 5V system.
  
• You're using an RC filter on the output: 330 ohms and 0.01 uF.   I presume that the resistor is connected between the output pin and the capacitor, and that the capacitor is connected between the resistor and ground.  I also presume that the audio output is taken from the junction of the resistor and the capacitor.  That output filter will have a cutoff frequency of about 48 kHz, and it won't noticeably attenuate the frequencies that you're interested in, which range from 440 Hz to about 1.5 kHz - and those figures are based on the code you linked with your first post, rather than the code that you've pasted into your posts.  It's worth noting that a this filter won't attenuate the 32 kHz PWM signal very much, either.  It's not clear to me that it's doing much good.
  
• You're using an LM386 to amplify the output, but you haven't described how it's hooked up.  I presume that it's connected to provide a gain of 20, because that configuration uses the fewest parts, and that you're powering it from 5V and ground.
  
• You recorded the wav file that you posted using a speaker and microphone, rather than directly connecting the filter output to a recording device.  I don't see much of the PWM signal in the file, so I suspect that the whole circuit - including the LM386, the microphone, and the recording input - attenuate that signal quite a lot.
  

So, it looks like you're using a 5V peak-to-peak signal to drive an amplifier with a gain of 20, and a power supply of 5V.  The amplifier can't deliver 20 times the input voltage under those conditions, so the output is clipped. 

The LM386 has an input resistance of 50k ohms, so a quick way to get the output signal into the linear range is to connect a 1M ohm resistor between the output of your filter and the input of the LM386.  The voltage divider formed by the 1M ohm resistor and the 50k ohm internal impedance of the LM386 will attenuate the input signal by a factor of 20, and the amplifier won't be forced to clip the output signal.  You might be better off with a 1.2M ohm resistor.  Either way, the impedance of the 1M+ ohm resistor is much higher than the filter's impedance, so it won't affect the filtered output in any noticeable way.

I believe also that you'll get better results if you use an output filter with a lower corner frequency.  I'd suggest a frequency of maybe 6 kHz - two octaves up from the highest frequency you'll output, and 2+ octaves below the PWM frequency.  As it stands, your output filter passes the PWM frequency almost unaffected.  Maybe change the 330 ohm resistor to a 2.5k ohm resistor.

In the wav file, the regions between the flat-tops show a nearly constant slope, but it's too shallow to correspond to a sine signal with the same frequency as the wave in the file.  That leads me to believe that the output is also slew-rate limited.  The LM386 datasheet doesn't describe a slew rate.  However, the data in the wave file are pretty much what I'd expect to see for an overdriven, slew-rate limited amplifier.  Reducing the input signal, as described above, will help a lot with the slew rate - it'll reduce the rate by a factor of 20.

Try that, and see if you don't get some improvement.  I believe that you'll hear only a small loss of volume, but a much clearer sine output. 

I've made a lot of assumptions, and those could be wrong.  But, we don't have much information to work with.  I'll note, though, that the wav file provides a lot of insight into your system, and we'd have never gotten it from a verbal description of the audio.  I'll also note that the audio doesn't sound bad at all, and it sounds to me that it's doing what you wanted it to do.  I'd have thought that the effect you describe was an artifact of the recording technique.  If I'd built this project, I might be calling it a success by now.

Two things you must do:
1) Disable the Timer2 interrupt while you change the tuning word, and
2) Calculate the new value of the tuning word while the Timer2 interrupt is enabled.
See the code, posted earlier, explaining exactly how to accomplish both things.

With regard to your output filter, and selection of components:
Your output signal will vary between 440 Hz and (440 + 1023) = 1463 Hz.  Your signals are close to pure sine waves, so you aren't interested in preserving any higher harmonics.  The pulse-width modulation frequency is about 32 kHz.  The frequency that you want to filter out is 32 kHz, and the frequency that you want to keep is 1463 Hz.  There's no point in filtering at 50 kHz.  I'd recommend filtering at about 2500 Hz, corresponding to a resistor of about 6K in place of your 330, and see how that works.

If you want pure tones, then you just might have to go get the components for a multi-pole Chebyshev filter.  The single-pole resistor-capacitor filter that you're using may not be adequate to meet your expectations.

I'll note that it seems that you don't have a clear understanding of what you're trying to accomplish.  I don't think that you understand very well how the program works, how interrupts work, or how the hardware works.  If that's so, then I'll recommend that you start with the wikipedia article on pulse width modulation.