Close

PWM vs Pulse-Density Modulation: Power Supply

A project log for 2.5-3D thing

a tiny-but-scalable three-ish axis-system *from* laser-cuts

esot.ericesot.eric 09/02/2015 at 13:3012 Comments

Update (9-19-15):

Adding another pseudo-related hypothesis to the end...

Update (9-8-15):

@RoGeorge has a great project-page dedicated to comparing PWM and PDM aka "Delta-Sigma Modulation." #Delta-Sigma versus PWM. His project-page discusses the differences, and has some excellent graphics.

And Thanks to @Al Williams (or is it @Al Williams, 'if that is your real name...') for the writeup on the HaD Blog! http://hackaday.com/2015/09/08/pulse-density-modulation/

Update (9-8-15 2.0):

Adding a groovy image and description at the bottom...

Update (9-9-15):

Another, in ascii-art, at the bottom.

Adding a different fraction to the drawings, where cyclical nature is more evident.

A few TODOs added in the original text...

Adding disclaimer at the top... (right below the line, below...)

Update (9-9-15 2.0):

Adding a summary of and link to the hfModulation code

---------------

NOTE: I'm no expert on Pulse-Density Modulation, Pulse-Frequency Modulation, nor Delta-Sigma Modulation. In fact, I have a difficult time understanding their wikipedia articles. AS FAR AS I'M AWARE, these are all the same, or very similar. My so-called "High[est]-Frequency Modulation" (hfM) is something I came up with on my own, and used for years before discovering these terms for it (PDM, PFM, DSM). It's my [minimal] understanding, again, that these are all pretty much the same thing, and I've slowly (after years of using and improving hfM) started referring to it as PDM. THAT MAY BE A MISTAKE. Again, I don't fully understand the wikipedia articles on these things. It has been my intent, ever since I discovered the terms, to eventually figure out their differences and possibly rename hfM appropriately. In Other Words: TAKE THE INFORMATION HERE as nothing more than *my understanding* of PDM... Where I say "PDM" below, I'm referring, specifically, and plausibly mistakenly, to my hfM implementation....

NEW VIDEO:

Here, for this project, I have a motor rated for 3-6V... I'm using a 12V power-supply with PWM (or PDM).

At full-power (PWM = 100%, should be 12V) the motor draws more current than the power-supply can supply. The supply drops-down to 6V.

BUT: There's a big-ass capacitor where the power-supply enters the circuit.

PWM and PDM recap:
(I call my implementation of PDM "HFM",
 "highest-frequency modulation")

PWM: (cycle period = 6 counts)      >| |<--- one PWM "count"
 _._         _._          _._._       _._._
|   |_._._._|   |_...    |     |_._._|     |_...
^-----------^            ^-----------^
one PWM cycle            one PWM cycle
 33% power                50% power
     = 2 counts               = 3 counts

HFM: (max power = 6 counts):      >| |<--- one "HFM" "count"
 _     _     _            _   _   _   _
| |_._| |_._| |_...      | |_| |_| |_| |....
^-----------^            ^-----------^
one HFM "cycle"          one HFM "cycle"
power = 2 (33%)          power = 3 (50%)


UPDATE 9-9-15: Adding a different fraction, e.g. 2/5 and 3/5, 
      where cyclical nature is more evident

PWM: (cycle period = 5 counts)    >| |<--- one PWM "count"
 _._       _._          _._._     _._._
|   |_._._|   |_...    |     |_._|     |_...
^---------^            ^---------^
one PWM cycle            one PWM cycle
 40% power                60% power
     = 2 counts               = 3 counts

HFM: (max power = 5 counts):      >| |<--- one "HFM" "count"
 _   _     _            _._   _   _._   _
| |_| |_._| |_...      |   |_| |_|   |_| |....
^---------^            ^---------^
one HFM "cycle"          one HFM "cycle"
power = 2 (40%)          power = 3 (60%)

Where was I going with this, again...? Hmm, big-ass capacitor...

So, I intend to run the motor at no more than 33% power, using 12V and one of these modulation-schemes. That's roughly the equivalent of running the motor off 4V...

But (as I discovered late in the game) the power-supply drops-out at the current required by this motor at 12V. And, using one of these modulation schemes, the motor is *actually* given 12V quite regularly... So why isn't the power-supply dropping-out (to 6V) on every pulse of 12V? Well, in part, because of that big-ass capacitor.

