In SX Microcontrollers, SX/B Compiler and SX-Key Tool, PJMonty wrote: The whole "sampling" issue seems very misunderstood to me. 1st, the Nyquist theorem says you can't sample a signal that is any higher than 1/2 of the sample rate. However, this is [i]in regards to a signal you intend to reconstruct[/i]. Specifically, if you are sampling an audio signal that goes as high as 20 kHz, you must sample at a minimum of 40 kHz in order to reconstruct that signal with any fidelity. The truth is that as your signal frequency approaches the sample rate, the reconstructed fidelity gets lower and lower. This is easy to understand if you imagine sampling a 20 kHz sine wave at 40 kHz. If your sample rate was [b]perfectly[/b] synchronized with the signal (not likely, but lets pretend), [b]and[/b] you just happened be sampling at the peaks of the sine wave, then you would have one sample at maximum value and one at minimum. Of course, this means that your nice pretty since wave has now been converted into a square wave. In the real world, folks depend on output filtering of the DAC to reconstruct the sine wave, but the fact is that your sine wave is gone and won't be coming back with any fidelity any time soon. It only gets worse when the signal isn't some simple sine wave, but is instead some bit of real audio. What does this have to do with UART sampling? Basically nothing. We are [b]not[/b] attempting to reconstruct the sampled signal. We are merely interested in the absolute value at the moment the sample was taken, and our amplitude is limited not to 16 bits, but 1 bit - simply on or off. Further, [b]we can happily sample at the [i]exact same rate[/i] as the incoming signal all day long[/b]. Yes, I am stating that Nyquist be damned, it doesn't apply to the problem we are solving. The whole point of oversampling in a UART is [b]if[/b] we take the multiple samples and average them together to come up with a consensus. In other words, if there is some noise on the line and during one of our sample periods we got a one when we should have received a zero, then by having 2 or 3 or 8 other samples, we can easily see that if only one of them has a value of one and all the rest are zero, then our true result should be zero. But what about drift? We have two different clocks! Who cares? That's the whole point of the start bit. The entire sampling duration starts over on each new start bit. Every UART on the planet is designed to see the start bit, wait 1 1/2 bit times, and then start sampling on each bit time. The 1 1/2 bit widths gets us past the entire start bit and halfway into the first bit [b]where we take a sample[/b]. By then sampling every bit time width, we are now sampling in the middle of each bit in the data stream. Remember, [b]we are not not concerned with reconstructing a signal[/b]. We merely want to get the sample value in the middle of each bit. From that single sample, we have all the information we will ever need to decode the bitstream. Everything else is just icing on the cake. [i]Sampling at 2X or 3X or 100x of the baud rate won't get us any better information than sampling at 1X the baud rate if we don't do some sort of statistical analysis of the over sampled data[/i]. Simply taking a ton of samples and then using the one in the middle is [b]exactly the same as sampling at 1X[/b]. In fact, it [b]is[/b] sampling at 1X. So, if you aren't doing the extra work with all those samples, save yourself the trouble and just sample at 1X. If you need a higher interrupt rate to run multiple VPs in a single interrupt, go right ahead. However, you will still only take one sample in the middle of the bit time width and not do any UART work the rest of the time. You are now returned to your normally scheduled programming... Thanks, PeterM ---------- End of Message ---------- You can view the post on-line at: http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=213780#m214255 Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2007 (http://www.dotNetBB.com)