The HW filtered input is delayed relative to the raw accelerometer output as well. One could see this by collecting analog data from both the accelerometer output and the RC filter simultaneously.
you mean like this ?
This in NOT true generally speaking. Arduino ADC uses sample and hold circuit.
thanks for your comments, i will look up to learn about "sample and hold circuit."
Hope this helps.
it does indeed - thanks for that very informative website link - it looks like just the right level of complexity for my current level of knowledge.
As stated by MrMark, the R-C will delay the accel signal, the delay is a function of frequency.
If you look at Bode Plot in the figure titled "Frequency Response of a 1st-order Low Pass Filter" you can see the delay, represented as a phase at (each) frequency.
i'll have to study that more closely, am not quite sure what i'm looking at and where the delay is occuring in
When looking at how the A/D works, it takes a "snapshot" of the input pin and holds it in a 14 pF capacitor. This is akin to taking a "flash" photo of someone in motion, often the resulting photo is shows the subject in some awkward position. The same goes for the arduino A/D. If a noise spike occurs at the time the analog multiplexer disconnects from the sampling capacitor, your conversion reflects that noise spike as a real value.
That is expanding in more detail on what Smajdalf was mentioning, right ?
His mention of "ADC" and your "A/D" are one and the same thing.
PS If you want to be philosophical, there is not such thing as DC voltage. The universe has only been around for 13.772 billion years. So the lowest frequency one could see is 1/13.772 billion years (converted to Hz).
interesting point - will have to mull that over !!
If you want to compare your RC filter with a simple software filter, have a look at:
[ code ]
thanks a lot, i will certainly try that out.
With your RC filter you can calculate the Time Constant.
To simulate the same time constant in software, you calculate the number of sample times.
So, with your 1k/10uF, RC = 10mS
If you do an analogRead() once per millisecond, 10 x 1mS sample period = 10mS 'Time Constant'
It is important to note that the speed at which you sample the signal affects the 'software time constant' but, of course, does not affect the hardware RC time constant.
ahh, this gets to what i was trying to grasp earlier with the "delay(1000);" - of course in a non-blocking method with millis().
so the sampling or reading of the signal is every "n-th" period (of the time constant) - instead of once every loop() execution.
this would mean ignoring some readings in between - it doesn't seem that the HW version would do the same ? (or is that 'phase delay' doing exactly the same thing.)
thanks everyone for the insightful comments.
(it's very helpful for my learning while doing" approach - which probably is not as efficient as a formal approach from learning in an organised instructional way)