Jump to content

  •  

CNers have asked about a donation box for Cloudy Nights over the years, so here you go. Donation is not required by any means, so please enjoy your stay.

Photo

On The Edge of Defeat

  • Please log in to reply
187 replies to this topic

#151 cfosterstars

cfosterstars

    Mercury-Atlas

  • *****
  • Posts: 2563
  • Joined: 05 Sep 2014
  • Loc: Austin, Texas

Posted 13 September 2019 - 10:08 AM

  Should not surprise anybody.  Doug and his crew have been pulling this on customers for years, and it's the reason I have stopped buying anything sbig/cyanogen.

 

  My only question, and this may have already been done in this post, is there a reason to stick with zwo?  Why not try another camera like FLI, then see if the problems go away.  You already have the software and $$$ invested and maybe someone at the remote site will loan a camera. 

 

  Many vendors blame the hubs, and for maxim 666 that is the first excuse that they will use to get rid of you.  I have the Icron powered usb hub with 150 ft of cat 6 cable, SGP and no problems.  There was a noticeable improvement in going from cat 5 to cat 6.

 

  In all fairness to maxim, version 5 worked very well.  666 has been a train wreck for many.     

John, Gunny,

 

I used an ASI290MM-mini, ASI174MM-mini and a QHY 5-III 290 for my guide scopes and OAGs. I have had no issues at all with SGP and PHD2 related to the cameras other than when I had the USB speed at 90. This has been for over three years. I also used and ASI174MM-COOL at one point for my guidescope thinking that I would see a benifit for a cooled guide camera. This was just not the case at all. A good dark frame compenstation in PHD2 works just a well. It seems that you dont and an issue with running without the cooler. Is there some reason that you think that you need to have a cooled guide camera? I would suggest the ASI174MM-mini since it has a nice sized chip, but the ASI1600MM that you have without the cooler should be fine. Is there something I am missing here?



#152 jhayes_tucson

jhayes_tucson

    Fly Me to the Moon

  • *****
  • topic starter
  • Posts: 7147
  • Joined: 26 Aug 2012
  • Loc: Bend, OR

Posted 13 September 2019 - 10:13 AM

John, I am curious about the specifics with PHD. Did you actually identify WHY the original failure of the camera occurred? Or did you just notice that a failure occurred, and that when PHD tried to reconnect to the camera, it did not turn the cooler back on?

 

If you DID identify the problem that caused the camera to fail, what was it?

 

So in both cases with MDL and PHD, the camera chugs along normally until at some point, the commands to acquire an image simply stop and the commands that read (or control) the cooler are the only commands being called.  In the case of MDL, that stops everything dead in its tracks.  In PHD, when an image is not received, it waits for a user specified period of time and then disconnects and reconnects the camera.  When it reconnects the camera, it comes back on line with the cooler turned off and PHD does not restore this setting.

 

I do not know why this is happening.  It could be due to the way that commands are being issued from the controlling code (MDL or PHD).  It could be due to the way that the ZWO ASCOM driver is interpreting the function calls from the controlling program or it could be due to a hardware issue in the camera.  There is some little glitch that's not being handled properly somewhere.  It could be a timing issue or an error condition that not being properly handled.  I could almost certainly debug the problem if I had access to all of the code; but, I don't.   The interesting thing is that this problem may actually affect a lot of cameras but for those folks using PHD, it might not be all that noticeable given the way PHD handles the fault.  ZWO has told me that they've seen this problem before but that they don't know the cause.  I've asked them to set up a test bench to see if they can reproduce the problem, but so far all I've heard back are crickets chirping.  Maybe they'll try it but I'd expect them to at least say, "Yes, we hear you...and we'll get back to you."

 

Running the camera with the cooler turned off (or the set point set at 40C+) seems to fix the problem so I'll carry on.  At this point, my hopes for a fix are pretty low.

 

John



#153 jhayes_tucson

jhayes_tucson

    Fly Me to the Moon

  • *****
  • topic starter
  • Posts: 7147
  • Joined: 26 Aug 2012
  • Loc: Bend, OR

Posted 13 September 2019 - 10:21 AM

John, Gunny,

 

