High frequency (50kHz) 16 bit PWM

[LinuxHata]

LT8500 by linear provides exactly what you need - very precise PWM control for LEDs.

[BennoG]

Already ordered a Nucleo board capable of HRTIM, now find some time to experiment with it.

Benno

[BennoG]

LT8500 by linear provides exactly what you need - very precise PWM control for LEDs.

Can only do 6.1 kHz and not more at 12 bits. So no not by a long shot.

I did not say it was a easy task 

Benno

[ebastler]

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.

Can it be a single LED flash per exposure? If you know "roughly" when the shutter opens, turn the LED full-on a bit after that and leave it on for as long as you need to get the right amount of light?

[DavidAlfa]

A shot is a cumulative process, the total light captured during the frame time is what makes the final image, so in theory you could use lower pwm resolution, and create a pattern or sequence varying the duty cycle.

In a very simplified example, let's say you have 5 and 10% but you want 7%,  alternating the pwm outputs 50% of the time will make it.

[BennoG]

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.

Can it be a single LED flash per exposure? If you know "roughly" when the shutter opens, turn the LED full-on a bit after that and leave it on for as long as you need to get the right amount of light?

Than you need a DAC to control the brightness of the LED and if you need some power then you have a settle time of at least 10ms.
The camera exposure starts usually about 0.5 - 1.5 ms after setting the brightness. Waiting for the settling is not an option because we have only about 250 ms to make 4 images of 4 different brightness values. (and also process the 4 images within that 250 ms)

[BennoG]

A shot is a cumulative process, the total light captured during the frame time is what makes the final image, so in theory you could use lower pwm resolution, and create a pattern or sequence varying the duty cycle.

In a very simplified example, let's say you have 5 and 10% but you want 7%,  alternating the pwm outputs 50% of the time will make it.

O that is something that I can do in the UC that is generating the PWM, this is only needed for 0.1% to 2% of the pwm range because only in the very dimmed state you have clear steps in brightness.

[ebastler]

Can it be a single LED flash per exposure? If you know "roughly" when the shutter opens, turn the LED full-on a bit after that and leave it on for as long as you need to get the right amount of light?

Than you need a DAC to control the brightness of the LED and if you need some power then you have a settle time of at least 10ms.
The camera exposure starts usually about 0.5 - 1.5 ms after setting the brightness. Waiting for the settling is not an option because we have only about 250 ms to make 4 images of 4 different brightness values. (and also process the 4 images within that 250 ms)