And, in part, because my first attempts with this motor were done using "HFM"/PDM.

I didn't notice the effects of the power-supply dropping-out until experimenting with output powers >50%. With output powers >50%, the output pulses seemed to be drooping strangely. Weird, but not a problem, since I don't plan to use it at >33%.

Eventually I switched to PWM, just for the heck of it... (In this case, my PWM "counts" are the same duration as my HFM "counts"--their complete "cycles" occur at the same frequency). And, right off the bat, I noticed the output drooping strangely, again... even at really low power-output levels... It became noticeable at just 2 counts out of 256/cycle, less than 1% duty-cycle, less than 1% power output to the motor.

A little hunting, and sure-nough discovered it wasn't that the output-power was drooping, the power-supply was. It seems the "big-ass capacitor" happened to be just about the right size to keep the 12V supply pretty stable for one high PWM/HFM "count," but little more. At 2 "counts" the capacitor charge depletes noticeably, at 3-4 counts, the power-supply drops-out to a pretty steady 6V.

Guess it's just luck the capacitor I chose randomly weeks ago just happened to have been doing its job fine for so long, despite running *right* at its limit!

So, what's this all mean...? I dunno, exactly... This is a *really* odd setup, in my experience.

Usually the PWM frequency can be *much higher* than my software-based HFM implementation, since there are often dedicated PWM peripherals, and I've yet to see a dedicated PDM peripheral. In this case, however, the playing-field has been leveled due to the motor-driver's slow response-characteristics; the switching-speeds are plenty slow-enough to be handled by bit-banging in software, PWM or HFM.

Also odd about this setup is the fact that I don't intend on using output power >50%. That particular factor is what makes this discovery interesting... Since I'm using <50%, with HFM, there will be no pulses that are two "counts" wide. The capacitor sags *slightly* during a single high pulse and gets "recharged" in the following (low) pulse(s). If I stick with HFM then I don't need to increase the size of that "big-ass capacitor" nor upgrade the power-supply. Both of which would be necessary if I switched-over to PWM (in this setup).

Usually one would prefer a high enough PWM frequency that it wouldn't be audible, >20KHz is preferable. But that's not an option here. And, in general, there's always an upper-limit to the PWM frequency due to switching-speeds of the motor-driver... Even motor-drivers that are significantly faster than the one I'm using.

In this era of MOSFET-based H-Bridges, most of the heat generated is actually generated during the time it takes to switch a MOSFET from full-on to full-off, or vice-versa. This is the time where the MOSFET is actually acting like a (large/varying) resistor, thus generating heat. Usually that transition is so quick most people won't even notice it, but when switching *a lot* it becomes a concern. Note, because of that, HFM/PDM(?) is generally a *bad* option, because its main purpose is to switch at the highest frequency possible. Lots of (sloped) edges = lots of heat. OTOH, switching-times of MOSFETs are improving every day... easily-acquirable Class-D (switching) subwoofer-amplifiers can run at 250KHz switching-frequencies... maybe PDM has a place.

(TODO: Comments in the blog-entry suggest that PDM is actually used for audio encoding... should look into this)

Note, in this case, I could use PWM and a much-larger capacitor where the power-supply enters the circuit... It would have to be something like nearly 100 times larger. As-implemented: 1 count works, I want 33% power-output, 33% * 256 counts =~100! And, actually, I'm unsure as to whether the longer-duration discharge could be recharged quickly-enough without causing the power-supply to sag merely from the recharging-action... Here's where my hypothesizing gets a bit [more] iffy.

Anyways, PDM/HFM seems like the best-choice right now... at least with regards to the power-supply and "big-ass capacitor."

Update (9-9-15 2.0):

Here's a snippet of the 'hfModulation' code:

if(modulator->desiredSum > 0)
{
	(modulator->desiredSum) -= (modulator->maxPower); //0xff;
	toReturn = TRUE;
}
else //avg == desired is handled at the start... (except 0-case which works here too)
{
	toReturn = FALSE;
}

(modulator->desiredSum) += (modulator->power);
from: https://github.com/ericwazhung/meh-heartbeat/blob/master/_commonCode_localized/hfModulation/1.00/hfModulation.c

I think we have determined with little doubt that this is in fact "first-order delta-sigma modulation" whatever that means!

Update (9-8-15 2.0):

This image is of my implementation of Pulse-Density Modulation on a graphical display...

(from my avr-lvds-lcd project)

Seriously, look at @RoGeorge's #Delta-Sigma versus PWM page for a much more intuitive explanation...

But here's plausibly an interesting visualization.

I don't know why I left the screen rotated sideways for this picture...

The left column of (really large) "pixels" displays a power of 0/64(?), the next column displays a power of 1/64 (notice the one red pixel at the bottom, and the rest of the column is blue). The third column has a power of 2/64 (notice the red pixel at the bottom, and another in the middle). And so-on. At 50% power, 32/64, the column in the middle of the screen, the pulses alternate between red and blue...

(Update 9-9-15)

The following is the output of the 'hfModulation' test-application...

The first two graphics show hfm at various power-levels, (0-100% = 0/5 to 5/5).

Pulses which are on are indicated with '#'

There are two methods of changing the power-level, one is to start a new hfm_setup where you can set both the power-level and the maximum power (5 = 100%, here). The other is to use hfm_setPower, which does not allow changing of the maximum power, but is intended to be used for realtime changes in power, e.g. when fading an LED or simulating a sine-wave.

Using hfm_setup on each change:
0/5:|                                                                          |
1/5:| #    #    #    #    #    #    #    #    #    #    #    #    #    #    #  |
2/5:| # #  # #  # #  # #  # #  # #  # #  # #  # #  # #  # #  # #  # #  # #  # #|
3/5:| ## # ## # ## # ## # ## # ## # ## # ## # ## # ## # ## # ## # ## # ## # ## |
4/5:| #### #### #### #### #### #### #### #### #### #### #### #### #### #### ###|
5/5:| #########################################################################|
4/5:| #### #### #### #### #### #### #### #### #### #### #### #### #### #### ###|
3/5:| ## # ## # ## # ## # ## # ## # ## # ## # ## # ## # ## # ## # ## # ## # ## |
2/5:| # #  # #  # #  # #  # #  # #  # #  # #  # #  # #  # #  # #  # #  # #  # #|
1/5:| #    #    #    #    #    #    #    #    #    #    #    #    #    #    #  |
0/5:|                                                                          |
Using hfm_setPower on each change:
0/5:|                                                                          |
1/5:| #    #    #    #    #    #    #    #    #    #    #    #    #    #    #  |
2/5:| #  # #  # #  # #  # #  # #  # #  # #  # #  # #  # #  # #  # #  # #  # #  |
3/5:|# ## # ## # ## # ## # ## # ## # ## # ## # ## # ## # ## # ## # ## # ## # ##|
4/5:| ### #### #### #### #### #### #### #### #### #### #### #### #### #### ####|
5/5:| #########################################################################|
4/5:|##### #### #### #### #### #### #### #### #### #### #### #### #### #### ###|
3/5:|# # ## # ## # ## # ## # ## # ## # ## # ## # ## # ## # ## # ## # ## # ## # |
2/5:|# # #  # #  # #  # #  # #  # #  # #  # #  # #  # #  # #  # #  # #  # #  # |
1/5:|#    #    #    #    #    #    #    #    #    #    #    #    #    #    #   |
0/5:|                                                                          |

Attempting a gradient with realtime hfm_setPower() calls
  #           #    #   #  #  #  # #  # # # # ## # ## ## ## ### #### ########### 

Update (9-19-15): Hypothesizing on matters not really related to the log-title:

While this wasn't the intent, exactly, it just occurred to me that hfM lends itself well to varying the modulation power *during* a "cycle"... E.G. The "gradient" above, as a simple example. That portion of hfM was designed with the original intent of trying to keep smooth transitions while fading an LED between different power levels, without having to align a change-in-power with any particular position in the cycle. It was later improved explicitly for the purpose of creating gradients, wherein the "power" increases or decreases incrementally numerous times within a "cycle".

