## CIC filters with decimation ratio jitter

Started by 5 years ago9 replieslatest reply 5 years ago157 views

I'm familiar with CIC filters (https://en.wikipedia.org/wiki/Cascaded_integrator%...). What happens if the decimation ratio isn't constant? For example, I have a $$f_1$$ = 1.024MHz sampling rate, and the downstream consumer is approximately 1kHz, so the decimation ratio is nominally N=1024, but the entity in charge of the 1kHz rate has lousy jitter specs and is not synchronized to my $$f_1$$ clock, so the number of samples acquired at $$f_1$$ ranges from N=1020 to N=1028? (BUT -- I know the value of N associated with each output sample)

Is there a way for the CIC structure to still be useful? Or is it worthless without a rock-solid guarantee on decimation ratio synchronization?

[ - ]

JMS-

Trying to get a mental picture ... you're saying that you have a sample buffer (or more than one, at 1.024 MHz) and the "downstream consumer" is taking an irregular number of samples from your buffer at his rate ?  You can't control how much he consumes ?

-Jeff

[ - ]
You can't control how much he consumes ?

Nope. Different example: Picture you have a Swiss watch with a CIC, ticking at once per second on the dot, dutifully adding up ADC samples, and Uncle Ned comes over once a day... noonish. You tell him how many samples since the last time, and the output of the last integrator value. He goes away, scratching his head, and does something with it. You don't know what. It pains you. Sometimes you give him 86123 samples, sometimes 86902 samples, sometimes 85779 samples... but if you happened to get a day where exactly 86400 seconds had gone by since the last time, you'd be flabbergasted.

The question is, can Uncle Ned make any sense of your ADC values? (Maybe he's trying to get average temperature over a day. I don't know.)

[ - ]

"It pains you", hehe.  Yeah I can see that.  Maybe Ned is wiser than he looks, if he knows the number of samples he consumes (seems like a reasonable assumption) then possibly he's maintaining enough previous data (delay) in order to perform processing that depends on a constant / regular number of samples.

[ - ]

Yeah, well, except in this case Ned is me. Or, rather, Ned is just a courier acting on my behalf, and all he does is go fetch the ADC samples and give me the information while I start swearing and wondering why he can't manage to be punctual.

Certainly if I had sample counts like 86303, 86303, 86303, 86303, 86303, 86397, 86397, 86397, 86397, then I would expect everything to be perfect except around the transient where the number of samples changes. But if the sample count changes every time, what can I do if it is a system built of 2 stages or more of CICs?

[ - ]

One possible solution is for Ned to relax and be tolerant. But seriously it is normally the responsibility of input side to eject the right outputs and not expect the current module to detect and correct that.

I said normally but remember line coding is done by input side and the receiver must act upon. This is justified in long distance comms but do we extend the same to low level local design?

This problem sometimes arises in team work when for example once somebody asked me to detect his wrong packet headers sent to my module and correct them instead of him sending the correct headers always.

[ - ]

Yes, that's useful.   I do that in resampling loops and tracking loops where the output sampling instant is steered by the loop, i.e., the decimation ratio is steered by the loop.

This is not unlike using a loop to steer a polyphase filter decimation rate, where there is essentially jitter in the coefficient selection for the same reason.

This generally does not cause appreciable output distortion in either CIC or polyphase filters.

[ - ]