Bug in SGP's Handling of Filter Wheel Errors

Last night I believe I found a bug in SGP’s handling of errors related to the filter wheel.

I photographed a series on a target in Ha, OIII, and SII. When I looked at the data, it appears all the subs were actually all Ha, even though 2/3 of the subs were named OIII or SII. Looking at the SGP log files didn’t show anything amiss. It logged that it moved the filter wheel to the various filters, though clearly nothing happened when trying to set OIII or SII.

I eventually figured out the issue. I had just updated the drivers for my QHY268M camera. Apparently installing the new drivers reset the configure for my filter wheel to a default of 5 filter positions as opposed to 7 in my original configuration. So it seems that when SGP told the filter wheel to move to the position for OIII or SII, those operations failed because the filter wheel was configured for 5 filters, and the OIII and SII filters were removed.

Now what I’d expect is that SGP would detect that there was a problem with changing the filter wheel position to an invalid position, but it just merrily continued on as nothing happened. I confirmed that QHY ASCOM driver does indeed throw a InvalidValueException when told to set a position to a value that isn’t configured. So it seems that SGP doesn’t look at the error returns when setting filter position.

For that matter, it seems SGP doesn’t interrogate the filter wheel when connected, because if it did, it would have noticed that the list of filter names returned was only 5 and not the 7 that SGP is configured to expect. It should have flagged an error or at least a warning on connection, alerting me to the discrepancy.

BTW, I’m running the 3.2.0.660 version of SGP. This may be fixed in the 4.x version, but I didn’t see anything in the release notes that sounds like this problem. A copy of the log from last night is here: Dropbox - sg_logfile_20210827001604.log - Simplify your life

Alex