Re: delta sigma mod. for BLDC motor controller

High frequency current in the motor coils induce high frequency currents in the motor magnetic path, which warm the rotor (and decrease it's magnetic permeability) without doing anything useful.

I've never been sufficiently involved to need to run the numbers, but the d ifferent between magnetic core materials for different frequencies is that the higher bulk resistance materials are more suitable for higher frequency applications - laminated iron cores for 50/60Hz mains distribution, powder iron cores for higher frequencies, manganese-zinc ferrites for up to about 100kHz and the higher resistivity nickel-zinc ferrite for use up to about

The 3kHz limit could reflect the nature of the rotating component in the pa rticular motor.

Hi Bill,

Bill Sloman wrote: []

Ok, now I understand. As long as the motor movement is still within the

The motor speed is 10 rad/s max and number of poles is 7 so we are not talking about great speeds. It means ~7*1.6 electrical turns per second, ~10Hz. Why would we want to cut off that high?

See above. Even with margins we are a too big factor away from the maximal speed. Am I wrong?

Al

PWM usually runs at 20KHz or above, to reduce acoustic noise from the motor.

Delta-sigma will generally have more transitions per second than PWM, hence higher switching losses. And d-s will have low frequency noise components, which could cause acoustic hissing (whereas PWM has whining) and, in a precision positioning app, maybe mechanical jitter.

Most uPs have PWM generators built-in.

Your FPGA can generate PWM or d-s. One trick is to generate PWM but dither the LSB to increase resolution without increasing the switching rate. That's equivalent to coarse PWM plus fine d-s.

Be careful with your terminology. Does Al mean a 3kHz loop bandwidth, or a 3kHz filter between drive and motor?

If the latter, I would expect some limitation on harmonic content, not just something called a "cutoff".

Sigma-delta around the PWM command modulus, per this article. The short story is that if the number you need to command the PWM is 23.4, you command it with 23, 23, 25, 23, 25, repeat.

If you've got more than 6 or 7 bits of resolution to the PWM generator, noise in the system will probably swamp out any attempts to sigma-delta the thing. Sometimes noise _is_ your friend.

Then you need to pay attention to those. Do you just need to round off the edges, or do you need to keep the PWM out?

If you are working on a control loop and Harry Nyquist knocks on the door, escort him to the nearest Starbucks (or priest, given his birth date). Then get on with your job.

You don't want to even _think_ in terms of the Nyquist limit when you're working on control loops. Sample at least ten times faster than your desired loop bandwidth, unless you have a superlatively well-behaved plant. Higher precision loops need higher sampling rates.

Re-read my article on sampling:

Over 20kHz if audible noise is an issue (over 25kHz or 30kHz if you want to cover 99.9% of the population instead of just 99%).

Resolution should be enough that, after cleaning up the rest with sigma- delta modulation, the residual noise does not make audible noise (growling, hissing, or singing) and does not consume excess power.

If you have 11 bits of resolution into the motor, you are worrying needlessly. The noise in your current sensing loop will swamp out the bottom three to five bits anyway, so sigma-delta techniques would be a waste of time (oh, if I'd read this earlier...).

Do you mean the current loop bandwidth? The driver for that is their required control loop bandwidth, and how close they think they can push it to the current loop bandwidth. They probably need between 300Hz and

Higher than 20kHz switching is going to add bearing currents, so you might have failures of the motor over time if you just increase the frequency

You also have more conducted EMI noise which combined with chaotic delta sigma can cause big problems when designing the EMI filter (both to high levels, but also triggering known resonances of the EMI filter/mains source)

Regards

Klaus

I forgot: also, it needs to be fast enough so that the triangular current wave in the motor is small enough so that the I^2*R losses at "zero current" (really zero average current) is acceptably small. For any motor bigger than your big toe, 20kHz is probably enough.

As mentioned, iron losses in the motor may be a factor, but usually these aren't an issue. If the motor mysteriously runs hot, then you can start worrying about it.

Hi Tim,

Tim Wescott wrote: []

The 3KHz are on the loop bandwidth. Apologize if I wasn't clear from the beginning.

w.r.t. filtering the customer is specifying wants to *avoid* any source of emission between 5KHz and 50KHz because this is where the scientific signal will by laying.

When we talked about a 20KHz PWM in our first proposal they saw the risk and changed the spec to impose a hard notch in that region. That is why we are somehow obliged to go beyond that notch.

Al

Hi John,

John Larkin wrote: []

acoustic noise is not a driving factor, we are flying in low earth orbit, with 10E-5 mbar there's very little to propagate sound. Yet it is possible that microvibrations might be effected (but is just a guess).

I see the switching losses argument, yet I don't understand what is the low frequency noise related to. But I believe you pretty much made it clear that driving directly with d-s would consume more the driving stage.

we do not have a uP. Software is banned from this system to reduce development costs (software qualification for space equipment is a heavy burden for this type of application).

If I understand correctly you mean dithering the already converted signal, right? I guess that some level of noise would be there 'for free', but preparing for the worse is never a bad idea.

But how do I choose the PWM frequency?

Al

It's really interesting that an FPGA, programmed in VHDL or Verilog, is inherently more reliable than software programmed in, well, any language. I've noticed that myself... far fewer bugs in FPGAs compared to uP code. Finite state machines vs essentially infinite-state machines. Makes sense.

The easiest way is to try it, and see what's most efficient. In vacuum, you'll have cooling problems with the electronics and the motor, so measure everything.

You can simulate the switcher in Spice, and get pretty close, but motor losses are hard to simulate.

On a sunny day (Thu, 11 Dec 2014 08:04:20 -0800) it happened John Larkin wrote in :

Maybe the FPGA code is simpler, or the programmer more concentrated. I have very few reliability issues with software, if any. It runs if it runs. FPGAs may have timing issues, something a software writer do not normally have to bother about as that has been taken care of by the processor vendor.

And many FPGAs have some processor core these days, so you make no sense. What else is a processor than a state machine?

The issue is the number of states, and specifically whether the programmer understands and controls all the possible states. In a sequentially executed program, the state is the bits of the program counter concatenated with every bit of every flag and variable, which can get to be a big number. Ironically, most programmers don't know what "finite state machine" means. I teach them when I need to.

The number of states of even a modest program is probably more than the number of electrons in the universe. Some of those paths will be diabolically pathological.

In an FPGA, there are usually many small synchronous state machines that interact in controlled ways. Usually, data does not affect control states. States are visible and usually explicitely managed... ALL of them. The biggest hazard in FPGA design is usually clock-domain crossings. Pure timing problems are rare, what with modern FPGAs being blindingly fast and the tools being pretty conservative about margins.

And FPGAs do not depend on operating systems and drivers and undocumented peripherial controllers. Well, sometimes they do use a mysterious PCIe block, or encrypted IP, but even those usually work.

Once you add a couple of ARM cores to an FPGA, naturally the ARMs inherit all the bug potential of C procedural software... horrors of interrupts, mutexes, threads, pipes, callbacks, logic mazes.

We write realtime uP software that usually has an explicit central state machine to manage top-level operations. That seems to help.

C is a sequential, procedural language. VHDL is not. That seems to make a lot of difference.

On a sunny day (Thu, 11 Dec 2014 09:28:21 -0800) it happened John Larkin wrote in :

I run a real time DVB-S encoder on a Raspberry Pi that can do live video. To get over the task switching delays I use a small hardware FIFO. Does that mean it is less reliable than an FPGA? No, it is more flexible, options can be added in minutes, it is networked too, I can stream via from IP cameras on the LAN, or content anywhere on earth (netcat is cool). Does it ever crash? No, been running all day, it exited when it found an EOF on the video, made while loop. Sure you can make such a thing in FPGA (of course I investigated that possibility) but your development time would go out the window, and making changes and a net interface would require additional hardware, cost could go up exponentially, did I mention the HDMI out, the USB facilities, etc. And that is the reason many FPGAs now have some processor core. If you are into those [state] machines opencores.org at one time had many simple processor cores,. easy to make your own processor. I dunno if opencores still is active ? The Raspberry plus a few TTL - or whatever, interface chips, is cheaper than that FPGA board you have been advertising. In fact there is an FPGA plug in for the Raspberry (have not used it) probably a better way to do things. Then you can run your precious hardware thingy where it should be, and the programs on the Raspi.

Anyways it is not one thing better than the other, you cannot compare apples and oranges. Well you can, but does not make a lot of sense.

Sometimes I really wonder if you did not mislay that clue. You can write bad - and good code either way.

Hi Tim,

Tim Wescott wrote: []

So the duty cycle of a PWM would be regulated with a d-s which would have, on average, a better resolution than just the PWM. Still I do not see from the Fig. 6 of the above link, why a dithered DAC gives less DC error than a straight DAC.

And still I do not see how do I relate my precision in the current provided to the motor with the PWM frequency and the resolution of the current sense and the d-s.

Lost you here. From the article above I understood that dithering would help me to get a closer desired output even if the resolution of the DAC is not extremely high. Considering that a higher resolution on my current would potentially pick up 'free noise' from the load itself, why would it swamp out the attempt to delta sigma the loop?

Still don't have access to the EMI spec (due to ongoing changes!), but I believe the notch would be so severe that the only practical solution would be to keep the PWM out of the range 5KHz - 50 KHz. The interferometer is measuring uV in that frequency range, the entire scientific mission is running on that frequency range.

Where the factor 10 comes from? What makes me choose a higher/lower frequency? Is it related to the 'uncertainties' of the plant that I want to be able to *meausure* in order to control them?

I like the 3500 pole order filter to get to a 40dB signal to alias ratio, a hell of a filter :-) Thanks for the pointer.

audible noise may not be as important as microvibrations on the platform.

Lost again. Which residual noise you're talkin about?

Is that because the noise replace our 'dithering' and therefore allows for a increased resolution? The problem I have is that I'd like to have a relationship between the desired precision *and* one or more paramenters of my control loop.

Yup.

So if the control loop bandwidth is higher than the current loop one it would be limited by the latter, correct?

Let's see how smart they are...new specs is coming under the Christmas Tree, just to delight the family reunion!

Al

Hi John,

John Larkin wrote: []

There are two fundamental aspects that make a difference between the two worlds:

1. ease to change
2. complexity

Re-programming and FPGA is rather a PITA compared to just running 'make' and this very simple aspect has a huge impact on the way development is carried out. That is also why, for space applications, the development flow tends to limit the possibility to wildly change the code base, increasing the risk to break everything.

Most of the FPGA used in space applications are also *not* reprogrammable and they cost a fortune, so great care is taken before giving the go to program the device. Usually code coverage aims to 100% and often gets very close to it, yet bad specifications are the very root of all mistakes.

Secondly the complexities tackled by a software stack w.r.t. to an FPGA is certainly far from being comparable. A software system is extremely more complex to handle, but things are changing rapidly since new space rated FPGAs are becoming huge monsters for multicore SoC and loads of fancy capabilities (dsp blocks, serdes, PLL, ...). A paradigm shift would be required in handling those devices since verification efforts will skyrocket together with complexity.

We do not have the motor, we *just* make the electronics for it and when (or if) we get the motor it will be too late to make mods. We need to rely our choices on analysis and not on a trial.

This is what I also believed. But maybe for my precision requirement I do not need to know motor losses and a static inductive load would suffice, am I wrong?

Al

Hi Jan,

Jan Panteltje wrote: []

The quality of a product is not given by the programmer capability but the quality of the process he's working with. The reason why the Shuttle program has a code base of 750 KLOC and 17 documented bugs is because the process they worked with was rock solid.

A simpler code may rely on lighter processes, but as soon as complexity rise the process needs to rely less on the programmer's ability and more on the thought through development flow.

have you ever done an HSIA? What about an FMECA? What's the code coverage? If your code is relying on any driver, OS, library, are they verified?

I guess we are talking about a different type of reliability.

Software /writers/ need to take care about asynchronous tasks interaction, priority inversion, dead locks, interrupt handling...I'd say the FPGA guy must be happy with his two flops resynchronization effort for clock domain crossing...

The issue is not if the processor is a state machine or not, the issue is about the branches a software can get into and all the time you need to test and/or analyse those branches.

On top of it, compilers, as well as languages, are far from being optimally defined and leave undefined behavior creeping in your work of art silently. Likely enough norms and guidelines do exist to get you out of the mud and 'safely' produce high quality code, but the process is far from being cheap.

Al

When a straight DAC is wrong, it's wrong forever. If you dither it, then you can make it exactly right on average, at the expense of increasing the overall error energy.

Ahh -- it's complicated. Really, with an integrating controller and perfect current sense, your average error will be zero. Worrying about the resolution of the current sense ADC is probably pointless -- you'll have so much noise in there that even a sleazy 12-bit ADC will be far better than the signal it's trying to read.

The lower the precision of your PWM is (with or without D-S modulation), the harder it is for the control loop to hold the current steady.

Because the magnitude of the changes to the PWM command as a consequence of the free noise will be far larger than the magnitude of the changes to the PWM command as a consequence of the D-S modulator.

That's new to me. Just run the PWM higher, and possibly filter if that gives the motor gas pains.

It's a rule of thumb, that mostly comes from the fact that sampling adds delay and delay means phase shift. Ignoring the delay in the processor, sampling adds, on average, sorta, 1/2 of a sampling interval of delay. That means that -- again sorta -- the phase shift at loop closure from sampling alone will be about 20 degrees if you close the loop at 10 times below sampling rate.

If you're driving the PWM frequency above 50kHz, and you're sampling at the same frequency, then if you have the processing power for it just make sure that your integrators are deep enough not to underflow and enjoy the fact that you don't have to worry about the sampling rate as a limiting factor.

I like reductio ad absurdum arguments. It seems like the quickest line between "oooh, shiny!" and "nope, this ain't going to work".

That's a good argument against sigma-delta -- but again, I don't think that's going to be a problem for you.

Residual noise from the sigma-delta. It works by taking the DC error and pitch-forking it up in frequency: you have to account for what it does wherever it ends up.

Yes.

This is getting beyond what I want to answer for free. The way to find the answer is to analyze the loop for noise response, with noise injected at the various points that you know will cause difficulty (like the current measurement).

It's in my book. It's in any decent book on control systems, except they usually don't tell you why you want to know it (I'm pretty sure I do).

No, the control loop bandwidth is limited by the phase shift of the current loop, even when the current loop bandwidth is higher. Look at the phase shift of a simple 1st-order lowpass filter, and how low a frequency it starts to come on compared to the 3dB point.

ng

What hasn't been said so far, and probably needs to be said, is that people using PWM to drive motor coils tend to use the inductance of the motor coi l to suppress the harmonic content of the pulse-width-modulated waveform.

This can be a bad idea. The parallel capacitance of motor coils tend to be quite high, so all the really high frequency content goes straight through the coil, and circulates around the leads to and from the motor - a larger radiating area than necessary.

And, as I've mentioned, the high permeability material defining the magneti c paths within the motor can have relatively high conductivity, so that the inductance of the coil can be shorted by the "shorted turn" in the magneti c path, so - once again - more high frequency current travels along the mot or leads and radiates into the environment.

It's a good idea to put a passive low pass filter on the output of the PWM generating electronics. It's expensive - high current rated inductors aren' t small or cheap - but it confines the high-frequency radiating components to the smallest possible area, and you can specify a high resistivity core material for the local inductor, minimising any "shorted turn" problems.