EGAIN not correct at first connect

allhoest

My camera gain is set to 300, so an EGAIN (12bit) about 0.156...

I open the settings, set 139 as gain. Then close the settings popup.

To be sure, I open again the settings popup and check the gain 139, which is is well set.

Then connect the camera and take a picture. In the fits header, the EGAIN is set to 0.156... which belong to gain 300.

Then I disconnect the camera, check the gain again, which is still 139. Close the popup setting again.

Connect the camera and take again a picture. From now, the EGAIN is set to the correct value -> 1.0011… (12 bit).

This process can be reproduced at each gain change process, eg while setting back to 300. (gain of 1.001 is erruneously show at the first connection/capture).

I browsed the net, and have found this post, which describes the same behavior:

http://forum.mainsequencesoftware.com/t/conflicting-gain-values-in-fits-header-zwo-ascom-driver/8915

Details:

Running an ASI1600 Pro

An ASI174 is also used from time to time along the same computer, but not at the same time as the ASI1600

ZWO Driver v3.0.0.5

ZWO ASCOM v1.0.3.21

Ascom plattform 6.3

Maxim 5.23

Maxim Ascom plugin 5.22

Win 10 up to date

allhoest

phenrotay

Problem confirmed on my equipment as well.

ASI 1600 MPro, Maxim 5.18, Win 10 Pro laptop

Seems to be related to ZWO ASCOM driver: 1.0.3.22 and 1.0.3.21 do show the problem but NOT V1.0.3.18.

Pierre

phenrotay

The problem can also be reproduced in Sequence Generator Pro V3 : EGAIN is not set properly after gain is changed in the ASCOM interface when using ASCOM v1.0.3.22.

No problem with v1.0.3.18.

Support@ZWO

Thank you guys for feedback this problem. I will tell our engineer to check the code.

chad

Hi Pierre，

After v1.0.3.18, we changed the Egain's algorithm. Before that, it is a fixed value, only pointed to the value of gain=0. But actually, it is not fixed for different values. You can find it in our EG&RN&FW&DR-map. That's why we add a algorithm to calculate the egain for current gain.

In this way, there are 2 problems.

First, for some software, when they save the file, according to our situation in the past, it is a fixed value, there is no need to reload the Egain value again. It means they will use the last value that mapped the the old gain. At this time, the new gain and the egain value will no mapped. We also reflected this problem to some applications, asking them to re-get the current egain value when saving the image.

Second, there is a mathematical problem. Like the curve, gain and egain are not simply linearly related. Usually, the new egain can be calculated by the following formula: NewEGain = (EgainMax) / (10 ^(Gain/200)), EgainMax is the value of gain=0. Because division in a computer operation can only have integer parts, Therefore, the curve obtained by the mathematical algorithm cannot completely coincide with the actual curve, so that the calculated result presents like a step shape. So far we haven't found a better algorithm. So you have this problem. We are sorry for it.

Hope you can understand.

Thanks

Chad

phenrotay

Hi Chad,

Let me detail a simple procedure to clarify reproduce the problem - I am not sure that your explanation is 100 % relevant - saving the image does not play a role here.

I use Maxim as an example. ZWO ASCOM driver.

I connect the camera and take an image. I look at the FITS header and the EGAIN is OK (say : 1 for 139).

I change the camera settings (no need to disconnect) and set gain to 0 (or any other value except 139).

I take a new image and look at the FITS header; the EGAIN still reads 1 which is not normal.

Pierre

chad

Hi Pierre,

Yes. It is caused by the algorithm.

As I said before, because our formula, the second reason, it will caused the following result, any gain value less than 200 is one result, and any gain between 200 and 400 is another result. We are also try to find a better formula. But did have it now.

Thanks

Chad

rjurevicius

Anyone,

I pulled a lot of hair out getting an understanding/workaround for the issue of the fits header as reported by pixinsight reporting a gain and egain not matching what I expected to see.

Here is what I now do for ASI1600MC-C, Pixinsight, Sequence Generator Pro V3.X (SGP)

1) set up more than one profile in SGP with differing gain settings. They are available in the dropdown when the camera is linked.

2) apply the profile to the sequence and take an image. The Pixinsight fits header will now show the gain setting correctly but the egain is unreliable.

