Navigation:
Validation
Check this document for XHTML 1.0 Strict conformance and CSS 2.1 conformance and see all these nasty errors.
Debugging
I would be very grateful if you could let me know about any language errors still remaining in this site. Thanks!
Trust WB-5400 webcam case has a ball-like shape and is mounted on two-armed stand. The photo below shows the camera.
Two arms holding the camera are quite flexible, by carefully bending them it's possible to dismount the camera from the stand. The camera case consists of two parts connected by two pair of latches. In order to open the case it's necessary to insert something sharp between the case parts near each latch and use it as a leverage to pry it open. Do not try to push the latches with a screwdriver, it's easy to break them this way.
 Camera dismounted from the stand |
 Camera case latches |
After opening the case and unscrewing the screws holding the camera PCB it should be possible to get the PCB outside the case. The next step is to remove the camera lens holder, it's held by two screws from the back of the board. At the end you should have the full access to the board, including the camera sensor area. The following photos show the camera PCB waiting to be modified.
 Back side of the PCB |
 Front side of the PCB |
The good news is that the traces on camera PCB under the sensor are wide and quite long, it should be easy to connect to them without using any sophisticated tools. I soldered a thin wire to pin 14 in the first camera to get access to FSIN input and to pin 41 in the second one to get VSYNC output signal. The following photos show the wires soldered to the pins.
 Connection to pin 14 (FSIN) |
 Connection to pin 41 (VSYNC) |
Before reattaching the lens to each board I cut a small holes in lens holder base to get the wires out safely without squeezing them too much. The lens holder base is made of plastic, so a sharp knife did the job. There's a small hole on the front of camera case (made for the microphone most likely), I used it to drag the wires outside. Finally I reassembled the cameras and got the whole set ready for experiments.
Linux 2.6.33 kernel supported the camera out of the box with gspca_sn9c20x module, however I was unable to use two webcams simultaneously. For some reason gspca driver was allocating so much USB bus bandwidth for the first camera, that there was not enough left for the second. To get around this problem I used the most recent sources of the microdia sn9c20x driver instead of the mainstream kernel module. Here you can find some instructions for building the driver module.
The sn9c20x module has some interesting options: bulk to use bulk transfers instead of isochronous USB
transfers and jpeg to enable jpeg compression. After inserting the module with the following parameters
I was finally able to get video stream from both cameras.
insmod ./sn9c20x.ko bulk=1 jpeg=1
Initial tests revealed that the frame synchronization input is working in SOI968 sensor without a need to tweak any register values. I confirmed that by observing the frame rate of the synchronized camera running in 320x240 mode getting down to 30 fps after switching the camera generating the synchronization signal to 1280x1024 mode. The weird thing is that the frame rate of WB-5400 in 1280x1024 resolution is 15 fps, not 30, so I expected the synchronized camera to go down to 15 fps as well. Perhaps this difference was somehow caused by different resolutions set.
In order to check the synchronization of the webcams I carried out two experiments.
The first experiment was to record video stream simultaneously from unsynchronized cameras pointed to the timer working with sub-second resolution and check if asynchronous operation of cameras can be confirmed by comparing the frames from both streams. I recorded 100 frames of video stream from webcams pointed to the computer monitor with the timer application running on the screen. To record video stream frames I used video capture utility from Video4Linux 2 API website. Both webcams were running in 1280x1024 resolution.
This image shows consecutive recorded timer values from both cameras. The top sequence is from the first camera, the bottom is from the second. It's easy to see that they are running out of sync, as there are differences in displayed 1/10s digits between the top and bottom sequences. Consider for example the part below:
As you can see while the bottom camera captured clear 6.2s, the top camera is already making a transition from 6.2s to 6.3s. In the next frame the bottom camera made the transition to 6.3s, but the top one shows already a faint shadow of 6.4 and so on. Unfortunately the 1/100s digits are blurry due to long exposure, but the differences in 1/10s digits are still clearly visible.
In the next experiment I connected VSYNC output of the first camera to FSIN of the second and recorded video stream simultaneously from both cameras. Again they were pointed to the same timer application window visible on the computer monitor and 100 video frames were captures from both cameras in order to compare the recorded time values. This image shows consecutive recorded timer values from both cameras. As you can see, first few frames of the recorded sequences were different, but subsequent ones are pretty much identical. Take a look at the part of the sequence below:
As far as I can tell from the visual inspection of both sequences, cameras were running synchronously. I repeated both experiments to make sure and got the same results.
I wanted to compare the time value on captured frames with better accuracy, so I started looking for
exposure-related parameters in sn9c20x kernel module. I found two: auto-exposure and
exposure. After disabling auto-exposure and trying some exposure values I managed
to get much sharper images with the following module parameters:
insmod ./sn9c20x.ko jpeg=1 bulk=1 auto_exposure=0 exposure=30
This image shows consecutive recorded timer values from both cameras with the exposure settings above. As you can see on the picture below, 1/100s digits can be now compared without any problems:
Recorded timer values in sequences captured from both cameras were exactly the same.
From the conducted experiments it's safe to assume that connecting VSYNC output of the first camera sensor to FSIN input of the second camera sensor resulted in both webcams running synchronously.
Trust WB-5400 has been identified as a cheap consumer-level webcam capable of receiving an external synchronization signal, suitable for amateur computer vision experiments.
