Failed Sensor Analysis of QSI 726

[richard_]

I tried multiple Sensor Analyses with my QSI 726 but I've had issues at the same point each time, which was during the gain measurements stage. The previous stages would run successfully, including the linearity measurements.

During the gain measurement state, at the low gain setting a banner would appear at the top of the screen with a message along the lines of "exposure time is too long, consider increasing the brightness". However, this is not possible as during the initial setup of Sensor Analysis I ensured I was hitting the ~65% brightness on the histogram with an exposure time close to 0.5s so I can't increase the brightness much further without dropping below the 0.5s recommendation. At about ~1 minute into the gain test, a dialog would appear with an alert saying that Sharpcap has crashed and will close after submitting the error report (you may have seen multiple error reports come in over night over various releases of Sharpcap, up to the most recent 64-bit release).

One issue I'm aware of is that QSI state a minimum exposure time of 1ms and the camera will crash if I set this too low (I learned this during setup of Sensor Analysis, where I accidentally set the exposure time to 0.5ms instead of 0.5s to get the histogram at ~65%). Also, the text output during the crash appears to be similar to post #9 in the below thread but without having it in front of me I can't be certain it's the same issue:
viewtopic.php?t=3858

Do you have any suggestions or is there any more information I can provide?

[admin]

Hi Richard,

thanks for taking the time to submit the bug reports - always helpful as I was able to find them and then access the log showing what happened up to the failure point.

There are two issues going on.

Firstly the failure to run the analysis looks as though it comes down to the ordering of the gain options in the QSI ASCOM driver. SharpCap expects the gain options to be in ascending order (lowest gain first), but the QSI gains are 'High, Medium, Low' in that order. This problem really only comes to light because the QSI Ascom driver has a list of gains rather than a more conventional (and useful) numerical gain range. Lists of gains are mostly used for things like DSLR cameras where the items are 'ISO100' , 'ISO200' etc.

With the current code there isn't going to be a workaround, since the analysis code wrongly assumes the first gain in the list is the lowest and proceeds based on that. The whole thing to do with exposure lengths then gets messed up , as you are guided to set the light level at the highest gain, but should be guided to do that at the lowest.

I will add a workaround to the ASCOM camera support to put the gain values in the right order for the next update - that should deal with that problem.


Secondly, the crash... In the logs I looked at, it seems to be related to SharpCap trying to cancel an exposure as part of the analysis process and then the state of the ASCOM driver not being as expected afterwards. SharpCap waits a couple of seconds at this point in the hope that the state of the camera updates to 'idle' after cancelling, but then tries triggering another frame in the hope that it works (after all, waiting for ever is no good). In this case, this attempted next frame fails and that error causes the crash, but the initial problem is the ASCOM driver not handling the cancellation of the frame properly.

Now, it's possible that once we get the gains in the right order, this bug will go too, as SharpCap will not need to make so many changes to the exposure during the analysis with the corrected gains. On the other hand, if it is a general problem with stopping/cancelling frames on the ASCOM driver, it may still crop up both in the analysis and in general usage of the camera. You could try switching SharpCap into 'Still Mode' rather than Live Mode - that may help as it reduces the number of reasons that might cause SharpCap to try to stop/cancel a frame that is already in progress.

cheers,

Robin

[richard_]

Thanks for the update Robin!

I will add a workaround to the ASCOM camera support to put the gain values in the right order for the next update - that should deal with that problem.

If I understand the settings correctly, when I choose low/medium/high, these come with preset gain and offset values which I don't believe I can change in software or in QSI's ASCOM driver interface (so a sensor analysis could possibly just report three gain levels rather than intervals of 10 etc.). However, there is a fourth gain mode in their dropdown menu, which is a custom mode (see page 12 of the manual, linked below):
https://qsimaging.com/wp-content/upload ... -Guide.pdf

In my version (ASCOM.QSI 1.1.0.4), when I select "Custom" gain mode and tick "Show settings on connect" I have freedom to change the following:

• Gain (change value)

• Offset (change value)

• Dew heater (check box, on/off)

As an adjunct, when I connect the camera to my image acquisition software (NINA) and select "Custom" gain mode, I can change the gain and offset within NINA instead of using QSI's ASCOM dialog box. Perhaps there's a way for you to do a similar approach in Sharpcap by accessing the "Custom" gain mode and when running the sensor analysis, Sharpcap can instruct the camera what gain/offset values to use during the analysis? Hopefully that makes sense

Let me know if there's any other information you need which will help.

[admin]

Hi Richard,

anything that happens inside the ASCOM setup dialog, or when connecting, is invisible to SharpCap (in the sense that SharpCap has no idea what was done in those places or even that the interaction occured in most cases). From SharpCap's point of view the gains seem to be just Low/Medium/High.

I suspect that NINA has direct SDK support for QSI cameras rather than going through the ASCOM driver, giving them full control over things like gain, etc. That's not something I'm able to add to SharpCap unless QSI want to provide a camera or two for development/testing purposes (I've tried to do that sort of thing without a camera to test with before, and it just doesn't work out).

cheers,