3) disconnect camera, reconnect camera, take a second image. Pixinsight will show the gain setting correctly and the egain is now correct.

I assume image follows the profile loaded in SGP, and the egain value reported in the Pixinsight fits header may be incorrect.

I remains unclear how to set camera offset and verify it.

There does not seem to be a way to set offset when using profiles. Is is stuck at 50 when using SGP profiles?

If anything above is incorrect or there are other things I should know, please let me know.

Ray J

phenrotay

chad wrote:

Hi Pierre,

Yes. It is caused by the algorithm.

As I said before, because our formula, the second reason, it will caused the following result, any gain value less than 200 is one result, and any gain between 200 and 400 is another result. We are also try to find a better formula. But did have it now.

Thanks

Chad

Sorry Chad, I cannot agree with your explanation - or there is a misunderstanding.

As one can see in the FITS header when EGAIN is set correctly :

gain 0 corresponds to (approx) EGAIN=4.96

gain 139 to EGAIN=1.00

gain 300 to EGAIN=0.15

Now let us play with these values...

Start MaxIm

Connect the camera

Take image - no need to save it

Disconnect

Setup camera : (ASCOM>Advanced>Properties) just read DO NOT change gain

Connect the camera

Take image 1 - no need to save it

Disconnect

(the above steps are to guarantee that the proper EGAIN is written to the FITS header of the last image)

Setup camera : (ASCOM>Advanced>Properties) change gain to ANOTHER value

Connect the camera

Take image 2 - no need to save it

Disconnect

Inspect FITS header : image 1 and image 2 have the same EGAIN; this is not normal

Setup camera : (ASCOM>Advanced>Properties) just check that the previously selected gain is still active and DO NOT change gain

Connect the camera

Take image 3 - no need to save it

Inspect FTS header : image 3 has a different EGAIN from image 2 (and this one is the correct one !!)

Conclusion : EGAIN is not always matching the gain selected

Pls note that the correct gain is used for taking the image (as shown by histogram). Just the FITS key is incorrect/

1.03.18 was OK for this

Hope this makes the problem clearer.

Pierre

chad

phenrotay wrote:

chad wrote:

Hi Pierre,

Yes. It is caused by the algorithm.

As I said before, because our formula, the second reason, it will caused the following result, any gain value less than 200 is one result, and any gain between 200 and 400 is another result. We are also try to find a better formula. But did have it now.

Thanks

Chad

Sorry Chad, I cannot agree with your explanation - or there is a misunderstanding.

As one can see in the FITS header when EGAIN is set correctly :

gain 0 corresponds to (approx) EGAIN=4.96

gain 139 to EGAIN=1.00

gain 300 to EGAIN=0.15

Now let us play with these values...

Start MaxIm

Connect the camera

Take image - no need to save it

Disconnect

Setup camera : (ASCOM>Advanced>Properties) just read DO NOT change gain

Connect the camera

Take image 1 - no need to save it

Disconnect

(the above steps are to guarantee that the proper EGAIN is written to the FITS header of the last image)

Setup camera : (ASCOM>Advanced>Properties) change gain to ANOTHER value

Connect the camera

Take image 2 - no need to save it

Disconnect

Inspect FITS header : image 1 and image 2 have the same EGAIN; this is not normal

Setup camera : (ASCOM>Advanced>Properties) just check that the previously selected gain is still active and DO NOT change gain

Connect the camera

Take image 3 - no need to save it

Inspect FTS header : image 3 has a different EGAIN from image 2 (and this one is the correct one !!)

Conclusion : EGAIN is not always matching the gain selected

Pls note that the correct gain is used for taking the image (as shown by histogram). Just the FITS key is incorrect/

1.03.18 was OK for this

Hope this makes the problem clearer.

Pierre

HI Pierre,

As I said before, the reason 1, for the new calculation, it need the application to get the new eGain for the current gain when you click the Save Button to save a image every time. Like refresh the eGain first, then save it.

But most of the application did not noticed this. They did it as before, get the eGain when the application was start, then when the Save Button is clicked, use this eGain directly, did not refresh the eGain, just save it.

When you close the application, there is a new gain will be saved into our SDK, we will remember this gain and calculation the eGain. At the next time, when you run the application, the eGain and the Gain that application got from our SDK will be right. But if you changed the gain, we need the application to do a refresh of the eGain when saving the image. If they did not refresh it, they will use the eGain that they got at the beginning of the application to save. Then thing go wrong.

