LX Control Signal

[samtheeagle]

I'm working on a LX webcam project and I need to understand better how the webcam shutter is controlled...

So my basic understanding is that the camera shutter is controlled by whatever data line is specified e.g. DTR. What I'm unclear of is what signal is sent on this line? Is it a brief pulse to open and then another to close the shutter? Or is the line set high for the required exposure duration? Or some other method?

Thanks in advance

[rwg]

You hold the line high (or low - depending on the exact circuit you are using) for the duration of the exposure. If you get it the wrong way round you'll get no images, so it's fairly easy to work out by trial and error.

Robin

[rwg]

Hmm, just realised that the previous answer isn't quite complete...

There are typcially two lines that you have to take control of to take long exposures, and unfortunately they both get described as 'shutter' sometimes which gets a bit confusing.

The first is the real shutter control line - this one goes from the controller chip to the CCD and tells the CCD how long each exposure should be. Often you just put a hardware switch and a pull up resistor into this line. This is connected to what is referred to as pin 10/pad 10 on this page : Philips SPC900NC uncovered. When the switch is closed, the camera will function as a normal webcam, when it's open the camera will have it's exposure stuck to maximum (ie the software controls will do nothing) and it can work in LX mode

The second line is the one the computer needs to control - this enables or disables the frame transfer function of the camera. Normally at the end of each frame (5 times a second or 30 times a second or whatever), the control board sends a pulse to the CCD telling it to read out the accumulated image. By cutting that pulse of for a period, we allow the image to accumulate for longer and we get long exposures. Then, when the long exposure is over we re-connect that pulse and the whole accumulated image is transferred back to the PC over the next frame captured (*).

The circuit we typically use is based on the 4066 analogue switch, which electrically connects pins 8 & 9 when a voltage is applied to pin 6 and disconnects them otherwise (**) - this allows us to control the flow of the frame transfer pulse based on the output of a serial or parallel port line.

Robin

(*) Sadly it's not as simple as that - sometimes the image arrives not at the next frame but the one after that.

(**) I think I have this the right way round - maybe it connects 8 & 9 when 6 is low not high, but the idea is the same.

[themos]

Hello Robin, I am trying to understand what effect the frames/second setting has when doing LX. I am trying to cure the problem of dropped frames in PHD and thinking that its LE Delay setting has some subtle interaction with the FPS setting. I don't seem to have dropped frames with SharpCap!

[rwg]

Hi Themos,

I spent quite a bit of time in SharpCap ironing out dropped frames in LX mode - the problem is that the frame that the LX image arrives in isn't always the first frame after you've ended the exposure - sometimes it's the one after. In high FPS modes, the SPC camera does some sort of time based compression, so the LX image arrives over a number of frames!

What SharpCap does is to watch the first 3 frames after closing the LX exposure and pick the one with the highest total brightness as the exposure frame. This seems to work reliably, particularly as SharpCap locks you down to 5 or 10 fps when you go into LX mode (too much compression at higher FPS rates to be worthwhile).

It sounds like PhD is using a simpler approach where you set a delay value and it will wait that delay after closing the LX exposure and then capture the next frame. If that is the case then the delay will need to be varied as you change the FPS rate to make sense. I guess that a good value will scale as 1/FPS (roughly). Additionally, since at the higher FPS rates the LX image is smeared over a number of frames, you probably have more chance of getting some sort of image at higher FPS, although it won't necessarily be full brightness. At lower FPS you're more likely to either get the full brightness image or a dropped frame.

Hope this helps,

Robin

[samtheeagle]

Many thanks Robin, that's a pretty much perfect answer! You're a gent Hopefully I'll be able to post details of my project by then end of the weekend with this new found knowledge.

[themos]

Yes, very helpful indeed! I wonder if we can get PHD to improve... have you been in touch with the author?

[rwg]

@samtheeagle - Looking forward to seeing what you're up to

@themos - no, not been in contact about PHD - I don't do guiding myself, so it's not something I've ever used. Quite happy to share the technique I've used though.

Robin

[themos]

I will download PHD 1.12.3 which is a "pre-release" version and have a play with that first.

[themos]

We aren't about to be treated to an ASCOM Camera driver for the LX-modded webcams, are we Sam?

[samtheeagle]

Lol, sorry themos, no we are not... May I present my Frankenstein's monster, a hardware LX mod:

I find the requirement for a second cable to control the LX a bit annoying, so I got thinking about a hardware signal generator. Nothing flash, just an Arduino pro mini and a potentiometer. When the pot is below a certain threshold the LX mod is disabled, akin to a physical on/off switch, and above the threshold it will vary the length of the exposures.

The Arduino code can be set up however you like to map pot values to exposure times, at the moment I divide the value (max of 1024) by 50 to give a range up to ~20 (which I map to seconds).

It's not actually working yet, but a reckon a bit more fiddling and I'll get there. Electronics is certainly not my forte! Then it'll need to be packaged into a new enclosure and I'm done. A hardware controlled LX webcam for guiding purposes.

[rwg]

