ruffrecords said:
JohnRoberts said:
Keep in mind if you do the rectification inside the digital domain you give up one bit of resolution so 10B A/D turns into 9b rectified. On paper this is enough for most modest meters (54 dB). I used 12 bit A/D and my resolution floor was limited by settling time of A/D input S/H, but I was multiplexing more than two input signals.
Good point about losing one bit. Can I assume your conversion time was short enough to handle 20KHz audio?
If you perform the rectifier before the PIC you gain one more bit of resolution, but the design engineer in me says don't spend more money and more PCB real estate to do anything outside that you can do inside. The digital rectifier requires learning an AC zero and performing some simple math on a per sample basis, but this is the kind of stuff microprocessors do well. Add, subtract, even multiplies only take one clock tick, so microseconds for even a slow PIC.
I don't recali the upper conversion time limit but it is fast enough. As I mentioned elsewhere I ran into a different time issue related to the input S/H settling time. The way the PIC provides their multiple A/D inputs is to multiplex input pins between only one internal A/D convertor. Visualize sampling between a stereo pair of inputs where one channel is at full volume and the other full off. Every other input sample for the A/D is slewing from as much as full scale back to nominal zero. This could become an issue for displaying wide dynamic range (low levels). On a meter this looks like low level crosstalk between inputs, while the mechanism isn't literally crosstalk and improves with adequate input capture times.
Another technical point that may not be obvious about sampling theory, the Nyquist criteria of Fs= >2xF, is primarily to prevent aliasing the frequency information, down to a lower pitch. For amplitude detection, who cares if a signal is showing up as 22 kHz or 18kHz as long as you can read the amplitude? For significant intentional under-sampling there is probably merit in dithering the sample period so it doesn't find a dead spot and under report if people meter HF steady state tones, but IMO the PIC are more than adequate for a 2x audio meter, and for only complex audio even a fixed under sampled rate probably works fine.
With byte wide I don't know if we run into resolution issues for coefficient, or accumulation registers, but you can double precision with some increase to code complexity (I ASSume).
Provided we stick to integer maths that should not be too much of a problem from the coding pint of view but timing might be an issue. I am keeping an open mind on 8 vs 16 bit.
Cheers
Ian
There is nothing about a simple meter that can not be handled in byte wide internal paths and operation, it is just a PIA IMO so I don't want to do it. For example the 10 bit A/D result, requires two bytes to represent. Likewise the AC zero to perform internal rectification requires two bytes, and subtracting the two to rectify the result requires an several step operation, not a single clock tick operation as with 16 bit wide data and instructions. The time to crunch this is not a critical constraint for even a relatively slow PIC while it's waiting for the next A/D conversion result, but somewhat more difficult to code and keep track of. I also prefer the extra 2 bits of A/D resolution (12 bit) in the newer PIC families but if the meter is limited to a modest dynamic range the extra resolution isn't needed.
I see no reason why the meter couldn't be done in one of the 8 bit families, only I don't want to do the gymnastics. If you do the rectification outside the PIC and only use the top 8 bits of A/D result, you could stay completely in 8 bit math. While I would still perform the time constant routine using two byte wide data (Note the 8 bit multiply gives a 16 bit result so this is not heavy lifting.).
You could simplify the code even further if you perform the rectify and time constants outside the PIC too, but the design engineer in me is screaming don't do that.
JR
PS: also check the pricing, Don't assume the older byte wide stuff is cheaper, IIRC the newer 16b processor I changed to was a little cheaper too. While the comparison is new PIC + LED latch vs. old PIC.
