Author Topic: High resolution analog to digital conversion of current spikes  (Read 8041 times)

0 Members and 1 Guest are viewing this topic.

Offline npelov

  • Frequent Contributor
  • **
  • Posts: 284
  • Country: bg
    • Microlab.info
Re: High resolution analog to digital conversion of current spikes
« Reply #25 on: April 26, 2015, 10:39:16 am »
I talked about digital filters in general because I want to implement them in my projects. I did't  say I'll implement them in this project, although I probably will. But let's say I don't have any digital filtering - is the highest possible error the attenuated frequency at Fs/2 or Fs? Let's say there is very strong 0 db tone just above Fs/2 - at (Fs/2)*1.1. If the filter has -40dB at Fs will the error be 1% it'll be the attenuation level at Fs/2.
 

Offline T3sl4co1l

  • Super Contributor
  • ***
  • Posts: 14080
  • Country: us
  • Expert, Analog Electronics, PCB Layout, EMC
    • Seven Transistor Labs
Re: High resolution analog to digital conversion of current spikes
« Reply #26 on: April 26, 2015, 03:51:49 pm »
If there's no digital filtering, then it's Fs/2.

Tim
Seven Transistor Labs, LLC
Electronic design, from concept to prototype.
Bringing a project to life?  Send me a message!
 

Offline npelov

  • Frequent Contributor
  • **
  • Posts: 284
  • Country: bg
    • Microlab.info
Re: High resolution analog to digital conversion of current spikes
« Reply #27 on: May 02, 2015, 04:42:06 pm »
I realize that digital filters of 24 bit data are not really an option with 8 bit MCUs. Floating point is too slow to achieve anything > 900sps (leaving no CPU time for anything else) and compilers for 8 bit mcus do not support more than 32 bit integers, so there is no space of multiplying 24 bit data by reaasonable resolution coefficients.

So I should either switch to more powerful MCUs  (not going to happen soon) or I should stick to analog filters. The problem with MCP3901 is that it has digital noise +-2000 LS digits in 24 bit and about 4-5 digits in 16 bit mode. Probably my circuit is adding even more.

So I'm going to forget about 16 bit resolution and maybe round it to 10 000 counts (14 bits, non full scale). I think I can get almost stable reading at 10 000 counts.

Digital filters are quite interesting, but I wasn't able to find good calculator that scales the coefficients to integer with certain number of bits. That would be useful for MCUs. Is scalling the coefficients as simple as multiplying them by certain number and then the result should be divided to that number?
 

Offline T3sl4co1l

  • Super Contributor
  • ***
  • Posts: 14080
  • Country: us
  • Expert, Analog Electronics, PCB Layout, EMC
    • Seven Transistor Labs
Re: High resolution analog to digital conversion of current spikes
« Reply #28 on: May 02, 2015, 06:11:55 pm »
Hmm, I had written a... was it a 16x16-->32 bit MAC?  That takes 29 cycles on AVR (has 8 bit, 2 cycle hardware mult).

Do some reading on fixed point.  The best premise is to consider the ADC reading a dimensionless fraction of its range (0 to 2^N - 1 == 0 to 0.999... == 0 to 5V or whatever), and then it becomes apparent that: every addition potentially produces a carry, which is overflow and nothing else (can be detected and used to saturate the result, if needed); every multiply produces additional bits, which should be carried for the duration of the immediate calculation but must be discarded at the end, because they are simply such tiny fractions (in the 2^(-2N) range) that they don't matter to the result.

That is, when you perform the multiplication
AB * XY = A*X + ((B*X + A*Y) >> N) + (B*Y >> 2N) = CDEF
(where A/X and B/Y are the high and low words, respectively, and C is high, D is low, E is low-low and F is low-low-low),
the last product is superfluous because it lands in words EF (except for possible carry into D), and therefore can be truncated at the end of the calculation.

At the very last possible, final, step, you might apply scaling (calibrations?) and units (perhaps even resorting to floating point), only for the last step of, say, writing it to the display as a human readable number.  At such low update rates, this is a tolerable use of such slow operations.

FIR coefficients are scaled linearly, because the distributive property.  IIR coefficients you'd have to work out.

If nothing else, you can simulate a series of N samples on a spreadsheet, or write a script for it in any language you prefer (C, Java, MATLAB/Octave, etc.).  You can achieve perfect numerical accuracy (i.e., bitwise perfect agreement with the integer code that will eventually end up on the MCU) by making judicious use of scaling and rounding functions.

The MAC I mentioned earlier, was a function I wrote as part of proving out a temperature correction function.  Here's the heading comment,

Code: [Select]
;
;     countToTemp
;
; Converts a 12 bit ratiometric ADC count into a
; temperature (in 12.4 fixed point format, °C),
; using a 7th order polynomial approximation.
;
; 74 words, approximately 310 cycles.
;
; Input:
;   r17:r16: 12 bit ADC count to convert
; Returns:
;   r1:r0: 12.4 fixed point, temperature in °C
;

I had written two of these, the other based on a seemingly elegant sum-of-reciprocals method: however, because division is such a painful operation to compute (without hardware... heck, even with!), it was way larger and slower.

Tim
Seven Transistor Labs, LLC
Electronic design, from concept to prototype.
Bringing a project to life?  Send me a message!
 

Offline npelov

  • Frequent Contributor
  • **
  • Posts: 284
  • Country: bg
    • Microlab.info
Re: High resolution analog to digital conversion of current spikes
« Reply #29 on: May 03, 2015, 05:42:33 am »
Well, 16x16 is not a big deal. I don't think that it's worth trying to optimize it because of the results of the Microchip App. Note:
http://ww1.microchip.com/downloads/en/AppNotes/00852a.pdf

Their test results with 16 bit IIR and 8 bit FIR coefficients show that at 8kHz of 10 bit ADC uses ~ 2.5MIPS of the 10 MIPS available - which is 1/4. I'm assuming that they spent some effort optimizing it, even if it's not the best optimisation. So 10 bits by 16 bits will rarely spread to more than 24 bits. But what if I have to multiply 24 bits ADC data by 16 bits coefficients. If I use fixed point that would give me 48 bit result which I can later round to 24 bits again. Also the MCU time for doing that would be a lot more. Also you said that IIR is a lot sensitive to rounding.

I could spent a lot of efforts of doing optimized assembly code for the filters, but that'll probably not stabilize the ADC input. With second order IIR I was able to get stable 500.000 mV reading (LS digit playing +-2) at cut off frequency <1Hz (not sure about the exact numbers). The display wasn't updating fast enough. It took seconds to get into 1% reading.

I agree that it could be done (probably), but I'm not sure if it's worth the time spent for optimizing it.

Maybe some day I'll try to optimize it for dsPIC which has 16x16 bit signed hardware multiplier. With it 24 x 16 multiplication won't be that time consuming. And even then it might be less expensive to replace it with PIC32 and just use non-optimized floating pointing in plain C ... unless it's something that will be produced in 1000s.
 

Offline T3sl4co1l

  • Super Contributor
  • ***
  • Posts: 14080
  • Country: us
  • Expert, Analog Electronics, PCB Layout, EMC
    • Seven Transistor Labs
Re: High resolution analog to digital conversion of current spikes
« Reply #30 on: May 03, 2015, 08:08:48 am »
Well, 16x16 is not a big deal. I don't think that it's worth trying to optimize it because of the results of the Microchip App. Note:
http://ww1.microchip.com/downloads/en/AppNotes/00852a.pdf

Their test results with 16 bit IIR and 8 bit FIR coefficients show that at 8kHz of 10 bit ADC uses ~ 2.5MIPS of the 10 MIPS available - which is 1/4. I'm assuming that they spent some effort optimizing it, even if it's not the best optimisation.

That's probably fair for that platform.  Their inner loop looks awfully long.  I don't know if that's a PIC thing.  Possibly; it's an ancient instruction set, and pretty sparse, most ponderously so on registers.