Not sure whether I made myself clear. I meant to run the LED at full brightness and just vary the LED on-time. No DAC needed. (That's assuming that you can live with variations of the effective exposure time, which will no longer be 1 ms always but shorter in situations where you want less light.)

More out of curiosity, but also to make sure I understand the challenges: Where does that 10 ms settling time come from? Why can the LED settle to a new intensity level faster when driven by PWM than when driven by a DAC?

[Siwastaja]

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,

Yeah, but on the other hand this specific case would be exactly what the designers had in mind: high resolution PWM, so I would expect this is a very easy job with STM32F334 or the friends. Just be careful that some values close to min and max duty are illegal, in other words you can't output 1/65536 with HRTIM but you can output 16, 17, or 18/65536 just fine.

Then again, I also question the idea that 16bit accuracy on PWM is needed and then frame-by-frame variation depending on how the shutter and PWM happen to coincide is 1/50 or roughly 6 bits.

PWM is probably inaccurate anyway, what are you going to do with the PWM, control the LEDs from a voltage source using some MOSFET? Then the brighness will vary based on voltage and temperature variations. Constant current circuit is really needed, and then you could just adjust that current setpoint.

If both accurate amount of photons with short exposure (i.e., uniformity of light), and quick setpoint changes are needed, then maybe design two filtered constant current drivers and a quick switch between them. You can basically short-circuit the unused constant current driver while the other is connected to LEDs.

[tooki]

Can it be a single LED flash per exposure? If you know "roughly" when the shutter opens, turn the LED full-on a bit after that and leave it on for as long as you need to get the right amount of light?

Than you need a DAC to control the brightness of the LED and if you need some power then you have a settle time of at least 10ms.
The camera exposure starts usually about 0.5 - 1.5 ms after setting the brightness. Waiting for the settling is not an option because we have only about 250 ms to make 4 images of 4 different brightness values. (and also process the 4 images within that 250 ms)

Not sure whether I made myself clear. I meant to run the LED at full brightness and just vary the LED on-time. No DAC needed. (That's assuming that you can live with variations of the effective exposure time, which will no longer be 1 ms always but shorter in situations where you want less light.)

Indeed, this is precisely how modern camera flashes control flash power: altering the length of the xenon tube discharge.

[LinuxHata]

Well, if LT8500 is no match, then something like MBI5026 or other multiplexed led display drivers should work.

[radiolistener]

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.

Well, I wrote a small and simple N-bit 1-st order DSM DAC model in Octave for you:

Code: [Select]

pkg load signal;

% Parameters
Fs = 8000;      % Sampling frequency of input signal
BITS = 5;       % Input signal resolution in bits
Fsig = 1000;    % Frequency of the input signal (1 kHz)

OSR = 32;       % Over Sample Ratio for DSM
N = 1;          % N-bit DSM

% Derived parameters
Ts = 1 / Fs;        % Sampling period
Fosr = Fs * OSR;    % Oversampled frequency
Tosr = 1 / Fosr;    % Oversampled period

% Time vectors for input and oversampled signals
t = 0:Ts:2/Fsig;        % 2 periods of the input signal
t_osr = 0:Tosr:2/Fsig;  % Oversampled time vector for 2 periods


% n-level quantizer
function quantized_output = quantize(signal, range, n)
    min = range(1);
    max = range(2);
    scale = max-min;
    % Scale from [min, max] to [0, 1]
    normalized_signal = (signal - min) / scale;
    % quantize [0, 1] for n levels
    quantized_output = round(normalized_signal * (n - 1)) / (n - 1);
    % Scale back from [0, 1] to [min, max]
    quantized_output = quantized_output * scale + min; 
end

% Generate input sine wave (5-bit resolution)
input_signal = sin(2 * pi * Fsig * t);

% Quantize input signal according to AES17 standard (zero-symmetric)
input_signal_quantized = quantize(input_signal, [-1, 1], 2^BITS - 1);

% Delta-Sigma Modulator (First-order)
error = 0;
output_dsm = zeros(1, length(t_osr));
for i = 1:length(t_osr)
    current_input = interp1(t, input_signal_quantized, t_osr(i), 'linear', 'extrap');
    signal = current_input - error;
    quantized_output = quantize(signal, [-1, +1], 2^N);
    error = quantized_output - signal;
    output_dsm(i) = quantized_output;
end

% Low-pass filter to reconstruct the analog output
% Use 4th order Butterworth filter with cutoff at 1/OSR
[b, a] = butter(4, 1 / OSR);
output_filtered = filter(b, a, output_dsm);

% Scale the filtered output to match the input signal amplitude
output_filtered = output_filtered * max(input_signal_quantized) / max(output_filtered);

% Plot results
figure;
hold on;
grid on;
plot(t_osr(1:length(output_dsm)), output_dsm, 'r', 'LineWidth', 1, 'DisplayName', 'DSM Output');
plot(t, input_signal_quantized, 'b', 'LineWidth', 3, 'DisplayName', 'Input Signal');
plot(t_osr(1:length(output_filtered)), output_filtered, 'g', 'LineWidth', 1.5, 'DisplayName', 'Filtered Output (DAC)');
ylim([-1.05, 1.05]);
legend('show');
xlabel('Time (s)');
ylabel('Amplitude');
title(sprintf('Delta-Sigma Modulator DAC, N=%d, OSR=%d', N, OSR));
hold off;

You can play with it and see how quantizer resolution (N) and oversampling ratio (OSR) affects 1-st order DSM DAC output quality.

The blue trace is input signal.
The red trace is N-bit output of DSM.
The green trace is a filtered result, it has some phase shift due to filter delay.

Here is example in attachment for 1 kHz sine at 8 kHz sample rate converted with 1-bit DSM DAC and with 4-bit DSM DAC, with using 32x oversampling.

As you can see, using 4-bit DSM is much better than 1-bit DSM. 

[MasterT]

I ask for "a circuits/ schematics".

Octave, Python, LTSpice, MathLab etc. are all in my "parasite" list.

I invented "multi-bit" SD technology, and know pretty well how intelectual property theft network is operating.

[radiolistener]

Octave, Python, LTSpice, MathLab etc. are all in my "parasite" list.

As you can see, I haven’t used any MATLAB Designer tools or graphical components.
The entire code is contained within a compact script, making it easy to implement in either software or hardware.

I just used MATLAB language to describe the concept, as C++ would be less visually intuitive for this purpose. It is designed to support Octave which is a free tool, so you can use it on Linux/Windows/MacOS.

It's not hard to write it in verilog, upload to FPGA and run on real hardware. I tried it and it works.

I invented "multi-bit" SD technology, and know pretty well how intelectual property theft network is operating.

When you mention that you invented 'multi-bit' SD technology, could you clarify whether you are referring to your contributions in the context of advancements similar to those made by Jan Van der Spiegel, who is known for his work in this area?

I would be interested to hear more about your specific innovations in this field.

[BrianHG]

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.

The FPGA part isn't hard.  All you need is any bottom end FPGA with a 3.2768 Gbps serial transmitter.  (Basically overclocking any Xilinx part which can do 3.2500gbps, well within range, or get a 6gbps LVDS transmitter capable part.)

The real problem is converting that tiny almost 1v differential output to a meaningful analog signal retaining the full fidelity.  Just amplifying it to a true over 3GHz switch with enough slew rate to hit your chosen rails and an analog reconstruction filter to properly discern that tiny single 305ps pulse when the DAC code is a 1 vs a 0.  That is the true nightmare.

[pcprogrammer]

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.

The FPGA part isn't hard.  All you need is any bottom end FPGA with a 3.2768 Gbps serial transmitter.  (Basically overclocking any Xilinx part which can do 3.2500gbps, well within range, or get a 6gbps LVDS transmitter capable part.)

Ah, that is a clever trick. You just have to load the shift register with the correct data so many bits at a time reducing the clock of the rest of the logic.

I was thinking in the more traditional counter setup with a compare function.

The real problem is converting that tiny almost 1v differential output to a meaningful analog signal retaining the full fidelity.  Just amplifying it to a true over 3GHz switch with enough slew rate to hit your chosen rails and an analog reconstruction filter to properly discern that tiny single 305ps pulse when the DAC code is a 1 vs a 0.  That is the true nightmare.

I can see that being a big problem indeed. To be able to use the full range of 1 on over 65534 off up to 65534 on over 1 off you need to preserve the full > 3GHz bandwidth. Transition any slower and you loose on resolution you wanted to have in the first place.

[BrianHG]

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.

The FPGA part isn't hard.  All you need is any bottom end FPGA with a 3.2768 Gbps serial transmitter.  (Basically overclocking any Xilinx part which can do 3.2500gbps, well within range, or get a 6gbps LVDS transmitter capable part.)

Ah, that is a clever trick. You just have to load the shift register with the correct data so many bits at a time reducing the clock of the rest of the logic.

I was thinking in the more traditional counter setup with a compare function.

Using a 16:1 transmitter, you still are creating a 1/16th counter and compare function, it's just the bottom 4 bits which serve as a remainder, deciding how many low or high on the specific transition transmission 16bit byte.

[BrianHG]

Through some clever trickery, I've managed to get the cheapest slowest Altera Cyclone IV and Max10 FPGAs to output 1gbps on their software LVDS regular IOs at 3.3v.  Though, I also found a 1$ 4 channel 3GHz capable LVDS to 3.3v TMDS amp as well.
I guess it is just about good enough for 60khz at 14 bit.  With some dithering, maybe you can gain a pseudo 2 bits.

[BennoG]

So fare everything except for the fpga option is not a real solution to my problem. (the big steps in the low brightness of the led say 0 - 20 from the 1024 steps)

A simple solution I just tought of is use 2 PWM output 1 for normal use and the 2nd with a resistor of 1k - 20k to get the brightness of 25 at the first PWM  when the 2nd PWM is set to 100% 
So for 2.5 - 100% use the first pwm output without resistor
and For 0.1 to 2.5% use the 2nd PWM with resistor. Now I find myself stupid because I did not think of this before.

Benno

[mikerj]

So fare everything except for the fpga option is not a real solution to my problem.

You didn't respond to ebastler's suggestion of running the LED at full power and varying the on time during the exposure period.  This would be far simpler to implement than super high frequency PWM and would allow you to control the average illumination during an exposure, is there a reason this wouldn't work?

[BennoG]

You didn't respond to ebastler's suggestion of running the LED at full power and varying the on time during the exposure period.  This would be far simpler to implement than super high frequency PWM and would allow you to control the average illumination during an exposure, is there a reason this wouldn't work?

This is because I have no direct control over when the exposure starts. So it is a bit of russian roulette if the single pulse is during exposure. The camera has now hardware trigger input and both camera and pwm are controlled over USB from a linux running IPC.
I have a other PCB for the more expensive systems where you have a hardware input for the trigger and global shutter there I use what you suggest by adjusting the ON time of the led.
Because the problem for this project is make it as cheap as possible.
Benno

[tooki]

So fare everything except for the fpga option is not a real solution to my problem. (the big steps in the low brightness of the led say 0 - 20 from the 1024 steps)

You didn't respond to the multiple solutions I mentioned above.

[mtwieg]

You didn't respond to ebastler's suggestion of running the LED at full power and varying the on time during the exposure period.  This would be far simpler to implement than super high frequency PWM and would allow you to control the average illumination during an exposure, is there a reason this wouldn't work?

This is because I have no direct control over when the exposure starts.

The camera exposure starts usually about 0.5 - 1.5 ms after setting the brightness. Waiting for the settling is not an option because we have only about 250 ms to make 4 images of 4 different brightness values. (and also process the 4 images within that 250 ms)

So you're saying the camera has no sync/trigger functionality, either input or output? That's very surprising, I assumed all modern cameras had at least sync output capability (though it might be wireless in more modern cameras).

[BennoG]

So you're saying the camera has no sync/trigger functionality, either input or output? That's very surprising, I assumed all modern cameras had at least sync output capability (though it might be wireless in more modern cameras).

After your message I went looking at the camera documentation, and the camera has a trigger input (directly connected to the FPGA)
And on a tiny header on the back of the board.

So the reason I assumed it had nog trigger input, was I assumed the connector was the jtag programming connector.

https://www.baslerweb.com/en/shop/daa3840-45uc-s-mount/

The connector is that small and with direct lines to the FPGA I don't think it is wise to connect that to the PWM controlling board.

Benno

[langwadt]

The connector is that small and with direct lines to the FPGA I don't think it is wise to connect that to the PWM controlling board.

Benno

it has some protection and there's a supply so you could easily add an optocoupler to make it isolated