High frequency (50kHz) 16 bit PWM

[BennoG]

For the led light of a camera setup I want to use a pwm signal to adjust the brightness of the led's
The shutter time of the camera is between 1 and 10 ms. It is a camera with a global shutter and no trigger input.
This is to have at least 50 led flashes during the 1 ms exposure. Because of the missing trigger input the PWM signal must be on for about 50 ms.
The best I can do with pars I have is 10 bits at 48 khz (50 Mhz 10 bit counter input)
Are there options besides using a variable DC (DAC -> Amplifier)

Benno

[ArdWar]

The "normal" way to do this is to current control the first 3 or 4 MSB and PWM the rest. Even then you still need 100s of MHz clock.... Do you really need that much dynamic range? Why that high of a frequency? Why 50 flashes?

[PGPG]

I don't understand why you need LED flashes during exposure and can't drive LED with PWM passed through low pass filter?

[BennoG]

Do you really need that much dynamic range?

I can get away with the 10 bits I have now, was curious if it was possible to extend.
In the really low (pwm 1-5) the steps are very noticable. (even 10 or 20 % per step)

Why 50 flashes?

I don't have exact control over when the camera shutter starts and stops. So if I have at least 50 flashes during the 1 ms exposure I chan have max variation of 2% in brightness of the image. Between the individual camera captures.

[BennoG]

I don't understand why you need LED flashes during exposure and can't drive LED with PWM passed through low pass filter?

Because I get a signal from the PLC and need to capture 2 images in fast sequence, with 2 different brightnesses.
So at the moment I set the PWM value that will change in 1/50000 of a second after the command. And then start the camera trigger by software. Between setting the PWM value and the CCD exposure starting is about 1 ms or even shorter (and probably not constant, the trigger is send over USB)
So the time is too short for LP filter to settle at a constant value during the exposure.

P.S. I can get away with the 10 bits I have now. Always on the lookout for a better solution.

[PGPG]

I understand that having 50 pulses in exposure time and being not synchronized you have to assume 1 pulse error so 2%.
You set PWM with 0.1% accuracy (10 bit) and you are trying to improve it to get 0.0015% accuracy (16 bit) and then use this light with 2% accuracy. Did I missed something?

[pcprogrammer]

Did you do any calculations on this?

50kHz carrier with 16 bit PWM resolution based on a timer needs a clock frequency of 65536 * 50000 = 3276800000Hz. That is 3.2768 GHz. Even for a FPGA not an easy thing to handle.

I can get away with the 10 bits I have now, was curious if it was possible to extend.
In the really low (pwm 1-5) the steps are very noticable. (even 10 or 20 % per step)

Is this not due to properties of the LED's and might not improve with a higher resolution of the PWM granularity.

[BennoG]

I understand that having 50 pulses in exposure time and being not synchronized you have to assume 1 pulse error so 2%.
You set PWM with 0.1% accuracy (10 bit) and you are trying to improve it to get 0.0015% accuracy (16 bit) and then use this light with 2% accuracy. Did I missed something?

Yes at really low intensities (PWM value between 1 and 10) you get noticeable steps due to the nonlinearity of our perception of brightness.
For the higher brightness this is accurate enough. (At the moment I do not need the lower PWM values, lowest in use now is 20 out of 1024). It is more to know there is a good solution when I need lower light values.

Benno

[tggzzz]

If they are white LEDs intended for illumination, you may find the phosphor decay characteristics are important and work in your favour (for once!). Use a reverse biassed PIN diode, and observe the decay characteristics on a scope.

PWM can be done naively and cleverly. MCU PWM outputs are naive. It may be worth you understanding

• delta-sigma DACs
• ripple cancellation https://www.edn.com/cancel-pwm-dac-ripple-with-analog-subtraction-revisited/

But unless you need computer control, it is probably simplest to just use a PSU to set the current.

[BennoG]

But unless you need computer control, it is probably simplest to just use a PSU to set the current.

That is the problem the PC needs to set the brightness and it should be stable within 1 ms.

[tggzzz]

But unless you need computer control, it is probably simplest to just use a PSU to set the current.

That is the problem the PC needs to set the brightness and it should be stable within 1 ms.

Apparently you only need two brightnesses, but to switch between them.

Have two slow speed DACs each controlling separate "DC" currents. Use a fast digital signal to divert the currents into either the LEDs or a different load.

Consider a long-tailed pair with the DAC controlling the emitter "tail" current. One collector would have the LEDs as a load, the differential signal on the base would direct the emitter current through one or other of the collectors.

In this diagram one collector resistor would be replaced by the LEDs. Ignore the marked voltage "outputs"; your output is the current into the LED


The current would be switched orders of magnitude faster than 1ms, so the LED response would dominate the timing.

[tooki]

I don't understand why you need LED flashes during exposure and can't drive LED with PWM passed through low pass filter?

Because I get a signal from the PLC and need to capture 2 images in fast sequence, with 2 different brightnesses.
So at the moment I set the PWM value that will change in 1/50000 of a second after the command. And then start the camera trigger by software. Between setting the PWM value and the CCD exposure starting is about 1 ms or even shorter (and probably not constant, the trigger is send over USB)
So the time is too short for LP filter to settle at a constant value during the exposure.

P.S. I can get away with the 10 bits I have now. Always on the lookout for a better solution.

You could divide the LEDs into two or more banks that you can control independently, adding another level of brightness control without needing more bits of PWM. (For example, alternate every LED between 2 banks, so that for lower brightnesses, you just disable one bank.)

