Author Topic: PDM vs PWM  (Read 13113 times)

0 Members and 1 Guest are viewing this topic.

Offline merymeryTopic starter

  • Contributor
  • Posts: 14
  • Country: tr
PDM vs PWM
« on: March 09, 2021, 09:29:41 pm »
Hello everyone, although I researched, I could not understand the difference between PDM (pulse densty modulation) and PWM (pulse width modulation) in practice.
PDM: The analog modulation type in which the carrier signal pulse width changes according to the modulation signal. There is no change in the amplitude or position of the pulses. definition is made.

https://ars.els-cdn.com/content/image/3-s2.0-B0122274105001654-gr7.gif

PWM: a special case of PDM where the switching frequency is constant and all pulses corresponding to a sample are adjacent in the digital signal. definition is made.

https://circuitglobe.com/wp-content/uploads/2019/08/PWM-signal.jpg

It is described as the same in most sources, I can not see any difference in the graphics. Not used in fixed frequency in PDM? As an advantage, PDM allows ZVS / ZCS, reduces EMI, ok but how does it do it, what is the difference in implementation?
 

Offline Manul

  • Super Contributor
  • ***
  • Posts: 1109
  • Country: lt
Re: PDM vs PWM
« Reply #1 on: March 09, 2021, 10:34:30 pm »
Someone will correct me if I'm wrong, but I believe that:

1. PDM migh be confusing (pulse density modulation or pulse duration modulation, both are valid)
2. Pulse width modulation (PWM) has fixed period and encodes by varying the time ratio between states low and high during this period
3. Pulse density modulation has fixed pulse length and encodes by concatenating these pulses in more or less compressed chain (density)
4. Pulse duration modulation is I guess same as pulse width modulation
 
The following users thanked this post: merymery

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 6273
  • Country: fi
    • My home page and email address
Re: PDM vs PWM
« Reply #2 on: March 10, 2021, 04:41:31 am »
Perhaps an example signal illustrates the difference best.

Let H denote a high sample, and L a low sample, for a single clock cycle.
A PWM of period 37 and duty cycle of 32.4% (12 out of 37) is
    H H H H H H H H H H H H L L L L L L L L L L L L L L L L L L L L L L L L L
but a pulse density modulated signal with the same clock rate and duty cycle would be
    L L H L L H L L H L L H L L H L L H L L H L L H L L H L L H L L H L L H L
Essentially, in the same number of clock cycles, at the same duty cycle, you have the same number of high (H) and low (L) samples.  Within a single PWM period, they are separated, but in PDM, evenly distributed.

While PWM has a clearly distinguished period – above, 37 clock cycles –, pulse density modulation does not have a clearly defined period at all.

Because PDM does not have a clearly distinguishable period, with quantization noise at the high end of the spectrum, it is much easier to filter: just a low-pass filter at some fraction of the clock rate.  Compare to PWM, where any duty cycle except 0% and 100% have a characteristic frequency, at relatively low frequencies (compared to the clock rate used), and is much more difficult to filter out.  (Coil and capacitor whine are common results from pulse width modulation, at that characteristic frequency.)

Personally, I like most the fact that pulse density modulation can be adjusted at any clock cycle without any extra work; unlike pulse width modulation, which can only be modified effectively once per each period.



You'll usually see PDM defined as a function which converts an analog sample (or discretized analog sample), once per clock cycle, to a digital signal (high or low).  That is useful for signal analysis and mathematical treatment, but it isn't useful for hobbyists like myself that would just like to see what such signals look like.

Therefore, let me show you a pseudo-code approach to generating PWM or PDM signals – much like the one I showed you above, but something you can experiment with.

Since PWM operates in full periods, we'll let N be the number of clock cycles per PWM period.  (We will use it for the PDM as well, to make the two pulse trains easily compared/comparable.)

Let duty cycle be D, between 0 and N, inclusive.  (So fractional duty cycle is really 100%·D/N.)