The pile of registers on the AVR lets it plow through DSP stuff like this -- set up all your coefficients and operands, and just chug chug chug away.  If register values need to be protected, push/pop goes outside the loop, around the function, so they only cost constant time.  The fewer memory sources you have to read/write during the loop, the better; and if they can be accessed with sequentially indexed addressing, all the more (e.g., reading samples or coefficients from a linear buffer).

Most any modern CPU should perform as well or better.  At a glance, dsPIC and MSP430 (assuming hardware multiply is included) are probably a few times better than AVR at this task, and PIC32 (MIPS core) and ARM anything (Cortex M0 on up) even better still (wider operands, especially handy for higher precision; more addressing modes; higher clock rates, and in the even faster ones, pipelines and cache).

Or a DSP architecture, but that would be serious overkill for such simple filtering.  Setting up the data flows might well be more overhead for such a simple problem on those.

Quote
So 10 bits by 16 bits will rarely spread to more than 24 bits. But what if I have to multiply 24 bits ADC data by 16 bits coefficients. If I use fixed point that would give me 48 bit result which I can later round to 24 bits again. Also the MCU time for doing that would be a lot more. Also you said that IIR is a lot sensitive to rounding.

Total number of (possibly required) bits in the product is always the sum of bits in the operands, but 10b x 16b with real signal data probably won't miss the two bit truncation (but you will still need to carry them through, otherwise that would be equivalent to truncating one or the other operand directly, which wouldn't be nice).

For a fixed size hardware multiplier (i.e., 8x8 or 16x16 or whatever), more bits takes O(N^2) operations, so if you're doing 24 or 48 bit MACs, it can get very attractive to use a more powerful instruction set.

IIR is very sensitive, but that's one place where simulation can help.  Occasionally, you can play around with the bits, and round it to a convenient number, that happens to give a stable result, but at a slightly different cutoff frequency, or Q factor, or gain.  This can be solved before hand, and the compensating gain term can be calculated.

Much the same as selecting rounded component values for the analog filter, but those are much more stable, so it's a lot easier (since the poles lie on the complex plane -- instead of poles inside the unit circle, a much tighter margin).

Point being, if you calculate a filter that requires, say, 18 bit coefficients for stability, but you get lucky and find a set of coefficients that end in two zeroes, you can truncate those to 16 bits, and save a whole bunch of calculations on an 8/16 bit platform!

Quote
I could spent a lot of efforts of doing optimized assembly code for the filters, but that'll probably not stabilize the ADC input. With second order IIR I was able to get stable 500.000 mV reading (LS digit playing +-2) at cut off frequency <1Hz (not sure about the exact numbers). The display wasn't updating fast enough. It took seconds to get into 1% reading.

Well... yeah, that's exactly what a filter should do.  If you want an aggravatingly slow update, you can filter the piss out of it, and get one really stable number.  It might not even be as accurate as it is stable (i.e., you're stretching it out to way more bits than the ADC is even worth), but that's certainly something that can be done.

If you want something nice and responsive, an IIR with rapid settling, or an FIR, or a combination of both, would do well.  The IIR, of course, must be calculated in much the same way that you'd calculate an analog filter with rapid settling -- i.e., minimal overshoot and phase delay: a Bessel filter.  (The FIR can simply be a "hump" of any suitable shape -- a windowed piece of sin(x), Gaussian, actually sampled Bessel impulse response, etc.  But to get comparable performance, it will have to be long.)

There are still other possibilities.  If you want a periodic update, where each frame evaluates exactly the data in the proceeding frame duration, then you can just accumulate for a long time, then when it comes time to spit that out to the display, divide by the number of samples and correct for gain and whatnot.  The output sample rate is therefore the frame rate, which is less than the input sample rate -- a decimation process.  An impulse read during a frame will only show up after that same frame, so the impulse response is finite (= FIR).  This is what almost all DMMs perform, whether through analog (multi-slope integration) or digital means.

Tim
« Last Edit: May 03, 2015, 08:10:34 am by T3sl4co1l »
Seven Transistor Labs, LLC
Electronic design, from concept to prototype.
Bringing a project to life?  Send me a message!
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf