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

#126 Seanem44

Seanem44

    Vanguard

  • *****
  • Posts: 2,266
  • Joined: 22 Sep 2011
  • Loc: Stafford, VA

Posted 05 September 2019 - 06:35 AM

Wow John...  crazy ride you have been on.  Hope this is the end of the journey and you can image pain free.  I swear by my ZWO 1600 and am fortunate I haven't had any major issues other than frosting up at a Star Party two years ago which was fixed with an easy $15 heater sold on ZWO's site.  Best of luck!!!



#127 AIP

AIP

    Vostok 1

  • -----
  • Posts: 194
  • Joined: 14 Feb 2019
  • Loc: Madrid, Spain

Posted 05 September 2019 - 09:44 AM

Sorry to hear about all this bawling.gif



#128 Jon Rista

Jon Rista

    ISS

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

Posted 06 September 2019 - 01:29 AM

 

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.

 

This is really great to hear, John! It has really been a long and clearly frustrating journey. I think you are indeed zeroing in on the cause of the problem, finally, and hopefully you can get the DL guys to implement a fix so you can truly rest easy about not having problems again in the future. Man, all the money you have spent trying to resolve this issue... 



#129 jhayes_tucson

jhayes_tucson

    Fly Me to the Moon

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

Posted 07 September 2019 - 12:45 AM

Thanks Jon.  I have to report that I was being presumptuous about the response that I might get out of the DL folks and frankly it was wrong to express an opinion before even asking.  In the meantime, I've contacted DL on their support forum and so far, Collin is all ears and has expressed nothing but willingness to pull whatever resources necessary to solve this problem.  I am very impressed with Colin's responses and very encouraged.  So, I want to be careful to clearly take back everything I said about my expectations and I apologize for begin so opinionated without any real reason.  Hopefully we can get this thing figured out and completely resolved for future users.

 

John


  • Bart Declercq, WesC, Jon Rista and 1 other like this

#130 gunny01

gunny01

    Vanguard

  • *****
  • Posts: 2,219
  • Joined: 02 Jun 2014

Posted 07 September 2019 - 10:25 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

  I never had luck with Maxim version666 as I called it.  They always had me sending in logs and blamed everything on the hub.  The problems I had with it and remote operation were similar to yours going back about 5 years.  Their excuse was that it was my equipment that was causing the problem.  $800 down the drain.

 

  It would work for a while at night, then just drop connections.  I got fed up with Doug and his team and just took the screwing.  I have since gone with SGP and have never looked back.  No dropped connections in the 4-5 years that I have been using it. 

 

  I would highly recommend that you make the switch.  Free trial for 45 days or longer.  What do you have to lose other than misplaced loyality?

 

  There is also acp for guys like you with distant remote sites.  Bob Denny is a good guy.



#131 bigjy989

bigjy989

    Vostok 1

  • -----
  • Posts: 119
  • Joined: 23 Nov 2010
  • Loc: Saline, MI

Posted 07 September 2019 - 10:43 AM

Sorry to hear about your struggles.

 

One other idea:   I've had issues with an ASI1600 randomly hanging over USB to an ICRON CAT5 if the guiding subexposure (QHY5L-ii) is less than about 3s.     The issue goes away with guiding exposures greater than 4s implying that the ASI1600 image download interferes or hangs when the guide camera sends its image and it can't handle successive wait commands. I.e. Guide download in progress - ASI (wait) - ASI (commence) - next guide subexposure start before ASI finished =hung camera.   At 3s I can usually get 5-6 images to download before the successive wait and hung camera.   Less than 2s usually hung after first frame.   More than 4s usually good for 10+ sessions until I forget and turn the guide exposure down...   semi-permanent setup with SGP.

 

By any chance are your guide exposure frequency less than the ASI image transfer time on your system?



#132 Corsica

Corsica

    Vendor (Innovationsforesight)

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

Posted 07 September 2019 - 11:11 AM

