Large jitter on angle in resolver and sincos mode

[johu]

Alright, first off here is the plot I took in Touran. You can see jitter is just 0.7°. And that is with PA0 still configured as input with pull down.
Then I flashed the software attached in my previous post to my test board without seeing any improvement. Still 20mV dips and angle jitter around 5°.

[bexander]

Bexander, I am sending you a fully built and working board. Its the one I used in the FOC tuning video and in a recent video running an MGR. Let's see if this solves your problems.

Thank you! Very kind!

[bexander]

Alright, first off here is the plot I took in Touran. You can see jitter is just 0.7°. And that is with PA0 still configured as input with pull down.
Then I flashed the software attached in my previous post to my test board without seeing any improvement. Still 20mV dips and angle jitter around 5°.

So here is a firmware where PA0 is configured as analog input in resolver/sincos mode. Please check, I will do the same.

Are you shure that this is the correct SW with PA0 changed as it turns up the same as the one with spot values sin and cos added? (4.91.R)

I also get no change in angle spikes with this SW when testing on blue pill. There is nor any change in the dips seen at PA0.

Regarding the 20mV dips I have an answer. They are caused by to high impedance in the 10k/1nF filter. The information I found yesterday from ST states that the max impedance is 0,4kohm with a ADC clock frequency of 14MHz and 1,5 cycles sample time.
I did some measurements on pin PA7 with a 3.3V supply and a potentiometer feeding via a 10k/1nF 16kHz break off frequency filter.

Then with 330r/1nF filter 482kHz break off frequency.

And finaly with a 330r/30nF 16kHz break off frequency filter.

Also another interesting finding. When having the oscilloscope probe at PA7 (sin) this is what angle plot looks like.

And this is when the probe is at PA0.

A hole lot more jitter when probeing at PA0, which is odd. Something is happening with this pin. However on the blue pill PA0 is also the throttle pot input which might mess it up a bit. I will pull my real board out of the inverter tomorrow to take better measurements.

Would it be possible, for testing, to completely remove PA0 from the injected ADC reading?

Johannes: What tool/program do you use to compile the SW.

[johu]

Very interesting find! the ADC only runs at 9 Mhz but still. I do remember experimenting with different sample times and 1.5 seemed best. Maybe you can check again. You can also try to sample PA6 PA6 PA7 and only use the second PA6 reading. Still surprised the problem doesn't show in Touran and many other boards.
There are build instructions in readme.md, I use arm-none-eabi-gcc that I installed with my package manager.

[bexander]

I think the dips at PA0 is due to ADC as well. When the ADC reads it creates a dip due to the capacitance in the ADC.
With 9,33MHz the resistance at the input can be 1kohm so will test with 1kohm/10nF filter tomorrow and also put a capacitor at PA0.
1nF should give a dip of 26mV when charging 8pF which is Cadc. 10nF to 8pF gives 2,6mV and 33nF to 8pF give 0,8mV. 0,8V is one bit. The resolver should be able to drive 330ohm.

On the blue pill PA0 is set as ADC normally as this also is the input or throttle pot. This also explains why this disturbance looks different on the blue pill compared to the Yaris board as it is read constantly and not only when PA6 and PA7 are read.

What I still can't explain is how disturbances on PA0 effects the angle plot? Will keep at it.

Still surprised the problem doesn't show in Touran and many other boards.

Yes, that's the hardest part to explain...

[johu]

I have changed the injected sequence from 0, 6, 7 to 6, 6, 7
The result is indeed a cleaner angle plot and about 1.5° jitter on my test board. With 10k/1nF low pass that is.
Also played with sample times, increased them to 13.5 clocks but that didn't make any difference.

[johu]

Improvement when using 1k/10nF instead - 0.7° jitter

[bexander]

I was about to post that I had no success with measurements today when I discovered the new SW.
Ran out to the garage to test it on the blue pill.
Sin and cos with old SW:

Sin and cos with new SW:

Quite some difference!
I call that a win!
Will test on the Yaris board in the inverter later or tomorrow.

[bexander]

Both plots are using 330ohm/30nF filter.
Will also test this with the resolver later.

[johu]

That is indeed remarkable! Will test if it solves the jumpiness in Touran at very low speed and very low throttle.

[bexander]

I'm afraid it had no effect on the spikes in angle plot on the Yaris board.

Blue is exciter voltage feed to resolver:

Blue is sin and red is cos from resolver, feed to logic board:

Now looking at sin (left) and cos (right) from SW, looks like this most of the time:

But sometimes this apperes:

A sign shift on cos?? How is that even possible?
All measurements done with 330ohm/30nF filters.

[bexander]

The cos signal is read twice now as the SW does 6, 6, 7.
I really don't understand what the ADC is doing or how it can have these effects?
How can reading in input 0 create a lot of disturbance on 6 and 7? Can a double reading of input 6 also create disturbances?
The fact that the first injected ADC reading is always noisy. Is this your finding or does this information come from a specific source? And how noisy will the signal be?
Would it be possible to do a SW with the dummy read removed?
A lot of questions and not alot of answers...

[johu]

I wonder if the phase shift changed by swapping in another low pass. Can you scope the digital exciter signal (as it exits the STM32) vs. one of the return lines?
The noise on the first read was my finding, I roughly remember it was over 100 digits.

EDIT: apart from that there is always cross talk between ADC channels as the sample & hold capacitor needs to be either charged or discharged from the previously sampled input. Also a scope lead is like an antenna and might feed crap back into the chip.

Of course that doesn't explain the huge jumps you are now seeing, they are caused by something being fundamentally wrong

[bexander]

I wonder if the phase shift changed by swapping in another low pass. Can you scope the digital exciter signal (as it exits the STM32) vs. one of the return lines?