Another thing you could consider is not using PWM, but some other encoding like PDM (pulse density modulation, which is almost the same thing as delta-sigma modulation). This would reduce the brightness error by spreading out the pulses within a 16-bit value.

It also seems to me you could use a DAC to control a constant-current LED driver. Modern audio DACs, for example, are often 24-bit at 48, 96, and 192kHz, more than enough. The question I don’t know off the top of my head is how long the latency is.

[MasterT]

stmH7, stmG4 have HRTIM. G4 equivalent clock is >4 GHz, so 16-bits at 83 kHz PWM.
Nucleo-G474re is at mouser about $23 CAD.

[BennoG]

that looks interesting. Will have a look at this when i have some spare time.

[pcprogrammer]

stmH7, stmG4 have HRTIM. G4 equivalent clock is >4 GHz, so 16-bits at 83 kHz PWM.
Nucleo-G474re is at mouser about $23 CAD.

This HRTIM is also mentioned in this thread but it comes with a lot of constraints, and is not a true high speed clock, but something with delay lines, so read the manual carefully before you decide to buy. A G474 board from weactstudio is ~7 euro on Aliexpress.

[BennoG]

You could divide the LEDs into two or more banks that you can control independently, adding another level of brightness control without needing more bits of PWM. (For example, alternate every LED between 2 banks, so that for lower brightnesses, you just disable one bank.)

Another thing you could consider is not using PWM, but some other encoding like PDM (pulse density modulation, which is almost the same thing as delta-sigma modulation). This would reduce the brightness error by spreading out the pulses within a 16-bit value.

It also seems to me you could use a DAC to control a constant-current LED driver. Modern audio DACs, for example, are often 24-bit at 48, 96, and 192kHz, more than enough. The question I don’t know off the top of my head is how long the latency is.

That would limit the flexibility of the device I want it to be. At the moment it is 2 recording with vastly different lightning settings.
My experience is that if you develop something with limits you will run into them at a later moment when you want to reuse the same device then find it can not meet the requirements forcing you to do the same thing again.

This post is for me a investigation if there are other possibilities using a microcontroller and a Fast Mosfet driver to drive the switching mosfet.
This is to make the device as flexible as possible so it can be reused

[tggzzz]

This post is for me a investigation if there are other possibilities using a microcontroller and a Fast Mosfet driver to drive the switching mosfet.
This is to make the device as flexible as possible so it can be reused

Yes there is at least one; see my earlier post.

No fast MOSFETs needed. Only low-speed DACs/current sources, and ordinary BJTs operating in a mode that is known for its excellent high frequency performance. Turning the LEDs on/off only requires a <1V swing.

Plus, since the current is constant (it goes through either one or the other BJT), there is minimal EMI/EMC. That's relevant if the LED current is high (you don't state the current).

[DavidAlfa]

Why not use constant current control?
I think it would be way easier, using a dac or digital interface to adjust the CC controller.
Though 16 bit resolution seems overkill, I don't think you need so much fine control for lighting?

[radiolistener]

50 kHz PWM is very low frequency, not high.

[langwadt]

50 kHz PWM is very low frequency, not high.

it is if you want 16 bit resolution at the same time ...

[DavidAlfa]

Yep, would need a crazy 3.2GHz base clock (50KHz * 65536 steps)

[radiolistener]

Using 1-st order 1-bit Delta-Sigma Modulator you can get 16 bit with oversample 2048x. For 48 kHz sample rate it needs 98.304 MHz clock.
Using 1-st order 4-bit Delta-Sigma Modulator you can get 16 bit with oversample 512x. For 48 kHz sample rate it needs 24.576 MHz clock.

Using 2-nd order 1-bit Delta-Sigma Modulator you can get 16 bit with oversample 128x. For 48 kHz sample rate it needs 6.104 MHz clock.
Using 2-nd order 4-bit Delta-Sigma Modulator you can get 16 bit with oversample 64x. For 48 kHz sample rate it needs 3.072 MHz clock.

But 2-nd order DSM is unstable and can produce artifacts.

Its better to use DSM with 4-bit DAC.

[tooki]

50 kHz PWM is very low frequency, not high.

No it isn’t. You’ve clearly not noticed the many threads where people think an Arduino’s 490Hz default PWM is more than enough, because they remember that 60Hz is enough for moving images.

As someone who is sensitive to slow PWM flicker, it always bugs me when people want to use anything below around 3KHz.

Note that the PWM frequency isn’t the clock frequency used to generate the PWM. That is the PWM frequency multiplied by the number of bits.

[MasterT]

.....
Its better to use DSM with 4-bit DAC.

 Totaly agree. Have you mind to show a circuits/ schematics? Have you ever build DSM, or know somenone who did?
Otherways copy/ paste wikipedia quatation is not really helpfull.

[mtwieg]

Do you really need that much dynamic range?

I can get away with the 10 bits I have now, was curious if it was possible to extend.
In the really low (pwm 1-5) the steps are very noticable. (even 10 or 20 % per step)

Why 50 flashes?

I don't have exact control over when the camera shutter starts and stops. So if I have at least 50 flashes during the 1 ms exposure I chan have max variation of 2% in brightness of the image. Between the individual camera captures.

I don't know much about photography and modern cameras, but is variation in luminous output within the exposure not a concern?

Anyways, if all you need is high precision (as opposed to high accuracy), then I would suggest looking at using a microcontroller with special high precision pwm. C2000, STM32, and Kinetis V MCUs have such special peripherals (need to be careful though, not all devices have them). Though using these peripherals is generally far more complicated than your basic pwm on an arduino. The Nucleo board suggested by MasterT above may be a good start, hopefully they offer a good example project for setting up the HRTIM.