To generate the PWM signal for one period:

    For T = 0 to N-1, inclusive:
        If D < T, then:
            Output level is High
        Else:
            Output level is Low
        End If
    End For

To generate the corresponding PDM signal:

    V = 0
    For T = 0 to N-1, inclusive:
        V = V + D
        If VN, then:
            Output level is High
            V = V - N     (or, equivalently, V = V modulo N)
        Else:
            Output level is Low
        End If
    End For

I guess I could create a web page (similar to my FIR Filter Analysis web page) that would let one play with these visually, but I feel a bit too lazy today; apologies!  :-[

For the PDM (latter) case, note that N is completely arbitrary, and only defines the range for the duty value D; and that D can be safely changed to any value between 0 and N, inclusive, every clock cycle.  On the other hand, PDM generation does require an addition on every clock cycle, whereas PWM is much easier to generate (digitally, just a comparison).
 
The following users thanked this post: tooki, JohnnyMalaria, atmfjstc, merymery

Offline pwlps

  • Frequent Contributor
  • **
  • Posts: 372
  • Country: fr
Re: PDM vs PWM
« Reply #3 on: March 10, 2021, 08:04:20 am »
Note that if you remove V=0 in the PDM code you can get a much higher resolution (depending on filtering, this is similar to 1 bit sigma-delta).
 

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 6273
  • Country: fi
    • My home page and email address
Re: PDM vs PWM
« Reply #4 on: March 10, 2021, 08:08:50 am »
Note that if you remove V=0 in the PDM code you can get a much higher resolution (depending on filtering, this is similar to 1 bit sigma-delta).
V is the internal continuous state, and is only reset to zero at bootup, not at any point afterwards.  It can be completely internal to the generator, and not directly accessible; and in the case of analog-to-digital converters, can be something like a capacitor storing a charge with a voltage comparator as the comparison/modulo operator.

Setting V to zero, or any other value, is basically always an error.  (But you do need to initialize it to some state at bootup.  The common values are zero and the default duty value D.)

The only case when you would modify V after startup is if you needed to ensure an output event at a specific clock cycle, and accept the overall error this incurs.
« Last Edit: March 10, 2021, 08:17:41 am by Nominal Animal »
 

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 8183
  • Country: fi
Re: PDM vs PWM
« Reply #5 on: March 10, 2021, 09:01:37 am »
A practical difference is, microcontrollers, even the cheapest ones, offer multiple channels of PWM generators. They rarely offer PDM generators, so even if you'd actually prefer PDM, you end up using PWM because hardware does it for you, often at high clock frequency, so your CPU doesn't need to run any code in real time, you can just fire-and-forget it.

PDM could be easily implemented in hardware; the pseudocodes Nominal Animal posted for PWM and PDM are both easily translated into digital logic (via hardware description language) and both have small silicon area; but due to tradition you just have PWM.

One may opt for a hybrid solution where the hardware PWM is used with a much shorter period (and hence, lower resolution), then a software loop "dithers" this PWM setpoint. The point is, the software doesn't need to do this for every output symbol. The result is like a "clumped" PDM; compare these examples (just boring 50% duty because I'm lazier than Nominal Animal):
Code: [Select]
HHHHHHHHHHHHLLLLLLLLLLLL
HLHLHLHLHLHLHLHLHLHLHLHL
HHHHLLLLHHHHLLLLHHHHLLLL

Now if you would adjust out of this 50%, the last example would start to have different duty for each different period, like HHHHLLLLHHHLLLLL...
 
The following users thanked this post: merymery

Offline merymeryTopic starter

  • Contributor
  • Posts: 14
  • Country: tr
Re: PDM vs PWM
« Reply #6 on: March 10, 2021, 10:18:35 am »
I understand your pseudo-code approach much better, but I didn't quite understand how your FIR Filter Analysis web page works, I'll look at it again in another free time, thank you  :)
 