Sorry to hear about your struggles.

 

One other idea:   I've had issues with an ASI1600 randomly hanging over USB to an ICRON CAT5 if the guiding subexposure (QHY5L-ii) is less than about 3s.     The issue goes away with guiding exposures greater than 4s implying that the ASI1600 image download interferes or hangs when the guide camera sends its image and it can't handle successive wait commands. I.e. Guide download in progress - ASI (wait) - ASI (commence) - next guide subexposure start before ASI finished =hung camera.   At 3s I can usually get 5-6 images to download before the successive wait and hung camera.   Less than 2s usually hung after first frame.   More than 4s usually good for 10+ sessions until I forget and turn the guide exposure down...   semi-permanent setup with SGP.

 

By any chance are your guide exposure frequency less than the ASI image transfer time on your system?

There is something wrong here. I can run my ASI1600MM with SKG using exposures as little as 100ms (0.1s) when doing some testings on my optical bench with an artificial star, so much bright that I need to use such a short exposure.

I would not advice to use so short exposures for guiding, 5s or more is fine (the longest you can afford would be the best), but my point here is about the ASI1600MM capability.

 

The time between two frames is related to the rate of ASI1600MM frame download (SKG will request a new exposure after the camera has finished the download) which is around one frame per second in my case (0.1s exposure) or so since I have an USB hub with a USB 2 connection to the PC in this configuration.

I suspect if I would use an USB 3 I could go faster. I have run this for days with 16M pixels (bin 1x1) frames without any issue using the ASI1600MM (uncooled).

I use the ZWO ASCOM driver.

 

Therefore I do not thing there is any intrinsic ZWO camera, nor driver, limitation at play here.

 

My guess is issues with short exposures are more about how the guiding/imaging software interacts and manages its interface with the camera (through the driver) than about the camera/driver itself.



#133 CygnusBob

CygnusBob

    Vostok 1

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

Posted 07 September 2019 - 11:19 AM

Corsica

 

I can download 3840 x 2160 images from my ASI1600MM Pro in less than 0.25 seconds over the USB3 interface.  This is operation in what ZWO calls the snap shot mode not the video mode.  In the video mode with 12 bits, ZWO says it can run at up to 23.1 frames per second with this frame size.

 

Bob


Edited by CygnusBob, 07 September 2019 - 11:26 AM.


#134 bigjy989

bigjy989

    Vostok 1

  • -----
  • Posts: 119
  • Joined: 23 Nov 2010
  • Loc: Saline, MI

Posted 07 September 2019 - 11:53 AM

There is something wrong here. I can run my ASI1600MM with SKG using exposures as little as 100ms (0.1s) when doing some testings on my optical bench with an artificial star, so much bright that I need to use such a short exposure.

I would not advice to use so short exposures for guiding, 5s or more is fine (the longest you can afford would be the best), but my point here is about the ASI1600MM capability.

 

The time between two frames is related to the rate of ASI1600MM frame download (SKG will request a new exposure after the camera has finished the download) which is around one frame per second in my case (0.1s exposure) or so since I have an USB hub with a USB 2 connection to the PC in this configuration.

I suspect if I would use an USB 3 I could go faster. I have run this for days with 16M pixels (bin 1x1) frames without any issue using the ASI1600MM (uncooled).

I use the ZWO ASCOM driver.

 

Therefore I do not thing there is any intrinsic ZWO camera, nor driver, limitation at play here.

 

My guess is issues with short exposures are more about how the guiding/imaging software interacts and manages its interface with the camera (through the driver) than about the camera/driver itself.

In my case, I agree the issue lies in how the various software interacts with each other.  I only have the option of using USB2, a hub, which then goes to CAT5 and then to a fairly old laptop and slow hard drive.    It is about 2.5 s to download a frame in my case (USB speed 40 in the ASI driver).    

 

