Remix.run Logo
throw646577 7 hours ago

> The LED should be connected to camera's power, or maybe camera's "enable" signal.

Wiring it in like this is suboptimal because this way you might never see the LED light up if a still photo is surreptitiously captured. This has been a problem before: illicit captures that happen so quickly the LED never has time to warm up.

Controlling the LED programmatically from isolated hardware like this is better, because then you can light up the LED for long enough to make it clear to the user something actually happened. Which is what Apple does -- three seconds.

nine_k 6 hours ago | parent | next [-]

Pray read the third paragraph of my reply :) It specifically mentions a way to make the LED be lit for long enough.

throw646577 5 hours ago | parent [-]

Which is not an adjustable method -- without changing the hardware design later in production to just tweak a delay -- and surely causes the LED to slowly fade out?

rightbyte 6 hours ago | parent | prev | next [-]

You can design a simple circuit such that both long and short pulses light up the led for atleast 500ms. There is no tradeoff needed to be made at all.

atoav 6 hours ago | parent | prev | next [-]

The mentioned one shot circuit does precisely that, in hardware for less cost and 100% non-overridable.

The only time that isolated hardware approach is benefitial in terms of costs would be when you already have to have that microcontroller there for different reasons and the cost difference we are talking about is in the order of a few cents max.

throw646577 5 hours ago | parent [-]

Well there is a microcontroller there, isn't there? For the camera.

atoav 4 hours ago | parent [-]

But is it isolated? If you can update its Firmware from the computer it isn't.

kirkules 6 hours ago | parent | prev [-]

I mean can't you just have the input signal to the light be a disjunction of signals? So it's on if the camera is on OR if some programmatic signal says turn it on?

I don't see why they should be mutually exclusive