I used an ASI290MM-mini, ASI174MM-mini and a QHY 5-III 290 for my guide scopes and OAGs. I have had no issues at all with SGP and PHD2 related to the cameras other than when I had the USB speed at 90. This has been for over three years. I also used and ASI174MM-COOL at one point for my guidescope thinking that I would see a benifit for a cooled guide camera. This was just not the case at all. A good dark frame compenstation in PHD2 works just a well. It seems that you dont and an issue with running without the cooler. Is there some reason that you think that you need to have a cooled guide camera? I would suggest the ASI174MM-mini since it has a nice sized chip, but the ASI1600MM that you have without the cooler should be fine. Is there something I am missing here?

 

I'm using ONAG and the chip size is smaller than I'd like with the ASI174MM.  Yes, I agree that running with the cooler turned off is just fine and now that I know that the cooler is causing the problem that's how I'm operating.  The problem is that it has taken almost two years of chasing red herrings before finally identifying a workable solution.  Regardless, it would be nice if the problem could actually be fixed, but that's looking increasingly unlikely.  Hopefully, I'll hear back from ZWO when they get back from their holiday.

 

John


  • PrestonE and 2ghouls like this

#154 Corsica

Corsica

    Vendor (Innovationsforesight)

  • *****
  • Vendors
  • Posts: 636
  • Joined: 01 Mar 2010
  • Loc: PA - USA

Posted 13 September 2019 - 10:23 AM

So in both cases with MDL and PHD, the camera chugs along normally until at some point, the commands to acquire an image simply stop and the commands that read (or control) the cooler are the only commands being called.  In the case of MDL, that stops everything dead in its tracks.  In PHD, when an image is not received, it waits for a user specified period of time and then disconnects and reconnects the camera.  When it reconnects the camera, it comes back on line with the cooler turned off and PHD does not restore this setting.

 

I do not know why this is happening.  It could be due to the way that commands are being issued from the controlling code (MDL or PHD).  It could be due to the way that the ZWO ASCOM driver is interpreting the function calls from the controlling program or it could be due to a hardware issue in the camera.  There is some little glitch that's not being handled properly somewhere.  It could be a timing issue or an error condition that not being properly handled.  I could almost certainly debug the problem if I had access to all of the code; but, I don't.   The interesting thing is that this problem may actually affect a lot of cameras but for those folks using PHD, it might not be all that noticeable given the way PHD handles the fault.  ZWO has told me that they've seen this problem before but that they don't know the cause.  I've asked them to set up a test bench to see if they can reproduce the problem, but so far all I've heard back are crickets chirping.  Maybe they'll try it but I'd expect them to at least say, "Yes, we hear you...and we'll get back to you."

 

Running the camera with the cooler turned off (or the set point set at 40C+) seems to fix the problem so I'll carry on.  At this point, my hopes for a fix are pretty low.

 

John

John,

 

I would recommend, as cfosterstar suggested, to set the ZWO USB traffic below 100%, I usually use 60% or 70%.
I do not have any issue with my ZWO ASI1600MM, but it is an uncooled version.



#155 2ghouls

2ghouls

    Viking 1

  • *****
  • Posts: 788
  • Joined: 19 Sep 2016

Posted 13 September 2019 - 10:25 AM

Glad to hear that you are imaging again John. I would really miss your images if you gave up the hobby! 

 

Sorry to hear about all the hassles you have had over the past couple years chasing this down.

 

Nico



#156 Jon Rista

Jon Rista

    ISS

  • *****
  • Posts: 23720
  • Joined: 10 Jan 2014
  • Loc: Colorado

Posted 13 September 2019 - 01:45 PM

So in both cases with MDL and PHD, the camera chugs along normally until at some point, the commands to acquire an image simply stop and the commands that read (or control) the cooler are the only commands being called.  In the case of MDL, that stops everything dead in its tracks.  In PHD, when an image is not received, it waits for a user specified period of time and then disconnects and reconnects the camera.  When it reconnects the camera, it comes back on line with the cooler turned off and PHD does not restore this setting.

 

I do not know why this is happening.  It could be due to the way that commands are being issued from the controlling code (MDL or PHD).  It could be due to the way that the ZWO ASCOM driver is interpreting the function calls from the controlling program or it could be due to a hardware issue in the camera.  There is some little glitch that's not being handled properly somewhere.  It could be a timing issue or an error condition that not being properly handled.  I could almost certainly debug the problem if I had access to all of the code; but, I don't.   The interesting thing is that this problem may actually affect a lot of cameras but for those folks using PHD, it might not be all that noticeable given the way PHD handles the fault.  ZWO has told me that they've seen this problem before but that they don't know the cause.  I've asked them to set up a test bench to see if they can reproduce the problem, but so far all I've heard back are crickets chirping.  Maybe they'll try it but I'd expect them to at least say, "Yes, we hear you...and we'll get back to you."

 

