QHY5III462M - no 16 bit option?

[Clayton Yendrey]

I’m not sure 16 bit really does anything useful for guiding, but it has always been an option I’ve selected with the Windows native and ASCOM drivers for my ZWO guide cameras.

I have changed from an older ZWO 290mm- mini to a QHY5III462M mini guide camera (a newer generation of a sensor IMX290 to IMX462 that is supposed have better low light sensitivity).

I ran into two issues:

1) I tried the ASCOM QHY Guide camera driver first.  I could not create a new Dark Library because PHD2 kept losing camera connection.  TSX had no such issue.

2) Switched to the Windows native driver (assuming based on the PHD2 SDK?).  Dark Library was successful, but no option to select 16 bit support.  It operates only as 8 bit in PHD2.  Is it supposed to be that way?

Like stated at beginning, not sure 8 bit is really a drawback.  I’ll be testing the 462M’s operation this evening, so I’m hoping no other unexpected issues crop up.

[Bruce Waddington]

Be sure you're running with PHD2 2.6.13dev5 and the latest QHY drivers.

Bruce

[Brian Valente]

Setting the bit depth in the native zwo driver is done through the gear button:

--
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/ac8860c4-8b7e-47f6-b581-874e5389c791n%40googlegroups.com.

--

Brian 

Brian Valente

astronomy portfolio https://www.astrobin.com/users/bvalente/ 

[Brian Valente]

woops - cancel that, I read it backwards (thought you were going to zwo)

--

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/503956a0-d913-4254-b25a-efc9ee629d72n%40googlegroups.com.

[Clayton Yendrey]

Briian, I’m iding the latest on both PHD2 and QHY.  I’m am using the QHY recommended newest (beta), NOT the latest stable version.  QHY doesn’t appear to recommend the stable unless you’re using one of the older devices.

The “toolbox” icon is greyed out. Regardless of whether the camera is connected or disconnected.  My inference is the native Windows QHY driver is 8 bit.  But I haven’t found anything that tells me that in the sparse QHY docs.

[Clayton Yendrey]

I had to ditch the native windows driver forbthe qhy5iii462m.  It was so slow, it could not feed a calibration run consecutive images.  When I was tryingbyo focus the OAG, it was (with a 3s exposure in phd2) taking 9 to 12vseconds to get image updates at times.  I went back to the ASCOM driver (which IS 16 bit).  However I had to turn the USB speed down to 15 so that phd2 would stop disconnecting.  

So I did get it working and I can see the improved dark sensitivity of the IMX462 sensor vs that of the older IMX290.  But I wouldn’t give a nickel for the QHY drivers.  I’ve submitted a report/trouble ticket to QHY, but it took them a couple of years to get “stable” drivers running up before Covid.  I’m not hopeful on this as a consequence.

[Dale Ghent]

Hi, perhaps a PHD2 log file would help explain what is going on far
better than what has been related thus far. The PHD2 log file will spell
out what camera parameters are being utilized and help level-set what is
going on.

I happen to have a QHYIII462C here at my desk and it is operating just
fine using the native driver in the current PHD2 dev release. While this
is the color version, not the mono one, I would not expect there to be
much difference as far as the underlying QHY SDK is concerned.

You can find PHD2 logs under Documents/PHD2.

/dale

> <https://groups.google.com/d/msgid/open-phd-guiding/503956a0-d913-4254-b25a-efc9ee629d72n%40googlegroups.com?utm_medium=email&utm_source=footer>.

>
>
>
> --
> Brian
>
>
>
> Brian Valente
> astronomy portfolio https://www.astrobin.com/users/bvalente/
>

> --
> 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/d591f82d-f4d7-4f93-b3ac-ec14eaaf4c3dn%40googlegroups.com
> <https://groups.google.com/d/msgid/open-phd-guiding/d591f82d-f4d7-4f93-b3ac-ec14eaaf4c3dn%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Clayton Yendrey]

Logs attached from last nigh.  I think a need to run a new PEC, based on what I'm hearing from SB.

[Dale Ghent]

Sorry, I should have clarified - I need the DebugLog file, not the
GuideLog file.

/dale

> <https://groups.google.com/d/msgid/open-phd-guiding/d591f82d-f4d7-4f93-b3ac-ec14eaaf4c3dn%40googlegroups.com?utm_medium=email&utm_source=footer>>.

>
>
> --
> 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/4640201b-47ff-48e0-8fa6-ccf3e03a013dn%40googlegroups.com
> <https://groups.google.com/d/msgid/open-phd-guiding/4640201b-47ff-48e0-8fa6-ccf3e03a013dn%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Brian Valente]

