[cross-post] dither generator on fpga

Calculate the worst-case inaccuracy in position due to quantization errors. This will be at a point where one ADC is reading maximum or minimum, and the other one is reading close to it's center point. If that inaccuracy if small enough to not cause you problems, then you're golden.

If you don't know how small an error you need, then you must analyze your control loop, or you must build the system and give it a whirl. As a rule of thumb, your allowed quantization step should be about 1/4 or less of the desired precision of the axis, and it must be small enough that the quantization noise going into the derivative term in your controller does not heat up your motor or final amplifier, or cause undue power drain.

Also, look at the ADC data sheets. If the internal noise from the ADC is greater than 1 LSB (it usually is for ADCs of more than 14 bits or so) then you're getting dither generated for you for absolutely free. In that case you may need to oversample the ADCs and average their outputs anyway, to avoid noise issues.

That depends on how complicated you want to get. In general dither is only going to do you any good if you accompany it by oversampling and decimating. In that case you'd either like the dither to be out of band, which you can approximate pretty well with a sigma-delta modulator on the dither signal, or you'd like the dither to be periodic, in which case you'd sample the raw ADC synchronously with updating the dither, and you'd average the ADC readings and decimate synchronous with the periodicity of the dither.

If you oversample by a factor of 16, and if your four FPGA pins go through weighting resistors to make a 4-bit DAC, then just count from 0 to 15 and repeat. Unless you're driving an RC filter to your Vref you won't be able to do better than that.

I would capture the correct number by doing an arctan of the ADC inputs. This has worked well for me in the past, in software. You'll probably want to calculate the arctan using CORDIC or some other FPGA-ish method, but that's a nit.

Hi Tim,

In comp.arch.fpga Tim Wescott wrote: []

The precision we have on the position can be directly transformed into angular precision:

A = A0 + A1*sin(2*pi*opd/lambda) B = B0 + B1*cos(2*pi*opd/lambda + psi)

where A/B are the sine/cosine signals, opd is the optical path difference (position in nm), lambda is the optical frequency (1550 nm) and psi a phase shift. With a precision in position of 20nm we have to have a precision in the phase accumulator which is of the order of

But it looks to me a bit too big as a precision on a very sensitive optical mechanism... According to my calculations the 4 deg error corresponds to a normalized signal (A0/B0 removed and A1/B1 renormalized) of nearly 10% full scale... I guess something is wrong in my calculations!

I guess though precision is not the only factor to take into account. While I can drive the motor precisely, it does not mean that I drive it smoothly instead might be rather jerky if I allow spourious frequencies to get out.

But how can I hit the quantization error? Shall I consider a particular frequency for my sine/cosine waveform? IIRC quantization errors show up especially in submultiple of the ADC sampling frequency.

That is a good hint. I have an ENOB of 11.1, so in principle I have less than 1LSB noise for both distortion and noise...

We are sampling at 250KSps a signal which is from DC to 4KHz... I'm wondering even why we are sampling with such a rate. Anyway it seems that decimating may be easily achieved.

Being out of band would save me additional logic I guess. Indeed I can make it such to be filtered by the tracking demodulator.

wouldn't that harmonic be affecting my tracking demodulator?

This is something I'm also wondering. Offset and renormalization are steps which need to be done anyway, but instead of a tracking demodulator the atan may be very simple, no loop required, no cutoff frequency...just plain easy. What about if your signals have a small phase shift?

Truth is that if the phase shift error induced is not that large I could throw away the demodulator and live with the arctan...

We are doing this in hardware and indeed we could have a look at the performances of the CORDIC to be used in our demodulator. Up to now nobody really looked at how we could optimize the algorithm.

Al

Are you sure that the outputs are true sine and cosine? The analog output, optical devices I have worked with, output trapezoidal waveforms with a phase shift similar to sine/cosine.

BobH

Hi BobH, BobH wrote: []

The input signals are specified as sine/cosine. We do not perform system integration therefore would be up to the system engineer who specified the interfaces to make sure box A can talk to box B,

And 20 / (1550 * 2 * pi) is roughly 0.005 radians, if I'm doing the math right in my head (do double check with a calculator).

In closed-loop systems it's usually best to treat quantization errors as an injected noise signal at the worst possible frequency. So you should analyze the loop for its response to a signal injected at the ADC, and you should see if the response to noise at the level of the quantization error and at that worst-case frequency is going to cause you a problem.

Be careful with ENOB numbers. Sometimes they're measured assuming that you're doing some averaging. Also, it looks like your input to the ADCs may have its own dither -- when you're dealing with quantization noise, random noise is actually your friend, because random noise can be averaged out, where quantization noise cannot.

If you average and decimate synchronously with the dither signal, then the dither signal would not show up in your decimated signal.

Then you'll have the same difficulty with you tracking generator as you would taking the atan. If the signals have a small known phase shift, you can get the correct orthogonal pair by a linear transformation (work out the math).

Hi Tim,

Tim Wescott wrote: []

oops I must have hit a wrong number, you are right, 4 deg *is not* .00022 radians.

Well, I guess we both made a mistake. Given the definition of A:

A = A0 + A1*sin(2*pi*opd/lambda)

and a precision on opd of 20nm @ lambda=1550nm means an angular precision of:

debian@debian:~$ echo '20/1550' | bc -l .01290322580645161290

in radians, or:

debian@debian:~$ echo '180/(4*a(1))*20/1550' | bc -l .73930038081396543067

in degrees, which makes a little more sense w.r.t. the 4 degs I came out with earlier.

So a sine with 1LSB amplitude at a submultiple of sampling frequency, I guess that would be the worst case you are referring to, is that right?

That is clear, unfortunately the incoming signal has no noise figure, instead a THD is specified.

I had the impression the tracking demodulator was not as sensitive to the phase shift (I took for granted), but I guess I'm wrong since lately we simulated the result with a phase shift bigger than specified and the demodulator went bananas!

Unfortunately the phase shift is not known, but indeed a phase shift is easy to estimated with a phase detector and corrected for with the CORDIC (in rotation mode).

The signal has a max. frequency of 4KHz when the motor is moving at full throttle and we are sampling at 250KSps, it means my phase correction cannot be better than 360/(250/4) ~5.7 deg. But I guess that phase shift comes mainly from the feedback sensors relative position so should not change in time. If the motor is slowly moving we can have a much more precise measurement of the phase shift and correct for it.

Is that too naive?

The atan approach is in openloop and is seems easily implemented with two CORDIC, one for the phase shift correction and one for the atan...The offset removal and renormalization will still be needed though.

Interesting. I've worked on transmissive optical quadrature encoders that specified a sine wave output.

In the OP's case, he's computing an output based on the wavelength of a reference source, which leads me to believe that there's some sort of interferometry going on, which would be sinusoidal because that's what the peaks and valleys of the light are going to be.

Hi Tim,

Tim Wescott wrote: []

You nailed it! Unfortunately I cannot disclose the name of the project due to a certain amount of NDAs we have signed. It is possible that indeed nothing would happen otherwise, but I'd like to avoid looking for legal troubles... I prefer the technical ones ;-)

These encoders were HP (now Avago I think) transmissive, current output, optical quadrature sensors looking at a rotary wheel. We converted the current output to voltage, put some comparators on the voltages and fed the voltages to two channels of ADC. The comparators provided an integer value and we interpolated a fractional value from the ADC's based on the state of the comparator outputs. The outputs were triangular with some flat topping. It worked great and got me away from walking point on a really high visibility project. The manufacturing guys checked our results with high speed cameras and were amazed at the accuracy. That's about all I can say about that project for NDA issues.

BobH