Author Topic: Higher frequency PWM results in higher brightness when controlling LED driver  (Read 1208 times)

0 Members and 1 Guest are viewing this topic.

Offline ohrenTopic starter

  • Contributor
  • Posts: 17
  • Country: se
Hello,

While trying to control a TV backlight without its logic board I came across an unexpected result. I first tried the following circuit:

Rpi3 hardware PWM → 220 Ohm → NPN transistor → LED driver PWM pin on power board

...where the transistor was switching the 3.3 V supply from the Pi (3.3 V was measured at presumably 100% brightness on TV startup).

This worked, but with the side-effect that when I increased the frequency (without adjusting the duty cycle) the LEDs got brighter, and the total power draw increased significantly:

1 % duty [Hz] [W]:

15 10
30 11
60 13
120 17
240 27
480 46
600 55


In contrast, when I skipped the transistor and used the Pi's PWM output directly it behaved like expected, and brightness only increased with increased duty, and not with frequency.

My question is: why did this happen?

- I don't have access to an oscilloscope, so I'm left to asking and guessing. I don't expect any definite answer, but your guesses are better than mine.
- I asked in another forum, but didn't get any wiser there.
- The transistor is marked "8050" and came in a Pi kit where it was used for driving buzzers in example projects, etc. Assuming I connected it properly, I assume it's suitable for the task?
- The only idea I could think of is maybe using a pulldown resistor after the transistor, but it's just a wild guess since I'm not familiar with when that should be used.
- The LED driver chip has no available data sheet.
 

Online brucehoult

  • Super Contributor
  • ***
  • Posts: 4853
  • Country: nz
Why do you feel you need the transistor at all, if you're just driving a digital input that works without it?

It seems the 8050 is designed to work in push/pull wth an 8550 in audio output stages, putting out up to 2W. Maybe it's not soo happy single-ended. Do you have it forming a voltage divider for the output, or what?

The frequency response should be fine. It's got 400:1 gain (so you're probably over-driving and saturating it) but it's got >1 gain up to 100 MHz ... even at 10 MHz it's got surely plenty of gain for this application. 600 Hz is a walk in the park.  But, yeah, you probably want small voltage swings on the input, not full CMOS output swings.

If you really want to put something between the RPi and the backlight board, maybe a digital inverter chip?
 

Offline johansen

  • Super Contributor
  • ***
  • Posts: 1185
The turn on time is shorter than the turn off time because your 220 ohm resistor has to pull the transistor base down below 0.6 volts to turn it off, so you have 12ma of current available to turn it on. (3.3-0.6/220)

where as for turn off, you've only got .6 volts/220 ohms or 2.7ma of current available. and your transistor is probably saturated so the turn off is going to be extra long on top of the base emitter capacitance.

basically run the frequency up high enough and the transistor won't turn off.
 
The following users thanked this post: tooki

Offline mikerj

  • Super Contributor
  • ***
  • Posts: 3409
  • Country: gb
As I interpret this you were driving the transistor base via a 220 Ohm resistor, which seems very low.  How was the transistor wired e.g. as common emitter with a resistor as collector load (if so what value resistor), or as an emitter follower?  A simple schematic would help.

I suspect that your drive waveform from the transistor has very asymmetric rise/fall times which means the effective duty cycle will change with frequency. If it's a common emitter with a weak pull-up (e.g. relying on a weak pull-up in the LED driver) then you'd have a fast falling edge and slow rising edge.
« Last Edit: January 03, 2025, 12:59:43 pm by mikerj »
 

Offline ohrenTopic starter

  • Contributor
  • Posts: 17
  • Country: se
Thank you for taking the time. I didn't know I wasn't automatically subscribed to notifications (did I miss a checkbox when signing up?) so I didn't notice at first.

basically run the frequency up high enough and the transistor won't turn off.