What phase shift are you talking about? The resolver exciter vs feedback in first picture? That is due to the position of the motor. Both sine and cos are read as negative, hence phase shifted vs exciter voltage. Or are you talking of somethinge else?

Yes, noise is inevitable but the disturbance when reading 0, 6, 7 was more than crosstalk and probe noise.
When doing 6, 6, 7. Is it possible that not all register bits are zeroed or somehow miss read when doing two readings of the same channel? Both are stored in the same register and perhaps sometimes a erroneous bit remains, hence the sudden sign shift? What I have seen so far the sign shifted cos signals are the same amplitude so only sign bit wrong.

[johu]

What phase shift are you talking about? The resolver exciter vs feedback in first picture? That is due to the position of the motor. Both sine and cos are read as negative, hence phase shifted vs exciter voltage. Or are you talking of somethinge else?

Well the exciter signal starts out as a square wave. It then travels via 3 low pass filters that make it sinusoidal AND add some phase shift. Then the amplifier, the resolver and the input low pass filter add more phase shift. The software needs to know the time between toggling the exciter pin and the peak of the return signal. We have an amplitude modulation, the 4.4 kHz carrier we generate and the resolver modules the amplitude. If we do not sample at the peaks, the value might be bogus.

Yes, noise is inevitable but the disturbance when reading 0, 6, 7 was more than crosstalk and probe noise.
When doing 6, 6, 7. Is it possible that not all register bits are zeroed or somehow miss read when doing two readings of the same channel? Both are stored in the same register and perhaps sometimes a erroneous bit remains, hence the sudden sign shift? What I have seen so far the sign shifted cos signals are the same amplitude so only sign bit wrong.

I'd not look into digital errors now. That would require a bad processor.
Just scope the exciter and one return signal as close to the processor as possible and we'll go from there.

[bexander]

I hope this will do the job. Measured at R35 (STM32 side of first resistor in exciter filter) to R32 (STM32 side of input filter resistor).

I do not have a cursor function in this scope SW under Linux but as far as I can measure there are 158us from exciter rise to peak of cos signal. With a period time of 227us I get a phase shift of 158/227*360 = 251 degrees.

Also the motor position is at about 348 degree when doing this measurement to get a nice large amplitude on the cos signal and also the signal to be close to in phase with the exciter signal.

[bexander]

Depending on how I set the data point and the burst length I get some different results but I find this very odd.

Both sin and cos jumps alot between negative and positive values but the angle signal seem fine. If the sampling always occur at the peak of the feedback sin and cos values the measurements presented should be a straight line on or close to the same value all the time when the motor is stationary.
Could it be that sampling point trigger sometimes triggers at rising flank and sometimes at falling flank? As far as angles goes the math results in the same angle so output should be fine anyway.

Regarding spikes in angle plot, to catch them I need to set 10000 data points and 1000 burst length. Then I catch them every time. With less data point I don't always find them.

[johu]

Yes, good scoping. So the delay between an edge and the next peak is expected to be 40us, in your diagram it is 45us but I think that is still close enough.

And now: DOOOH! Yes of course the signal is sampled at both peaks! And then the sign is inverted on the negative peak.

Code: Select all

      if (invert)
         return SineCore::Atan2(-sin, -cos);
      return SineCore::Atan2(sin, cos);

But the sin/cos spot values were not inverted so you see the jumps
Ok, so angle all good now, not jittering too much or jumping?

[bexander]

Ok, so angle all good now, not jittering too much or jumping?

No, sorry to say but I still can find spikes of several degrees, as before.
It depends on what settings I have on the plot window. If I set 10000 data points and 1000 burst length I find them every time. But with setting as above 100 and 10 it usually looks great.

I will do more testing later today.

[johu]

Yes with low burst length you miss a lot of data. It's like http request - get 10 data points - next http request - loose 1000 data points - get 10 data points.

[bexander]

Several plots of angle at a couple of different motor positions.
An overview.

Same position, more detail.

Different position

Different position

The accuracy of the plot window is maybe not the best but to me the spikes all look very similar. To similar to be a coincidence.
I'm still thinking that it might be something more in the ADC.

Is it possible without to much trouble to make a firmware with sin and cos without sign shifting, so I can look at sin and/or cos simultainiously as angle? I wan't to see if the spikes can be seen there as well.

[bexander]

In order to find the spikes it would be very helpfull if I can find its periodicity but the plot window does not have what it takes.
My idea is to read the data directly on the uart from stm32 to esp8266.
My guess is that this data is sent with alot higher rate then what is shown in plot window.
If this is possible, I could also do absolute value on sin and cos so no firmware upate needed.
Good or bad idea?

[johu]

Yes you can do something like "http://192.168.4.1/cmd?cmd=stream%20100 ... ,cos,angle"
that gives you 10000 lines of comma separated data that you can then paste to a spreadsheet.

Data rate is 921400 baud. Every character is 11 bits, so about 83 kb/s. Every data point is like 7 characters so you'd end up with about 12000 data points per second. Of course if you sample 3 data points that becomes 4000 per second. Still about every other PWM period but if you want real time you can query only one value.

EDIT: the ESPs 80 kb RAM will limit you on the number of data points. A USB UART adapter would raise that limit.

[bexander]

Excellent!!

Now the results.
First only logging angle to sample every data point possible.

Zoom at first spike.

Zoom at 8th spike.

Remember some points are logged twice, hence the flats.

[bexander]

Now sin, cos and angle in the same log. As johu mentions, some data points are missing but all three graphs are in sync.
Angle

Absolute value of sin

Absolute value of cos

Spikes appere in both sin and cos.