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

#101 Jon Rista

Jon Rista

    ISS

  • *****
  • Posts: 24,340
  • Joined: 10 Jan 2014
  • Loc: Colorado

Posted 31 August 2019 - 06:20 PM

Thanks for your kind words Jon.  Right now I'm not sure if the light at the end of the tunnel is daylight or an oncoming train.  Sam helped me the first time this happened but now he's dumped me over to customer support  and I'm very concerned about what I'm hearing.  I won't go into everything that they've said, but here is just one example:

 

"2. Now we think even if you send the camera back to us, we probably won't be able to figure it out.
And replace a camera won't make a difference if we do not find out where the problem is since you have replaced a camera before."

 

We are still in the middle of the discussion (at least they haven't shut me down yet,) but I believe that they are saying that it's not their problem.  They are implying that the problem is with the controlling software, which in my case is MaximDL.  I'm still experimenting to try to understand what is going on but the problem may be due to the way that the guiding loop is implemented in MaximDL.  Something is going wrong, which causes the temperature control instructions to go into an infinite loop, which of course shuts down the camera.   The folks at DL are not well know for customer support but I may have to try to get them to fix it.  Otherwise, I may have to switch to another piece of control software like the SkyX or SGP.  I'm caught in the middle and it's going to be difficult to find a suitable fix that works with my hardware implementation.  Stay tuned and I'll provide an update when I know how to proceed.  I've got an all-consuming meeting most of next week so it may take some time to sort out.  In the meantime, my telescope only runs for random lengths of time before it hangs.  Grabbing maybe 2 subs over an 8 hour stretch of clear, dark skies with excellent seeing is not a very efficient way to gather data.  That's what was happening before the roof broke on the alpha observatory a few days ago.   tongue2.gif

 

 

John

I'm curious...are you cooling the ASI1600?



#102 jhayes_tucson

jhayes_tucson

    Fly Me to the Moon

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

Posted 31 August 2019 - 06:44 PM

I typically run it at -20C even though that doesn't do much to reduce dark noise.  I've tested the camera with the set point at -20C, 10C, and 18C and it makes no difference--the camera always dies.  It's an interesting idea to just unplug the cooler to see what happens.

 

John



#103 robertimorrison

robertimorrison

    Lift Off

  • -----
  • Posts: 4
  • Joined: 28 Jun 2017

Posted 31 August 2019 - 07:48 PM

John -- I'm still thinkin' its a power problem and since you have changed out / replaced essentially everything on the 5v USB bus, the only remaining power input is the 12v DC which (I guess) primarily powers the peltier cooler and its significant current draw.  The cryptic log seems to at least hint at cooler commands and related data interchange when the one hang you caught occurred.

 

I imagine you have changed out the 12v DC supply, but have you tried something like a big-brick Meanwell 12v 5A supply - something with overwhelming capacity?

 

Also, what happens if you remove the UPS you mentioned from the system; many of those only produce approximated 60 Hz sine waves by building up square wave forms (even when the line AC is on) and the switching noise inherent in the square waves is material.

 

Bob Morrison



#104 jhayes_tucson

jhayes_tucson

    Fly Me to the Moon

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

Posted 31 August 2019 - 08:19 PM

Bob,

Thank you for your thoughts.  The camera cooler is run from a 12A, 12VDC Astron RS-12A linear supply that originally came with my AP-1600 mount (https://www.astronco.../linear-desktop.)  It can supply 9A continuous current and I have it set to supply 12.5VDC.  It is super stable and it has plenty of reserve to drive this little camera cooler.  The UPS supplies power continuously from the battery, which is on a line charger.  I think that the AC current is well filtered and pretty clean.

 

I haven't gone into the details because I don't yet have all the facts but the concern is that during the guide cycle, the calling code is continuously opening the camera and never closing it.  This may be causing a memory leak, which would produce unpredictable results.  I want to emphasize that I don't know for sure if this is the problem and I'm still trying to sort out what's going on.  The problem may be with a cable or with a supply, but right now, I think that it's more likely that the parent code may have a bug.  I am in the process of trying to test the behavior with other software.

 

John



#105 Jon Rista

Jon Rista

    ISS

  • *****
  • Posts: 24,340
  • Joined: 10 Jan 2014
  • Loc: Colorado

Posted 31 August 2019 - 09:52 PM

I typically run it at -20C even though that doesn't do much to reduce dark noise.  I've tested the camera with the set point at -20C, 10C, and 18C and it makes no difference--the camera always dies.  It's an interesting idea to just unplug the cooler to see what happens.

 

John

Yeah, I would just disable cooling of the ASI1600 alltogether and see how it goes. If TEC commands seem to be getting stuck in a loop, maybe taking the TEC out of the picture entirely will help.



#106 Corsica

Corsica

    Vendor (Innovationsforesight)

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

Posted 31 August 2019 - 10:17 PM

Yeah, I would just disable cooling of the ASI1600 alltogether and see how it goes. If TEC commands seem to be getting stuck in a loop, maybe taking the TEC out of the picture entirely will help.

I concur.

 

I could not find this on CN anymore, but I do remember years ago having read posts on USB hanging with some cameras (not the ZWO, there were not on the market yet) when cooling was used.

 

The problem was related, if I remember correctly, with some driver issues, with symptoms very similar to yours.

A conflict somewhere between the camera control and the cooler control.

 

Real time systems are complex and tricky, glitches can happen, due to missing proper synchronization tools or bad implementation leading to nasty problems which typically exhibits the type of random pattern you experience.

 

The probability of a real time issue, due to some design problems, may be very small, say once every few hours in your case.

 

Just as an example if we assume that you take a frame each 5s (to pick a number) and you have a real time glitch (average time between failure) every hour (to pick another number) this means, in average that it takes 720 frames before having any failure (camera frozen in this case).

 

With the same failure frame rate and an exposure time of 5 minutes (to pick yet another number), like when doing imaging with the same camera, the average time between a failure would be now around 60 hours, very unlike to happen during any imaging session.

Which may mean that the problem could very well be there for every users of the camera since some time but because its failure frame rate is so little, when using the camera for imaging (its primary goal) you can seldom expect to be hit by this live. Just a guess though.

 

In any case if this is a ZWO driver/hardware issue it should be found and fixed for good. They may just not have heard about it much yet.

 

For the time being disabling all together the cooler, since it is seldom useful for guiding anyway (I understand you elected the PRO version for its DRAM capability, not the cooler), should tell us if it is part of the equation.

I would monitor the UBS traffic to be sure there is no activity related to cooling the camera anymore indeed and also to catch and record the data in the event of another USB crash or erratic behavior, if any.

 

As I mentioned before, I and other users of the ZWO ASI1600MM uncooled have not experienced any issue. I do not have any experience with the cooled version.


Edited by Corsica, 01 September 2019 - 09:42 AM.

  • ollie31770 likes this

#107 lambermo

lambermo

    Viking 1

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

Posted 02 September 2019 - 02:27 PM

We cannot have John quit this hobby. Not an option ;-)

 

Where are we with things to try ? Is this the complete list so far ?

  1. Disable the USB power settings.
  2. Test your UPS output for a clean sine wave. Do you have an oscilloscope there to do so ?
  3. Try without using the cooler.
  4. Try a powered USB cable.
  5. Try without the ASCOM driver by talking to the ZWO camera via INDI on a separate computer (like a rpi for instance) but can be anything running Linux.

-- Hans


  • t-ara-fan likes this

#108 CygnusBob

CygnusBob

    Vostok 1

  • -----
  • Posts: 193
  • Joined: 30 Jun 2018
  • Loc: Las Vegas, NV

Posted 02 September 2019 - 03:32 PM

John

 

I have been using an ASI1600MM Pro with 5 second exposures for up to 3 hours without any problems.  I do run the cooler.  However I am using a Macintosh with software I wrote using ZWO's camera software development kit.  

 

One thing that puzzles me is in the messages that you recorded, all of those calls to the TEC.  Are they generated by the camera or from Maxim DL? In my code I just send a single command for the temperature  set point and tell the cooler to run and that is it for the next 3 hours.  There is no more communication with the cooler  except for reading the temperature achieved and the % power used, but no control commands to change anything.  No commands to do anything with the % power except to read what value the camera decides to use.

 

So maybe there is an issue with MaximDL or ASCOM.  There is no ASCOM on the Macintosh as you know.  I wonder if the Maxim DL or ASCOM folks are using the latest and greatest software library dlls from ZWO.  I am using the latest version available ( a Macintosh static library) on ZWO's web site.

 

I had some USB3 cable problems.  Fixed by just changing the cable.

 

I use a single 15 foot USB3 cable directly to the computers USB3 port.  I also have the filter wheel and an SBIG St-i camera plugged into the ZWO camera's USB hub.  I do supply the 12 volts to the cameras.  Seems to run just fine.

 

Bob


Edited by CygnusBob, 02 September 2019 - 05:43 PM.


#109 jhayes_tucson

jhayes_tucson

    Fly Me to the Moon

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

Posted 02 September 2019 - 05:48 PM

John

 

I have been using an ASI1600MM Pro with 5 second exposures for up to 3 hours without any problems.  I do run the cooler.  However I am using a Macintosh with software I wrote using ZWO's camera software development kit.  

 

One thing that puzzles me is in the messages that you recorded, all of those calls to the TEC.  Are they generated by the camera or from Maxim DL? In my code I just send a single command for the temperature  set point and tell the cooler to run and that is it for the next 3 hours.  There is no more communication with the cooler  except for reading the temperature achieved and the % power used, but no control commands to change anything.  No commands to do anything with the % power except to read what value the camera decides to use.

 

So maybe there is an issue with MaximDL or ASCOM.  There is no ASCOM on the Macintosh as you know.  I wonder if the Maxim DL folks are using the latest and greatest software library dlls from ZWO.  I am using the latest version available ( a Macintosh static library) on ZWO's web site.

 

I had some USB3 cable problems.  Fixed by just changing the cable.

 

I use a single 15 foot USB3 cable directly to the computers USB3 port.  I also have the filter wheel and an SBIG St-i camera plugged into the ZWO camera's USB hub.  I do supply the 12 volts to the cameras.  Seems to run just fine.

 

Bob

 

I'm communicating with ZWO about this and we see a lot of strange software calls.  We don't yet know the source but I suspect MaximDL.  I did a test with the camera cooler unplugged and the camera ran for 12 hours.  The folks at ZWO don't think that's a factor in this but I'm not so sure.  I'll tell you more of the story when I get closer to a solution.  Right now I'm pretty convinced that it's not the cable since we've tried two--both USB3 and USB2 with the same results.  I've tried different version of MaximDL and see the same issue.  I'm working on trying SGP next but it's all going to have to wait until I get back from a meeting this week.

 

John


  • Jon Rista likes this

#110 CygnusBob

CygnusBob

    Vostok 1

  • -----
  • Posts: 193
  • Joined: 30 Jun 2018
  • Loc: Las Vegas, NV

Posted 02 September 2019 - 06:07 PM

John

 

What if the Maxim DL or ASCOM people decided to implement their own temperature control routine.  I don't know why.  Maybe in the spirit of some general control scheme that would work with all cameras.  Maybe an object oriented software paradigm running amok.  It seems odd to me.

 

Good Luck!

 

Bob



#111 cfosterstars

cfosterstars

    Mercury-Atlas

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

Posted 02 September 2019 - 07:41 PM

John,

 

I know that this is a big issue for you and I wish I could help. One thing is that I stopped using MaximDL about three years ago since I had an issue and got no support to fix the issue from MaximDL. I went to SGP and have not looked back. I know that might be drastic, but is might be a consideration. I cant speak to everything that you have but I have had good luck running multiple ZWO cameras simultaneously with the only issues is the one I post previously that was resolved a USB speed of 40. Others will say SGP is terrible for this or that, but I have had good success with it. I wish I had more to offer.

 

Chris


Edited by cfosterstars, 03 September 2019 - 10:46 AM.


#112 jhayes_tucson

jhayes_tucson

    Fly Me to the Moon

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

Posted 02 September 2019 - 10:31 PM

Chris,

I've been in a detailed discussion with one of the programmers at ZWO.  After logging function calls to the SDK, we can see that MaximDL is not doing the right thing.  The basic problem is that they appear to have camera initialization instructions imbedded in the acquisition loop.  The guys at ZWO can't figure out why that should cause the problem, but one of their other guys has seen the same camera lock-up behavior when running similar code.  For some reason, after running for a while, the code stops acquiring data from the camera it and just monitors the cooler temperature.  I believe that the folks at DL wrote the acquisition code to work for a single frame grab and then simply imbedded that same code into the guide loop.That's not the right way to do things on a lot of levels.  The camera should be initialized when it is connected and the guide cycle should be a tight set of instructions in a loop.

 

I'm not very optimistic about getting the folks at DL to pay any attention to this problem but I'll give it a shot.  As it is, MaximDL is NOT compatible with the ASI-1600MM-C or the ASI-1600MM-C Pro used as a guide camera.  I suspect that it may have very similar problems using the same camera for short exposure imaging, but I haven't tested that claim.

 

I plan to switch to SGP to see if that will solve the problem.  The thing that concerns me is that I'll have to integrate SGP with PHD and FocusLock to accomplish dithering, guiding, and focusing.  Hopefully, it will all just work, but that's never been my experience with astro software.  There's always some problem...

 

 

John


  • WesC, BenKolt, Jon Rista and 3 others like this

#113 SXBB

SXBB

    Vostok 1

  • -----
  • Posts: 163
  • Joined: 05 Jul 2015

Posted 03 September 2019 - 01:41 AM

Hi John,

 

That's really great news that you've been able to figure out the problem!

I'm an ONAG/FocusLock/PHD2 user myself and I'm pretty happy with the way it all works together.  SGP does have a bit of a learning curve but it's pretty straightforward.  I'd be happy to TV with you to show you how I get it all going if you'd like.  Just PM me if you'd like to set it up.

 

Best,

 

Bruce



#114 Corsica

Corsica

    Vendor (Innovationsforesight)

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

Posted 03 September 2019 - 05:48 AM

Chris,

I've been in a detailed discussion with one of the programmers at ZWO.  After logging function calls to the SDK, we can see that MaximDL is not doing the right thing.  The basic problem is that they appear to have camera initialization instructions imbedded in the acquisition loop.  The guys at ZWO can't figure out why that should cause the problem, but one of their other guys has seen the same camera lock-up behavior when running similar code.  For some reason, after running for a while, the code stops acquiring data from the camera it and just monitors the cooler temperature.  I believe that the folks at DL wrote the acquisition code to work for a single frame grab and then simply imbedded that same code into the guide loop.That's not the right way to do things on a lot of levels.  The camera should be initialized when it is connected and the guide cycle should be a tight set of instructions in a loop.

 

I'm not very optimistic about getting the folks at DL to pay any attention to this problem but I'll give it a shot.  As it is, MaximDL is NOT compatible with the ASI-1600MM-C or the ASI-1600MM-C Pro used as a guide camera.  I suspect that it may have very similar problems using the same camera for short exposure imaging, but I haven't tested that claim.

 

I plan to switch to SGP to see if that will solve the problem.  The thing that concerns me is that I'll have to integrate SGP with PHD and FocusLock to accomplish dithering, guiding, and focusing.  Hopefully, it will all just work, but that's never been my experience with astro software.  There's always some problem...

 

 

John

Great news John,

 

Maybe it is time to consider using SKG again now.

The 64 bits version can connect to Maxim-DL but it does not need to, it can control the guider from the ASCOM driver (64 bits).
Also SGP uses our API to fully control SKG for guiding and dithering.

Let's talk off line when you have some time, I'll be more than happy to work with you.


Edited by Corsica, 03 September 2019 - 05:54 AM.


#115 Gary.McK

Gary.McK

    Viking 1

  • -----
  • Posts: 511
  • Joined: 29 Jan 2009
  • Loc: Geelong, Australia

Posted 03 September 2019 - 06:32 AM

Hi,

You may also wish to try Voyager...many hear have shifted from SGP to it. I swapped after SGP kept having is issues with unreliability. Voyager is the most bullet proof astro app I've ever used. It does no require Maxim to work...although it can utilise it.

 

Best of luck,

Gary



#116 SeymoreStars

SeymoreStars

    Mercury-Atlas

  • *****
  • Posts: 2,738
  • Joined: 08 May 2014
  • Loc: Pennsyltucky

Posted 03 September 2019 - 07:02 AM

Good news John I hope this solves your issue and you can get back to imaging full-time.



#117 PeteM

PeteM

    Mercury-Atlas

  • -----
  • Posts: 2,646
  • Joined: 12 Jul 2009
  • Loc: Southwest Michigan

Posted 03 September 2019 - 10:23 AM

John, another SGP-PHD-ONAG-Focuslock user here for the last couple of years and I can report no real problems at all with that combo.



#118 cfosterstars

cfosterstars

    Mercury-Atlas

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

Posted 03 September 2019 - 10:51 AM

Chris,

I've been in a detailed discussion with one of the programmers at ZWO.  After logging function calls to the SDK, we can see that MaximDL is not doing the right thing.  The basic problem is that they appear to have camera initialization instructions imbedded in the acquisition loop.  The guys at ZWO can't figure out why that should cause the problem, but one of their other guys has seen the same camera lock-up behavior when running similar code.  For some reason, after running for a while, the code stops acquiring data from the camera it and just monitors the cooler temperature.  I believe that the folks at DL wrote the acquisition code to work for a single frame grab and then simply imbedded that same code into the guide loop.That's not the right way to do things on a lot of levels.  The camera should be initialized when it is connected and the guide cycle should be a tight set of instructions in a loop.

 

I'm not very optimistic about getting the folks at DL to pay any attention to this problem but I'll give it a shot.  As it is, MaximDL is NOT compatible with the ASI-1600MM-C or the ASI-1600MM-C Pro used as a guide camera.  I suspect that it may have very similar problems using the same camera for short exposure imaging, but I haven't tested that claim.

 

I plan to switch to SGP to see if that will solve the problem.  The thing that concerns me is that I'll have to integrate SGP with PHD and FocusLock to accomplish dithering, guiding, and focusing.  Hopefully, it will all just work, but that's never been my experience with astro software.  There's always some problem...

 

 

John

John,

 

I have been using SGP now for about three years. If you decide to switch to SGP, and need any help, I would be happy to. I dont know ALL the ins and outs, but I run fully automated each night and just go to sleep. However, my rig is about 4 steps from my back door. SGP has also announced some future updates in Ver 3.1 and what is planned for V4 that should address many of its deficiencies including its autofocus efficency and accruacy and multi camera support. I am looking forward to the improvements, but I am still happy with what I get. Its not perfect for sure, but its not terrible either. It should be much better at version 3.1 and even more so with version 4. 

 

Chris 



#119 BenKolt

BenKolt

    Vanguard

  • *****
  • Posts: 2,168
  • Joined: 13 Mar 2013

Posted 03 September 2019 - 12:16 PM

Chris,

I've been in a detailed discussion with one of the programmers at ZWO.  After logging function calls to the SDK, we can see that MaximDL is not doing the right thing.  The basic problem is that they appear to have camera initialization instructions imbedded in the acquisition loop.  The guys at ZWO can't figure out why that should cause the problem, but one of their other guys has seen the same camera lock-up behavior when running similar code.  For some reason, after running for a while, the code stops acquiring data from the camera it and just monitors the cooler temperature.  I believe that the folks at DL wrote the acquisition code to work for a single frame grab and then simply imbedded that same code into the guide loop.That's not the right way to do things on a lot of levels.  The camera should be initialized when it is connected and the guide cycle should be a tight set of instructions in a loop.

 

I'm not very optimistic about getting the folks at DL to pay any attention to this problem but I'll give it a shot.  As it is, MaximDL is NOT compatible with the ASI-1600MM-C or the ASI-1600MM-C Pro used as a guide camera.  I suspect that it may have very similar problems using the same camera for short exposure imaging, but I haven't tested that claim.

 

I plan to switch to SGP to see if that will solve the problem.  The thing that concerns me is that I'll have to integrate SGP with PHD and FocusLock to accomplish dithering, guiding, and focusing.  Hopefully, it will all just work, but that's never been my experience with astro software.  There's always some problem...

 

 

John

John:

 

SGP's integration with PHD has worked well for me for several years now.  I've had few issues, none of which couldn't be solved quickly.  For the most part it just works behind the scenes without the need for my attention.

 

I have not yet implemented FocusLock through SGP, but it's on my to do list.  I've seen others on this forum that have done this successfully.

 

Ben


Edited by BenKolt, 03 September 2019 - 03:50 PM.

  • cfosterstars likes this

#120 cfosterstars

cfosterstars

    Mercury-Atlas

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

Posted 03 September 2019 - 03:01 PM

John:

 

SGP's integration with PHD has worked well for me for several years now.  I've had few issues, none of which couldn't be solved quickly.  For the most part is just works behind the scenes without the need for my attention.

 

I have not yet implemented FocusLock through SGP, but it's on my to do list.  I've seen others on this forum that have done this successfully.

 

Ben

I have used PHD2 with SGP for years also but not with focuslock. I would actually be interested to see how this would work. Does this require on ONAG? I thought that it did.



#121 MikeMiller

MikeMiller

    Viking 1

  • -----
  • Posts: 902
  • Joined: 22 Jul 2014
  • Loc: Pittsburgh, PA, USA

Posted 03 September 2019 - 03:08 PM

Please disregard my previous comment on USB naming specifications.

 

Just released today, USB-IF is once again retroactively renaming the standards and making them even more confusing. 

 

https://www.techrepu...h-usb4-gen-3x2/



#122 BenKolt

BenKolt

    Vanguard

  • *****
  • Posts: 2,168
  • Joined: 13 Mar 2013

Posted 03 September 2019 - 03:59 PM

I have used PHD2 with SGP for years also but not with focuslock. I would actually be interested to see how this would work. Does this require on ONAG? I thought that it did.

Maybe Gaston can chime in about this point, but I think FocusLock does not necessarily require the ONAG be in place.

 

But what it does require is application of astigmatism similar to what the ONAG places on the guide star with transmission through its dichroic beam splitter to the guide port.  IF sells a small astigmatism corrector that can be placed in its guide port to dial back or correct that astigmatism, and I imagine that this little corrector could instead be placed in front of any guide camera, let's say in an OAG or maybe even between a guidescope and guide camera.  At first blush, I think that could work in causing the star shape to distort astigmatically through focus.  It's the changing of this distortion through focus that FocusLock measures when adjusting focus position.

 

Whether or not this would work well I couldn't say as I have not done it.

 

Ben



#123 spokeshave

spokeshave

    Vanguard

  • *****
  • Posts: 2,302
  • Joined: 08 Apr 2015

Posted 03 September 2019 - 06:43 PM

Maybe Gaston can chime in about this point, but I think FocusLock does not necessarily require the ONAG be in place.

 

But what it does require is application of astigmatism similar to what the ONAG places on the guide star with transmission through its dichroic beam splitter to the guide port.  IF sells a small astigmatism corrector that can be placed in its guide port to dial back or correct that astigmatism, and I imagine that this little corrector could instead be placed in front of any guide camera, let's say in an OAG or maybe even between a guidescope and guide camera.  At first blush, I think that could work in causing the star shape to distort astigmatically through focus.  It's the changing of this distortion through focus that FocusLock measures when adjusting focus position.

 

Whether or not this would work well I couldn't say as I have not done it.

 

Ben

I don't know if it is IF or not that makes the Lacerta, but it is sold by Optec, and it only works with Lodestar cameras. It is not cheap for what it is ($250) and you still have to pay another $100 for FocusLock. I could never get it to work properly (well, at all actually).

 

Tim



#124 jhayes_tucson

jhayes_tucson

    Fly Me to the Moon

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

Posted 04 September 2019 - 12:33 PM

First off, thanks for all of the offers of help!  As I get further along getting SGP set up, I may need it.

 

Second, I wanted to follow up with report on my experiments with disconnecting power to the ASI-1600MM-C Pro cooler.  A few days ago, while the roof on the Alpha observatory at DSW was broken, I used MaximDL (V6.20) to turn on the cameras and run them to see how long they would go without stopping.  I accidentally also connected the focuser system (which I had intended to leave off.)  In this test, the ASI-1600 ran for 12 hours straight until something crashed in the focusing system (I've never had a problem with this but the crash may have been a side effect of running the guider loop continuously with only the camera and the focuser connected--so I'm not going to worry about it.)

 

Last night, the roof was open and the sky was clear so I set up to guide on an object for 6.5 hours and the sequence ran all the way to the end without a hitch.  This is NOT a definitive test, but it looks like the odds are good that the camera can be run with reasonable reliability under MaximDL with the cooler disabled.

 

I still plan to install and commission SGP Pro when I have a little more time next week and we'll see how that goes.  I also plan to talk with the folks at DL about all this.  Hopefully, they will be receptive to fixing the problem but at least I have a path forward if they are not.

 

Whew...looking back, it has taken, countless trips, a lot of money, and nearly two years to solve this problem--and I finally feel like a have a clue about what's going on.  Hopefully, I can get back to just taking images, without a long tale of woe about all the stuff that went wrong.  I have my fingers crossed that I can finally get everything configured to simply work.  I'm not there yet, but maybe I'm a step closer.

 

John

 

 

 

PS  The folks at TeamViewer lifted my "commercial use" ban yesterday.   So things are looking up.  Chrome Remote Desktop has been working really well so I'll probably just keep TV as a backup.


Edited by jhayes_tucson, 04 September 2019 - 12:39 PM.

  • tjay, BlueGrass, WesC and 3 others like this

#125 Corsica

Corsica

    Vendor (Innovationsforesight)

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

Posted 04 September 2019 - 02:17 PM

Maybe Gaston can chime in about this point, but I think FocusLock does not necessarily require the ONAG be in place.

 

But what it does require is application of astigmatism similar to what the ONAG places on the guide star with transmission through its dichroic beam splitter to the guide port.  IF sells a small astigmatism corrector that can be placed in its guide port to dial back or correct that astigmatism, and I imagine that this little corrector could instead be placed in front of any guide camera, let's say in an OAG or maybe even between a guidescope and guide camera.  At first blush, I think that could work in causing the star shape to distort astigmatically through focus.  It's the changing of this distortion through focus that FocusLock measures when adjusting focus position.

 

Whether or not this would work well I couldn't say as I have not done it.

 

Ben

FocusLock (FL) or SkyGuard (SKG) both use the astigmatism of the ONAG guider port, or LACERTA with an OAG. The former using a guide star from a third party auto-guiding software the latter the all image (frame) of the guider regardless its content (there must be something else than noise of course).

 

This patented technology was designed around the ONAG. In order to provide a solution for OAG users OPTEC sells, under license from us, their LACERTA optical device for Lodestar users.

 

When using an OAG the FOV may be limited and the guide star may exhibit abberations. Depending of the scope model and F/# this may impact the FL performance.

Unlike FL SKG is not based to any centroid (no explicit guide star) and therefore is much more immune to the "shape" and quality of the guide star in the context of an OAG. As a consequence off axis guide stars are less a concern for live focusing when using SKG.

 

There are other differences at play, for instance using the ONAG means working in NIR with the guider, which may help depending of the local seeing.

 

I cannot not say for sure but I would guess that the ONAG astigmatism corrector may not be the best candidate for an OAG and FL. It has been designed to compensate most of the NIR astigmatic aberration of the ONAG guider port under a specific geometry and wavelengths.

Here again SKG could lead to better result by the nature of its full frame processing approach.


Edited by Corsica, 04 September 2019 - 02:18 PM.



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