I’m curious if there is a plan to provide a 64-bit version of SGPro? I’ve recently acquired a QHY600M and, due to file size (120MB per file), I often am running into “OutOfMemory” errors on SGP when running with this camera (I was able to take about 30 - 45 dark frames before the camera stopped saving images…similarly, PS2 ran into an “overflow error” when attempting to solve). These issues don’t appear when using 64-bit software, which is QHY’s recommendation when using that camera.
I would love to be able to integrate the camera via SGPro, so I’m curious if a 64-bit version would be considered for development.
I don’t think a 64bit version of SGP would be hard to do, but the problem is the lack of 64bit drivers for a lot of hardware, i don’t think i’ve seen 64 bit drivers for anything other than cameras.
SGPro is compatible with with both 32 and 64 bit machines… it is “Large Address Aware” and capable of mapping areas of memory far larger than even the biggest images. SGPro is what is called a “managed application”… it means that SGPro does not need to be compiled in 2 different ways. When we see this message, it is usually issued by the ASCOM driver and SGPro is just relaying it. It doesn’t typically mean you are out of memory, rather that the driver cannot find a contiguous spot in memory to put the new image into.
This typically means that there is a memory leak somewhere. Either in SGPro or in the camera driver. We can run some tests that fake creating these very large images. Would you mind posting one of your darks on Dropbox or similar? I can use that to fake a large format camera.
What version of SGPro are you running?
You are not attempting to display every dark frame in its own tab right? Sometimes this setting gets accidentally toggled.
Does the sequence contain a large number of targets?
@Xplode that is true, 64-but drivers are harder to come by. I have had success running another 64-bit program using the Astro-Physics V2 driver and the Pegasus driver. All worked really well, but I haven’t tried any other drivers or equipment.
@Ken interesting to know regarding it being “Large Address Aware.” I assumed the issue was the bit depth because of the memory issues in 32-but programs addressed in QHY’s documentation…but I admit this is somewhat out of my depth of knowledge.
Regarding the dark frames, I actually ran using SGP last night and had the same issue with the light frames (I captured 29 before the failure to write image/out of memory error occurred). Restarting SGP solved the issue and allowed for me to continue imaging for the rest of the night.
I am not displaying each frame in its individual tab…I let it only display one tab. I have log files from the imaging run last night which I’ll post here for everyone later today (I’m away from my machine right now, but will be back this afternoon). I can also load up a dark and a light frame for your reference to test the issues.
@Ken Sorry for the delay on this! First, here are the log files from my session last night (two logs because I reset SGP mid-way through to solve the file saving issue):
Second, here is a light frame from that session. Let me know if you need others!
@lucam absolutely! Note that I’m still working out the spacing on my system a little bit, so the far corner stars are a little misshapen. Also, there is a large reflection that I’m working out that appears to be coming from the filter…it is calibrating out, so you have to just kinda look past it
I’m doing some tests with a 60MP image using the ASCOM simulator. So far everything with SGP is working well. I’m 108 images in (just images, no auto focus, dithering, etc). SGP is ranging between about 800mb and 1.7gb of memory used.
I’d be interested to see what the memory consumption range looks like when using the actual QHY ASCOM driver. I’ll also do some tests with my QHY128 to see how the driver handles the memory footprint. But so far seems like SGP is handling things just fine.
@Jared that’s great to know! I saw on the Windows SDK on the QHY tab that there was a memory leak found in the SDK (https://www.qhyccd.com/index.php?m=content&c=index&a=show&catid=127&id=162). I don’t know enough to know how the SDK works with the ASCOM driver, but I’m wondering that could be the cause of the failure? It does appear they have a fix for it…once that is released, I’m wondering if that will solve it? I’ll keep an eye on it and download the updates as they have them…
I also have the QHY600 camera now, and am testing it prior to mounting in the observatory.
I’m having an issue where I can connect to the camera in SGP via the QHYCCD Cameras Capture setting when I install the main driver package. However, when I install the SDK qhyccd.dll file in the /common files/ascom/camera folder as instructed SGP throws and error message when I attempt to connect - either via the setup button, or main connect.
I’ve been in touch with Robin Lee at Cyclops Optics and Dr Qui about this and they don’t have a solution. Since this camera is so new the SDK and drivers are evolving rapidly so being able to use the most up to date dll is crucial.
@flywaldo, you’ll need to use the 32bit version of the DLL with SGP for now. Hopefully QHY can change their drivers to be able to detect which version of the driver to load (like ZWO does) but until then you’ll need to copy the 32bit qhyccd.dll into C:\Program Files (x86)\Common Files\ASCOM\Camera
Also make sure you use the DLLs from the link above:
I discovered this solution on my own before reading your explanation just now.
I did this and it works fine now in SGP. But now NINA doesn’t work since it is 64 bit. I renamed the qhyccd.dll to qhyccd2.dll and put it in the /camera folder and NINA now works with the 64 bit dll.
Here’s to hoping that QHY works out these driver issues. I’m very excited about the QHY600 but am working through some issues with Dr Qui now with the drivers.
I have just got a QHY600L and am finding that downloads take around 15 seconds on SGP with the ASCOM driver. Will the 64bit version improve this figure, I understand that people using NINA with the native driver get much faster downloads? Also, roughly how far away is 64bit SGP , are we talking weeks or months?