Clayton please use the built-in log uploader under Help menu to send the relevant logs

https://openphdguiding.org/getting-help/

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/542b95a1-f662-4df5-b09c-0e1bed0685b7%40elemental.org.

[Clayton Yendrey]

Link to uploaded log files:
https://openphdguiding.org/logs/dl/PHD2_logs_3Lis.zip

I've a question or maybe questions, separate from the issues with the QHY drivers.

I'm seeing the RA instability on the log view and while imaging, with some fairly significant excursions past 2 a-s, sometimes as large as 8a-s in my guiding on The Cave Nebula last week (37 hours of integration).  Despite the apparent issues seen by PHD2, when I blink the raw subs in Pixinsight looking for discards due to star motion/movement in the subs or enough guide error to create oblong stars, those "bad" subs just don't exist.  Of the 442 subs on The Cave nebula, there were only 3 with actual movement/streaking of the stars in a sub.  There were a handful that exhibited some slight oblong star shapes,  but nothing BlurXterminator couldn't fix (Hoorah for Russ Croman!!!).  In the past when guide issues were occurring, it was evident in the subs, but this time, not really.  In last nights sessions, even with my low confidence in the QHY drivers, there were only a handful that showed even very slight "non-round" star shape.

If I really entirely on what the subs are showing me, I'd have to conclude that whatever PHD2 thinks it is seeing, it does not appear to be 'real'.  So can this be induced by poor focus, insufficient or incorrect gain/offset settings, etc.?  Because the stars are not 'sharp' but more soft edged.    The OAG sits in front of the EFW, so it does not see the stars through the EFW filters.  Consequently the OAG is only really in focus when the system is imaging through the primary focus filter from which the filter offsets are calculated.  Is there a 'best practice' on focusing the OAG when using an EFW?

[Brian Valente]

Couple questions:

Are you using a rotator?

How did you decide on these guiding parameters? you have a very low aggression in RA combined with a low guidespeed, so your guiding is not as responsive as it could be

you also seem to be fiddling with the settings a lot, I'd recommend stopping that. Changing aggression by 5 points isn't doing anything meaningful other than maybe false hope ;)

>>>> I'd have to conclude that whatever PHD2 thinks it is seeing, it does not appear to be 'real'.  

PHD is 'the most real', because it represents actual measured star movement, not calculated or derived star movement. 

You are probably seeing a combination of short excursions (and by short i mean spikes) and longer exposures that average that out. To evaluate star eccentricity (elongation) you should be comparing RA and Dec RMS contributions. If they are close, you will get round stars, the HFD will just be higher when you have those kinds of excursions

how exactly are you evaluating your star shape during review? 

If you are just blinking through them and feeling pretty good, that may be good enough, and sometimes that is indeed good enough. If you measure the data using a more statistical tool like FWHM Eccentricity or Subframe selector, you may find your eccentricity shows some elongation. My guess would be in the 0.6 range

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/69191cb8-9b74-4fee-9a0f-6d81bb2d4a03n%40googlegroups.com.

[Dale Ghent]

A lot going on in these logs; it seems that there was a bunch of reconnects with the ASCOM driver before you switched to the native one at 1:36pm. The QHY native driver in PHD2 logged the following, which is what I was after:

13:36:20.418 00.001 17572 Connecting to camera [QHY Camera] id = [QHY5III462M-6de1c44ca114a91b0]
13:36:20.419 00.001 17572 QHY: found 1 cameras
13:36:20.574 00.155 17572 QHY: cam reports BPP = 16
13:36:20.578 00.004 17572 QHY: cam reports bayer type -1
13:36:20.581 00.003 17572 QHY: max binning = 2
13:36:20.584 00.003 17572 QHY: call SetQHYCCDBinMode bin = 1
13:36:20.587 00.003 17572 QHY: call SetQHYCCDResolution roi = 1920,1080
13:36:20.589 00.002 17572 QHY: connect done

So the camera is reporting a 16bit mode *is possible* (BPP = 16) and that may very well be its default operating mode. The QHY SDK call that PHD2's native driver uses to get this info just tells us what is possible, not necessarily what the camera is currently operating in or has been initialized to. This may be fine for most cameras but the QHY5III462M might be different.

