Problem with asi185mc

vlaiv

I have a problem with my asi185mc camera.

It was working fine just a week ago, but yesterday I went to shoot some deep sky with it (M42) and noticed something extremely strange.

Images were really bad, although I used longer exposure than my previous session (30s vs 10s) results were much worse (I did same session a week ago and wanted to improve results by longer exposure).

I examined frames obtained and realized that my dark frames (30s, 15db gain) are almost completely dark - filled with 0 values apart from occasional noise value up to 200 ADU or so (out of 65536). Also my light frames look like missing data from it (like I was shooting in 8bit or something). Darks from my previous session (10s and 0db gain) display normal noise patterns (almost no pixel is 0 but rather small random noise values and noticable amp glow). With new darks amp glow is almost not noticable.

I'm not sure if I installed new drivers in the meantime, so I reverted drivers to the oldest version I have, but problem remains.

Either there were some kind of firmware upgrade that I was not aware that came with new drivers, or my camera stopped working properly.

Has anybody had same problem with this camera?

If camera is malfunctioning, is there any kind of warranty on this product?

xs_man

Hi vlav,

I have the ASI185 cooled and I hope I could help you a little bit.

Here is the first test I made with 8 seconds subs in 8 bits (sorry in french...)

http://www.webastro.net/forum/showthread.php?t=133707

Amp glow is visible, I don't use here the preset values for deepsky imaging

as Firecapture don't support ASCOM.

For deep-sky imaging with exposure time more than 1 or 2 seconds, it's

necessary to use the same way as for long exposure imaging.

So use only 16 bits raw images and darks. All processing in 16 bits,

don't mix 8 and 16 bits images. Be careful for darks, use exactly the

same exposure/gain/color balance and a nearly constant temperature

Use the ASCOM driver with a deepsky imaging software that support it.

You have 3 preset configurations very usefull to reduce 'amp glow'

(in the last driver available).

Now I'm waiting for clear skies (1 month and half with clouds, fog, rain... : ) to

make longer exposure images. ;)

Albéric

vlaiv

Thank you for the info.

I did use 16bit images. My problem is that suddenly my data started showing characteristics different from what it used to show.

For example let us talk about dark frames only (to avoid different shooting conditions).

Previously darks were what I consider normal. They showed expected noise distribution along with amp glow (which is ok, as can be removed with darks, bias and so on). At the same settings, previously darks had almost no pixels with value of 0.

Now when I shoot for example 30s exposure, most of pixels in darks have value of 0 regardless of gain settings (0db, 15db etc).

Same goes for light frames that I captured yesterday. I'm in quite light polluted area, and any kind of long exposure should capture some of LP signal. But my light frames show similar pattern - most of pixels that are not star or nebulosity have value of 0 (no calibration of any kind, not even bias subtracted).

vlaiv

I managed to pinpoint the problem. It was due to new version of SharpCap (probably new SDK aswell).

Brightness setting was the cause of bad images.

Latest version of SharpCap comes with brightness settings (0-500) and gamma (0-100)

What settings for brightness and gamma should I use to get most linear and correct response from sensor (as if no brightness and gamma settings were applied)?

vlaiv

There has been something very strange done with new SDK and/or drivers.

Issue seems very serious.

Camera is now totally useless for long exposure.

I just took 2 frames at exact same settings:

Gain 0

Gamma 50

Brightness 500

One being 30 second dark, other short exposure bias frame.

Median value of dark is: 7568

Median value of bias is: 8000 (that is exactly 500*16 as expected for offset of 500ADU units, both values are multiplied with 16 - stretched to 16bit)

There is simply no way that dark frame has lower median value than bias! At least it should not have it, as 30s dark should have both bias and dark current signal!

xs_man

Do you have tried Firecapture software ?

Do you have tried to substract only dark from raws (without using bias) ?

As far I understand, bias are necessary if darks and raw images are taken

with different exposure time.

Albéric

vlaiv

Only reason to take bias frames is because taking sufficient number of darks can be too long.

One should take as much darks as possible in order not to inject additional noise when calibrating. But sometimes it is just too long to wait (for example one would have to wait 6 and a half hours to take

64 x 10min darks).

If you want proper calibration then you should never create darks of different exposure length to lights, no matter if using bias frames or not.

I'll test with FireCapture now, I used new version of SharpCap for median test.

vlaiv

Just tried, FireCapture gives same bad values for median of dark and bias (dark having lower value than bias).

