Jump to content

Banner.jpg.b89429c566825f6ab32bcafbada449c9.jpg

Why is there a delay for LX webcams?


Reggie

Recommended Posts

Hi all, I know that sharpcap and wxastrocapture both deal with the philips long exposure webcams very well without any user intervention, with a very occaisional frame drop. However, phd has a long exposure 'read delay' setting where you can fine tune the delay to adjust for more or less dropped frames, this is also hit and miss.

Does anyone know why grabbing the LX frame is so hit and miss? Does anyone know what causes the delay?

I've been wondering whether it's a latency issue or a timing issue myself. It's hard to tell whether it's grabbing to early or too late.

Link to comment
Share on other sites

I think it's because the webcam keeps sending frames at the configured rate even when in LX mode. In LX mode all frames are black while a long exposure is in progress. Once the exposure has stopped, the next frame will contain the long exposure image. Then the webcam will keep sending black frames again.

I can imagine that there might be timing issues getting the exact frame that contains the exposure. This will probably work better with lower frame rates.

I seem to remember that sharpcap actually checks whether a frame is completely black and if yes, discards it. If the frame contains anything other than black, it's the frame with the exposure. But I'm not too sure about that....

Link to comment
Share on other sites

I agree that the frame transfer input and the shutter pin into the 16510 chip are constantly running. The shutter pin is toggled from on to off at the start of the frame (I think) for the duration of the shutter speed, the frame transfer pin is toggled at the end of each frame.

I had heard sharpcap looks for the exposed frame, and carries on until it gets one, I wonder if phd can be made to do it? PHD no longer produces a black frame anymore, you get a normally exposed image instead so I'm wondering what's changed to make it do that. Kind of shoots the 'camera is sending out black frames' scenario, unless it's also trying to check for the black frames, discards them and grabs the first frame it sees after that (Which could be a normal frame).

Link to comment
Share on other sites

I asked these questions on the QCUIAG yahoogroup, still waiting for a reply, in the meantime, a bit more investigation tells me that its the 'ROG' pin on the saa8116 chip that's connected to pins 8/13 on the 16510 chip (in yesyes circuit, pins8/13 are the LX part essentially). So I need to measure the rog pin as I'm not entirely convinced that we actually need to wait for the ROG pin to fire again, or whether we can just mimic what the ROG pin is doing and have the frame 100% ready for us when we come to grab it :(

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. By using this site, you agree to our Terms of Use.