The point is that each system needs to be managed differently depending on the components involved.   In my case it will hang 100% of the time if the guiding bandwidth and camera bandwidth exceed a buffer limit somewhere in the system.   I cannot expect the software/drivers to be fully aware of all combinations of hubs to be able to react accordingly to fluctuations in bandwidth.


Edited by bigjy989, 07 September 2019 - 12:08 PM.


#135 Tonk

Tonk

    Cosmos

  • *****
  • Posts: 9,292
  • Joined: 19 Aug 2004
  • Loc: Leeds, UK, 54N

Posted 07 September 2019 - 12:03 PM

Hi Jon,

I'm late to this and read only the first 3 pages - then I rushed here with my own experiences of running a remote rig. If any of what I say below has been said before in this thread I apologize. I think you know I've been building a remote rig for over 3 years now - and its been operating remotely now for 6 months in southern Spain - but not without a few camera problems.

Some the key discovery/decisions I made regarding reliability while building and testing the rig where:

1) Install USBTreeView ( https://www.uwe-sieb...treeview_e.html ) so you can watch how your USB is performing in real time. Locked up and errored devices show up near instantly and you usually get to see the error codes (which can be Googled).

2) Use powered hubs. If you can, make sure the hubs can be configured so power pass-through is turned off. I.e. if you turn the USB Hub power off via a remote controlled relay then all down stream devices become un-powered. This is a simple way to force a USB reset - just cycle the USB hub power to get devices to restart without having to cycle the main computer. (I use StarTech industrial hubs mounted on the OTA - these have internal jumpers to setup various power configurations). There are also specialist USB hubs that can power cycle each port individually (Google "USB per port power control") - they are relatively expensive (but small beer in the scope of your problem) and typically use one the the USB ports to control the power switching on the others. See https://www.yepkit.com/products/ykush for an example

3) If your camera has both USB power and 12v power intakes (my SX46 and QSI 683 are both like this) I have added dedicated buck-boost 12V precision regulators right next to the cameras

4) Camera reliability drops over summer months for my rig. The root cause is the current drawn by the camera coolers (especially my SX46) when battling with high ambient night temperatures. I've had trouble with my SX46 drawing way too much power when cooling, operating the shutter and running the A/D converter at the same time (current peaks briefly >5A under certain circumstances) resulting in a short period voltage drop which in turn messes up the required stable reference voltage to the A/D convertor which in turn leads to a corrupted image. Moral of the story here is you need to have a lot of head room for your camera regulated power supply - i.e it must maintain a fixed voltage up to and including the max current draw your camera takes - and don't accept the manufactures max current as gospel - see next point.