Offline merymeryTopic starter

  • Contributor
  • Posts: 14
  • Country: tr
Re: PDM vs PWM
« Reply #7 on: March 10, 2021, 10:29:49 am »
A practical difference is, microcontrollers, even the cheapest ones, offer multiple channels of PWM generators. They rarely offer PDM generators, so even if you'd actually prefer PDM, you end up using PWM because hardware does it for you, often at high clock frequency, so your CPU doesn't need to run any code in real time, you can just fire-and-forget it.

PDM could be easily implemented in hardware; the pseudocodes Nominal Animal posted for PWM and PDM are both easily translated into digital logic (via hardware description language) and both have small silicon area; but due to tradition you just have PWM.

One may opt for a hybrid solution where the hardware PWM is used with a much shorter period (and hence, lower resolution), then a software loop "dithers" this PWM setpoint. The point is, the software doesn't need to do this for every output symbol. The result is like a "clumped" PDM; compare these examples (just boring 50% duty because I'm lazier than Nominal Animal):
Code: [Select]
HHHHHHHHHHHHLLLLLLLLLLLL
HLHLHLHLHLHLHLHLHLHLHLHL
HHHHLLLLHHHHLLLLHHHHLLLL

Now if you would adjust out of this 50%, the last example would start to have different duty for each different period, like HHHHLLLLHHHLLLLL...

Thank you for your answer. I have the stm32f103 microcontroller, can I produce PDM with this microcontroller?

As far as I understand from your example, when PDM is produced with microcontrollers containing PWM, we do not produce a real PDM. We are clustering PWM signals using low frequency, right?
« Last Edit: March 10, 2021, 10:36:01 am by merymery »
 

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 6273
  • Country: fi
    • My home page and email address
Re: PDM vs PWM
« Reply #8 on: March 10, 2021, 11:24:02 am »
I understand your pseudo-code approach much better, but I didn't quite understand how your FIR Filter Analysis web page works, I'll look at it again in another free time, thank you  :)
Just stick some FIR filter coefficients in the top bar (for example, 1 0 1 for a very simple three-tap filter), and press Enter, and the page will draw its frequency response.

A PDM example page would have just three input numbers: number of clock cycles, length of PWM period in clock cycles, and the duty.  It would plot the PWM and PDM signals as a function of time.  I find such web pages useful for visual inspection and exploration, and find it easy to construct them, that's all.

The simplest way to generate PDM is to use a function that is called once per PDM clock cycle,
Code: [Select]
#define  PDM_PIN  PC_14  /* Or any other pin */
static uint32_t  pdm_state;
static uint32_t  pdm_duty;

static void  pdm_cycle(void)
{
    pdm_state += pdm_duty;
    digitalWriteFast(PDM_PIN, (pdm_state & (1 << 31)));
    pdm_state &= ~(uint32_t)(1<<31);
}
which uses the stm32duino digitalWriteFast() function to set the PDM_PIN based on the most significant bit of pdm_state.  The final line clears that high bit, so it is used as the overflow or carry indicator for each addition.

If you call pdm_cycle() at regular intervals, PDM_PIN state will be high pdm_duty/231 of the time.  Valid range of pdm_duty is from 0 (PDM_PIN always low) to 231 = 2147483648 (PDM_PIN always high), inclusive.  Unlike for PWM, pdm_duty can safely be set to any value (within the valid range) between calls to pdm_cycle().

(If called from a timer interrupt, I personally might write the entire handler in GCC extended inline assembly, minimizing the function overhead; it is that simple.)
For testing, you can just call it in a loop; or perhaps with a fixed delay, or reading a potentiometer via ADC and setting pwm_duty based on that.
 
The following users thanked this post: merymery

Offline Wolfram

  • Frequent Contributor
  • **
  • Posts: 383
  • Country: no
