iGuider flakey behavior in CEM70G, plus bug in PHD2 logging

[DesertCrawler]

I am curious if people are successfully using the CEM70G iGuider. It may help me decide how to proceed.

Long post. Sorry.

Mount firmware is up to date.

ASCOM is the latest available and has been reinstalled.

Correct FTDI USB driver is installed and reinstalled.

The camera always shows up correctly in Windows 10.

USB 3, excellent quality shielded and RF choked minimum length cable from imaging computer to the mount.

The problem comes PHD2 is directed to use the camera. It connects and is business as usual for some amount of time. Then without any other hints found to date, PHD stops getting subs. No hints in the logs except guide star not found. The camera is connected as far as PHD2 is concerned ,and Windows for that matter.

There's also a bug in the error message which is curious. See SNR below. It is like the c format specifier is being emitted, and SNR should always non-negative. Cursory scan of the source didn't reveal anything obvious, but clearly there's a bug lurking. 

22:20:08.477 00.001 7516 OnExposeComplete: enter

22:20:08.480 00.003 7516 UpdateGuideState(): m_state=1

22:20:08.483 00.003 7516 Star::Find(15, 44, 347, 0, (0,0,0,0), 0.0, 65535) frame 1

22:20:08.486 00.003 7516 Star::Find returns 0 (3), X=44.00, Y=347.00, Mass=0, SNR=-1.$, Peak=0 HFD=0.0 <=============== SNR value is oddly formatted

22:20:08.489 00.003 7516 Error thrown from C:\cygwin\home\agalasso\projects\phd2\guider_multistar.cpp:940->UpdateCurrentPosition():newStar not found

22:20:08.493 00.004 7516 Throw from C:\cygwin\home\agalasso\projects\phd2\guider.cpp:1345->unable to update current position

22:20:08.496 00.003 7516 Status Line: Star lost - low mass

Disconnect and reconnect within PHD2 does not resolve the issue.

Disconnect in PHD2, reset the driver using devmgmt.msc (Device Manager) then reconnect in PHD2 will either 1) cause PHD2 to be happy again or 2) cause PHD2 to crash hard without notice or fanfare. If it chooses to crash, restarting PHD2 will use the camera again more or less correctly until this happens again, anywhere from minutes to maybe up to an hour.

The other flakey thing is PHD2 doesn't always find the appropriate gain setting which is tied to sub length per the iOptron documentation. This feature really should be transparent to the user. I find it is only marginally useful if I manually set the gain to match the sub duration per the iGuider doc, otherwise it is hit or miss if PHD sees and displays an appropriate image. Again, no hints in logs.

Drivers have been uninstalled and reinstalled. It is not a power issue (that I can control) -- there's ample, stable, low sag power, zero doubt about that.

If it is USB traffic issue, it isn't showing up in USB logs. Image camera is a ZWO ASI094MC in this case which is a FF USB 3 device. Errors in PHD2 do not coincide with the large imaging camera file downloading. If a USB traffic issue, it is only the mount and the guide camera at play, neither of which are high traffic in a USB 3 situation.

When it works, it works just fine for my purpose but is too unreliable to set and forget, so I have stopped using it. I would prefer to have it working reliably however.

Pure speculation at this point: PHD uses the open source WDM driver for this camera. The problem could actually be there, or perhaps some oddity in PHD around the way the driver is being used, or maybe even the firmware in the camera itself. I've browsed the source for PHD and dove into the WDM driver a bit but nothing obvious stood out, and not inclined to attach a debugger. Other fish in the fryer these days.

It appears the WDM API for grabbing the image fails which is caught by PHD, without any error surfaced by PHD2 beyond the log entry, which results in PHD to conclude there are no stars. When this happens, somehow the connection becomes corrupt even though Windows believes the iGuider is healthy and is in use. Remediation requires disconnecting and restarting PHD2 and sometimes (not always) the camera via device manager.

