Phase Correct PWM

As far I can tell, Phase Correct seems to be AVR-specific terminology and for multiple PWM outputs would center the respective output pulses in relation to one another. This is due to the dual slope operation as the counter doesn’t roll over but rather counts from bottom to top and back to bottom. I guess with a single PWM output that it would also create a constant time between the center of each successive pulse.

My question is… does it matter if all we are doing it turning a LED off and on? Wouldn’t fast mode work just as well? If so, then why do all the driver manufacturers boast that they are using “phase correct” mode?

My understanding is for most uses, fast PWM is better. With a fast PWM driver there’s no high-pitched whine in medium modes like there is with some phase correct PWM drivers.

On the other hand, I do recall that Comfychair’s FET mod, which substitutes a FET for the 7135 regulator chips, does not work properly fast PWM. It requires phase correct PWM.

It seems for our application the PWM-mode, fast or phase-correct, doesn’t matter. What matters is the resulting frequency. Low frequencies flicker visibly, medium frequencies produce an audible whine and high frequencies drop out of regulations pretty fast.

It is just important to know, that with an ATtiny13A you can’t reach every frequency with both PWM versions. Some you can, some only with fast or phase correct PWM:

PhaseCorrect FastPWM
kHz CPU freq divider fuse CPU freq divider fuse
1.2 kHz 4.8 MHz :8 0x65
2.4 kHz 9.6 MHz :8 0x6a 4.8 MHz :8 0x65
4.7 kHz - - - 9.6 MHz :8 0x6a
9.4 kHz 4.8 MHz :1 0x75 - - -
19 kHz 9.6 MHz :1 0x7a 4.8 MHz :1 0x75

CPU freq is set by the fuse (Low Fuse bit 0 and 1) and “#define F_CPU” should be set accordingly.
PWM is set by “TCCR0A = 0x23”, where 0x23 is FastPWM and 0x21 is PhaseCorrectPWM
The divider is set by the fuse (Low Fuse, bit 4) and can be :1 or :8

In the STAR Firmware thread of RMM/JohnnyC this had been adressed, just look some posts up and/or down to find more about the topic by others.

~4.7 and ~9.4 kHz both produce an audible whine, so the PWM version doesn’t help here.

The ~19kHz frequency can be reached with both and I tested both in lights and couldn’t tell (see or hear) any difference in practical use. Both are silent and similarly bright.
The downside of this high frequency is, that the driver drops out of regulation even in low modes pretty fast, HKJ showed this when he tested the Qlite driver. Perhaps one of the 2 PWM-versions would be better than the other in this department, I simply don’t know.
Or perhaps our FET-driver developers here found differences between the PWM-versions and could chime in, if that’s the case.

Not true! there were some early issues with the MCU locking up for unknown reasons with certain firmwares, after some work it turned out to be the design of the Nanjg's power supply on the Vcc pin. Move the C1 capacitor to any location between B+ and GND and it works correctly with any firmware.

Stock, C1 connects to a spot after the diode...

That combination of a diode and a capacitor acts like a check valve and an accumulator (the same basic thing a boost driver does), and when the MCU is driving a FET instead of a 7135, the current drawn through the diode increases, and it turns that boost circuit up to '11' and the voltage present at the MCU's Vcc rises to over 6 volts, and the MCU freaks out and shuts down.

Move the capacitor and all that stops happening...


Now, which driver manufacturers brag about phase-correct being superior or whatever?

And, thanks to ToyKeeper doing things with code I can't even pretend to understand, you can mix phase-correct and fast-PWM modes in the same firmware.

#define F_CPU 4800000UL

// PWM Mode
#define PHASE 0b00000001
#define FAST 0b00000011


  • =========================================================================
  • Settings to modify per driver

#define LOW_TO_HIGH 1 // order in fast-tap mode (long-press will go the opposite direction)
#define VOLTAGE_MON // Comment out to disable - ramp down and eventual shutoff when battery is low
#define MODES 0,1,3,12,40,125,255 // Must be low to high, and must start with 0
//#define ALT_MODES 0,1,3,12,40,125,255 // Must be low to high, and must start with 0, the defines the level for the secondary output. Comment out if no secondary output
#define MODE_PWM 0,PHASE,PHASE,FAST,FAST,FAST,PHASE // Define one per mode above, 0 for phase-correct, 1 for fast-PWM
// (use PHASE for max to avoid a lingering moon-like mode while holding the button, side effect of FAST mode)

That's from a momentary-specific version, but I don't see any reason why it couldn't also be used in a clicky switch version just the same. Full source here:

Is that the case for a 7135-driver (Nanjg and derivates) as well, meaning C1 does what it’s supposed to do on either side of D1?

I believe so, yes. Note that this is not a generally recommended way to lay things out. Ideally you want your decoupling capacitor to be closer to the component it’s decoupling than any other component is. (EG you should not have components in between the cap and the component it’s supposed to filter).

There are probably several reasons we get away with it, including how simple the circuit is. Another reason is that we seem to have a lot of capacitance for a decoupling cap. Some recent testing I did with an FET driver showed that 1uF, 2uF, and 3uF were all unable to let the MCU perform correctly. 5uF worked. I did not test 4uF. This was without a protection diode AND with the protection cap very close to the MCU.