Re: PDM vs PWM
« Reply #9 on: March 10, 2021, 11:43:43 am »
A practical difference is, microcontrollers, even the cheapest ones, offer multiple channels of PWM generators. They rarely offer PDM generators, so even if you'd actually prefer PDM, you end up using PWM because hardware does it for you, often at high clock frequency, so your CPU doesn't need to run any code in real time, you can just fire-and-forget it.


The NCO peripheral in some low-end PICs can be configured to generate PDM, by using the fixed-width pulse output mode, here's an example of it being used: https://electricdruid.net/electric-druid-chips-the-next-generation/ . You only get one channel, but it works without any special tricks or real-time code.
 
The following users thanked this post: merymery

Offline viperidae

  • Frequent Contributor
  • **
  • Posts: 306
  • Country: nz
Re: PDM vs PWM
« Reply #10 on: March 12, 2021, 05:59:42 am »
Just don't use PDM for motor control :-)

You'll end up with higher switching losses due to more transitions and lower current due to higher frequency through the windings
 
The following users thanked this post: Nominal Animal, merymery

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 6273
  • Country: fi
    • My home page and email address
Re: PDM vs PWM
« Reply #11 on: March 12, 2021, 06:43:21 am »
As far as I understand from your example, when PDM is produced with microcontrollers containing PWM, we do not produce a real PDM. We are clustering PWM signals using low frequency, right?
Since Siwastaja hasn't answered, I'll butt in again.  (I hope you don't get offended by me butting in, Siwastaja; I just find this very interesting and am trying to help. :-[)

Yes; another way of describing it would be using a shorter PWM period, and dithering the duty cycle to get better resolution.

Essentially, it works by having an interrupt every PWM period, which updates the the duty value and/or the period of the next PWM period.

For example, if you have period of 8 cycles, and you want a duty cycle of 3.5/8 = 43.75%, you generate
    H H H L L L L L  H H H H L L L L  H H H L L L L L  H H H H H L L L  ...

The exact implementation depends on which timer registers are buffered on a particular microcontroller.  Many have a register that sets the duty for the next period (loaded to the comparator when the current value of the comparator matches the timer count).  On some microcontrollers, it may be that only the period (and not the duty) is buffered thus, so instead of dithering the duty value, you dither the PWM period.  For a duty cycle of 4 to achieve 43.75%, the average period is 4/0.4375 = 9.14, so we alternate between period 9 and 10,
    H H H H L L L L L  H H H H L L L L L  H H H H L L L L L  H H H H L L L L L H H H H L L ...
where the underlined L is the extra clock cycle, as that fourth period has a period of 10 instead of 9 like the others.

On some microcontrollers, duty or period can be updated via DMA instead of an interrupt, which minimizes the overhead.  For example, with the above four period pattern (9 9 9 10, much too short for practice), you achieve 16/37 ≃ 43.24% duty cycle, whereas 16/36=4/9=44.44%.

Just don't use PDM for motor control :-)

You'll end up with higher switching losses due to more transitions and lower current due to higher frequency through the windings
Interesting; I never thought of that aspect.  PDM is definitely easier to filter to a DC-like voltage (as a simple low pass filter suffices), and I would have thought that motors would act like a low pass filter, without much effect on the efficiency; but it makes sense that the high frequency components of the driving signal are "lost" (converted to waste heat) rather than torque.

For small hobby motors, where typical PWM causes an annoying whine at the base PWM frequency, PDM would be a viable alternative: there, one would just be spending a bit of extra power to avoid the whine.  But that's the same case as for LEDs and 1-bit DACs, where having those high frequency components present are much preferable to the base PWM frequency.  (If you can hear the coil whine on most LED dimmers, you know what I'm talking about!)

I wonder if programming those cheap Padauk microcontrollers as an I2C- or UART-controlled PDM generator (with all free output pins as independent outputs) would be useful?
 
The following users thanked this post: Siwastaja, merymery

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 6273
  • Country: fi
    • My home page and email address