Running the camera with the cooler turned off (or the set point set at 40C+) seems to fix the problem so I'll carry on.  At this point, my hopes for a fix are pretty low.

 

John

Ok, thanks for the details.

 

With PHD...this may be something they could fairly easily fix. I've noticed with SGP that it has functionality built in where it can leave the cooler on when you disconnect the camera. It seems some CCD cameras have explicit commands to turn the cooler on and off. With the ZWO cameras, the cooler turns off when the camera is disconnected from the driver, and the cooler must then be explicitly turned on again. My guess is that PHD's reconnection flow is simply not trying to re-enable the cooler with the previous setpoint settings again. The PHD guys have always seemed friendly and responsive to me, so you might just ask them if they could add cooler re-enabling to their camera failure/retry flow, for cameras that need it.

 

PHD's camera failure/reconnection flow does seem to be pretty reliable to me. I have been having some issues with the QHY5L-II lately. If the driver doesn't outright crash and die itself (which it sometimes does, which then seems to require a full reboot...i think I made a mistake updating the QHY driver a few months back!!! The old one did not do this... :(), when the connection is lost PHD is able to reconnect to the camera, reacquire the guide star and start guiding again without issue. So PHD2 might be a more reliable option for you, given the recurring issue you seem to be having.


  • kingjamez likes this

#157 jhayes_tucson

jhayes_tucson

    Fly Me to the Moon

  • *****
  • topic starter
  • Posts: 7147
  • Joined: 26 Aug 2012
  • Loc: Bend, OR

Posted 13 September 2019 - 01:58 PM

John,

 

I would recommend, as cfosterstar suggested, to set the ZWO USB traffic below 100%, I usually use 60% or 70%.
I do not have any issue with my ZWO ASI1600MM, but it is an uncooled version.

 

Hi Gaston!  Yeah, I've tried EVERY speed setting for USB traffic and none of them fix the problem.  This is an issue directly related to the cooler.  The uncooled camera won't have the problem.

 

John


Edited by jhayes_tucson, 13 September 2019 - 01:59 PM.


#158 cfosterstars

cfosterstars

    Mercury-Atlas

  • *****
  • Posts: 2563
  • Joined: 05 Sep 2014
  • Loc: Austin, Texas

Posted 13 September 2019 - 02:16 PM

I'm using ONAG and the chip size is smaller than I'd like with the ASI174MM.  Yes, I agree that running with the cooler turned off is just fine and now that I know that the cooler is causing the problem that's how I'm operating.  The problem is that it has taken almost two years of chasing red herrings before finally identifying a workable solution.  Regardless, it would be nice if the problem could actually be fixed, but that's looking increasingly unlikely.  Hopefully, I'll hear back from ZWO when they get back from their holiday.

 

John

Well maybe you can get ZWO to swap the ASI1600MM-PRO for the uncooled ASI1600MM. You get the chip size and no cooler at all. 

 

https://astronomy-im...oduct/asi1600mm



#159 cfosterstars

cfosterstars

    Mercury-Atlas

  • *****
  • Posts: 2563
  • Joined: 05 Sep 2014
  • Loc: Austin, Texas

Posted 13 September 2019 - 02:17 PM

Well maybe you can get ZWO to swap the ASI1600MM-PRO for the uncooled ASI1600MM. You get the chip size and no cooler at all. 

 

https://astronomy-im...oduct/asi1600mm

I also have two ASI1600MM_Cool/PRO. I could try using my APO as a guide scope for my SCT with the cooled camera to see if I have the same issue.



#160 vdb

vdb

    Apollo

  • -----
  • Posts: 1461
  • Joined: 08 Dec 2009

Posted 13 September 2019 - 03:11 PM

If I had spend that much time and money I would have swapped out the ASI for the QHY, as soon as I discovered the ASI / MDL problem ... I know ASI and QHY each have their own fiddly USB issues, but it would be really bad luck if you would encounter the same issue ...

 

/Yves



#161 Jon Rista

Jon Rista

    ISS

  • *****
  • Posts: 23720
  • Joined: 10 Jan 2014
  • Loc: Colorado

Posted 13 September 2019 - 03:43 PM

If I had spend that much time and money I would have swapped out the ASI for the QHY, as soon as I discovered the ASI / MDL problem ... I know ASI and QHY each have their own fiddly USB issues, but it would be really bad luck if you would encounter the same issue ...

 

/Yves

I am pretty sure the current QHY drivers have some issues. I updated the driver somewhat recently, and have STARTED to have problems with my QHY5L-II that I was not having before... 



#162 vdb

vdb

    Apollo

  • -----
  • Posts: 1461
  • Joined: 08 Dec 2009

Posted 13 September 2019 - 04:01 PM

I am pretty sure the current QHY drivers have some issues. I updated the driver somewhat recently, and have STARTED to have problems with my QHY5L-II that I was not having before... 

As mentioned they both have their fair share of issues, but I could cycle my QHY163 all night without issues ...

/Yves



#163 Jon Rista

Jon Rista

    ISS

  • *****
  • Posts: 23720
  • Joined: 10 Jan 2014
  • Loc: Colorado

Posted 13 September 2019 - 04:11 PM

As mentioned they both have their fair share of issues, but I could cycle my QHY163 all night without issues ...

/Yves

The same can be said about my ASI1600 v1. :shrug:



#164 tomb18

tomb18

    Vendor - AstroRotor

  • -----
  • Vendors
  • Posts: 42
  • Joined: 13 Oct 2015

Posted 14 September 2019 - 09:39 PM

The thing that concerns me is that you say that, “There are a couple of places for this.”  A long time ago, I triple checked every USB node to confirm that power management was turned off.  I run Windows 7 Pro and I’ve searched but I can’t find anything called “USB Selective Suspend” under the Power tab in the control panel.  Regardless, this suggestion begs an important question:  Does Windows randomly turn on USB power management over time?  I turned this stuff off when I got the computer, I installed the camera, and it ran just fine for 4-6 weeks before it started to randomly disconnect.  Are you suggesting that something has turned USB power management back on?  If that’s the case, how can Windows be trusted to run anything with a USB connection?

 

Windows 7 has this.  Open the control panel, Power.  Select High performance profile. Then Click change Plan Settings. Then click advanced.  There will be a USB entry.  I bet it is enabled.

If you don't interact with your computer with a mouse or some interactive action it will put the USB devices into a low power state, disrupting any communications.  It must be off

It is also my experience that Windows will change this back, sometimes randomly at reboot, it might also do this when it does a software upgrade.

I don't recall how you do all your connections but there is another choice and that is to use a device like the Silex USB to Ethernet device.  One ethernet connection to your router and then you can plug all your USB devices into a small hub and then into the Silex.  You can use 1 foot long cables.  It works reliably, and is what I use for my remote operation.

Tom



#165 nathmath

nathmath

    Sputnik

  • *****
  • Posts: 43
  • Joined: 12 Oct 2015
  • Loc: Wisconsin

Posted 16 September 2019 - 05:59 AM

I was just perusing the latest PHD2 beta changelog and came across the following update from the Sept 10 beta: ASCOM cameras: fix crash attempting to set cooler after camera is disconnected.

https://openphdguidi...ment-snapshots/

Not sure if it's exactly related to what's going on here, but it reminded me of this thread.
  • kingjamez and bugbit like this

#166 jhayes_tucson

jhayes_tucson

    Fly Me to the Moon

  • *****
  • topic starter
  • Posts: 7147
  • Joined: 26 Aug 2012
  • Loc: Bend, OR

Posted 16 September 2019 - 09:10 AM

I was just perusing the latest PHD2 beta changelog and came across the following update from the Sept 10 beta: ASCOM cameras: fix crash attempting to set cooler after camera is disconnected.

https://openphdguidi...ment-snapshots/

Not sure if it's exactly related to what's going on here, but it reminded me of this thread.

 

Interesting...



#167 Kaydubbed

Kaydubbed

    Vostok 1

  • *****
  • Posts: 176
  • Joined: 29 Sep 2018
  • Loc: Kansas City, Missouri

Posted 16 September 2019 - 10:36 AM

Buy no means throw money at this problem, but a solution to provide USB power/3.0 data/management is the Pegasus Powerbox. You can reset the hung USB ports through the software, monitor current, and run debugs. Everything is fused too and has smart shutdown, which is nice to have when you are 1,000 miles away. 



#168 jhayes_tucson

jhayes_tucson

    Fly Me to the Moon

  • *****
  • topic starter
  • Posts: 7147
  • Joined: 26 Aug 2012
  • Loc: Bend, OR

Posted 16 September 2019 - 08:15 PM

Buy no means throw money at this problem, but a solution to provide USB power/3.0 data/management is the Pegasus Powerbox. You can reset the hung USB ports through the software, monitor current, and run debugs. Everything is fused too and has smart shutdown, which is nice to have when you are 1,000 miles away. 

 

Why does the notion that the USB port is hanging keep coming up (recurring in more than just this one suggestion?)  I thought that I was pretty clear that the debugging code continues to read the camera through the USB port just fine even after the commands to read a new image are replaced by the cooler commands.  Furthermore, I've clearly stated that if the cooler is disabled, the camera runs reliably.  That's been verified over a period of 5 days for runtimes up to 12 hours at a stretch.  I have chased every possible USB issue for 2-years and that's why I arrived at the most simple configuration, which is a PC connected through a single USB cable directly to the camera.  At this point, all available evidence shows that the problem has nothing to do with a failed or intermittent USB connection.  Having the ability to reset a USB hub is nice in principle, but I haven't seen any evidence that it would do anything whatsoever to fix the problem that I've reported.

 

John


Edited by jhayes_tucson, 17 September 2019 - 12:07 AM.

  • kingjamez and sink45ny like this

#169 t-ara-fan

t-ara-fan

    Viking 1

  • -----
  • Posts: 725
  • Joined: 20 Sep 2017
  • Loc: 50° 13' N

Posted 17 September 2019 - 12:58 AM

  Furthermore, I've clearly stated that if the cooler is disabled, the camera runs reliably.

Many of us don't have a cooled guide camera.  Of course cooled sounds way better (and cooler!) than a warm guide camera.

 

What about shooting some darks for your guide camera, running at at ambient temp+, and letting PHD2 use those darks to chase away most of the hot pixels?

 

Annoying AF after all you put into it, I know.  But does a cooled guide camera get you MORE than a regular temp guide camera? 



#170 lambermo

lambermo

    Viking 1

  • -----
  • Posts: 891
  • Joined: 16 Jul 2007
  • Loc: .nl

Posted 18 September 2019 - 08:05 AM

Hi John,

So in both cases with MDL and PHD, the camera chugs along normally until at some point, the commands to acquire an image simply stop and the commands that read (or control) the cooler are the only commands being called.  In the case of MDL, that stops everything dead in its tracks.  In PHD, when an image is not received, it waits for a user specified period of time and then disconnects and reconnects the camera.  When it reconnects the camera, it comes back on line with the cooler turned off and PHD does not restore this setting.

 

Please open a ticket at the PHD2 bug tracker at https://github.com/O...ing/phd2/issues for the reconnect-without-cooler issue.

 

Also, being a PHD2 volunteer myself albeit without ASCOM I may be able to help test this issue as I do have an ASI1600 camera, just not as a guide camera. Are you saying you just let PHD2 loop through images all day to test (so without guiding) ?

 

-- Hans



#171 jhayes_tucson

jhayes_tucson

    Fly Me to the Moon

  • *****
  • topic starter
  • Posts: 7147
  • Joined: 26 Aug 2012
  • Loc: Bend, OR

Posted 18 September 2019 - 09:53 AM

Hi John,

Please open a ticket at the PHD2 bug tracker at https://github.com/O...ing/phd2/issues for the reconnect-without-cooler issue.

 

Also, being a PHD2 volunteer myself albeit without ASCOM I may be able to help test this issue as I do have an ASI1600 camera, just not as a guide camera. Are you saying you just let PHD2 loop through images all day to test (so without guiding) ?

 

-- Hans

Hi Hans,

Yes, I just looped images from the ASI-1600MM-C Pro with 2 second exposures.  Be sure that the cooler is turned on.  I specified a set point of 10C, which was about 10C below ambient.  The exact temperature isn't important but it does need to be below ambient so 0C should be a good number in any case.  I tracked the camera operation using the CatchSDK_Log.exe code from ZWO to be able to catch and analyze the error, which in my single test occurred after about 7.5 hours.  You could also set the camera disconnect time-out value to be a very large number so that the whole thing will just stop if an error occurs.  For this test, my cable was a 15 foot USB3 cable.  The camera was connected through the most current ZWO ASI-1600 ASCOM driver.  I suggest running the camera for at least a 24 hour period before declaring a result.

 

I would be interested to see if you can reproduce this error as well using your camera.  I've seen it on two ASI-1600s--both with a "cool" and with the "Pro" versions.

 

When I get time, I'll submit a bug-ticket.  Thanks for that suggestion.

 

John


  • kingjamez likes this

#172 kingjamez

kingjamez

    Vanguard

  • *****
  • Posts: 2021
  • Joined: 03 Oct 2006
  • Loc: Fairfax, VA

Posted 18 September 2019 - 11:57 AM

I can run this test too... just for more data points. I'll get it setup tonight.

 

-Jim


  • jhayes_tucson likes this

#173 lambermo

lambermo

    Viking 1

  • -----
  • Posts: 891
  • Joined: 16 Jul 2007
  • Loc: .nl

Posted 19 September 2019 - 05:12 AM

Hi Hans,
Yes, I just looped images from the ASI-1600MM-C Pro with 2 second exposures.  Be sure that the cooler is turned on.  I specified a set point of 10C, which was about 10C below ambient.  The exact temperature isn't important but it does need to be below ambient so 0C should be a good number in any case.  I tracked the camera operation using the CatchSDK_Log.exe code from ZWO to be able to catch and analyze the error, which in my single test occurred after about 7.5 hours.  You could also set the camera disconnect time-out value to be a very large number so that the whole thing will just stop if an error occurs.  For this test, my cable was a 15 foot USB3 cable.  The camera was connected through the most current ZWO ASI-1600 ASCOM driver.  I suggest running the camera for at least a 24 hour period before declaring a result.
 
I would be interested to see if you can reproduce this error as well using your camera.  I've seen it on two ASI-1600s--both with a "cool" and with the "Pro" versions.
 
When I get time, I'll submit a bug-ticket.  Thanks for that suggestion.
 
John

I'm running the test using 1s exposures, setpoint also to 10C, 3m USB3 cable, ASI1600MM-Cool, no ASCOM.
I cannot use CatchSDK_Log.exe as I'm not on Windows. Do you know if that tool has a Linux version ? (my Google search did not help).
I have the camera running for over 12h so far and have not caught any issues :

~/PHD2/ egrep 'new camera|to camera|Connected Camera|cooler|Cooler' PHD2_DebugLog_2019-09-18_233011.txt
23:31:08.717 00.000 140737353747008 Created new camera of type ZWO ASI Camera = 0x555556979910
23:31:13.312 00.000 140737353747008 Connecting to camera [ZWO ASI Camera] id = []
23:31:13.880 00.010 140737353747008 ZWO: camera has cooler
23:31:13.914 00.000 140737353747008 Connected Camera: ZWO ASI1600MM-Cool
23:31:31.324 00.006 140737353747008 GetDouble("/profile/4/camera/CoolerSetpt", 10.000000) returns 10.000000

and it's over 12h later here now. Well over 10 000 images were taken so far :

egrep 'Exposure complete' PHD2_DebugLog_2019-09-18_233011.txt | wc -l
13976 

I'll let it run another 12h as you said.
 
Update: And I've made a ticket https://github.com/O...phd2/issues/798 # GearDialog::DoConnectCamera needs to call SetCoolerOn for ReconnectCamera
 
-- Hans


Edited by lambermo, 19 September 2019 - 06:02 AM.

  • Jon Rista likes this

#174 jhayes_tucson

jhayes_tucson

    Fly Me to the Moon

  • *****
  • topic starter
  • Posts: 7147
  • Joined: 26 Aug 2012
  • Loc: Bend, OR

Posted 19 September 2019 - 09:59 AM

Hans,

You’ll have to talk to ZWO about what versions of the debugger are available.  Let me know if you make it to 24 hrs.  If you do, that would point to the ASOM driver as the most likely culprit; but, I think that without confirming the failure on another system, the results will be inconclusive.  I was hoping that someone could use the exact same configuration to independently confirm the behavior.

 

John



#175 kingjamez

kingjamez

    Vanguard

  • *****
  • Posts: 2021
  • Joined: 03 Oct 2006
  • Loc: Fairfax, VA

Posted 19 September 2019 - 05:56 PM

Well darn, Since you all were running the ASI1600, I thought I'd do it on a different camera... I'll move over to my ASI1600mm-cool after I let my ASI183MC-Pro run for a full 24 hours.

 

I'm at 12 hours right now and it's still chugging along with cooler on and set to 10c with 3 second exposures. 

 

-Jim




CNers have asked about a donation box for Cloudy Nights over the years, so here you go. Donation is not required by any means, so please enjoy your stay.


Recent Topics






Cloudy Nights LLC
Cloudy Nights Sponsor: Astronomics