Hello Alex,

I have been playing with synchronized led by camera VSYNC pin,
and came across some effect. Basically blinking 3 diodes are recorded
by SDK interface, and difference image is created. Everything works
great until CLEYE_EXPOSURE parameter is set to some moderately high values.
The dark image (when the diodes are off) is then half bright and half dark.

I would be very grateful if you could see attached set of archived images,
which will hopefully better explain.

Details of the setup: SDK 1.1.0.0509, 30fps, CLEYE_MONO_RAW, P4 hardware,
CLEYE_EXPOSURE=250, CLEYE_GAIN=10

In general, the effect is triggered by exposure parameter alone, which may possibly
mean it is not a matter of the driver, maybe exposure parameter changes required
blinking timings but I’m mot sure. I have not tested this situation under linux,
but can if it helps.

Best regards and many thanks for a great job!

How are you triggering the LEDs. Is there a variable delay you are using?
It is logical what you are seeing as your exposure gets longer, the sensor will stay “open” for longer period of time and capture other LEDs that are on at that time. To achieve desired effect you need to vary the LED timing as well.
Are you capturing in VGA or QVGA resolution?

Triggering is done by a very similar circuit as shown in this post.

It takes VSYNC input from the camera, and it definitely varies frequency depending on the camera frame rate frequency.
However, it does not seem change when exposure parameter changes, in theory it should not even need to,
because there should not be any frame image overlapping even at high exposure values.
It synchronizes good in this sense that there is no blinking on difference image, and no slow drifts, at all
frame rates.

Posted images are from VGA resolution, but the same effect is visible at QVGA, at all fps, all color modes.

Also attached one of the frames from the tar archive, where upper half is bright, where it should be all dark.
At lower exposure values everything is perfect.

Tested under linux, and the artifact is unfortunately exactly the same.

VSYNC pin just marks new frame event. Hardware circuit is able to
switch at many MHz freq, also diodes are much faster than required.

And how camera sensor can be exposed for a longer time than
duration of the frame?  Can’t imagine that.

Seems to be a very hard test for a camera, if it does mix frames
it can be very difficult to notice it without light keying.

Another thing is that you might be dropping some frames and losing the even/odd sync.

Should not be the case, images saving is buffered and driver does not skip frames
at mono mode, 30fps.  Anyways, if there were skipping,
there would be two bright or two dark images, we have different effect here.

What about thing I did not think before, the camera has infrared filter removed,
and no any replacement filter placed. It’s now more sensitive to light,
so maybe sensor “remembers” strong light for a too long with high exposure setting?

Here’s little program that allows anyone having ps3eye camera to experiment
with synchronization. No hardware modifications necessary.
Program blinks synchronously using built in red diode on the camera.

Just use mirror or CD disk to reflect red diode light, so camera can see it.
Try moving mirror to see reflection on higher portion of the image - it will not be fully visible with high exposure.
At low exposure reflection is visible on every portion of the image.

Program controls: ‘g’ - low exposure,  ‘h’ - high exposure.

addition:
Program is a slight modification of CLEyeMulticamTest from SDK.
Attached image with low exposure - reflection on CD disk is visible on higher part of the screen with low exposure,
try to see the same with high exposure!

toucheur, I’m pretty sure that the “VSYNC” pin I found on the PS3Eye is out of phase with the actual “beginning” of the sensor exposure. I don’t know what its “position” is with respect to the exposure, but I’ve seen the same artifacts you’re seeing before. I haven’t had a chance to explore the VSYNC any more recently, but my next experiment was going to involve using a microcontroller for generating a delayed version of the VSYNC signal.

Kyle, thanks for the information, I really awaited your post!

Now I know at least that this artifact is known and reproducible
and not caused by my particular hardware.

toucheur,

Controlling the LED from the code as opposed to directly from the VSYN signal will not be accurate. This is true because the frame capture function does not return until the whole frame image data is fully transfered to the PC. What you really need is to trigger the LED at the beginning of the frame capture (ie. at VSYN). Having the ability to delay the LED pulse and control the duration of the pulse is the ideal. This is something we are working and it is going to be part of the CLMulticam API in the future.

That’s great, support from within SDK would be very useful!

Just some thoughts which may save your time working on SDK support for synchronization.

Single most important thing it to control the duration of the pulse.
Light pulse have to be shorter than VSYNC to next VSYNC period.

This is mainly caused by lack of physical shutter, which normally would block light from the sensor.
The pulse has to emulate physical shutter by turning off during “shutter closed period”.
Otherwise sensor will not have enough time to “forget” the impulse.

To clarify, the pulse parameters will be set via the new API in the CLEyeMulticam SDK, but all the work will be done in hardware.

Just posted some more info on the VSYNC to NUI Group forums here.

Also, Alex: from my experiments I believe there is a small gap between frames of about 8 rows, but I don’t see any mention in the datasheet so I don’t really understand it.

It is simple, the camera uses rolling shutter. So each row is exposed until its read, all under a control by the exposure value.
When that value is 511 then the rows are exposed all the time but a time that it takes to readout a single row.
The VSYNC signal only signifies the start of the row data readout.

Hey Alex—it’s mostly simple, like you say. Two corrections:

- When the value is 511, only half the rows are exposed all the time (this can be tested by setting the exposure to 511 and blinking an LED for a very short period of time).

- While all the rows are not exposed “all the time”, they do seem to be sensitive up to a certain saturation level. Check out the second picture here http://www.flickr.com/photos/kylemcdonald/4676818703/sizes/l/ where the exposure is set to zero and an LED is flashed between two VSYNCs, then off. You’ll notice that the second (“black”) frame is actually brighter than the black frame above where the LED is only flashed for a very brief moment.