It is customary in the native QHY drivers I've looked at (and coded - the native QHY driver in NINA was my project) to explicitly set the bit mode during the initialization run so that there's no ambiguity about which output mode it's in. But PHD2's native driver does not, and it probably should just to be sure. QHY also doesn't offer any 8bit-only cameras, so just forcing any camera to 16bit output ought to be fine. Adding this logic to the driver would be straight-forward. I'm not saying that this is the problem, but it's an observation related to it.

Also, in PHD2, any camera-specific configuration option for bpp, cooler, or other features are optional for a native driver to implement. They are implemented in the ZWO native driver and the ASCOM client, but not for QHY. So expecting this to be present for /any/ camera is a misunderstanding in that regard.

I went back over your original post and you never quite explained how you came to conclude that the camera was outputting in 8bit mode. Did it just "look" that way or did you save a FITS image generated out of PHD2 and inspect it?

/dale

> To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/69191cb8-9b74-4fee-9a0f-6d81bb2d4a03n%40googlegroups.com.

[Clayton Yendrey]

Yes, I have a rotator.  It is part of the Moonlite Express Nightcrawler focuser.

The guide parameters originally came from other Paramount users; the Paramount mounts don't respond well to over aggressive settings.  Actually, it is still not back where it normally ran before all this went upside down.  It had run with 40 aggression from the day I first set the mount up.  When it started acting up, I tried to move the aggression up and that worked OK up to 60 with the old OAG, but it would not stabilize at all at 65.  With the replacement OAG and new guide camera, it started up yesterday going unstable from the outset.  I started dialing back aggression and it things lined out reasonably stable, but I was reluctant to dial it all the way back to where everything started.

I assess the star shapes visually in the Blink Function in PixInsight.  First pass after loading the images for a particular filter is a pass to assess exposure/clouds/fog etc. and remove any subs that show those issues.  Then I pick a region of the subs that has relatively good star density and zoom in until the stars are heavily pixelated.  By watching a particular star or two, it is relatively easy to determine if there is movement during the exposure because the pixelization changes shape and exhibits a 'direction' even if only faintly.  It is relatively easy to flip back and forth between one sub and another to do a closer examination in cases where the 'hint' of movement might be fairly faint.

I used to exclude any image that wasn't reasonably perfect on star shapes but the advent of tools like BlurXterminator have made the process more forgiving even when the causes are optical aberrations rather than guide errors.

I will say that I have never seen the type of tracking movement, much less guiding excursion when guiding/running the TrainPEC tool in TSX.  Of course, that is when using the primary OTA imaging train as the guider, not the OAG.  While the OAG has a lot of disadvantages vs. the primary imaging train, I wouldn't think the mount movement would be viewed/seen differentlly at least not to a major degree.  ???

[Clayton Yendrey]

I was going by the Max ADU value that PHD2 would allow after connecting to the camera which is 255 and not editable/changeable when the native Windows driver is chosen.  I did hear back from QHY support and they did say the Windows driver is 8 bit operation with PHD2.  They indicated they were going to contact their developers to contact PHD2 to see what is necessary to enable 16 bit mode in the Windows driver within PHD2.  They also indicated it operated in 16 bit mode if connected directly to SGP, MaximDL, NINA, and some other 3rd party software.  I take that as the PHD2 connection is the only one where 8 bit mode is the only current option for their Windows driver.