In the past, the eGain is a fit value, it always pointed the Gain=0, so there is no need to refresh the eGain value, that's why the applications did not do refresh of eGain when save the image.

Thanks

Chad

chad

rjurevicius wrote:

Anyone,

I pulled a lot of hair out getting an understanding/workaround for the issue of the fits header as reported by pixinsight reporting a gain and egain not matching what I expected to see.

Here is what I now do for ASI1600MC-C, Pixinsight, Sequence Generator Pro V3.X (SGP)

1) set up more than one profile in SGP with differing gain settings. They are available in the dropdown when the camera is linked.

2) apply the profile to the sequence and take an image. The Pixinsight fits header will now show the gain setting correctly but the egain is unreliable.

3) disconnect camera, reconnect camera, take a second image. Pixinsight will show the gain setting correctly and the egain is now correct.

I assume image follows the profile loaded in SGP, and the egain value reported in the Pixinsight fits header may be incorrect.

I remains unclear how to set camera offset and verify it.

There does not seem to be a way to set offset when using profiles. Is is stuck at 50 when using SGP profiles?

If anything above is incorrect or there are other things I should know, please let me know.

Ray J

Hi Ray,

Sorry for the trouble.

The reason is that, we changed the eGain's calculation, it is mapped the current gain now. In the past, it is only mapped to the gain=0, so the eGain in the past is a fixed value.

The developers of the application did not noticed this point. They still think it is a fixed value. So they do not do the refresh when they want to use the eGain to fix the file header.

In the past, for application, because eGain is a fixed value, no changing, application only need to get it one time when the application start.

But now, if a new gain is setted, eGain will be changed. It means when the application is stopped, the eGain will be mapped to the last setting of gain. And both gain and eGain will be remembered. When the application start next time, they will get the old eGain which is mapped to the old gain. Then if you changed the gain, our SDK will calculte a new eGain, but the application do not visit it, they will still use the old eGain, then thing goes wrong.

Thanks

Chad

phenrotay

Hi Chad,

I must say that this gets confusing.

1) you mention "In the past, it is only mapped to the gain=0, so the eGain in the past is a fixed value."; this is not correct - in V1.0.3.18, the EGAIN changes according to the gain selected (so approximately 1. if gain is 139, 4.5 if gain is 0 etc... ) - it was not fixed to the one corresponding to gain=0

2) it is strange that you ask developpers of applications to act differently now and make use of the ZWO SDK - they are supposed (in the ASCOM context) to be agnostic of the ccd/cmos itself. Which SDK by the way ? If an application uses ASCOM, there should be no need to use something like a proprietary SDK.

Regards,

Pierre

chad

Hi Pierre，

Sorry, It is our mistake.

We did not check it carefully. And the reason is the same. We updated the algorithm in our SDK, but our ASCOM driver missed updating this value, which led to the problem. :

Very sorry, we will fix this problem in our next release.

Thanks

Chad

billm

Any update on a fixed Ascom driver?

I have this same issue.

After I change the gain in the ascom settings, I need to connect camera, take an image, disconnect camera, reconnect camera, take an image. Only on the second image is the Egain reported correctly in the Fits Header.

Bill

chad

Hi Bill,

We will fix it in our next release. The new release will be free in late February.

You know, the Spring Festival is coming, we are so busy these days, a new release need several days to test. Beside that, new release will remove something unnecessary, it is too big now. So please wait for a month.

Sorry again.

Thanks

Chad

billm

Hi Chad

I’ll look forward to it.

Thanks

Bill

phenrotay

What is the status? End Feb (2019) you said... We are in March.

Regards,

Pierre

chad

HI Pierre，

Please install the latest version v1.0.3.22 of ASCOM which we released at 27/2/2019.

Thanks

Chad

phenrotay

Hi,

I did not notice that a new version was available. You did not change the version number ? The "change log" has not been updated either.

Or do I miss something?

UPDATE

Just downloaded the file and tested it.

The problem is still there. EGAIN is still incorrect.

The ASCOM dialog box says : ASI Camera Setup V 6.0.3.22

Pierre

Support@ZWO

This is the download link:

https://astronomy-imaging-camera.com/software/ZWO_ASI_Camera_ASCOM.exe