Robin

[richard_]

Hi Robin,

Thanks, I suspect NINA has a similar issue as Sharpcap as the gain/offset isn't always communicated between NINA, camera and the resultant FIT headers. I'll get in touch with QSI/Atik for support on this as it does feel it's ASCOM related.

In the meantime, is there anything I can support you with? I have the camera and I'm happy to share any details or test anything you would work on (even if you want to remote session?). Or is it a case of you needing the camera to be physically attached to your computer for developing code?

Cheers,
Richard

[admin]

Hi Richard,

it's really a case of needing a camera here that I can plug into my development machine, mess around with, test, unplug and reconnect when I break something. Working that way it takes me maybe 30 seconds to try a different approach when something doesn't work, and I can go round that loop dozens or hundreds of times in an afternoon to get things going. Having to work with someone testing remotely (no matter how keen) just isn't the same. Beyond that, if I don't have a camera here then I am stuck when someone reports in a month or so that it breaks if they do A then B then C.

cheers,

Robin

[richard_]

Hi Robin,

I totally understand and know where you're coming from, sometimes it's just easier to have everything in front of you!

I've raised a request to speak with QSI/Atik about the integration of the ASCOM driver with Sharpcap/NINA. I'd like the readout modes to be accessible by software and then changed within software to suit, not with the Custom option. I haven't seen the code so I'm not sure how to frame my request other than by way of example.

My previous camera (QHY268M) has a few different readout modes which can be selected within Sharpcap/NINA software and the gain/offset configured by the user. I was able to run a Sharpcap analysis using High Gain mode (readout 1 I think) and I even included some script to test at specific gain values close to HGC (eg 55, 56, 57). When using this camera in NINA, I can also select the readout mode and change gain/offset on the fly (even in the same image sequence if shooting LRGB then SHO which may require different settings). I can't do this with the QSI726. Other than asking "can you change the ASCOM driver to behave like the QHY268M when accessing readout modes and changing gain/offset within software", is there a better way of expressing this?

Cheers,
Richard

[admin]

Hi Richard,

unfortunately there isn't a good, standard, way for ASCOM drivers to make multiple read modes available to applications like SharpCap - the ASCOM standard just doesn't contain that concept, so the only option is really to have the read mode changeable in the ASCOM setup dialog. Unfortunately SharpCap (or any other software using the ASCOM driver) has no idea what choices have been made in that setup dialog, so doesn't know that there are multiple read modes, or which read mode is being used...

I must admit that I would think it would be useful to have at least the option of a numeric gain via the ASCOM driver (where the gain is a value between 0 and some maximum) - that can be detected by SharpCap and would offer more flexibility and easier control that the low/med/high/custom option.

By the way, try the new version of SharpCap uploaded yesterday - I added code that should put the gains into the correct order (Low/Medium/High) in the dropdown, which may also allow the sensor analysis to complete properly.

cheers,

Robin

[richard_]

Hi Robin,

OK thanks, I'll word appropriately to QSI in my response.

I downloaded and installed the latest 64-bit version (v4.1.13331) to my astro computer and tried connecting the camera. Unfortunately, as soon as the QSI.ASCOM dialog boxes shows up, Sharpcap crashes before I can even select a readout mode and I'm presented with a Sharpcap error log. I'm not able to type anything meaningful as Sharpcap and the dialog box close before I can finish typing, so I've only managed to hit "Save/Send" with no description, so please use this post as the description. See the screenshot below which shows the error. I noticed that there was a checkbox in the settings to automatically connect all hardware on connecting a camera (which wasn't ticked before) but unticking this box still results in the crash.

Screenshot 2025-05-20 184814.png (395.52 KiB) Viewed 3701 times

As an aside, here's what I see on my end when physically connecting camera to NINA (can't recreate in Sharpcap due to the above issue sorry) as you may not see the extra dialog boxes unless you physically have a camera connected.

1. Clicking a setup/config button

Screenshot 2025-05-20 185255.png (679.13 KiB) Viewed 3701 times

2. After a short delay, camera is connected and I can choose a readout mode (High, Low, Custom or Medium)

Screenshot 2025-05-20 185317.png (650.59 KiB) Viewed 3701 times

3. If I select Custom, I can then set Gain and Offset values manually. Then I tick "show settings on connect" and click OK

Screenshot 2025-05-20 185326.png (667.44 KiB) Viewed 3701 times

4. Here is how it looks when I connect in NINA. There is a floating ASCOM dialog box showing the readout mode and the ability to change Gain and Offset on the go.

Screenshot 2025-05-20 185403.png (274.14 KiB) Viewed 3701 times

[admin]

Hi,

sorry about the crash - that one crept in while I was trying to deal with a seemingly unrelated feature elsewhere. It's now fixed in a new version that is available to download.

I think that the extra window for the offset/gain is coming from the ASCOM driver - not quite sure why it would show in NINA but not SharpCap though. It looks like I have missed out on a couple of things that I could implement for ASCOM cameras, so I will revisit those and try to add in the ability to see the offset and read modes via ASCOM.

cheers,

Robin