Oddly, the ASCOM driver selection does NOT enable an 8 bit/16 bit mode selection in QHY ASCOM driver dialog.  But with the ASCOM driver selected, PHD2 does allow the MaxADU to edited - it just won't hold it, dropping back to 255 (8 bit value).  But it's like there is confused communication between PHD2 and the QHY driver - when a guide star is selected the ADU is shown in 16 bits with 65535 being the fully saturated value in the guide star box.  What was disturbing is the PHD2 insisted on selecting stars that were fully saturated (by that 65535 adu level reading) and I had to switch "Saturation via star profile" to get a non-saturated star selected - never had that issue before so it caught me by surprise.  I know this latest beta QHY driver pack is the version recommended and the QHY support person wanted to make sure that was the version I was running.  But there is something in the QHY PHD2 SDK (I'm assuming) and/or in the QHY ASCOM coding that seems to not be in alignment when used in PHD2.

Software Bisque support has asked me to run a guide session within TSX/guiding with TSX to get a good hour or so of data (NIH concerning PHD2, but I can't control that).

I never got to actually guiding with the native Windows driver, the camera response was so slow/delayed that it was unusable.  It could not take/feed consecutive images to PHD2 for focusing and took forever to create a Dark Library.  In the Dark Library creating process you would watch it take an image, a delay of several seconds then two or three quick images, then a delay again.  I just thought it was the software not updating status consistently, so didn't pay much attention other than it was taking a long time to get the Dark Library created. 
Next step was just trying to get the OAG focused well enough to get some good (ish) stars - using the PHD2 loop function to watch the stars/HFR values while making adjustments on the OAG (I connect remotely with RDP, so my wife was FaceTiming me to let me watch the display while I was out at the OTA).  It would update with each focus adjustment for one to two images, then nothing would change for the period of 3 to 4 images, then get a sudden update (and you had to realize it wasn't updating so you didn't keep chasing the 'fixed' display).
I then ran calibration in PHD2 with the native Window drivers and it finally did complete, but it would take an image then loop for two or three times the image exposure time, then take an image, loop - rinse and repeat through the entire calibration process.  When the calibration finally completed, the graph looked OK, but I wasn't willing to try to guide with that sort of camera performance.

I went back to ASCOM driver at that point and started playing with USB traffic readout speed as PHD2 was losing connection just sitting doing nothing.  I went up in value and it got worse, so I started down.  I left it at 15 as the spot where I got to reliable camera connections.  I misunderstood the slider though - according to the QHY tech, the lower the number on the slider, the faster the USB communication.  I don't know why PHD2/QHY choked on the default 40, and I've never had to adjust that setting for ZWO.  I don't know if their USB slider is the same in regards to speed/bandwidth as the QHY.  Once that camera disconnect issue was resolved, the Dark Library process and calibration went as fast as the normally do.  What I suspect is the non-adjustable Window driver was having the same issues as the ASCOM driver set at 40, just that PHD2 saw the windows driver and did not perceive a dropped/slow camera response like it did with the ASCOM driver.  ???

I did NOT go back and try to fine tune OAG focus after all of that, and I think I should have in retrospect.  So that is one of my objectives tonight, aside from the TSX guide run for SB Support.

[Brian Valente]

I'm looking at  few things in your guidelog

First, regarding RA aggression, i'm looking at how your RA responds to guide pulses. This really should be a one or two guidepulse and you are back on track. There is no reversal in RA, so there's no backlash to compensate for. Here's a typical snapshot of your RA performance (note the blue dashed lines around 0.25" are your limits).  

What I see is this mount takes a lot of guide pulses to get back to baseline. There are probably other things going on here, but low aggression is certainly not helping here

in your unguided run you show jumps of up to 1" in RA. it seems a little rough for a mount like a MyT. You might consider doing a GA run ofr 30 minutes to better capture the raw (unguided) mount performance. Not sure if you have other things going on like PEC or sky modeling, but those would be suspect as well. 

Second, Dec also takes quite a bit of time to reverse. Similar situation where you have multiple guide pulses required to reverse direction. 

Again, probably other things going on here, but a low pass algorithm for Dec with no backlash compensation does not help this kind of situation. Your RA is consistently higher than dec in your guided runs

Third, (and Bruce may disagree with me here) but i see a number of places where RA and Dec seem to mirror each other. This to me suggests the rotator setup might be questionable

to test this, you might lock down the rotator, calibrate and then don't use the rotator for a few nights and see if things improve.

I get your strategy you want to aggressively guide this by using a very low min move and then "smooth it out" with a low aggression, it's one that can be successful. i just don't think your mount is responding well to it as it currently behaves.

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/7d3b2f28-aa09-460e-b2fa-e74008398601n%40googlegroups.com.

[Clayton Yendrey]

Brian, the only time the rotator operates is when setting the framing for a specific imaging target.  It never moves again after that, not even in the meridian flip that I've observed.

I'm finding something that I suspect *may* be a bad influence on PHD2/guiding.  With everything going on, and wanting to make sure I had a sound foundation for focusing the OAG, I started running the Filter offset tool in NINA.  I was watching the curves this time (I was doing other things last year so didn't watch it that closely).  Frankly the curves on some of the filters were pretty bad and the offsets would (I would think) make an OAG being pushing PHD2's ability to find a solid star outline/boundary.  So, I'm currently running each filter manually and recording the focuser point and calculating the offset.  My results look much different (I hesitate to say better) with different focus points and a tighter grouping on the offsets.  Although I am still seeing things that are making think ill of the Antlia V Pro LRGB filters.  If I can get this finished and refocus the OAG, then there might be some difference reflected in the guiding.

A question - with an EFW and using an OAG, should the OAG be focused at a point roughly midway in the range of offsets, rather than with the prime focus filter focus point?

[Clayton Yendrey]

Ok, I've finished my OAG focus tweak after refiguring all my filter offsets.  Now the other problem with PHD2 + the QHY drivers.  It absolutely insists on selecting the brightest most  saturate star/object in the frame as the guide star.  The only way to NOT do that is to select a star manually.  I've not had this issue before but I suspect it is related to the ADU/* bit /16 bit mode between the QHY drivers (both native and ASCOM) and PHD2.  The Guide setup screen, regardless of driver, insists that 255 is fully saturated sensor.  With the ASCOM driver, I can enter the correct number but it does not hold and reverts back to 255.  At the same time the guide star screen plainly shows the autoselect guides start with a plateau like flat top with a fully saturated ADU reading of 65535 - solid.  I'm ready  to do a clean install of PHD2 and create a new profile from scratch at this point to see if that helps, I can't think of much else to do.

Clayton

[Clayton Yendrey]

Screen shot of current results.  I'm about to try a new profile first,  if that doesn't do it then a reload of PHD2.

[Brian Valente]

>>> Brian, the only time the rotator operates is when setting the framing for a specific imaging target.  It never moves again after that, not even in the meridian flip that I've observed.

Yes, that's typical, but i am seeing axis bleed in a lot of places. If you aren't concerned, you don't have to do anything, but if you see this there's the test I outlined

If your OAG defocuses due to filter offsets, yeah that can be a problem. You may need to find a median focus offset value

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/92e86f9f-f3aa-480e-b8cd-c7729a38ff24n%40googlegroups.com.

[Brian Valente]

>>> I can't think of much else to do.

you can switch to saturation via star profile

but you're right you don't want 8 bits if it thinks it's 16 bits

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/e313d3cc-320c-4283-b34a-349e246a3653n%40googlegroups.com.

[Clayton Yendrey]

Starting from scratch with new profiles seems to have helped both in the mount guiding and with the QHY drivers - well at least some with the QHY drivers.

Link to logs from last night:  
https://openphdguiding.org/logs/dl/PHD2_logs_U7jv.zip

I created two new profiles, one for the QHY native Windows driver with the QHY5III462M, another with the ASCOM driver for the same camera.

I there were some fits and starts; creating the Dark Library and completing the calibration for the Windows driver profile was VERY slow.  During the calibration run, the reason was evident - 15 or so seconds between each image transfer from the camera with looping indicated in PHD2 in the gap between each.  This inability to make timely image transfers continued into the guide session and GA run - while PHD2 indicated good guide performance, the updates to each guide image were abysmally slow.  I suspect the issue is the same as found with the ASCOM driver - with  no ability to adjust USB speed/bandwidth in the native driver, it is not able to make timely transfers of the data.

The "good" news is that PHD2 profile wizard recognized the Windows driver as 16 bit and indicated that in the MaxADU value in the camera settings.  It also selected an appropriate guide star for guiding on.  I reduced the aggressiveness from default slightly on both RA and DEC.  Despite the abysmal camera transfer performance, the guide session appeared to be good with sub 1 a--s Total RMS error.

I then created/switched to a profile for the ASCOM QHY driver with the 462M camera.  Speed was what you would expect, (the ASCOM settings were still at 15 on the USB bandwidth/speed).  The Dark Library was populated as fast as the exposures were taken and the calibration session also went fast.   The "good" news mostly ends there.

The Profile Wizard only recognized the ASCOM driver as 8 bit with no ability to select the 16 bit mode.  This was reflected in the MaxADU on the Camera tab in the advanced settings.  Selecting a guide star revealed a further "disagreement" between the ASCOM driver and PHD2.  The guide star profile reported the ADU in 16 bit, not 8 bit.  Autoselect would ONLY select the brightest star in the guide camera frame, regardless of MaxADU or StarProfile selection.  I could manually select a dimmer star but that would only be single star rather than multi-star guiding.  I decided to leave it the auto-selected star regardless.

I "think" for some reason that PHD2/the QHY ASCOM driver is not cleanly selecting the 8 bit mode and that at least some part of PHD2 is trying to use 16 bit mode data within 8 bit mode "expectations". As a result it can't find any star within those 8 bit limits and defaults back to "brightest" object selection.  Ironically, that is how TSX autoguide star selection  operates - brightest star in the detection window.

I chose to leave the aggression settings at the default values just to see how it would operate.  I think it did reasonably although, in reviewing the guide logs this AM, I see more RA instability occurring as the morning hours progressed.  I did see that PHD2 was displaying a camera connection lost dialog when I opened RDP this morning to check on it.  I have not "blinked" the short imaging session, so I don't know if what may or may not have been indicated in the images.  

I suspect that the new profiles took care of something else I overlooked - the upgrade in the MyT to MKS6000 electronics/controller from the 5th generation MKS5000.  From the driver (X2 ASCOM) perspective, PHD2 could not be aware of any change, but that doesn't mean the mount was actually responding the same to what PHD2 "knew" of the mount prior to the upgrade.  The new profiles let PHD2 learn the mount from a fresh start, and that may be one reason for the improvement in guide performance (combined with letting default settings ride).  I don't know this as a certainty, just some guessing on my part.  While the RA instability does appear as the night progresses, the overall performance in the quick analysis peak I made seems to show better overall guiding that previously.  Fixing the QHY drivers mode selection/interaction with PHD2 would be key to making further progress, IMO.

Clayton

[Bruce Waddington]

Setting aside the open issue with the 16-bit native driver operation, I think you're wandering off-track in terms of what you think happened with the profile re-initialization.  PHD2 doesn't "learn" anything about the mount that carries over from one session to the next.  It doesn't "know" about your mount. The ASCOM driver interfaces present an abstract view of an idealized mount, and all mounts are treated the same by PHD2. I think that any performance change you saw - assuming it was real - is due to restoring the default guiding parameters.  Since you seem to like futzing around with these things, I think you should take a look at the "fooled by randomness" discussion on page 13 of this document:

https://openphdguiding.org/tutorial-analyzing-phd2-guiding-results/

Regards,

Bruce

[Clayton Yendrey]

Logs from last night. 

https://openphdguiding.org/logs/dl/PHD2_logs_wCCz.zip

QHY ASCOM driver was, when I paid close attention to it, having issues transferring the image from the Camera to PHD2.  This was seen during Calibration when the Calibration dialog would show "Looping" in stead of moving to the next step movement and delays in getting the image/motion update from the camera image/data updated in the Calibration display.

This continued in the guide session.  One other aspect that I had ignored and this may be an issue exhibited in TSX as well, although in a different way.  PHD2, when running the QHY ASCOM driver, has required a fresh calibration each night to guide correctly.  Automatic Calibration Restore is enabled.  For the two nights running, if PHD2 is shutdown/closed, on restart of app, if the normal Loop, Select Star, Guide is chosen guiding seems to start normally but goes off the rails within a couple of minutes.  It seems to act like the DEC is reversed and drives in the opposite direction, but sometimes it is RA that takes off and won't stop, or both at the same time.  The "fix" is to run a fresh calibration, then everything works as it should. 

I only mention this next item as maybe an indication of possibly a related issue exhibiting in a slightly different way in another app.  In TSX, this (if it is related) exhibits as being unable to connect to the QHY camera even though shown in the Guide Camera tab as being the camera that should connect.  The entire process of chose the Camera, set Camera properties, then connect has to be executed.  Each step the QHY Camera is displayed as selected Camera, but has to be "touched" with the mouse/selected before TSX treats it that way.

Some very small "movement" is indicated by the star shapes from the night of 10/9-10/10.  However it is very slight and well within the capabilities of BlurXterminator to resolve.

My quick look at the logs linked to here from last night, show the false starts until a calibration is completed.  The first imaging sequence goes well with very good guiding.  The second goes well until the first dither.  Shortly after that, periodic spikes the DEC begin to appear.  In the next filter change/guide session, RA spikes begin to appear in conjunction with the DEC.  After the meridian flip, the spikes seems to be mostly if not completely, in the RA.  The frequency analysis shows only a strong signal at approximately 54 sec and sometimes a less sharp signal of similar magnitude around 150 sec.  They are not of the magnitude I've seen associated with major mechanical issues in the past.

One other observation which may be connected to the periodic "spikes".  During the first very good guide session, the issue with delayed/slow updates from the QHY camera did present with a series that would be on the 2 sec exposure cadence, then a period where the updates in PHD2 were much slower, around 6 to as much as 10 seconds.  In those periods of delay, is when the movement from solid guiding at (at that point) approximately .25a-s Total RMS error to around double that would occur.  In the guiding log, I don't see anything that indicates that lag that I observed, but it seems possible that this a (if not the) contributing factor guiding getting less smooth as the night progresses.  

Even with that, this is the best guiding result that been completed in terms of Total RMS error recorded even with "movement" that PHD2 captured.

Clayton