5) This might not be possible now in your rig if its already built - but I instrumented my key power lines (main DC input, camera 1, camera 2, heaters) so I could see exactly what was going on. This uses an Arduino Mega and a bunch voltage and current sensors. The reasons for my very recent summer woes with power and cameras was very easy to see in the graphs - the 5 second cooler current cycle was plain to see, as was the shutter motor current peaks at start and end of the exposure and the A/D convertor current draw during image download. In my case I could see that if the cooler happened to reach peak current draw in its cycle at the same time the shutter operated at the end of the exposure that I was going to get a corrupted image as I could also see the regulated camera input voltage collapse  briefly as the regulator was overwhelmed by the excessive but brief current draw. My solution is to beef up the camera regulator (something I'm working on now) - and not to take too seriously the manufacturers max current rating - in fact take what they say and multiply by at least 2.5. Again the moral here is problems become easier to solve if you know more about what is actually going on. I am very thankful that I did decide in the end to instrument - it was a little last minute in the decision making.

I hope some of this might help you.

Cheers, Tony

PS Here a link to my rig wiring - note the USB hubs are powered and the power is under remote relay control. https://www.astrobin...387836/?nc=user

Other than my own camera woes - the rest of the rig performs nearly flawlessly. Only one SX Lodestar guide cam lock up and one QSI lock up so far. Both fixed by cycling the USB hub power and not needing the main PC to be cycled. However SGP did lock up so the devices needed "software" disconnecting and reconnecting as well. You need to be awake to fix this ..... hence ....

As a footnote to this I'm now enaged in writing a USB monitoring program that will Text / WhatsApp me if key devices enter an error state so I can deal with them.

 


Edited by Tonk, 07 September 2019 - 12:08 PM.

  • jdupton, WesC and scadvice like this

#136 stryker66

stryker66

    Ranger 4

  • *****
  • Posts: 331
  • Joined: 31 Jul 2018

Posted 07 September 2019 - 01:24 PM

I have 3 ASI1600mm Cooled running at the same time and two ASI EFW connected to wherever camera I want and I have no problem running it on a 16ft USB3 cable. The secret is to tone down the USB3 speed. I set mine to 70 in ascom. aside from that I have guide camera and mount and focusers riding on same wire. Zero problems



#137 jhayes_tucson

jhayes_tucson

    Fly Me to the Moon

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

Posted 07 September 2019 - 05:22 PM

Tony,

Thanks for that but you should review post #112 on page 5.  I know it's hard to dig through everything, but you've missed my posts describing the discovery of the problem and its initial solution.  I've been at least as diligent as you have in designing the topology of my system and endlessly chasing USB issues, USB hub issues, EMI filters, power supply uncertainties, and other potential hardware related issues has turned out to be a total red herring.  None of that stuff made any difference.

 

The problem turns out to be a software (or possibly an obtuse temperature controller) related problem specific to MaximDL, the ASI-1600MM-C (both Cool and Pro) camera, and/or ZWO software.  Right now, the most likely source appears (at least to me) to be somewhere within MaximDL but we are still working to find the bug to accurately eliminate the failure mechanism.  It appears to be related to temperature control and when I know the exact cause, I'll report on it.

 

John



#138 jhayes_tucson

jhayes_tucson

    Fly Me to the Moon

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

Posted 07 September 2019 - 05:24 PM

I have 3 ASI1600mm Cooled running at the same time and two ASI EFW connected to wherever camera I want and I have no problem running it on a 16ft USB3 cable. The secret is to tone down the USB3 speed. I set mine to 70 in ascom. aside from that I have guide camera and mount and focusers riding on same wire. Zero problems

 

Are you running those cameras with MaximDL?  If so, please tell me the version number and how many frames you download each night.

 

John



#139 cfosterstars

cfosterstars

    Mercury-Atlas

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

Posted 07 September 2019 - 05:25 PM

John,

I hope that you get better support from DL than I did. I got basically ignored for 5 months with no response to repeated requests for any updates. Basically nothing. I gave up and sent 600$ down the drain. Switched to SGP and have not looked back. 

 

Chris


  • SeymoreStars likes this

#140 CygnusBob

CygnusBob

    Vostok 1

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

Posted 07 September 2019 - 05:59 PM

John

 

A problem with software constantly allocating memory for camera imagery and then deallocating memory when the grab image routine is finished is if main memory becomes fragmented, the operating system may deny the application access to a block of memory by returning a null pointer. If the application checks the pointer and it discovers that it does not have a valid place to get the data, well then game over.  No more new imagery will come down the pipeline.

 

Or they don't deallocate the memory, which would be even worse, a memory leak!   All available memory would be allocated which would leave no new memory for another image.

 

However you can run the camera a long time with the cooler turned off.  How running or not running the cooler effects the camera image grabbing process is a mystery to me, unless the cooler control code somehow uses a lot of memory (this would not make much sense, but you never know).

 

It might be instructive to monitor memory usage with the cooler running and without.

 

 

Bob


Edited by CygnusBob, 07 September 2019 - 06:20 PM.


#141 jhayes_tucson

jhayes_tucson

    Fly Me to the Moon

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

Posted 12 September 2019 - 05:58 PM

I hate to keep this thread going but I wanted to wrap it up with my latest test results and interaction with the folks at DL.  At first, the folks at DL were very receptive to my problem; but as the discussion progressed I found myself with a lot of testing assignments from them.  I've attached a matrix of tests that I did.  In the meantime, I discussed the issue with the folks at ZWO.  They said that their code does not have any problem running the ASI-1600MM-C Pro for as long as they can let it go.  We put a SDK logger on my system so that we could see what is happening and they told me that it looked like MDL was calling unnecessary functions, but they admitted that it shouldn't be a problem.  The folks at ZWO seemed convinced that there was something wrong in the main calling program--in this case--MaximDL.  After working through lot of testing, I finally ran PHD so that it continuously downloaded images from the camera and after nearly 7.5 hours, I managed to trap pretty much the same (or at least similar) bug.  PHD has a function that restarts the camera if it detects a fault so it was a bit of a challenge to figure out what was happening.  It turn out that it does restart the camera but it does not turn the cooler back on.  Either way, something screwy is happening.

 

I reported this result to the folks at DL so that we could discuss how to proceed and they immediately declared that it wasn't their problem and closed the case.  So much for their support and my previous optimism that they might be willing to actually fix the problem.  At a more basic level was the way that they handled this.  They could have talked to me about it, they could have asked for my opinion, or they could have made some suggestions; but, instead, they unilaterally declared that the case is closed.  I won't comment on their technical expertise, but they sure need some people at that company with some people skills.

 

So the folks at ZWO haven't done any testing and they don't think that it's their problem.  The folks at MDL haven't done any testing either and they've declared that it's not their problem.  So this whole issue that has cost me tens of thousands of dollars trying to identify and fix (yes, that's right) has now been declared a "not my problem" problem.  ZWO won't fix the camera, they've declared that since it works fine on their little frame grabber program, there isn't a problem.  (ZWO is on a holiday right now, so I haven't totally 100% given up on them; but, right now, it doesn't look good.)  The folks at Diffraction Limited clearly have no interest in fixing this so it's a dead issue--even though there is definitely a bug in the control code somewhere.

 

The only consolation is that I can run the camera with the cooler disabled and still make it work.  Clearly switching to SGP won't change things other than to get away from MDL...and that seems worthwhile at this point.  After this experience, I sure wouldn't ever consider buying anything from them ever again.

 

John

 

Attached Files


  • rockstarbill and bugbit like this

#142 Terry White

Terry White

    Vostok 1

  • -----
  • Posts: 188
  • Joined: 13 Sep 2017
  • Loc: Knoxville, Tennessee.

Posted 12 September 2019 - 06:41 PM

John, I have been closely following your interaction with the MaximDL folks, as I also have MaximDL, an ONAG, and several ZWO cameras. I must say that I was shocked at how quickly they closed your support ticket once they heard that you got another piece of software to hang your camera. Very crummy support, IMHO. I think I heard from Jon Rista that SGP has better (native?) ZWO driver support compared to MaximDL's generic ASCOM support, so that may be an option to consider. Optec's FocusLock (using Gaston's ShrapLock technology) is also compatible, so your ONAG should also work using Optec's ASCOM server. Franky, I'm considering dropping MaximDL as well. Hang in there.


Edited by Terry White, 12 September 2019 - 06:42 PM.


#143 jhayes_tucson

jhayes_tucson

    Fly Me to the Moon

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

Posted 12 September 2019 - 06:51 PM

John, I have been closely following your interaction with the MaximDL folks, as I also have MaximDL, an ONAG, and several ZWO cameras. I must say that I was shocked at how quickly they closed your support ticket once they heard that you got another piece of software to hang your camera. Very crummy support, IMHO. I think I heard from Jon Rista that SGP has better (native?) ZWO driver support compared to MaximDL's generic ASCOM support, so that may be an option to consider. Optec's FocusLock (using Gaston's ShrapLock technology) is also compatible, so your ONAG should also work using Optec's ASCOM server. Franky, I'm considering dropping MaximDL as well. Hang in there.

Terry,

Remember that SGP uses PHD for guiding and it showed the same behavior.

John


  • rockstarbill likes this

#144 scadvice

scadvice

    Vanguard

  • *****
  • Vendors
  • Posts: 2,212
  • Joined: 20 Feb 2018
  • Loc: Lodi, California

Posted 12 September 2019 - 06:52 PM

Thanks John for the follow up. Sorry it was wasn't a positive one.



#145 Terry White

Terry White

    Vostok 1

  • -----
  • Posts: 188
  • Joined: 13 Sep 2017
  • Loc: Knoxville, Tennessee.

Posted 12 September 2019 - 06:54 PM

Can't you just use SkyGuide/Skyguard instead of PhD?


Edited by Terry White, 12 September 2019 - 07:09 PM.


#146 rockstarbill

rockstarbill

    Cosmos

  • *****
  • Posts: 7,619
  • Joined: 16 Jul 2013
  • Loc: Snohomish, WA

Posted 12 September 2019 - 07:41 PM

Terry,

Remember that SGP uses PHD for guiding and it showed the same behavior.

John

It can use MetaGuide as well. 



#147 Jon Rista

Jon Rista

    ISS

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

Posted 12 September 2019 - 10:10 PM

Terry,

Remember that SGP uses PHD for guiding and it showed the same behavior.

John

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?



#148 Jon Rista

Jon Rista

    ISS

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

Posted 12 September 2019 - 10:11 PM

John, I have been closely following your interaction with the MaximDL folks, as I also have MaximDL, an ONAG, and several ZWO cameras. I must say that I was shocked at how quickly they closed your support ticket once they heard that you got another piece of software to hang your camera. Very crummy support, IMHO. I think I heard from Jon Rista that SGP has better (native?) ZWO driver support compared to MaximDL's generic ASCOM support, so that may be an option to consider. Optec's FocusLock (using Gaston's ShrapLock technology) is also compatible, so your ONAG should also work using Optec's ASCOM server. Franky, I'm considering dropping MaximDL as well. Hang in there.

SGP does have native (integrated) support for ZWO cameras. HOWEVER, since SGP uses external guide programs, and since John noticed a problem with PHD, switching to SGP may not resolve the issue.

 

MetaGuide is also an option with SGP, so he could try that. But if the issue is not solely due to MDL issuing incorrect commands, then MetaGuide may not resolve the issue either.



#149 rockstarbill

rockstarbill

    Cosmos

  • *****
  • Posts: 7,619
  • Joined: 16 Jul 2013
  • Loc: Snohomish, WA

Posted 13 September 2019 - 12:26 AM

SGP does have native (integrated) support for ZWO cameras. HOWEVER, since SGP uses external guide programs, and since John noticed a problem with PHD, switching to SGP may not resolve the issue.

 

MetaGuide is also an option with SGP, so he could try that. But if the issue is not solely due to MDL issuing incorrect commands, then MetaGuide may not resolve the issue either.

In fact it could exacerbate the issue given it uses DirectShow. 



#150 gunny01

gunny01

    Vanguard

  • *****
  • Posts: 2,219
  • Joined: 02 Jun 2014

Posted 13 September 2019 - 07:27 AM

John, I have been closely following your interaction with the MaximDL folks, as I also have MaximDL, an ONAG, and several ZWO cameras. I must say that I was shocked at how quickly they closed your support ticket once they heard that you got another piece of software to hang your camera. Very crummy support, IMHO. I think I heard from Jon Rista that SGP has better (native?) ZWO driver support compared to MaximDL's generic ASCOM support, so that may be an option to consider. Optec's FocusLock (using Gaston's ShrapLock technology) is also compatible, so your ONAG should also work using Optec's ASCOM server. Franky, I'm considering dropping MaximDL as well. Hang in there.

  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.     




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