There's some boosting present even on a totally untouched Nanjg/7135 driver, but the 7135's Vdd pin is a much softer load to drive than a FET's gate (the 7135 has a little FET inside, but it's not driven directly by the signal on Vdd, there's other switching parts in there that buffer it). On the stock driver the voltage doesn't rise high enough to shut down the MCU, but it does go up to around 5v, with a fully charged battery and in the middle-upper PWM ranges.

This shows CH1=Vdd, CH2=B+, and not Vcc directly, but you can see the top level of the Vdd trace is way up over 4v, and the baseline for B+ is down at around 3.80v, and from checking other drivers I know that the max voltage output on pin 6 is equal to what's present at Vcc/pin 8.

You never cease to amaze me with the stuff you come up with.

Awesome info Comfychair! Thanks for the update!!

… now to get rid of the whine on my FET drivers.

Same hardware, different firmware...

Great comparison pic.

Yeah really interesting. I should try using phase corrected just to see. I seen that in JonnyC code

TCCR0A = 0x23; // phase corrected PWM is 0x21 for PB1, fast-PWM is 0x23

I been using fast and left that alone. I was goofing around once and switched the PWM pin PB0 with Star2 PB1 and I swore the light was brighter stuck on full. But it could have been a trick to my eyes ;D Someone who has a meter could check that though.

Hey comfychair, were both of those operating at the same frequency? Phase Correct PWM

They all use the same fuses (0x75/0xff) so CPU freq is the same, phase correct is 9.4kHz & fast PWM is 19kHz.

With either one, the FET never makes it all the way to fully on, so the output is governed by the rise/fall time of the particular FET. And I'm guessing that a '1' with 19kHz makes more light because there are twice as many cycles as a '1' with 9.4kHz.

Since these drivers' lower modes come from just a percentage of whatever the full current is, that comparison pic really minimizes the difference between phase/fast - the drivers are identical except for firmware, but the dim one is the triple XP-Ls and the brighter one is triple N219Bs. Swap the firmwares between them and the bright one would be even brighter (at WOT, the XP-L is around double the light output of the 219B light).

This is in response to wight’s reply #6

I have always had a concern about the decoupling cap location after the move as well (tho not enough to stop me from doing it and making new boards with that layout because I can’t argue it fixes THAT issue) but I’ve wondered what would happen if we simply added a .1uF cap parallel over C1 (in its stock location). I don’t have an o-scope to test myself or I’d try.

Another thing on the subject (again no scope, only basing this off the fact I’ve never had any issue) but my PIC FET drivers are all fine running only a 2.2uf decoupling cap downstream of the polarity protection diode. Not sure if the lower cap is not causing the boosting effect or if the PIC simply isn’t sensitive to it (I’m running numerous different PIC’s). Note I was smart enough to put cap pad’s at both locations, just incase.

This is a BLF-20DD running at a PWM of 18 (only about 7%), old version with the original C1 position, and no gate resistor. CH1(blue) is the FET gate, CH2(yellow) is B+. That spike at B+ when the FET turns off shoots through the diode and into the capacitor, and then gets trapped in there since the diode shut the door behind it. And with the PWM output to the FET shut off, the MCU isn't consuming any power so there's nowhere for the built-up voltage to go.

You can measure the voltage after the diode with a plain ol' voltmeter, with the driver running at, oh I don't know, anywhere around 10%-50% duty cycle or something. If voltage after the diode is lower than B+ (from the drop thru the diode), there's no boosting happening. If it's higher it will be obvious, it's a constant voltage and not a signal you need a scope to see.

This is the same driver, but CH1(blue)=Vcc, CH2(yellow)=B+. Nice flat steady voltage there, easy to measure. Note that the 6v that was being sent to the gate matches the 6v present on Vcc.

A 2.2uF cap is a smaller accumulator than a 10uF, so it's not able to store as much of the spike, and the static voltage between the diode & Vcc will be lower. The attiny won't run with a cap that small, though.

In order to avoid muddying the waters, let me say that I have absolutely no concern as to implementing/using the circuit as it currently stands. Decoupling caps are present to prevent various electrical [mis]behaviors from reaching the component they protect. As long as the job is getting done it’s all good. I’m just trying to make sure that any future layout artists who read this thread do not get the wrong impression about what is generally acceptable for circuit layout. EG I do not want them to think that what we’ve done here is generally recommended, SOP, or anything like that. It’s not. It’s OK in this case because it still works. In another case it might not.

As far as adding a 0.1uF cap over C1 in the stock location… I’m not certain what you think this is going to achieve? All you’re doing is adding a tiny bit of capacitance to an already large capacitor. Comfychair does not directly address your suggestion in his post, but I would expect exactly no change vs the behavior he describes. As comfychair rightly points out you can actually measure a working version of this (whether boosting or not) using a DMM. In that case you’d have a flat signal, as shown by the blue line in comfychair’s second pic. If the driver was not operating correctly (for example: an Attiny13A DD driver with 2.2uF input cap) you would be unable to properly measure the behavior with a DMM because the signal is not flat, it’s changing with spikes and dips.

Early on, I tried a second cap added but in parallel with the diode and C1 still in the original spot. It worked but the waveforms all looked the same as C1 relocated to B+/GND, so why use two parts when just one gives the same result?

But the PIC may be totally different, for all I know it could have a softer turn-on/off built in or something that prevents the spikes that cause the boosting. If that's the case I think you're better off with the 'normal' cap location, after the diode.