Problem with Filter Wheel


Hi all

I am currently trying out SGP after having used MaximDL (successfully) for quite some time. Just playing around with the software I have to say it looks really really good.
But, I have a problem with my filter wheel and general equipment connection.
My camera is a Moravian G4-16000 with 7 Position Filter wheel. The wheel is connected to the Camera.
I have installed all ASCOM drivers from the Moravian Webpage.

Connecting to the Camera, setting Temperature etc works fine, but the filter wheel just doesn’t want to do anything. I have two problems with that:
-If I choose the filter wheel from the dropdown and hit connect, sometimes it works fine, sometimes it tells me that no camera can be found. I then have to restart SGP to get it to connect. This also happens if I connect, disconnect, and then connect the camera again. Does not work without restarting SGP.

-Bringing up the control panel after the wheel is connected, clicking the “Filters” tab and choosing anything in the “Set filter position” does not make the filterwheel move after hitting “Set”. It just doesn’t want to move, no matter what I do. I also tried running a sequence with different filter settings, but the wheel does not move.

Anybody using a Moravian Setup as well that can help with the settings for this equipment? Or maybe someone can provide a hint on where to start troubleshooting?


Moravian CCD cooling percentage shown?

After playing around with this some more, I got it to work partially. After reinstalling the ASCOM Drivers, the filtes are now moving. But they only move once the image integration starts. Setting a filter delay does not do anything, the filter only changes position once the integration starts. Not really what I’d like…
Any ideas on this?



You will need to petition your ASCOM drivers author to change this behavior. SGPro cannot influence this behavior.


Thanks for the information Ken. That’s too bad though. I’ve contacted Moravian, let’s see what they have to say (if anything at all). I can’t believe that I am the only one having this problem though.

Best regards


You aren’t. Every Moravian user complains about the same issue.


Well that’s too bad then…
Is this because Moravian doesn’t stick to standards?


I am not sure. It’s not really my place to speak for Moravian. They may have reasons for their design (hardware specific)… I just don’t know enough about their cameras to comment specifically. I am not sure if it is a standard or not… when people ask to move the filter, they expect a response from the filter wheel. This does not happen with Moravian cameras… the filter is just marked internally as the filter to use for the next exposure (but does not move) and it causes confusion (at least with our users). So either they just figure there is no point in moving the filter until you start an exposure (because what else are filters good for?) or there is a hardware constraint that enforces this behavior at the software level. It has been this way for years so I don’t suspect it will change anytime soon.


Thanks for the info. I don’t think there’s a hardware constraint or something alike, as changing filters in MaximDL works just fine. Granted that doesn’t use ASCOM but a dedicated driver, but if it’s possible to do there I do not see a reason the same shouldn’t be possible thru ASCOM.


From a quick look through their ASCOM driver sources it’s clear that the filter wheel is only physically moved as part of the StartExposure call to the camera.

I guess this will pass Conform because the filter wheel driver reports the position the wheel will be moved to when an exposure is started rather than the position it is actually at - an approach that I last saw in the Mikado.

The only reason that I can think of for why it’s done this way is to stop someone changing filter positions during an exposure.

This can only be changed by Moravian. It’s their driver and it’s up to them. It seems strictly speaking to comply with the standards, just a strange way to do it. Even if they have a reason not to change this something in the documentation to let people know would be a Good Idea.



Alright I heard back from Moravian. Basically this is only a display problem.

As Chris pointed out, the filter is only moved on StartExposure instead of on the SetFilter event.
Moravian’s explanation (with permission from Mr. Pavel Cagas):
“This behavior was kind of a solution of the fact that camera driver and
filter wheel driver are two separate ASCOM drivers and some software
packages access these drivers asynchronously from separate threads. But
because the filter wheel is integrated into our camera driver, the
underlying software layer is common for both ASCOM Camera and ASCOM
Filter Wheel drivers. To avoid unnecessary and possibly time-consuming
synchronization to ensure mutually exclusive access (e.g. all camera
commands have to wait until the set filter command finishes), filter
wheel driver only stores position and camera driver sets proper filter
before exposure.”

This means that:
When SGP shows that the exposure is complete, the camera is still integration for ever how long it took for the Filterwheel to move to the desired location.
So while not “pretty” to look at, at least the camera isn’t starting the exposure before the filter is actually in place.


I’d have implemented that using the ASCOM LocalServer model. This has a single LocalServer process that handles all the communication with the hardware for multiple ASCOM drivers. All the synchronisation is done in the LocalServer. It’s got the additional advantage that it can operate across the 32/64 bit boundary so 64 bit applications can operate with 32 bit drivers and vice versa. Not sure what Moravian will do if someone has a 64 bit camera control application and a 32 bit filter wheel application.



Hi Pogo,

only to be sure, I have understood you correctly: The integration isn’t affected by the filter wheel behavior - but only the progress bar display of SGPro (showing that the camera is integrating, while in reality a filter change takes place)?

As the “Filter Change Delay” setting for Moravian only delays the start of the “Integration” (which means: starting of the filter change - and only if that is finsihed the start of the integration) this setting is for Moravian users worthless - is that correct?

Thank you very much for clarification

Best regards



Hi Reinhard

Yes correct, the Progress Bar will show that integration is ongoing, while the camera is changing filters, and SGP will show that integration is complete while it is still ongoing for the time it took to switch to the filter requested.

Correct too, from my understanding. As the filter is only changed once the camera is commanded to integrate, there’s not much sense in setting a delay after a filter change.

Best regards


Since I’m looking in to getting a Moravian external filter wheel, has anything changed with this? It is a bit of a pain if the filter wheel will only move with the start of an exposure.
At a critical level, do things like the flat calibration wizard process move the filter wheel properly?


This is Moravian’s implementation. There is nothing we can do about it. To resolve Moravian will have to change how their driver is implemented. However, I can’t really see this as being an issue, other than the progress bar and image capture time being off.



Yeah I understand it’s Moravian’s issue; I was just wondering if anyone here knew if Moravian had changed anything.

So basically the only “problems” are the progress bar isn’t quite accurate, the camera image download time is off, and I can’t manually move the filter position from SGP module (it has to be part of a running sequence or flats calibration etc)?


You can manually move the filter wheel, iit just won’t actually move until you trigger a frame.



Does that include triggering a “frame and focus” frame? If so that’s not a big deal at all then.


Yes, FF would trigger the filter change.