High frequency (50kHz) 16 bit PWM

[tooki]

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.

You know what they say about assumptions: when you assume, you make an ass out of u and me waste everyone's time, including your own!

[BennoG]

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.

You know what they say about assumptions: when you assume, you make an ass out of u and me waste everyone's time, including your own!

Still going for the PWM option because it is not as irritating as a full brightness flash. It is now a slight glow for the moment.
And the first proto did not even use light so remote triggering was not needed.

[KrudyZ]

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.

So you are OK with 2% variations, but want 16 bit resolution?
This doesn't make much sense.
Your problem is one of aliasing, not resolution. Your sample window is defined by the exposure time and the thing you are sampling is your LED drive waveform.
One way to make your life easier is to use pulse density modulation rather than pulse width modulation. You should be able to get to unnoticeable brightness variations in your images with much lower clock rates than what would be required for PWM.

[BennoG]

So you are OK with 2% variations, but want 16 bit resolution?
This doesn't make much sense.
Your problem is one of aliasing, not resolution. Your sample window is defined by the exposure time and the thing you are sampling is your LED drive waveform.
One way to make your life easier is to use pulse density modulation rather than pulse width modulation. You should be able to get to unnoticeable brightness variations in your images with much lower clock rates than what would be required for PWM.

The problem is the bottom 2.5% of the dimming. And the big steps when below 1%, but as mentioned above the solution is simple use 2 PWM output 1 with and 1 without a resistor, and use the one with resistor for the 0-2.5% rangen and the one without resistor for the  2.5-100% range (if needed, so for now not needed)

[mtwieg]

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

All this time I was assuming this was a typical point-and-shoot camera...

Glancing at the documentation is seems like those GPIO pins can be configured either as inputs to trigger the shutter, or as outputs triggered by the shutter/flash.  It should be perfect for your needs.