Hi all, up to this point i have only used a osc camera on my 14" hyperstar as the thought of filter draw and flats on filter changing have put me off mono with this setup… but…I have modified 2 zwo mini filter wheels and fixed them together for use on my hyperstar. My thought is I can leave slot 1 empty on both wheels so they can look through each other then I have 8 spare slots for rgb and narrowband filters.
I have managed to get both wheels within 15mm of the camera sensor so dont think i will have much of a vignetting issue. The Zwo ascom driver allows 2 instances of filter wheels to be connected but I’m not sure if its possible to set a sequence that can use both wheels automatically without having to manually change the filter wheel that sgp is connected to?
Hope my crazy idea makes sense, I’m not sure if i may need to learn how to write a new ascom driver or if sgp can handle 2 wheels. Any help is much appreciated.
For sure you will need to write a driver that can interpret both units as a single CFW. No astro software out there (that I am aware of) allows for multiple filterwheel setups. Luckily, filterwheel drivers are one of the easier drivers (easy assuming you know the underlying protocols for the CFW)
Good evening Ken and thanks for the reply, you have saved me so much time diagnosing I require a new driver. I’m not bad with electronics and the hardware side of things but I can see my future lies with basic efw protocol!
It’s about time I attempt the software side.
Wish me luck.
There’s a commercial filter wheel which does this, two wheels in one housing. It’s an amazing piece of kit, expecially as it uses 2" filters and is collosal.
But doing something like you describe, having one empty filter position in at least one wheel, should be possible.
The ASCOM filterwheel template is the place to start, you set up two connections to two different wheels and configure them as one wheel. The configuration will be fun but I don’t see any fundamental problem as long as you can instantiate the two wheels together.
Hi Chris thanks for confirming its at least possible. I have installed all the developer tools and visual basic today but to be honest I all I have achieved is one of those really painful headaches right above the eyes! The only programming I have done is uploading someone else’s sketch to an arduino but I am going to stick at it and try to create a driver.
It says in all the docs that modifying existing drivers is asking for trouble but as zwo’s driver already supports 2 wheels do you think that could be changed to suit? or is it even possible to change zwo’s driver?
That question probably answers the level of my software knowledge if you were wondering!
Thanks again for giving me a starting point with the template. I’ve joined the Ascom talk group to see if I can get some more tips. The filter wheel is done and its tiny to say its a 10 position.
The reason that we say not to modify an existing driver is becaue there are identifying codes - GUIDS - which are generated when a new driver is started that identifies it. Using the same code doesn’t change these so there’s confusion between the original and new drivers.
Starting a new driver and doing a load of copy and paste of individual functions should be OK.
The existing code probably implements two separate wheels, each driver will only handle one. It’s a good start to begin by implementing a single wheel driver and then adding a second one. If you have the ZWO sources that should help.
Hope that helps but take my estimates of what’s easy with a pinch of salt. I’ve been playing with computers for over 50 years and may hae a distorted view of what is easy.
Getting a Bluetooth serial connection to work on a Raspberry Pi isn’t
All I have is 35 years experience of the internal combustion engine. The mechanical side is little changed but the ecu’s and CAN networking is beyond the scope of an 80’s mechanic. Is there any additional reading you could sudgest or a possible mentor that wouldn’t mind a new student!
How about making a filter wheel hub that would connect to 2 filter wheel drivers?
This would allow other people to use the same hub with 2 filter wheels from a different producer.
The hub could have “virtual” filter positions that you could set by combining filter from each filter wheel.
until you have your new ASCOM driver ready, you could use two instances of SGP. This is a half automated solution, but it is possible to do it remotely. One SGP instance for your camera and the ‚active‘ FW. Another SGP instance for the second (transparent) FW. Then you have to change the FWs in your SGP instances.
Thanks guys for all the replies, I’ve spent all afternoon investigating all the suggestions. I downloaded zwo’s efw developer sdk for the wheels to look at.
Thanks tri for the dual instance option but I can still only image with one wheel at a time even though zwo’s ascom driver allows 2 wheels to be connected.
I’ve done a bit of research on making a filter wheel hub Xplode but that also looks a huge project.
Hi Ken. The more research I do the more people I find have asked for this feature.
Since this has taken over my life now I have found that MaxIm has supported this exact and I mean exact feature since 2010. There are lots of “you could write a driver” answers but it seems it’s already been done. Doesn’t help here though.
Would this ever be considered for the feature list ( I know it the wrong place to ask)? I am confident others would benefit.
If I’m being completely honest, it’s pretty unlikely that we’d implement support for this in SGP. The use cases for this are unfortunately pretty low. Also the setup would also likely be optically difficult as you’d get a decent amount of focus shift between the two filter wheels. Not to mention you’d need large enough filters so that you don’t vignette. So while it’s physically possible I don’t think it’s the best direction to take SGP. The main reason is that we just don’t support more than one filter wheel at the moment. So it’s not just combining the filters from 2 filterwheels but also adding support and UI for another filterwheel altogether.
However, as has been mentioned, filter wheel drivers are not all that complex and it wouldn’t take much effort to create an ASCOM driver that utilized 2 or more other ASCOM drivers and combined them into a ASCOM driver that exposed the combined set of filters.
Hi Jared thanks for the explanation. I understand you can’t make the software bespoke for individual users but it was worth asking
Sgp is by far the best Astro software I wouldn’t use anything else.
Cheers to everybody for their help.
The best option may be a generic dual filter wheel driver that selects and connects to two filter wheels and combines them into one. This would work with any two filter wheels of the same type or different.
It could be easier to develop although still not trivial. At least it should be easier to test because at least one wheel could be a simulator.
The down side is that the filter names and offsets would need to be set using the individual wheel drivers but the dual driver setup could help with that.
That appears to be just how the maxim driver works, it states both filter wheels have to be set up first for direct control without it. Then connect through the dual driver.
Thanks for the pointers Chris I appreciate your knowledge. I’m buried in google like Johnny 5… input…input.
Chris, top job the driver works like a dream. Installed and setup perfectly with no issues. Great interface to chose the wheels. I imported the filter settings to Sgp and can control both wheels flawlessly.
I thought I may have to put an extra filter swap into my capture plan to get the unused wheel back to the empty position but your driver even takes care of that too, returning one wheel as the other moves to the selected filter.
Simply brilliant, like I said before I can’t say how much I appreciate it. on me do you have anyway I can make a donation?
Thanks, Good to hear that it’s working. I can think of a few things that need fixing, such as disabling choosing itself as a wheel, maybe more error reporting and tidying up the name and version data.
It skips the first position on the second wheel because that’s reserved as the open position when the first wheel is being used.
I’m impressed by your dual wheel. Is it two wheels with one side plate removed from each and bolted together back to back?
Hi Chris, I have milled one wheel casing down and moved the other carousel/motor and ir sensor out so they are both as close to the camera as poss. I even sank the holes in the carousels so once the 31mm unmounted filters are fitted then the securing screws are flush, I can then squeeze them even closer to the camera.
The whole assembly is only 27mm thick (but could be another 7mm thinner if I machine the rear housing as well)
As I’m going to use it on my hyperstar I removed the usb “b” connectors as these plug straight out of the side of the wheels. I hard wired usb leads out of the back to connect straight into the hub of my zwo1600
I think once ZWO get wind of this it will go straight into production!!
The driver works great so I can’t say anything needs changing. It did take a couple of attempts to connect to wheel 2 but I was confused which wheel I was choosing. In the zwo driver the wheels show as 0 and 1 but I think in the dual chooser they were 2_2. I think I had to choose 2_2 for both “A and “B” but then pick 0 for “A” and 1 for “B” in properties if that makes sense? I’m not really sure on that though I will have to re try and take more notice.
Still pretty speechless you wrote the driver. A couple of days ago I was quoted between £2000 and £6000 on the ascom developer group. To be honest that also rendered me speechless
on me do you have anyway I can make a donation?