I may be missing something here, but how will the capture/guiding software know when an LX frame is finished to capture the image? SharpCap, PHD and others all have to know this to know which frame to grab from the stream sent by the webcam.

During an LX exposure, the camera keeps sending the normal rate of frames to the computer, it's just that they are all blank. My guess is that what you'll see is a flash of your image for a frame or two at the end of each LX exposure and blank the rest of the time.

Robin

[samtheeagle]

Oh dear, a fatal flaw eh? That is annoying. In which case my circuit probably does already work as what you described sounds very familiar. Perhaps this Arduino is destined to become a focuser driver then... DOH ><

I guess that's why nobody has already made this mod! I did wonder I hadn't appreciated the way in which the mod works... I just thought that a frame was only returned when the mod said to dump the image buffer, but obviously not.

To support this the software would need to handle this specific flavour of mod. From what you described above an app could monitor the incoming frames and grab the ones that vary significantly in brightness from the rest. Maybe I'll see if I can knock up an app just to see if it works or not.

[themos]

I may be missing something here, but how will the capture/guiding software know when an LX frame is finished to capture the image? SharpCap, PHD and others all have to know this to know which frame to grab from the stream sent by the webcam.

You see? Now he'll have to write an ASCOM driver...

[rwg]

Well, I could write the code in SharpCap to cope with it - just keep looking at frame brightnesses until you see a peak and grab the peak frame as the LX exposure and use that until the next peak comes along.

You could write that ASCOM capture driver that Themos keeps suggesting to do the same thing - then it could feed captured frames back to PHD and it'd work (probably)

So it looks like it could be made to work

Robin

[themos]

Someone has had a first stab at an ASCOM driver for LX-modded webcams.

http://tech.groups.yahoo.com/group/ASCOM-Talk/files/Camera%20drivers%20from%20BB/

[samtheeagle]

Themos, you wouldn't be looking for someone to write an ASCOM driver for LX webcams would you? Well if a layer of abstraction such as that would make my hardware mod work I reckon I could have a crack at one... I can make it support my hardware LX and the more traditional LX control approach too.

[themos]

Having written an ASCOM Focuser driver, I'm over the worst part (says the fool).

It seems to me that Frankenstein will work with SharpCap as it is. You just have to sweep with the pot until the actual exposure matches what you've told SharpCap... or I am missing something. Sam, add an LCD panel for feedback of what the exposure is?

[themos]

Sam, why are you feeding power back to webcam board? I see 3 orange wires coming out of the 5V USB line, one to the "dead bug", one to the arduino and one back to the board.

[samtheeagle]

Themos, the LX instructions I followed (the ones linked by Robin) say:

"Also add a 100k Ohm resistor between pin 10 and +5V; it ensures that pin 10 always has a defined signal on it."

I assume that's the one you asking about? Like I said, I know very little about electronics, I just do what I think the instructions are telling me, but perhaps I've confused myself? The basic LX mod appears to work, if I ground the LX control wire the image buffer definitely accumulates data.

[rwg]

Feel free to use the SharpCap code as a starting point - all of the DirectX stuff is implemented already, as is code to examine each frame that is sent from the webcam and measure its total brightness.

Robin

[themos]

Right you are, it connects to a 100K that is out of sight in the pic, then.

Thanks Robin, if my PHD/SC1 problems persist, I might have a go.

[samtheeagle]

Sounds like some handy code just waiting to be reused Thanks!

[samtheeagle]

@themos, I have got a skeleton ASCOM driver created now... Obviously still a long way to go, but the wheels are in motion

@rwg, would you be so good as to point me in the direction of the most appropriate bits of code? I've downloaded the 1.0.9 sources and had a quick scan, but a few pointers would make life a great deal easier

Thanks.

[rwg]

Sam,

what you need to do is download the latest version - 1.3.114 and install it. Then in the installation directory you will find a src folder, which contains all the source you need. You definitely won't find the stuff you need in 1.0.9 since it didn't support LX mode then

The places to start looking are:

LXCaptureTransform.cs in the LXMod project - this receives each frame from the DirectX preview pipeline via the TransformFrame call, so it's the place to process frame data.

SPCLXCapture.cs contains the implementation of ICaptureProvider for LX cameras and is another good place to look. If you create one of these and call GetDeviceMenuItems() on it it will return the items that get put in the devices menu. The .Tag member on each menu item is actually a DeviceTagData object - you can pass that to the OpenDevice() member to connect to the device, then call StartPreview(). There are a few other things you need to do to make it work, but you should be able to spot these from what SharpCap does in the places where it crashes for you

Note that the Basler camera project won't build unless you have the Basler SDK installed, but you probably don't care about that. A couple of other projects don't build from the installed source because of missing app.config files that are in the projects but not shipped - just delete the app.config files from the projects. SharpCap.exe fails to build because the Settings.settings file is installed to the wrong folder - it should be in SharpCap\Properties. Finally, I don't include the referenced 3rd party assemblies in the src folder of the msi, but you can pick these out of the c:\program files\rwg\sharpcap folder and put them in the right places.

Hope this helps,

Robin