I have yet to contact iOptron on the topic. It is not a critical path item at the moment and my patience for things iOptron is a little thin these days. My GEM45 and CEM70 serve their purpose very well, most nights. They are generally good value at the price point but not without irritants, perhaps expected at this price point.

Still, I did pay for the feature, and it should work.

Anyway, thoughts? 

If it's an iOptron problem, likely will just drop it for a while and write off the feature. No matter the case, the WDM driver should respond differently, or PHD2 if there is visibility into whatever error is being surfaced. It is possible the firmware does not surface some underlying hardware issue to WDM though, clearly making it an iOptron problem.

Logs attached.

Thanks for any insights.

[bw_msgboard]

Don't really know what to tell you on this.  I am aware of at least one user other who has posted logs using this mount and his multi-hour sessions don't show any of these timeout conditions.  That's what's happening, the camera/driver isn't completing a command to either start or terminate an exposure.  From our point of view, the WDM interface is little-used and quite limited - it's generally a lowest common denominator option for cameras that don't have a specific driver.  All of the normal guide cameras we see have their own, vendor-provided drivers.  The business with the poorly formatted SNR value is just a consequence of us not having special handling for cases where the WDM device doesn't return anything at all - nothing to do with your actual problem and only something of interest to developers.  I'll log it as an open issue in any case.  All I can suggest is that you poke around in all the usual areas where camera timeouts become a problem:

 

https://openphdguiding.org/man/Trouble_shooting.htm#Problems-_Camera_Timeouts

 

Beyond the obvious areas of USB subsystem bandwidth, you probably have to consider power delivery requirements and whether Windows is "managing" the USB port(s) as part of a power conservation scheme.  The only good news is that you can mostly trouble-shoot these things in the daytime.

 

Even before you ran into problems with the camera, you were getting some pretty unsatisfactory tracking results:

 

 

These large deflections are externally induced, not anything caused by guiding.  Of course, the very coarse guider image scale makes the system very sensitve to things like cable drags.

 

Good luck,

Bruce

 

 

---

From: open-phd...@googlegroups.com [mailto:open-phd...@googlegroups.com] On Behalf Of DesertCrawler
Sent: Sunday, October 17, 2021 4:13 PM
To: Open PHD Guiding
Subject: [open-phd-guiding] iGuider flakey behavior in CEM70G, plus bug in PHD2 logging

--
You received this message because you are subscribed to the Google Groups "Open PHD Guiding" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-phd-guidi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/37e00963-790d-434c-8e2b-8f974dc2cbfan%40googlegroups.com.

[DesertCrawler]

I see that there are two iOptron iGuider camera options listed in PHD2 camera devices dropdown list.

One is "iOptron iGuider" and the other is "iOptron iGuider (ASCOM Camera)".

What is the difference between the two options?

The ASCOM entry is presumably what is installed from iOptron_iGuider_ASCOM_Installer_1210.exe. I suspect this is the one I should be using. Whe I tested the mount initially I chose the first one and it appeared to work with some oddities that were overcome (e.g. incorrect exposure vs gain, and general slowness to gather images), but it did function in my brief testing so never tried the other one. I guess I was stuck in the ZWO mindset where I always use native drivers which is I believe, perhaps incorrectly, the recommended approach.

The "iOptron iGuider" is the one giving problems. I'll try the ASCOM variant and see if that helps when we get clear skies again. Maybe with luck the iOptron provided driver works reliably. Clearly there are far better guide camera options than the iGuider, but it is handy for some use cases, plus it should work.

Thanks,

Barry

[DesertCrawler]

Just closing the loop.

The problems was two-fold. Short version, USB port fault of some sort, plus requirement to use the iOptron iGuider ASCOM v1.2 driver. Non-ASCOM and previous ASCOM drivers do not work.