Re: PDM vs PWM
« Reply #12 on: March 12, 2021, 06:49:09 am »
(It is my unfounded belief that using PDM instead of PWM with switch-mode supplies will yield a significant improvement on response time, as PDM response is basically immediate.  The limitation on the response time, I believe, is on the ADC.  A simple comparator is limited to a fixed response per clock cycle, whereas an ADC yields an immediate estimate on the magnitude of the correction needed.  A particular use case is a programmable supply with very fast transient response.  But, as an uncle bumblefuck hobbyist, while I can easily do the software, the hardware and especially the test equipment needed to analyse and characterise power supply circuits is outside my current skills and tools.)
 
The following users thanked this post: merymery

Offline fourfathom

  • Super Contributor
  • ***
  • Posts: 1884
  • Country: us
Re: PDM vs PWM
« Reply #13 on: March 12, 2021, 06:56:46 am »
PDM is a really powerful tool for generating arbitrary frequency or duty-cycle relationships.  It is also virtually identical (exactly the same?) as the Bresenham Line Drawing algorithm.  I sometimes use it in hardware frequency synthesis when I can't get what I want with a regular power-of-two DDS design.  Of course you can modify a DDS to also give you non-power-of-two relationships by feeding the registered DDS adder carry-out back into the adder input, but sometimes you need access to intermediate carry-outs to make this work.
We'll search out every place a sick, twisted, solitary misfit might run to! -- I'll start with Radio Shack.
 
The following users thanked this post: merymery

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 6273
  • Country: fi
    • My home page and email address
Re: PDM vs PWM
« Reply #14 on: March 12, 2021, 07:16:11 am »
It is also virtually identical (exactly the same?) as the Bresenham Line Drawing algorithm.
Bresenham's line algorithm is one implementation of digital differential analyzers: accumulators, whose overflow generates an output event.  In the Breseham line algorithm, each cycle you advance along the primary axis by one pixel, and the event is a diagonal step (an additional step along the secondary axis).  In its case, the "period" and "duty" are chosen to match the slope of the line, so it tracks the exact line; and also happens to then be an incremental error algorithm.

The midpoint circle algorithm is similar, except that the "duty" and "period" are adjusted so that instead of a line, a conic curve is followed.

All these have the inherent property that as long as an input event yields at most one output event, the implementation is trivial and asynchronous.  Otherwise, you need an independent generator progressing at a steady pace controlled by some input.