Thanks for the explanation. Would you say that what you describe would account for the ~30% increased power draw when going from 15 to 60 Hz? I would have imagined that adding 45 "extra long" turn off times per second still wouldn't add up to a lot of extra on-time per second. If the 1% duty actually resulted in an on-time of 10 ms/s then these 45 turn off times would have to add up to about 3 ms to account for a 30% increased power draw, right? (Edit, answering my own question: Well, no because the power board has some overhead, doh. But even if I subtract the 3 W of overhead, then the proportional increase in power draw will be even greater (42%) and the 45 turn off times would have to add up to ~4 ms.)

My initial impression was that the turn on/turn off times were down in the nano-to-microsecond range, but it seems to me that this "extra long" turn-off time would have to approach about 60 microseconds or so (3000 us / 45). Is that a reasonable order of magnitude for the phenomenon you're describing?


As I interpret this you were driving the transistor base via a 220 Ohm resistor, which seems very low.  How was the transistor wired e.g. as common emitter with a resistor as collector load (if so what value resistor), or as an emitter follower?  A simple schematic would help.

The simple schematic is basically exactly what was illustrated in the first post (minus the proper symbols) – I used no other components. I'm assuming there's only one sensible way to hook up the transistor in the specified series, with the specified components (and with the 3.3 V rail), so that's the way I did it.

To be honest I haven't really built any transistor circuit before so I just made sure I could dim a single LED with PWM via a transistor, and then substituted the LED with the LED driver to see if PWM was the way to go. I didn't put more thought into it because I didn't know enough anyway. Apparently it both worked, and failed.

What circuit design pattern(s) would you suggest I look up in order to do it properly with a transistor?

Why do you feel you need the transistor at all, if you're just driving a digital input that works without it?

I don't feel I need it now since I've since found the solution to the problem, but at the time I wanted some sort of indirection between my Pi and any unknown future mistake I was going to make. At the time I 1) didn't know whether the power board actually expected a PWM signal on the dimming control pin, 2) didn't have the service manual for the power board (i.e. didn't know what was connected to the control pin), 3) didn't (and still don't) have the datasheet for the LED driver on the power board (which turns out to be all that was connected to the control pin). It seemed like a good idea to let the transistor break instead of my Pi in case I messed up, I guess.
« Last Edit: January 04, 2025, 04:24:13 am by ohren »
 

Offline mikerj

  • Super Contributor
  • ***
  • Posts: 3409
  • Country: gb
I'm assuming there's only one sensible way to hook up the transistor in the specified series, with the specified components (and with the 3.3 V rail), so that's the way I did it.

There are three possible ways you could have configured this; common emitter, common base or common collector(usually called emitter follower).  A common emitter configuration would invert the signal, e.g. 99% duty cycle at the Pi would appear as 1% at the backlight driver, but this configuration gives voltage gain so can be used to give voltage level translation.  Emitter follower gives no inversion or voltage gain, only current gain.  Common base is probably the least used configuration but can be very useful for voltage level translation and does not invert the signal.

This schematic shows the difference, and includes the additional resistor(s) that should have been included.
2477143-0

 

Offline ohrenTopic starter

  • Contributor
  • Posts: 17
  • Country: se
Generous of you to illustrate with schematics, thank you for that.

Emitter follower without R4 connection to ground was my case, so R4 represents the gap in my knowledge. Now I'll just have to figure out why it's needed. Perhaps it suggests that the current through the led driver is too small for reliable operation of the transistor?

The other two configurations didn't occur to me 😅
 

Offline mikerj

  • Super Contributor
  • ***
  • Posts: 3409
  • Country: gb
The pin on the LED driver will inevitably have some parasitic capacitance (and possibly some intentional capacitance) which needs to be charged and discharged on each PWM cycle.  The emitter follower has lots of current gain, but it can only source current to your LED driver, not sink it.  Since it was working at all it suggests there is some kind of pull-down resistance or current sink in the LED controller, but it's likely to be quite weak.  This would give a very asymmetric charge/discharge waveform which will affect the duty cycle that the LED driver sees.  Since these charge/discharge times are more or less fixed, increasing the PWM frequency causes the effective PWM duty to change
 

Offline ohrenTopic starter

  • Contributor
  • Posts: 17
  • Country: se
Thank you. I think you put words on what I was thinking with my "pulldown resistor after the transistor", so that's encouraging.

If I understand correctly, since it works with the Pi's PWM driver directly, maybe the Pi can sink it quickly enough on its own, or maybe the Pi+LED driver can just about manage it together.

I suppose, in the same way, that matching the resistance between 3.3 V with the internal resistance in the driver (1.1 M) would risk never turning the LEDs on at all at, and isn't a solution.

Once again, thanks for the explanations. I have some things to try out now.
 

Offline mikerj

  • Super Contributor
  • ***
  • Posts: 3409
  • Country: gb
The Pi PWM outputs can source and sink a reasonable amount of current (around 16mA iirc).  To do this with your discrete transistor circuit you either need a suitably strong pull-down resistor (which still sinks current when the output is high, so wastes power) or you add another transistor for sinking current.
 

Offline DavidAlfa

  • Super Contributor
  • ***
  • Posts: 6438
  • Country: es
600Hz is really far away to take rise and fall times in consideration, no matter if using a bjt or a mosfet.

(3.3-0.7)/220 = 11mA which isn't crazy, will also desaturate the transistor quickly.

PWM'ing lights under 500Hz will cause flickering and weird perception, I'd try 1KHz.

Also remember our eyes don't perceive brighness in a linear fashion:

https://www.logosled.com/what-are-dimming-curves/
Hantek DSO2x1x            Drive        FAQ          DON'T BUY HANTEK! (Aka HALF-MADE)
Stm32 Soldering FW      Forum      Github      Donate
 

Offline ohrenTopic starter

  • Contributor
  • Posts: 17
  • Country: se
600Hz is really far away to take rise and fall times in consideration, no matter if using a bjt or a mosfet.

(3.3-0.7)/220 = 11mA which isn't crazy, will also desaturate the transistor quickly.

I interpret this as that you're skeptical to explaining the additional power draw and brightness solely in terms of rise and fall times. Since I asked, no one has asserted that this is in fact a significant factor even at the 15 to 60 Hz I tested at, so I see nothing that speaks against you.

The latest explanation, that there isn't a sink for the charge on the driver pin, seems like a separate explanation though. Do you agree with that as a possible explanation?

Thanks for the reminder. I read that workspace lighting needs at least 10 kHz, though I think it's not really up to me to choose any frequency I want here. Since the driver doesn't have a data sheet I reasoned I should go with a typical frequency used in TVs, which I understood to be around 800 Hz. I don't have a scope to measure the actual frequency used. Also, the higher frequencies started drawing significantly more power than I had observed with the logic board attached (~90 vs. ~70 W), so I didn't think it wise to increase the frequency even more until I understood the problem (by asking here).

The perception of brightness on the other hand doesn't really play a part here unless I'm supposed to perceive different brightness at the same specified duty cycle, which is what happened.
 

Offline johansen

  • Super Contributor
  • ***
  • Posts: 1185
15 to 60 Hz I tested at

i figured you meant 15 to 60khz.

what is the complete circuit of the system?
 

Offline ohrenTopic starter

  • Contributor
  • Posts: 17
  • Country: se
The circuit is as described in the first post and as illustrated in mikerj's diagram of emitter follower minus resistor R4.

(And Pi and power board grounds bridged)

I don't know how the LED driver would react to 60 kHz, but I tested at: 15, 30, 60, 120, 240, 480, 600 Hz
« Last Edit: January 12, 2025, 05:10:52 am by ohren »
 

Offline DavidAlfa

  • Super Contributor
  • ***
  • Posts: 6438
  • Country: es
Which tv? Which driver? Are there any schematics available?

Remember, you aren't making the pwm for the leds, that's done by the driver, you're modulating the PWM with the brightness input, and brightness isn't something that changes extremely fast.
Some drivers work with pwm input, others filter it out and use the resulting average.
Maybe 600Hz is faster than the led driver samples and it catches random pulses (Like Nyquist aliasing).

What you should do: Measure the original frecuency used by the main board and use the same, or at least follow the driver datasheet.
« Last Edit: January 12, 2025, 06:23:45 am by DavidAlfa »
Hantek DSO2x1x            Drive        FAQ          DON'T BUY HANTEK! (Aka HALF-MADE)
Stm32 Soldering FW      Forum      Github      Donate
 

Offline ohrenTopic starter

  • Contributor
  • Posts: 17
  • Country: se
Which tv?

Philips 55put6101/12

Which driver?

Two TPV101D populated at U8105 and U8106.

U8107 and U8108 are unpopulated.

Are there any schematics available?

TV service manual is too large to be attached, but can be found with the keyword "43puh610188.pdf".

brightness isn't something that changes extremely fast.

I change frequencies manually (running the program in terminal) so no parameters are being altered rapidly. Between invocations I walked across the room and manually read the power meter.

Some drivers work with pwm input, others filter it out and use the resulting average.

Thanks for the suggestion. I first tried a voltage divider (after measuring the average voltages output by the logic board with a DMM), but since there was no effect with steady voltages (except full brightness) I promptly moved on to PWM, which worked.

Asking multiple times over at Badcaps whether PWM was the correct assumption and the way to go yielded no answers, so I was left to discover the proper signal myself.

I have no third hypothesis on what possible signal it could accept, but then again I don't see the need since PWM works all the way down to single digit Hz.

Maybe 600Hz is faster than the led driver samples and it catches random pulses (Like Nyquist aliasing).

In the OP you can see the list of frequencies I measured at, which ranges from 15 to 600 Hz. There you can also see how the effect manifests at all frequencies.

What you should do: Measure the original frecuency used by the main board

How?

or at least follow the driver datasheet.

Still no data sheet
 

Offline DavidAlfa

  • Super Contributor
  • ***
  • Posts: 6438
  • Country: es
Quote from: ohren link=topic=449289.msg5780441#msg5780441
How?
Without oscilloscope, you could still connect the pin to the pi and measure the time between rising edges?

In contrast, when I skipped the transistor and used the Pi's PWM output directly it behaved like expected, and brightness only increased with increased duty, and not with frequency.
Well, I missed this. Probably means it's using a rc filter.
With a transistor you're only pulling or pushing, but not both.

Try a push-pull circuit like this:


A simpler method would be to use a 74xx logic gate to isolate the pin.
« Last Edit: January 12, 2025, 11:31:49 pm by DavidAlfa »
Hantek DSO2x1x            Drive        FAQ          DON'T BUY HANTEK! (Aka HALF-MADE)
Stm32 Soldering FW      Forum      Github      Donate
 

Online brucehoult

  • Super Contributor
  • ***
  • Posts: 4853
  • Country: nz
Try a push-pull circuit like this:


A simpler method would be to use a 74xx logic gate to isolate the pin.

Indeed so.

If you really want to put something between the RPi and the backlight board, maybe a digital inverter chip?
 

Offline ohrenTopic starter

  • Contributor
  • Posts: 17
  • Country: se
Thanks for reaffirming the issue. And thanks for suggesting alternative solutions and providing the name of the design pattern. I'm sure there's an opamp somewhere in the kit and that I can try your diagram as well. I'll just have to stare at it until I understand it.

Regarding measuring using Pi GPIO, it did cross my mind and I recall reading that recent Linux kernels ship with a module/driver that can turn a Pi into a "poor man's logic analyzer" for remote debugging. It sounds like the right thing for the job. Thanks for confirming the idea. The only problem would be that I can't be 100% sure of the peak voltages coming from the logic board and could theoretically damage the GPIO pin, but I doubt it.

I haven't done much GPIO input reading, so I wonder how reliable similar measurements would actually be from preempted user space code. I guess I'll go read up on that as well if I decide to measure.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf