ASCOM Camera Simulator using ESO DSS Images

I’ve put together an ASCOM camera simulator that will load an image from the ESO DSS Image archive. The driver connects to an ASCOM telescope and the position of the image is read from that when StartExposure is called.
The camera is 1600 x 1200 with a plate scale of 1.7 arc secs per pixel, giving a size of 45 x 34 arc minutes.

The installer is in the ASCOM-Talk files area, there’s a notification of exactly where there.

It should be useful for testing SGP.


Thanks Chris…

That’s pretty cool. For our own testing, we derived something similar and it works pretty well for our needs. We never released it because it has a dependency on Pinpoint. What’s great about yours is that it is available to every SGPro user who wants to go through indoor testing (on cloudy nights or whatever). Thanks for doing this.

Quick question… we hooked ours up to the rotator also (in addition to the telescope) so that our images could incur said rotation. Does your new camera sim allow for image rotation? Certainly not a necessity, just something we found useful when running regression tests on camera rotator movements.


Thanks Ken,

I was wondering how you managed to test.

It doesn’t handle a rotator, the image comes as it comes from the ESO archive. Rotation would be nice - including rotating the image by 180 degrees if the mount as on the other side of the pier. Do you know of some easy image rotation code?


There are 2 ways you can handle this I think.

  1. I don’t know what DSS API you are using, but NASA’s skyview has something you can use to set image rotation prior to fetch. Something like:

  2. You can use affine transforms. .Net stuff has a handy “Matrix” class you can use for this.


Thanks for that driver – it will help me do some testing.

I have found that if I select “Simulator” or “Telescope Simulator for .NET”, everything works fine. However, if I select the EQMOD simulator, when I try to connect, the EQMOD simulator starts but then I get the message: “Error connecting to ASCOM Camera Driver for DSSCamera.!” The behavior is the same whether I do this using SGPro or Nebulosity. Also, in SGPro, once the above error occurs, the driver appears to be in an indeterminate state where it will neither connect or disconnect (the Properties dialog box thinks it’s connected); at that point, the only way to recover is to kill SGPro.

Here is the trace from the driver:

14:50:48.682 Camera Starting initialisation
14:50:48.682 Camera Completed initialisation
14:50:48.682 InterfaceVersion Get 2
14:50:48.682 InterfaceVersion Get 2
14:50:48.683 Connected Get False
14:50:48.683 Connected Set True
14:50:48.683 Connected Set Connecting to scope EQMOD_SIM.Telescope

Let me know if I can provide any further information.


Does EQMOD accept more than one connection? The camera needs a connection so if it won’t SGP won’t be able to connect to the scope as well.
Try using a hub, such as POTH, for the scope.



Yes it does. I can have CduC, SGPro and my dome control program (which works quite well because of a .NET version of DomeControl.cls – thank you very much!) communicating at the same time. Using the DSSCamera driver with SGPro should not be a problem. Besides, when I was testing the camera driver, I had not yet connected the scope.


I’ve tried it with the EQMod simulator and get an error message that says exactly what is happening:

Connect failed with error Property read EQMOD_SIM.Telescope FocalLength is not implemented in this driver. - Property read EQMOD_SIM.Telescope FocalLength is not implemented in this driver.


Does that match what you are seeing?


I saw only the error mentioned in my original post. However, I did an additional test where I connected to the scope driver first and turned on the EQMOD trace; then I saw the 'Not Implemented" message. I went through the EQMOD source and could see that “ApertureArea”, “ApertureDiameter” and “FocalLength” are not implemented. I also looked at the setup screens for all of the telescope drivers I could see in the SGPro telescope list and there was only one other driver that did not support optics data entry.

I’m presuming you use those to determine what image FOV to display? Would it be possible for you to use a default FOV if you encounter a driver where those properties are not implemented?

(QUESTION TO KEN: do you use any of those three telescope properties in your code? If so, what action do you take if you encounter a driver where they are not implemented?)

I will also ask Chris Shillito (the current Guardian of EQMOD) if he would add support for those three properties. But that doesn’t solve the problem of other drivers that behave the same way (not that there appear to be that many).


No. We currently store the scope’s focal length internally (we do not ask for it via ASCOM)

My source code should trap the error and use a default value but I’m not sure if I put that in before the version I posted. I’ll have a look.

All this does is adjust the pixel size. The image scale is fixed at 1.7 arc secs per pixel by the data.



I’ve also been following the ASCOM-Talk thread regarding this driver. I downloaded the new version of the driver and it solves the crashing problem when using EQMOD. That’s as far as I got in my testing; I’ll try to find time to test further and see how reliable the downloads are. I live in The Middle of Nowhere where internet service consists of wireless broadband at about 2-3 Mb if I’m lucky – it should be an interesting test.


It will be interesting to see how well it works. I’m finding that once
you start trying to get multiple images of the same area the data
collection fails. This is what the SGP frame and focus will do.

I’m tempted to see if keeping the last image and only getting a new one if it’s significantly different will help.


Greetings Chris.

I am interested in trying out the simulator in question, but can’t seem to be able to find it in the Files section of the mentioned group on Yahoo. Could you please suggest where I can download it?

I am using a modified version of the EM-200 mount with motor drives replaced. The problem is that the original driver was not ASCOM-compatible, and at this point I want to verify that the custom ASCOM driver that I found online can accept sync commands from SGP.

I guess I could use either of the free ASCOM-compatible planetarium programs, and I will unless your simulator is available, but it would be more reassuring to send the sync command from SGP.

Thank you,

I decided to withdraw this driver because I found that the image download process wasn’t reliable, especially if using it for multiple images of the same area of sky in quick succession. An unreliable simulator isn’t a lot of use and would be a support nightmare.

Understood, thank you for the reply.

I was wondering why the ASCOM Camera V2 Simulator kept returning the pure black image regardless of what I’d select for it to use and thought it was limited to some specific data types, but in the end couldn’t get it output any predefined photo.

Ended up installing Cartes and verifying the Sync functionality from there.