I also checked set of frames taken a week ago. Settings: Gain 0, Dark 10s, Bias frame (don't remember doing anything with brightness - it was on default level at the time)

Results:

Bias median: 16 (values range 0-160)

Dark median: 80 (values range 0-1360)

vlaiv

Yes, there is most certainly something going on behind the scenes.

Take a look at following 3 pictures.

Gain: 0

Brightness: 50

First picture is histogram of 1/8000 ms exposure (notice peak histogram position)

Second picture is first frame after switching to 4s exposure (peak histogram position is where I would expect it to be if nothing was being altered)

Third picture is very next frame at 4s exposure - whole histogram suddenly jumps to the left (and stays there on following frames) - sign that something is being altered (subtracted from frames)

Edit: pictures are displayed in reverse order (first being on the bottom) for some reason

Is there any way to prevent this behavior?

rkayakr

In another thread Sam mentioned that they just released a new SDK to fix other problems.

http://zwoug.org/viewtopic.php?f=21&t=6139

Can you revert to an older version of SharpCap or FireCap to see if that restores the operation you expect?

vlaiv

Firecapture 2.4.11 has same problem (bias frame larger median than 10s dark) as version 2.5

I was not able to test on previous versions of SharpCap as they are not available for download - and had expiry date (this is the reason why I upgraded between last week's session and last thursday - everything was a week ago)

Sam@ZWO

Please update to latest version software to fix this problem

this problem is because ASI185 build in auto calibration

we didnot stop it before, but we stop it in our newest software

vlaiv

Where can I find the latest version?

Above issue was confirmed with:

Driver version: 1.1.1.20 (latest on your website)

SharpCap: 2.7.2108 (release)

Sam@ZWO

vlaiv wrote:
Where can I find the latest version?

Above issue was confirmed with:

Driver version: 1.1.1.20 (latest on your website)

SharpCap: 2.7.2108 (release)

I confirm that they are newest, just did some test with this camera

as you said the dark frames are not stable

this sensor is a little strange

we will try to find a way to solve this problem (after we finish our new year holiday)

sorry about this issue

I will contact you through email if there is any progress

vlaiv

Thank you, hope to hear from you soon.

Happy holidays

Sam@ZWO

a fast update

please test the new ASCOM driver

ASICamera ASCOM Setup.zip

and to test under SC: just uncompress and copy the dll to replace the old one under SC install directory

ASICamera2.zip

vlaiv

Here is test with 3 different versions of SDK (ASICamera2.dll) that I managed to get:

1.10.0.41

1.11.0.16

1.11.0.18

All of them exhibit same behavior regarding autocalibration but do it in different manner.

1.10.0.41 - after switching from short to long exposure (1/8000s vs 4s), just displays same frame (short exposure) as the first long frame (sometimes does not report first frame at all but takes 8s exposure as "first" frame, and then continues 4s exposures). All other long exposure frames are same and have histogram shifted to left.

1.11.0.16 and 1.11.0.18 (one that you provided download link for) behave exactly the same: first frame after switching exposure displays expected histogram, following frames have histogram shifted to left.

hokle

Hello,

I think that I have the same problem with cooled ASI185MC. I tried the latest libraries from the SDK kit 1.11.0.18 with FC 2.4.12, FC 2.5.03 and SC 2.7.2095 Beta, unfortunately without success. The first dark frame seems almost always good, but others are strange. For example I use a 30 second exposure to capture the moons of Uranus in order to determine the orientation of the planet. This behavior does not allow it me. The problem does not occur during short exposures, for example 100ms. Correction of this error would be welcomed.

On the other hand I must say that when I use ASCOM driver with a program SIPS for DSO long exposures, everything works without problems. Did you try ASCOM driver?

settings:

gain 120

exp 120s

gamma 50

wred 50

wblue 90

without cooling

Regards

Jan

vlaiv

Hi,

No, I did not try ascom version. Latest SC does not allow me to use ascom for some reason - I can select ascom camera driver but have no frames being captured. I did not know about SIPS. I'll give it a go this weekend (at least do some tests). It looks like cloudless weekend for me so I've planed some shooting - I think I have a good technique to circumvent this problem for now - set required exposure and gain, let dark stabilize, manage brightness to avoid histogram clipping to the left (all of this with lens covered), and skip usage of bias frames (take a lot of darks instead). This will somewhat limit useful range of 12bits - I'll have something like 0-3800 instead of 0-4095 but hope it will give me ok results. Hope to find some time to do ascom testing as well, but will not risk doing shooting with it without trying it first.

Vladimir

xs_man

vlaiv wrote:
Hi,

No, I did not try ascom version.

...

Vladimir

As I previously said in my first anwer, try ASCOM drivers.

It's the only solution to reduce and nearly remove amp glow with darks.

You can use SIPS software or trial Sequence Generator to access

to Ascom parameters for camera.

Albéric

~~Next Page »~~