Now, extend that to something like motor-control, with a feedback loop... The hfM "cycle" duration might be significantly longer than a sensor/feedback-loop update. There might, in fact, be a hundred or more feedback-loop updates during an hfM cycle, or there may be hundreds of hfM cycles per feedback-loop update. It really just depends on the system. But for a simple system, this needn't really be taken into account! An hfM cycle might have 255 counts, initially it's set to 50% power, after 5 counts it's set to 75% power, after 10 counts its set to 31%... doesn't really matter if the set-power varies wildly during a cycle, as that cycle might just as well have been made up of 1 pulse in 256, or 75... Since the system's smoothed enough to handle 1 in 256, then surely it'd smooth whatever completely arbitrary pattern may occur in that 256. (excepting maybe unintended resonance, EMI, etc.?). In a PWM system, however, the power-change is generally only effective after the cycle completes... so, really, there's no reason to have a feedback-loop that updates faster than the PWM frequency (right?). Or, rather, it might be necessary to design the feedback loop to take into account the fact that it can't update the output faster than the PWM frequency (e.g. averaging, interpolation, maybe even extrapolation?).

Another way to think of it, maybe, is like neuron-firing... I'm not exactly sure how, but vaguely makes sense to me...

Discussions

alpha_ninja wrote 09/19/2015 at 14:33 point

the @Al Williams you're looking for has the username of hackaday.io/wd5gnr and is followed by more people: https://hackaday.io/hackers/78538/followers. The callsign checks out: http://www.qth.com/callsign.php?cs=wd5gnr and also says league city, like @Al Williams' profile page.

  Are you sure? yes | no

Al Williams wrote 09/19/2015 at 14:36 point

I think they are both me, but I need to figure out how I got in there twice. Perhaps it was my evil twin skippy.

  Are you sure? yes | no

esot.eric wrote 09/20/2015 at 21:27 point

He does look very similar!

  Are you sure? yes | no

esot.eric wrote 09/20/2015 at 21:25 point

Excellent investigation, my friend! Thank you for that!

  Are you sure? yes | no

RoGeorge wrote 09/08/2015 at 22:10 point

Never mind. After all, who cares how it's called, or how it is compared with something else, as long as it sweet your need?
Better invest the time continuing what you were doing, rather then splitting the hair.

Good luck with the rest of your project!

  Are you sure? yes | no

esot.eric wrote 09/09/2015 at 13:21 point

The problem is, I don't understand how to parse feedback-diagrams... I keep trying to read the wikipedia pages on PDM/DSM and it's just a blur to me. It's been a running-plan to make those comparisons for quite some time, it'll come, I'm working on it.

In the short-run, I should probably just focus on comparing with the code-snippet you've got on your page.

  Are you sure? yes | no

esot.eric wrote 09/09/2015 at 14:58 point

...which is a lot easier to do when the brain's in the right place...

Yeah, it looks like your code is nearly identical to mine... Except you "if (sum < max)" and "sum+=req" at the top, and I "if(sum > 0)" and "sum+=power" at the bottom :)

OK, so I think it's official... hfM is officially Delta-Sigma Modulation! Thanks :)

  Are you sure? yes | no

RoGeorge wrote 09/08/2015 at 20:03 point

Nice project, and thanks for mentioning 'Delta-Sigma versus PWM'!
:o)

  Are you sure? yes | no

RoGeorge wrote 09/08/2015 at 20:20 point

Looking at your graphical display for PDM, I'm afraid I might have misunderstood the explanations from the PULSE DENSITY MODULATION article. After all, the two kinds of modulation might not be exactly the same, :o(

Very good idea with the graphical representation. Compared with a text explanation, the graphical display is much easier to comprehend from just one look. With the first occasion, I should give it a try too.

Well done!

  Are you sure? yes | no

esot.eric wrote 09/08/2015 at 21:04 point

I'm a bit tired at the moment, but I should probably clarify that whatever it is I've developed, here, is my own-doing originally intended for LED-fading, and I only found an official name for it recently, in part from having come across your page... So, it's entirely plausible it's I who misunderstand PDM and/or DSM.

But they look pretty much the same to me, (maybe not identical?). Your algorithm looks quite a bit like mine... I'll try to do a side-by-side right now...

  Are you sure? yes | no

esot.eric wrote 09/09/2015 at 13:27 point

Heh, sorry, was so exhausted I totally missed the part about the graphical representation. Actually I did that just for the heck of it, since I was trying to figure out what to use my LCD project for. But thanks for the compliment :)

I'll post another graphical representation in a second, actually, so take a look!

  Are you sure? yes | no

esot.eric wrote 09/09/2015 at 16:03 point

Well-deserved! Did you see all the comments from the blog regarding your 'scope image? (Hope you don't mind I shared it there).

  Are you sure? yes | no