Dear Folks, happy to have the 3.0v, with the native support for ZWO cameras. I have been testing the driver and seems to work (of course some suggestions about parameters etc… would come), but I found the download time of the images (arround 23sec using USB3, image history disabled) is still very high (even slightly better than with the ASCOM driver).
As with this kind of modern CMOS cameras the exposure times use to be short (usually few seconds) but you need to integrate many Subs (hundreds), the elapsed time during download is very relevant (you spend more time downloading than imaging…).
Not sure if this feature is something you are working on, but should be very important to be improved. I did some test with other imaging software using native support and the download times are really short (1-2 sec) in the same conditions.
There is something I am doing wrong or in fact the download times are arround 20-25sec? If this is the case should we expect some future improvements?
You are totally right, looking carefully the log, in my case the download time is 849ms, but the total time for a 5sec capture is 25sec (see the complete log for the capture below)…
There are certainly some areas that need performance improvements in SGP. It was primarily designed for CCD imaging where a few more seconds over a 20 minute frame don’t matter too much.
Having said that we will be making some performance improvements to speed up save and display. Hopefully in 3.0.
I’ve noticed the same thing. I routinely see ~750-800ms download using the native ASI driver in SGPv3 on a CS125 Compute Stick with my ASI1600MM-Pro.
For reference, I see much faster (near instant) download times in SharpCap, PHD2, or Firecapture with the same camera on the same computer.
As Jared mentioned, if I were only taking 20 minute exposures, it wouldn’t matter. But now that exposures are getting into the seconds, the download times are starting to add up.
I also welcome the native support; I’m just adding my voice and what I’ve seen.
Well until the SDK is updated to the latest version (which should be what SharpCap uses) we really should not compare the performance of the two native implementations.
The temperature settings seem to still be unstable. Not sure I mentioned this last time I talked about the native driver but it seems to read incorrectly. Anyhow, the replacement of the DLL did result in the camera operating better. I had consistent results with the native driver that I did with ASCOM, other than total imaging throughput. I did a set of 100 bias frames and they took 5 minutes in total to take. For CCD users, that would be awesome! But… for CMOS folks that is worse than you can get with ASCOM and worse than you can get with something like SharpCap with its native mode operation (which beats ASCOM hands down).
So the driver change is useful, but I think the implementation here still needs some work. To be fair to the SGP devs, they called this beta – although to be fair to the software development world, this is not a beta. This is more like an untested alpha.
Extremely interested in this thread. I’m using the ZWO 1600mm-cool version, sounds like you have the same or the OSC version maybe?
I also recently attempted to switch my imaging PC from an ASUS laptop to my old Microsoft Surface. Everything worked except that when I would try to download an image from the 1600 I would get a black image. Later I discovered that if I disconnected from the camera, swapped between the ASCOM driver and native ZWO Camera, reconnected, the first image taken would download. The next back to a black screen. Then rinse and repeat with disconnect / swap driver / reconnect and take one frame and focus and the first image would work and the next back to black.
I swapped back to using the ASUS laptop.
I originally assumed it was because of only having one USB port on the surface, that maybe the Orion StarShoot and the ZWO were not liking being on the same connection. Now I’m curious if it wasn’t maybe some kind of timeout.
I know should be difficult to say, but do you have any time frame in mind to improve it?
Yesterday I was imaging and just for 16min integration, it took more than 1 1/2 hours, which is a real pain… I makes almost impossible to image one RGB target in a single night.
I hope to firm things up with the native ZWO implementation over the NEAIC/NEAF time span since I’ll have some free-ish evenings. This will only really help with the offset and other configuration options and NOT the speed issues. Essentially adding a settings dialog for offset, no “gain per target” either. To resolve the speed issues is going to take a good deal more time and it’s more of an architectural issue with how data comes off of the camera at the moment.
Thanks Jared. I would love to get a pre-release to test with offset support. I am actually trying to troubleshoot an issue with the 183MM camera, and want to test Native vs ASCOM mode.