So, in practice, the same; mathematically, there is a common root: digital differential analysis.  There are other terms used for this (I'm not even sure if DDA is the most common!), and many have encountered implementations of the root idea (accumulator whose overflow generates an output event) without realizing how powerful it actually is.  It is one of those laughably simple tools that can be used to do incredible stuff.
 
The following users thanked this post: merymery

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 8183
  • Country: fi
Re: PDM vs PWM
« Reply #15 on: March 12, 2021, 07:20:03 am »
Remember that motors have massive amount of inductance, want it or not, it's there anyway so even low frequencies result in low current ripple. There usually just isn't any need to go beyond 10kHz (except maybe audible whine).

But because motors are such high-power devices, EMI is a real concern, and the simplest way to mitigate is to switch more slowly. And switching slowly dissipates power in the MOSFETs, this happens whenever the state changes. This is why we definitely want to minimize the number of switching events. Plain old PWM is quite good, but there are even better ways like some forms of space-vector modulation.
 
The following users thanked this post: Nominal Animal, merymery

Offline merymeryTopic starter

  • Contributor
  • Posts: 14
  • Country: tr
Re: PDM vs PWM
« Reply #16 on: March 12, 2021, 11:00:52 am »
Thank you for all comment, I was thinking of using PDM for an LED driver with 10 MHz switching frequency. I thought it would make sense as it reduces switching loss and EMI by allowing soft switching. I understand that according to PWM the switch will be on-off more frequently in PDM, wouldn't this increase the switching loss?
 

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 8183
  • Country: fi
Re: PDM vs PWM
« Reply #17 on: March 12, 2021, 12:26:16 pm »
Are you sure you want 10MHz switching for an LED, or is this a typo, should it read 10kHz? 10MHz sounds like a speed-of-light phase interference measurement, or data communication application, in which case you won't use either PWM or PDM but more application-specific modulation schemes.
 

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 6273
  • Country: fi
    • My home page and email address
Re: PDM vs PWM
« Reply #18 on: March 12, 2021, 01:12:40 pm »
Existing LED drivers like TPS61165 have a switching frequency (PWM period) around 1 to 2 MHz.

I still haven't had my ATtiny24A dual TPS61165 made, but its datasheet promises TPS61165 does not burst the output according to input PWM (and should have no audible capacitor whine), and the ATtiny is to be programmed with a base PWM frequency of 30 kHz - 100 kHz (to be tested in practice).
 

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 8183
  • Country: fi
Re: PDM vs PWM
« Reply #19 on: March 13, 2021, 06:26:46 am »
Existing LED drivers like TPS61165 have a switching frequency (PWM period) around 1 to 2 MHz.

This is just a power converter; it uses inductor and capacitor to convert the voltage. Using high f_sw helps minimize the size of these filter components, like in any switch mode supply. The LEDs see DC.

If you modulate LEDs directly, there is no point going much beyond the perception limit, which of course depends on the intensity, duty cycle, and person in question, but very seldom you PWM LEDs over a few dozen kHz, definitely not in the MHz range.
 

Offline gnuarm

  • Super Contributor
  • ***
  • Posts: 2219
  • Country: pr
Re: PDM vs PWM
« Reply #20 on: March 13, 2021, 07:12:40 am »
If I could ask a question that is related to the more general topic of PWM control chips.  I want to use a motor controller chip to drive a speaker for reasons that are slightly too large for the margin of this page.  The one chip I have identified as providing all the features needed without excessive complexity or cost does not clearly indicate the output states during operation. 

The Monolithic Power MP6519 is designed to drive motors with an average current level obtained through PWM.  When driving a motor the inductance back EMF is often secondary to the momentum back EMF.  These two effects are opposite in nature and polarity.  The inductance will react to interrupting power by reversing voltage and raising is very high in response to the collapsing field.  The momentum back EMF is the same as the applied polarity and until the motor slows down, equal to the applied EMF before the interruption (minus the resistive dissipation, etc), while current will be whatever the driving circuit allows at that voltage.  https://www.monolithicpower.com/en/documentview/productdocument/index/version/2/document_type/Datasheet/lang/en/sku/MP6519/document_id/180/

So motors alternate between being driven by a polarity corresponding to direction and an open circuit.  The inductive EMF reversal of polarity causes protective diodes to conduct dissipating that energy.  The momentum EMF needs to not be conducted to prevent a reverse current flow that will slow the motor. 

So motor controller chips apply power or are open for PWMing the motor.  I believe that when driving an inductive load (other than a motor) a controller should instead of opening the path, short the ends of the load so as to maintain the current.  So close the two low side FETs or the two high side FETs while leaving the others open. 

Unlike most motor controllers, the data sheet for the MP6519 does not define exactly what the output FETs are doing as the output is PWMed.  Anyone care to hazard a guess?
Rick C.  --  Puerto Rico is not a country... It's part of the USA
  - Get 1,000 miles of free Supercharging
  - Tesla referral code - https://ts.la/richard11209
 

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 8183
  • Country: fi
Re: PDM vs PWM
« Reply #21 on: March 13, 2021, 07:36:18 am »
gnuarm, you are misanalysing the motor controller. There never is "collapsing field" (such term would be meaningless anyway) or high voltage generated. The controller does not drive "open circuit". Also, in normal operation, there are no "protection diodes" to "dissipate" anything. That would be impossible to deal with; the amount of energy stored into winding inductance is massive and it would be released every cycle. You don't want to dissipate it anywhere; you want it to do the actual work.

The inductance of the motor is handled in a very simple way: there is always a current path provided. There are two states that work similarly: the current increasing state, and current decreasing state. (At very low loads, in DCM, you could say the current decreasing state transitions into a third state, a zero current state.)

There are two switches per phase, one of which can be a diode in the simplest case, but that doesn't change the analysis. Let's imagine high-side switch A and low-side switch B, between them is motor terminal 1, and motor terminal 2 is connected to ground. Let's say it's a simple brushed DC motor so runs on 1-phase PWM. Switch B can be a diode if 2-quadrant (regenerative) operation is not needed and if we can accept the forward voltage loss of the diode. But for analysis, it's just a switch.

Now, when the controller is enabled, it always drives either switch A or switch B.

When switch A is conducting, input DC bus voltage is applied over the winding inductance, so current in the windings is increasing, and more and more energy is being stored into the winding. di/dt = V/L. Because the torque generated is relative to current, torque ramps up at the same time. After some time, switch A is turned off and switch B is turned on, which connects the winding inductance to the supply ground. Current is still flowing in the winding; energy that is stored in the winding is now being released, not suddenly, but ramping down still at the rate defined by dI/dt = V/L. This energy is not dissipated in the switch B (possibly a diode) except for the (unwanted) loss component which for a diode could be like 0.7V * I_winding. This energy continues to produce torque, which is now ramping down as the current ramps down. At the end of the cycle, in CCM, there is still current flowing in the winding. The next cycle starts, switch A conducts again and current starts going up again.

The current waveform is a simple triangle; not necessarily symmetrical, though, the rate of increase and decrease may be different. Except for very brief spikes caused by circuit parasitics, voltage over the winding is well-defined, it's either Vsupply - Vbemf, or Vbemf, where Vbemf is the back-EMF voltage defined by the RPM. Respectively, the winding current charge/discharge rates are dI/dt(rising) = (Vsupply - Vbemf) / L, and dI/dt(falling) = Vbemf / L.

Back-EMF is simple; it's like an applied voltage. It's analogous to the output capacitor of a buck converter. Assuming no external forces that could rotate the motor to higher speeds than the controller itself is capable of, back-EMF sits between zero and the input DC supply. The only thing it affects in control is the ratio of the of the triangle wave rising / falling slopes as you can see from the previous formulae.

To avoid excess torque ripple, you want the motor current ripple to be some small percentage of motor maximum current. This is easy to achieve even with modest PWM frequencies due to motors having massive amounts of inductance as the side-effect of their large iron cores filled with large number of winding turns.
« Last Edit: March 13, 2021, 07:42:38 am by Siwastaja »
 

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 6273
  • Country: fi
    • My home page and email address
Re: PDM vs PWM
« Reply #22 on: March 13, 2021, 08:00:53 am »
Existing LED drivers like TPS61165 have a switching frequency (PWM period) around 1 to 2 MHz.
This is just a power converter; it uses inductor and capacitor to convert the voltage. Using high f_sw helps minimize the size of these filter components, like in any switch mode supply. The LEDs see DC.
Yes. Isn't that the root idea here (in this particular case) too?

I mean, the driver has a maximum current set by a sense resistor, and it boosts the output voltage to reach the fraction of the maximum current indicated by the voltage or PWM at the control input.

(I now understand why PWM is superior when simply controlling something via a MOSFET (total switching time being on the order of 10ns to 1µs means that at 1 MHz, the MOSFET spends most of its time switching, thus will be in its linear region where it converts power to waste heat); I've learned a lot of useful stuff about this in this and other related threads here.)

So, if OP intends to limit the current to the LED via e.g. a resistor, and pulse the current using a MOSFET or similar, then I'd say PWM at ~ 30 kHz should work best.  Yes, anything above say 250 Hz should be imperceptible, but may cause audible capacitor/coil whine in either the LED or the power supply.  At 30 kHz, the MOSFET switching time (say, 0.5 µs) is small enough compared to the PWM period (33 µs) to not affect efficiency too much, but the PWM frequency is well above human hearing.

For an indicator LED, or anything at less than a watt or so, the piezoelectric effects caused by the pulsing voltage and current should not cause audible noise, so even a 1 kHz PWM would work just fine.



I hope I haven't mislead anyone here, because I realize I haven't pointed out an important detail here: I believe the strengths of PDM appear only when used in conjunction with a feedback mechanism adjusting the duty of the PDM, and/or filtering, which converts the digital pulse train to an analog voltage.

Because of the higher-frequency spectrum in the PDM signal, it is easier to filter; and it can react immediately to changes in the load, if the load is measured.  Because of the higher frequencies in the generated signal, it is less efficient than PWM in many cases, for example due to high-frequency switching losses.
 

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 8183
  • Country: fi
Re: PDM vs PWM
« Reply #23 on: March 13, 2021, 08:34:08 am »
Note that even 1kHz PWM may look flickering under some circumstances; a bright high-power LED, driven at very low PWM duty cycle, in dark conditions. It's a shocking number to people expecting imperceptibility after some magic number like 60Hz. But if you think about it, a classical TV with 50Hz or 60Hz refresh rate used slow phosphors, wasn't usually used with maximum possible brightness in a total dark room, and yes, it did look flickery anyway! LED is completely sharp, and if you want to produce high dynamic range, you are going to use high-power devices with low duty cycles.

This is where PDM would give significant improvements. OTOH, you can just use higher PWM frequency instead. You may want to go up to some 5-10kHz to guarantee imperceptibility, while still have acceptable switching losses.

Capacitor whine is a point worth of considering. Slowing down switching helps here, too, as it does with EMI. Switching losses increase, though.
« Last Edit: March 13, 2021, 08:36:13 am by Siwastaja »
 

Offline ogden

  • Super Contributor
  • ***
  • Posts: 3731
  • Country: lv
Re: PDM vs PWM
« Reply #24 on: March 13, 2021, 09:31:21 am »
I have the stm32f103 microcontroller, can I produce PDM with this microcontroller?

With ease. Transmit PDM bits using SPI peripheral. If bit pattern does not change often - precompute PDM bitstrem in RAM and use circular DMA to feed SPI peripheral.
 

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 6273
  • Country: fi
    • My home page and email address
Re: PDM vs PWM
« Reply #25 on: March 13, 2021, 10:12:04 am »
In case anyone wants to play with it, I created a standalone (Creative Commons Zero -licensed) HTML page for comparing PWM and PDM.  PDM and PWM are the number of clock cycles per period, and duty is the number of clock cycles per period the output is high.  The "Match PDM" button sets the PDM to a comparable frequency, so that the same duty produces a similar (same in cases where possible) signal.  Upper/red is PWM, lower/blue is PDM.

While one might think that PDM requires a higher clock rate than PWM – the gray lines in the center show PWM periods for PWM and PDM clock cycles for PDM –, that is because we forget that to get K+1 distinct duty values with PWM at frequency F, internally the PWM requires a clock frequency of KF; incrementing or decrementing an internal counter and comparing it to a specific limit, once each KF -frequency clock cycle.

I guess it might be more useful to split it so one could assign separate duty values etc. to either signal, or maybe have 1-3 selectable signal windows, and a fourth display showing their frequency responses.  (I know at least one MIT-licensed JS FFT library one could use for this, and still keep the page standalone; although the fact that we have a pure binary signal to work with poses some interesting speedup possibilities – in particular, evaluating the Fourier integral piecewise in exact form in continuous time.)  Suggestions?  Do note that this PWM and PDM page is CC0-1.0, i.e. free to use for any purpose you like as long as you don't expect any warranties or blame me for any errors in it.

(It being standalone means that everything is contained on that single HTML page, and if you store it on your own computer, you can open it in a browser even without an internet connection, and it'll work just fine.)
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf