SBIG Cameras and Self-guiding

[Christopher Madson]

Hey guys,

    I have a request for a feature if you're interested in hearing me out.  I have a SBIG ST-10XME that has a second guiding chip.  Unfortunately, the way SBIG has setup their driver over USB, only one program can access both cameras thus programs such as PHD are limited to either using the whole camera (defeats the purpose) or relying on programs such as MaximDL that have guiding built-in.  I hate MaximDL.  I love using SGP! :)  The guys at SGP say they could figure out how to use the second camera, but they don't have a way to pass that image through to PHD and then do whatever PHD would do with the image.  Can you guys think of some way to do it?  IANA Programmer and just wish to use my self-guider in a decent program.

Help! :)

Chris

[Andy Galasso]

Chris, there are a number of ways to accomplish what you are looking for.

One possibility would be for SGP to expose a camera interface, similar to the way MaximDL does. MaxIm exposes its camera interface as a COM object, but that interface is non-standard and specific to MaxIm (I'm not sure, maybe it pre-dated ASCOM?). That leads to programs being dependent on MaxIm (for example, PemPro among others).

A better approach if we go this route would be for SGP to expose its interface as an ASCOM camera. If we had that, then PHD would not need any modifications: you would just tell it to connect to the SGP ASCOM camera!

That is something Jared or Ken would need to comment on to see if it is feasible for them to implement an ASCOM camera.

Andy

[Jared Wellman]

Andy and Chris, 

We actually have a working implementation of the ASCOM solution that Andy mentioned...we had it working about 3 days after Chris initially requested it 8ish weeks ago.  But we ran into some snags and with the 2.2 release of SGP we haven't revisited it.  

However it's not fully baked and we need to optimize it some.  Unfortunately going this route means there are some additional "hops" in pushing a rather large chunk of data around.  Generally it would go Camera -> ASCOM -> PHD.  With this implementation it would go Camera -> SGP -> ASCOM -> PHD.  The additional SGP hop isn't really the problem it's that to go between applications you generally have to go out to the file system...which takes time.  While the current implementation does work there is around 1-2 seconds of additional lag between the actual frame completing and PHD being able to take action.  We don't really think this is acceptable but to be honest we haven't tested it "in the wild" either.  

Currently we're polishing up some of the remaining changes for 2.2 to get complete.  Once that is done we'll likely leverage some of those features to enable the ASCOM pass through guide camera for SGP.  

To be completely honest this still isn't the best solution.  Ideally there would be an SBIG ASCOM driver that would expose the two cameras and act as the hub for different applications to split the cameras.  This would reduce the hops and I believe could be done entirely in memory (a benefit of COM). 

We do plan on revisiting it in the near future.  It will likely be at the top of our list once get the 2.2 release wrapped up.

Hope that helps, 

Jared