Sujet : Re: "Colorimeter"
De : blockedofcourse (at) *nospam* foo.invalid (Don Y)
Groupes : sci.electronics.designDate : 25. May 2025, 19:08:37
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <100vmb8$1gb4n$1@dont-email.me>
References : 1 2 3 4 5 6 7
User-Agent : Mozilla Thunderbird
On 5/25/2025 2:07 AM, Martin Brown wrote:
As mentioned elsewhere, how do they fare when light is shining directly on the
sensor? How do you keep it from saturating -- dark lens to attenuate the signal?
>
or a shutter to limit the time light hits the sensor
>
There's still a limit as to the peak intensity that a sensor can
tolerate. And, gating the light (instead of attenuating it)
means there is no signal when the source is gated off.
Simplest solution is to limit the aperture that you let the light in through which is normally focussed onto a narrow slit anyway. You might get a bit of an issue with readout smearing but it probably won't be too bad.
The issue would be knowing WHEN that was necessary and when it would
suppress the signal. You'd have to leave it "clamped down", normally,
take a reading and then decide if, instead, you should have "opened
it up".
And, once having made that decision, hope that conditions don't change.
Please bear in mind that my experience with spectroscopy the problem was mostly getting enough light to have *any* signal to noise.
I think their application is looking *into* light sources. The way the
problem was presented, it was measuring light falling here vs. there vs...
Fine if you are making a device with a button that says "measure now".
But, if you expect to be able to collect data at any time, you
want to be sure data is available.
In extremis the measure now button could just move a spring loaded mechanical shutter that normally blocks the light path.
That assumes there is a definite time to make a measurement. Most of the
systems that I've designed act continuously; the user isn't constrained to
follow a set process -- A, then B, then C.
So, typically, a service is just providing updates to a variable that
process(es) can examine at their leisure (you mmap() the hardware device
as if a simple datum instead of calling a procedure to make the measurement)
Consider, you don't ask a UART to fetch a character for you to consume.
Ditto a network stack. Or, a set of digital I/Os. Or, temperature
sensors, etc.
Instead, you consume what has already been *discovered* and react accordingly.
("Oh, my! The access panel has been opened, unexpectedly! How do I handle
this event?")
I.e., unlike a laboratory device that requires a particular set of actions
to yield results, the device provides data and you have to sort out what
the user is likely doing.
Unless the thing is imaging a nuclear blast, steel furnace or an arc lamp then I don't think light intensity is likely to harm a modern CCD. There are hot mirror and anti-UV low pass filters to protect such equipment from hostile radiation.