I am using all the latest ZWO drivers - I have both the base native and the ASCOM drivers installed and SGP is able to use them just fine.
Are you able to test / use the camera and f/w combo using the ASI capture s/w?
And do you also have a ZWO guide camera connected? SGP (and PHD2) can sometimes get confused which camera is which…
Some of the more recent ZWO ASCOM drivers have been problematic and have regressed where offset is concerned. Offset was working in one and then it stopped…or they removed support for it, I’m not 100% sure but it seems their newer drivers aren’t supporting offset. I would assume their newer drivers are what you want to use but it may mean not having access to the offset inside of SGP.
However I’d assume you need to use the newer drivers in order to access newer functionality like filter wheels and such.
Not really confused…just that their driver is unified so there’s no good way for us to actually know what camera is connected to which driver.
Jared
Hi Steve, which ZWO camera are you using ? I’m not using a guide camera, I’ve just been trying to take some flats using a sequence. Figured if I can’t do the simplest of tasks with SG pro there is no point moving forward. In the ZWO site they said they would talk to SG but not sure if this has happened. As Jared said there is no offset data with the latest driver, I have a pixinisght script and it checks the fits header for the offset value, I use different gain and offset for narrow band data.
When I had both zwo native and latest ASCOM driver on my pc all pixels went black. Took some time to reset everything, so currently only have old zwo ASCOM driver loaded on a fresh install. I used a Mac with sky x but switched to windows for the 10 micron mount. Will probably have to purchase sky x multi-license to use their software on a windows machine. Software support from sky x was very poor, was hoping SG would be better.
I’m using a 6200MM for main cam and an ASI 290MM as my guide cam.
So does everything work using ASIStudio / ASIImg app?
When I had both zwo native and latest ASCOM driver on my pc all pixels went black
And to be clear, you need the native drivers to use the camera at all. And if you want to use the ASCOM interface then you need the ASCOM drivers installed on top of the native drivers.
That’s good, we have the same camera. Can I ask if you see the camera offset value in the fits header ?
I believe I originally had the same driver setup as yourself, but I am currently seeing a picture without the ZWO native driver installed ! Just worried that if I install it I will see black pixels again.
If you do see the offset value in the image file then I will try again. I’m a long time Mac user and windows, ASCOM and drivers are new and somewhat confusing to me. I did not try the ASIStudio because I assumed it needed the native driver, but will also give it a try if you are seeing offset values. Thanks for you help on this.
See the following threads: Unable to set Offset in event settings via ASCOM (ASI 2600MM Pro) and SG pro not showing ZWO ASi6200 offset value .
Bernd
Just checked and confirmed that I don’t see the offset value in the fits headers, and again this is using the latest ZWO drivers (both native and ASCOM)
I am currently seeing a picture without the ZWO native driver installed
Not sure I understand how this would be possible: My understanding is that you must have the native drivers installed to use / access the camera. Yo can then choose to install the ASCOM drivers on top of the native drivers if you want. Without the native drivers though, the camera will not work.
Confirmed with latest ZWO ASCOM driver that the camera and filter work together ok but the fits header is missing offset. ZWO native driver still shows all 0 value pixels.
What is SDP’s position on this ? SDP chose not to support ZWO native driver and ASCOM Driver gives incomplete fits header information. SDP shows ZWO logo on list of compatible equipment, so either this issue should be fixed or at least a warning should be given that full zwo support is not provided.
I’m new to SDP so I’m not familiar with typical support level, so will this be addressed or does one need to look else where for those who support native drivers. I just tried a free trial of Voyager, they seem to advertise themselves on the robustness of their software, the ZWO camera and filter wheel connected first time, and the fits header shows correct data ! SKY X also works without problem, so this suggests a SGP issue rather than a ZWO issue.
Did you ever read the two threads that I linked above? There is a possible solution: use the older ZWO ASCOM camera driver v6.5.1.5.
Bernd
Yes, the older driver it worked fine, but the camera and 7 position filter wheel would not work together in a sequence. Typically they would both show as disconnected after a filter change. Camera and filter wheel only worked together with latest driver.
Best I can suggest is posting on ZWO’s forum about why the Offset implementation regressed in their newer ASCOM drivers. They initially had it working and something happened in newer drivers and it no longer works (as you’ve seen).
There isn’t much for us to do here unfortunately unless we were to go back to the native drivers and those had a lot of issues when we initially did the implementation which is why we pulled support for them. They may be better now.
Jared
Since other software providers use the native drivers without any issues your reason to exclude zwo does not seem logical to me. I would have thought given the large range of equipment you need to connect with, your goal would be to offer your customers the most connection options not the least. Refusing to use a popular camera’s native drivers is certainly a unique marketing strategy. It might make life easier for SG, but normally making life easier for your customers is the higher goal ?
When there is a viable ASCOM option that’s our preference…as it should be for everyone. ASCOM forces the manufactures to create good and viable drivers that are IMMEDIATELY usable by every platform out there. They release a new camera, they update the ASCOM driver, customer installs it…bam, immediate support.
Now if you take the “native” approach it’s quite different. New camera comes out, every platform that supports it has to update to the native drivers, likely needs an actual camera for testing, could take days or months to support new camera.
Windows realized that native driver support was a deal breaker back in the mid 90s. Just think if you had to update your windows version to support your new camera or printer. That’s basically what native driver support is, it requires the client software to update constantly at a pretty significant cost.
So what is actually best for our (shared) customers is not native drivers but is ASCOM, which is why we push so hard for ASCOM support from vendors. It means that the people that create the hardware also create the drivers and the interface layer for their hardware…and because they created the hardware and the drivers they’re best equipped to do this and create the best experience for our customers. We only have native support where viable ASCOM drivers do not exist.
We want to offer our customers the best connection option not multiple options that are confusing to them.
Jared
Every company is entitled to its competitive strategy, your strategy means my camera and filter wheel is not supported. Since this seems to be a long ongoing issue why do you not have a comment next to your ZWO logo in your supported equipment page that you are unable to fully support certain ZWO cameras ?
I would have thought a more responsive comment would have been ‘we are having ongoing technical discussions with zwo to resolve this issue as soon as possible to minimize our customer disruption’ rather than “nothing to do we me”.
I can work around this issue but I am disappointed and I am concerned your approach to solving issues might lack flexibility and initiative.
Sorry, should say “nothing to do with me”
Because SGP does fully support ZWO cameras. Lots of people, including myself, have been using several ZWO cameras without issue. Just because the current ZWO ASCOM driver doesn’t implement a feature properly doesn’t mean that a client application (SGP in this case) “doesn’t support the camera.” For the record, I’m using an ASI6200MM, ASI2600MC and ASI174mini, all at the same time, each camera with a filter wheel, and using the latest drivers for everything.
Don’t get me wrong, I feel your pain regarding the lack of offset in the FITS header. Like you I use PixInsight Keywords for lots of things and it has proven to be a bit of an annoyance. But again, this needs to be fixed in the ASCOM driver.
Going back to your first post, is the camera filter wheel working properly now? It really sounded like a USB communication/connection issue to me.
Hi Joel, yes it works fine with the latest driver, it works fine with the old driver when manually issuing a filter change, but frequently fails when used in a sequence.
I decided to update my mount so I changed from a paramount to a 10 micron. The sky x software just looks and feels dated so I thought I would take the opportunity to change. I write my own macros in pixinsight and often group images using camera fits data. I will look at others before deciding since I want to pick a supplier that is responsive to issues, I know connection problems are frequent given the vast range of equipment. I do know my equipment is fully functional with the native zwo driver and I wished I had realized SG Pro does not support zwo native drivers.
I use a ZWO ASI26000 MM Pro camera with SGP. The ZWO ASCOM driver has two problems wrt SGP: 1) The offset does not work, so I fix it in the ZWO ASCOM driver settings, and 2) The gain is limited by ZWO to 100, which is very problematic.
ZWO refuses to change the gain limit. I do not know if the 6200 suffers from the same problem.
I am asking Ken and Jared to again reconsider adding support for the ZWO native driver. It works well with SharpCap Pro 4, so maybe ZWO has stabilized their native drivers.
Mark W
Just adding my two cents…in my opinion the only reason to go above gain 100 is if you are doing EAA or planetary imaging, in which case you probably don’t want to use SGP anyway. Other than that, there is no reason to go above gain 100 because that’s the magic number where the read noise drops while still keeping high full well capacity. If you go over 100 all you are doing is decreasing the well capacity and not gaining any improvement with read noise.
Joel,
I increase the gain for plate solving and focusing to reduce exposure time. Also, If I am imaging RGB just to get star colors, I can push the gain and sacrifice full well depth/dynamic range. I usually image with gain 100 to get into the high dynamic range mode of the camera, but sometimes there are some targets where I can use higher gains as well.
Mark