So now I’m running more automated sessions with Voyager I wanted a way to change the gain of my ASI1600MM-Cool between LRGB and narrowband sequences.
This is a quick test:
It is an AutoHotKey script, a VBS script to launch the ASI Setup dialog, and a BAT file you can call as an external script to change the camera settings.
The AHK script accepts parameters like:
gain=200 offset=50 usb=90
You have to give at least one.
There is some sanity checking but I’m more releasing this as a proof of concept and USE AT YOUR OWN RISK obviously!
The main weakness as I see it is the control widgets in the ASI Setup dialog don’t have nice labels to use to select them so it is all by X/Y offsets within the dialog box. So if the dialog ever changes, etc the widgets won’t be found and it will fail.
I’m hoping a better AHK scripter than me can make it more foolproof.
thanks for posting … the CMOS i have to test is coming back two days after i received the thread for telescope and i cannot test it. So now im stopped in this task.
But you tell me that you can open 2 instance of ascom camera to ASI ? … or you disconnect equipment in Voyager ?
My way is to ask to ASI to allow using of commandblind ASCOM to set offset and gain but they doesn’t ear me and i dont have source of driver … other way is to disconnect in ascom call a API method from SDK and reconnect ASCOM inside Voyager. If you can write a little DLL to setgain and setoffset using SDK ASI that i can call from DOT.NET i can add this feature in Voyager.
Thanks again for your work
This is a good question about if the ASI camera driver can properly act as a hub (multiple clients) or not. I think we’d need official confirmation from ASI. I can try sending Sam @ ZWO an email.
My experience is if interleave the ASCOM access between the clients to not collide it works but this is clearly not something you want to rely on.
My solution is obviously not something I would recommend for serious use - I was just curious and wanted to learn more about AHK.
I am also not sure about SDK access while the ASCOM interface is connected but inactive. I played with using Sharpcap via SDK access to change values and it seemed to work but I really don’t know if the ASCOM and SDK access share a similar internal pipeline that is properly coded to handle multiple command streams. My intuition with drivers from these low end devices is not to assume it.
If you know Sam @ZWO please ask if they can implement a simple CommandBlind or CommandBool or CommandString in ASCOm driver to setup gain, offset and USB … in the SDK is really simple. Just add this to driver and game is done.
I did just send him an email asking about the use case we’re looking at and if we could do something like your suggestion above.
Your idea with CommandString/etc is interesting. I wonder why they never went that route.
I’ll send another email!
Very interesting Mike. This would be a real bonus for me along with having those values in the fits header.
I’ve raised a topic on the ZWO forum, hopefully it’ll add some traction to your email. There is also a Python interface to the SDK which looks very simple to use but I’m not sure how easy that would be to integrate into a dot net call.
I’ll look for the python interface that would be much nicer.
Python isn’t too hard to get going these days under Windows using the Anaconda distribution. I think python is finding use in the big data/analytics community these days (something called ‘panda’) and so getting it to run on Windows has become a priority.
You pretty much install Anaconda and then can make a .BAT file to launch any Python script from the Windows side fairly trivially.
The advantage is professional scientists and astronomers have been writing lots of code modules for Python to handle all kinds of astronomical problems. To solve many problems you usually just write some glue code to put these together.
Also I can make the code cross-platform and work with Linux/INDI fairly easily as well.
Sorry a bit late with this reply but this is what ZWO had in reply to my request to incorporate those controls in their ascom interface:
Not sure what you mean.
Do you mean you want to control the gain in the way you control the exposure? For the current, ASCOM do not have this interface, so for the gain and the offset control, you need to call our dialog to set it. When you call our dialog, there is no need to disconnect the camera.
Edit: I might give Iron Python a go if I get time as it is built to interface directly to dot net.
I’ve been working on an automation package in python for my imaging needs and I’ve successfully used:
to change the gain on my ASI1600MM. You can’t control the offset but I leave that set at 50 all the time anyways I don’t see a reason to change it for normal DSO operation.
Interesting that Chad at ZWO doesn’t think ASCOM supports Gain, but there it is in the link Michael provided.
Maybe you can send that link to him, Robert, since you are in touch with him on this topic?
FWIW I got that link from a developer at ZWO when I asked about changing camera gain programmatically.
Ok … an ASI071 incoming to my house for test of 2/3 months… i’ll write a driver if ASCOM doesn’t work.
Sounds like we need to get the right hand at ZWO talking to the left hand !
I posed another question or two on the ZWO forum but I suspect that they just haven’t implemented that particular property - we’ll see.
Leo, that’s great news. I hope you can get something sorted out quickly and without too much trouble.
I think 2 weeks needed for having camera. Now i restart to coding in Voyager after Viewer … just take 2/3 days of relax. I can prepare driver based on paper and see what happen when camera arrive.
All the best
When I exercised the interface with my automation python code the gain did change programmatically but I haven’t take any images yet to verify it actually changed in the camera.