First, I found the USB port on the mount is very picky about USB cables, apparently. I had tried several which work night after night with probably 100s of hours of imaging between them but none worked with iGuider in the mix. I cleaned and fiddled with the connectors in the mount's USB3 port and got one of the cables to reliably work with iGuider (with a caveat. see next point). Other devices also continue to work, so no change there. USB ports are a terrible choice for this application being mechanically weak.

Second, the ASCOM driver from iOptron v1.2 must be used for my particular mount (manufactured in Jan 2021, latest board revision, latest firmware as of today). When I set up the mount initially I followed the instruction manual that stated to use the 'iOptron iGuider' selection in PHD2 and if the device would not connect, then use the ASCOM driver. Since my camera connected and produced images with the WDM driver, and PHD2 could use it at least temporarily, I never bothered with the ASCOM variant. Further, only the v1.2 driver works. 

PHD2 ran with iGuider for over an hour with no issues. The mount guided reasonably well considering what it is and PHD2 behaved flawlessly as it generally does.

Thanks,

Barry

[bw_msgboard]

Hi Barry.  Glad you got it sorted out and thanks for letting us know how you got there.

 

Bruce

---

From: open-phd...@googlegroups.com [mailto:open-phd...@googlegroups.com] On Behalf Of DesertCrawler

Sent: Sunday, October 24, 2021 9:48 PM
To: Open PHD Guiding
Subject: Re: [open-phd-guiding] SOLVED: iGuider flakey behavior in CEM70G, plus bug in PHD2 logging

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/3fe83f68-718f-4a7a-a736-ecf0463d22a4n%40googlegroups.com.

[DesertCrawler]

Thanks Brian. For the record, I really appreciate what you and other contributors offer we users.

I'd like to assess the mount baseline performance eliminating things like 3D balance, cables, and maybe weight.

To test the iGuider I decided the RA balance was close enough without an OTA. Nothing was on the DEC plate. Is this anywhere close to a valid test from a guide log analysis standpoint? I  suspect the answer is no.

If I properly mount a guide scope such as an AT66ED - much lighter than the usual payload -- would this be a good baseline to assess the mount's performance? I use anything from a 81mm refractor up to a RASA 11 on the mount and I'm just looking to objectively assess the mount. It would have the guide camera and that's it, and one USB cable going to the DEC plate.

With this mount I have seen periods of 0.25" RMS consistently (over say an hour, with 8 hr average being ~ 0.6" RMS) with a 925 SCT and OAG @F/10, but sometimes feel the stars are a little soft although they are very round. This could be other things, of course.

Yet, on my 132mm refractor with ~0.6" typical performance the stars are about as good as I can hope being near perfect. 

I realize these are anecdotal generalities, and many things affect guiding, just trying to understand a best practice for isolating mount performance. If there's an FAQ that covers this I'd be happy to chase it down there.

Thanks,

Barry

[bw_msgboard]

Glad we could help you out a bit.  I think the best way to evaluate the guiding performance is to mount one of your refractors and temporarily run guiding tests through that refractor - in other words, no imaging.  That will tell you how the mount itself performs.  IMO, you are likely to get differential flexure between the guide camera and any heavy OTA like the RASA 11.  And of course, the coarse guider image scale of 6.45 arc-sec/px is going to set a floor for guiding that will probably limit you for any high-resolution imaging.  Frankly, I think these built-in guiders are a poor idea, starting with the original ones from Meade.

 

Here's a procedure you can use to run your guiding baseline tests:

 

https://www.dropbox.com/s/os1thorvswmzaul/How%20to%20create%20a%20baseline%20for%20guiding%20results%20using%20OpenPHD2.pdf?dl=0  

 

Good luck,

Bruce

---

From: open-phd...@googlegroups.com [mailto:open-phd...@googlegroups.com] On Behalf Of DesertCrawler

Sent: Monday, October 25, 2021 9:22 AM

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/10c19c29-a708-4bdc-bedc-7f01d00707a9n%40googlegroups.com.