Poor guiding with new CEM70g' embedded guiding camera

[Stefano O]

Hello,

I am new to the group,, and I have read the directions I've found and am trying to stick to them. but I apologize in advance if I don't do everything right.

I think my iOptron CEM70g internal iGuider camera performance in guiding is less than expected, and would like to understand the issues.
This embedded camera has a 30mm aperture and 120mm focal length, and the sensor has  3.75 micron pixels. If I am not wrong, that means about 6.5 arcsec/pixel.

The log of the session is at:
https://openphdguiding.org/logs/dl/PHD2_logs_jwvt.zip

and in particular I think the 4th section is the core of the guiding I've tried.
The initial part shows drift (a lot of it in RA I have to say) that happened when I started the guiding assistant (therefore guiding was interrupted). 
I accepted the suggestions out of the assistant, and the adjusted guiding resumed around 21:50.
I've adjusted the Min.Mo and aggressiveness a couple of times along the way, as the evening unfolded.
It seems also clear that there is a periodic large deviation on both sides in RA, which is compatible with the mount's worm period of 385 seconds, I believe, at least according to a chart that came with the mount.

Thanks

-stefano

[Stefano O]

I should add that I observe out in the open and there was a light breeze that would come and go -- when present I guess I could appreciate the effect on the guiding chart to some degree.

Also, I just checked another guiding plot from a session at the beginning of March, where the periodic large deviation that seem evident in the attached plot were NOT there... 

Thanks

[Stefano O]

... also, polar axis alignment was obtained through the embedded iPolar scope and software, and was just about spot-on.

[Bruce Waddington]

Hi Stefano.  I would say there’s something significantly wrong with the native RA tracking on the mount:

 

 

 

This is not normal periodic error.  Typical periodic error creates a sine-wave type oscillation with a period matching the worm period.  But your mount is showing all these abrupt, large excursions in RA – too large and too abrupt to control effectively with guiding.  The initial guide-star excursions are not caused by guiding – PHD2 simply reacts to them after the fact.  You can see the spikes occur in pairs with the initial deflection requiring numerous west guide pulses trying to restore the star position.  That’s equivalent to stopping or impeding the sidereal tracking of the mount for a brief period.   I think the second spike in the pair is a side-effect of the initial problem, the result of guiding and over-correcting for the first deflection.   I think you will have to talk to iOptron and get a resolution on this problem – I think something mechanical is interfering with the consistent sidereal tracking of the RA axis.

 

Good luck,

Bruce

--
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/499fb41d-3106-4c2e-9907-e9435bf3a9c5n%40googlegroups.com.

[S O]

Bruce,

thanks much, I was suspecting the same, but really didn't have the need to delve so deep into Phd2 data in the past.

I'll start taking some actions about it.

Thanks again

You received this message because you are subscribed to a topic in the Google Groups "Open PHD Guiding" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/open-phd-guiding/6sQ4WI8PY6M/unsubscribe.
To unsubscribe from this group and all its topics, 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/007801d72802%24fded1e20%24f9c75a60%24%40earthlink.net.

[Stefano O]

Hello,

I've had the RA worm serviced - apparently there was indeed a defect in one spot of the worm, that has been supposedly smoothed out to the satisfaction of the shop in charge of technical support and warranty.

So I've been back at attempting some satisfactory guiding, though so far I can't really say I'm seeing what I hoped to see.

I have two sessions to report, hoping in some insightful feedback -- as reference, we're talking about a CEM70g, and guiding is done via the embedded iGuider camera+scope; where applicable, the OTA is a Meade 10" LX850 ACF (F/8 native, plus a 0.63 reducer):

1.  session from Jun 16:
   I've run this *without* the OTA, just to make it easiest (or so I think) for the embedded iGuider;
   the night was clear, good transparency but seeing fairly poor; the guide star I was chasing (don't remember which however...) had an SNR close to 20. The scope was however pointing at an area around M5  (Ophiocus)  , so I'd say between 30 and 35 degrees over the horizon, initially not too far from the meridian.
   The guiding log is at:
   https://openphdguiding.org/logs/dl/PHD2_logs_tUYc.zip
   I've changed the RA aggression a few times to see how things would go, that evening in particular trying to push the RA agg higher.
   
   I may not have used the Guiding Assistant, but I guess it would show in the events if so...
   
   What puzzles me here (looking at the 2 longest guiding stretches in the log, #3 and #5), for what I can pick out of the results, is - as usual - why the RA is apparently so much less stable than the DEC. I have been able to often (as in other sessions) keep the DEC to well below 1", but RA is always above 1", and by a good margin. Is it normal that the two have such differences?
   
   Maybe in this case the moral is that I had to much agg on the RA? Or maybe the moral is that the RA worm is still not OK...? See also next session
   
   
   
2. this is from 2 nights ago, and is with the scope in full configuration:
   https://openphdguiding.org/logs/dl/PHD2_logs_gEJP.zip
   The night was not so transparent however (though the forecast seemed good - I couldn't pick up the Trifid visually through the scope with a 32mm eyepiece...). But the seeing was very stable, at least judging by the amazing sight of Jupiter I enjoyed at the end of the session through an 11mm eyepiece; it was very clear almost crisp, certainly very little wobbly.
   
   In this session, around 00:30 some breeze unfortunately picked up, so what is after that time is probably useless to look at.
   I was guiding on a star close to M12 (Ophiocus), beginning soon after it had passed the meridian, about 30/35 degrees over the horizon I'd say.
   
   I had the Guiding Assistant set the parameters after a short initial guiding stage. Then I started playing with the parameters myself a bit, this time aiming and turning the agg down -- which I started doing unfortunately more or less when the breeze picked up...
   
   At any rate, the RA oscillations are much worse.   One thing that makes me wonder in this session is whether it's due to the guide star being lost so many times, and even before that if it's natural that I lost the star so often given the sky condition. The SNR wasn't high, but it still was appearing to be above 12 all the times I looked, even just after PHD2 chimed about having lost it/having mass changed.  With no clouds in the sky and the conditions described above, was it the RA sways to cause PHD to lose the star, or the other way round?
   

Thanks as always.

stefano-

[Bruce Waddington]

Hi Stefano.  Like you, I don’t really see the expected improvement in the RA tracking behavior.  Here is a view of both RA (red) and Dec (green) from the 23:02 guiding session:

 

 

You can see that the RA tracking is very noisy with many abrupt excursions.  The Dec plot gives you a rough idea of what the seeing conditions would allow so I think the mount should have been able to deliver better results.  If we look at the raw RA behavior, it looks like this:

 

 

The frequency analysis shows this:

 

 

The two largest spikes probably line up with the native worm period and ½ the worm period so they might be helped by periodic error correction.  But there are other higher-frequency components (arrows) that work to generate a continuous background “tracking noise” of at least 1 arc-sec.  These are going to be difficult to guide out and I think they help explain the poor results. 

 

In any case, you should disable the star-mass detection feature because it isn’t helping you and it’s causing too many lost-star events.  I suspect your poor sky conditions are also a factor here because the SNR values you’re getting, while generally acceptable, aren’t what you would expect for 2-3 exposures on a wide-field guiding setup.

 

Sorry you’re having so much trouble,

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/a5878068-a6dc-4bac-9d5c-009a6dac2774n%40googlegroups.com.

[S O]

Thanks Bruce,

indeed the worm period is of about 360 seconds, so your frequency analysis guesses are accurate I suppose.

Just one question on your last paragraph, you might have skipped a word there? You mean anyway that an SNR of 12 or so isn't good enough for a 2-3 *minutes* exposure?

Thanks much again,

-stefano

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/006c01d773a9%2427432ca0%2475c985e0%24%40earthlink.net.

[mj.w...@gmail.com]

Hi Stefano

That'll be:

"the SNR values you’re getting, while generally acceptable, aren’t what you would expect for 2-3 SECONDS exposures on a wide-field guiding setup."

[S O]

Ah, Ok, of course :)

Thanks!

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/58caa2c3-2556-41e9-bc54-6fb63d9dc50an%40googlegroups.com.

[Stefano O]

Hello, 

I had the scope again in for repairs, and after 3 months I got it back and just got a first attempt at finally having it work properly.

The log file is here;

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

Things not quite right yet -- while the large oscillations seem to have been tamed, it would appear now that I'm having issues with polar alignment.  The iOptron CEM70g has a built in polar scope that is only accessible through the ASCOM driver based interface, and so far has done a reasonable job at getting me a decent polar alignment.  
But the first two attempts I've made after the repairs seem to show the same problem, even when the initial polar alignment through iOptron's provided interface seem to be successful; that is, I see the RA and Dec always off 0, and never converging to it, while guidiing continually tries to correct towards it.  Incidentally, RA I think stays North, Dec stays East.

In the end, assuming a polar alignment issue, I ended up trying the Drift Align method, and the errors that were being shown where orrendous.  To be honest, I had never looked at the instructions on how to do this with Phd2, so maybe all that follows is just not applicable because of that...

I couldn't try too many attempts to correct alignment (the evening wasn't clear and clouds were moving in, and in the end was running out of energy and time, and actually I had not realized the DST had expired at midnight!);  first I seemed to have corrected the RA drift, but it required changing the altitude (Latitude) on my mount body by 5 degrees compared to the correct latitude!  However, to tell it all, after a subsequent azimuth correction to contain the Dec drift, I ran one last Calibration and attempt to guide:  I guess, being past midnight, I shouldn't expect anything to work since the scope's time was still on DST, but just for completeness, the apparent polar alignment corrections did just worse, as RA was now steadily off by 4" (vs 2" at the beginning).

Is this a polar alignment issue only?  Or could there be more like axes of the scope not being aligned well anymore?

Thanks

stefano

[mj.w...@gmail.com]

Hi Stefano

"I guess, being past midnight, I shouldn't expect anything to work since the scope's time was still on DST,"

If you had set the time and date correctly earlier on, and hadn't altered it or DST setting, everything was still fine - it's not as if the earth had suddenly jumped backwards 15 degrees at midnight  !

But next time you fire up you will need to set to local time, with DST off.

Michael

Wiltshire UK

[bw_msgboard]

H Stefano.  Your complaint about the RA and Dec positions never being completely restored to the lock-point is easy to diagnose - you have so much drift in both RA and Dec that the guiding is always lagging behind.  I think you really need to concentrate on figuring out where this is coming from and fix it.  It is not a guiding problem, it something wrong with your setup and it was present in the original logs you sent in June.  Large drift like this is usually caused by large polar alignment error and it sounds like you're struggling with getting that done.  To begin, here is an objective picture of how the mount tracks with no guiding being done at al (RA is red):

 

 

You can see the large amount of drift on both axes: 7.4 arc-sec/min in RA, 8 arc-sec/min in Dec.  If this is being caused by polar alignment error, you were off the mark by 20 arc-min.  There are a number of possibilities that come to mind:

 

1.  You are making mistakes in how you are doing the polar alignment.  Possible options would be:

    a.  Get a more experienced imager to help you even if it's only via remote trouble-shooting

    b.  Quit trying to use the iPolar gizmo on the mount and use one of the three polar alignment methods in PHD2.

    c.  Put an eyepiece in the main scope and use the gold-standard drift alignment method to get a reasonably close alignment.

OR

2.  There is something wrong with the polar alignment gizmo or with the way it is fastened to the mount.  For example, maybe it is moving around by very small amounts.  Using a different alignment method will eliminate this possibility.

OR

3.  You might be doing the polar alignment correctly but the mount isn't holding its altitude/azimuth position after you've finished alignment.  So when you slew to a different location, the mount axes are moving around and you are no longer polar aligned.  Or maybe the mount is sitting on a soft surface like grass or dirt and the whole scope assembly can move or tilt by small amounts as it slews.

OR

4.  The large drift rates are being caused by something other than polar alignment error.  Again, this could be caused by any ability whatsover for the iGuider to move around as the scope changes position.

 

PHD2 and the Guiding Assistant are not the source of your problem - they are just telling you that you have a mechanical problem of some sort.  As you pursue these various trouble-shooting options, you should always re-run the GA in the same location, preferably the same position you use for calibration - that is, with a pointing altitude of at least 60 degrees and a Dec position within the range of -20 to 20.

 

Good luck,

Bruce

---

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

Sent: Sunday, October 31, 2021 9:26 AM
To: Open PHD Guiding

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/d3b8d952-c7d1-484d-90d5-6118de984281n%40googlegroups.com.

[S O]

Bruce,

first of all, I really appreciate the effort you put in such an articulated answer.

That said, I perfectly understand and share the analysis you propose.  Incidentally, the ground where my scope is setup is rock solid, and so is the sturdiness of the tripod which I checked during the setup, so that option is most likely off the table.

I was indeed wondering about the stability of the built-in polar scope in particular, having been told by the repair technician that he had been scrupulous and had, I understand, more than once opened up the instrument and replaced parts; maybe something gave with the polar scope in those occasions...

About the rest, I've been using the built in polar scope by now at least a dozen times without issues before this repair, and dozens of times in the past with my previous scope and a separately acquired polar scope there. I think I know the fundamentals, though I always opted to *not* do the polar drift procedures.  Something I need to reconsider now, if I am to ever squeeze the best out of this scope after all. I'll also ramp up on the tools in Phd2 in that area before I give the gear one more try, before calling foul again.

Thanks many,

stefano-

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/DB6D8993E5C44921BCCB2DD3BC3CB5FC%40HomeDesktop.

[Stefano O]

Hello,

here's an update out of the meager 1 day of clear skies in the past few weeks (with no hopes in the near term to have a few more...).

While I didn't get to use the dedicated polar alignment tools and procedures available (I found out there are 3 in the docs, not just the classic drift alignment), I did give extra care this time to making sure the plate-solving tool provided by the CEM70 for PA was kept honest.  
So in essence, the divergence between RA and Dec (and their continuous attempt to correct on one side only) disappeared. Even the general scope alignment for goto needed very little corrections, and the calibration process didn't show any of the oddities seen the past 2 attempts -- the moral seems to be, don't trust the PA plate solving CEM70 out of the box:  my assumption was that it would not show you the target to hit if the star field doesn't match the neighborhood of the Polar Star, but it turns out I was quite wrong?

That said, here's the log:

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

I also was seemingly able to finally see the large RA sways that have been afflicting me apparently corrected by the latest repairs, and apart from the loss of tracking at the end of the first chunk of the log (due to meridian crossing -- more below on this), the mean error during tracking stayed well below 1", especially after I loosened the aggressiveness in RA. 

Questions:

- the first chunk of the log shows, if I read the Viewer charts well, still the RA drifting, meaning no too good PA yet. Is that correct? 

- it may also suggest I was too aggressive in correction? Incidentally, while I wanted to attempt Phd2''s own suggestion on the best guiding params to use, I was caught by the unfolding of the night and didn't get to try query Phd2 for the optimal config...

-  back to the PA,   the second chunk of the  guiding   session was started after hitting the meridian and then re-centering the target (M36, which was quite high in the sky for most of the observing session). I didn't re-calibrate, but the log after this passage seems to show no drift in RA...  If my reading is correct, does that make any sense? Slewing to the other side of the meridian shouldn't affect the PA...

- yet, the resulting pictures were generally better in the first (pre-meridian) chunk of the guiding session; the post-meridian session, assuming I'm right in reading that it shows no drift in RA, ended up producing stars that were slightly but noticeably elongated in the RA direction (the pics from the first part of the guiding showed a bit of that too, but overall less the the second part). 
So is this result on the pictures to be expected, considering the lower mean errors of the second guiding effort, and most of all considering that the mean errors were in both cases well below the single-pixel resolution the  picture taking camera was operating under? (1.25" for the camera, and > 0.9 for the mean errors in the first chunk of guiding, later down to 0.7 in RA and ~0.5 in Dec)
Is this perhaps the price to pay for having the internal guiding   camera operate at 6.4 arcsec/pix vs the scope going at 1.25  (the OTA has 2000mm focal, plus a 0.63x reducer, and the camera is an old Atik Titan with 7.4 micron pixels), ?

- the CEM70 is per se able to track beyond the meridian:  beside "Reverse Dec output after meridian flip", is there any other param to consider to continue guiding across the meridian?

-  finally: I have upgraded to the latest gratest Phd2, and see the multi-point guiding option now available. I'm eager to try that the first chance I have.   If you don't detect any other major issues from my feedback in this post, I tend to think my next main issue on the road to being able to guide well over at least 15 or 20 mins exposures is to address somehow the mismatch between guide camera resolution and picture camera resolution.  I see a number of options, maybe you can indicate which are the best, whether or not included in the following list:

    > invest time in PA at the beginning of each session (I dont' have a fixed position, and unfortunately each session is setup + teardown)

   > get a scope with a shorter focal (I wouldnt't go for a Newtonian though, it's often humid here, and I don't want to have to do mirror cleaning or collimate often), hopefully still 10" aperture if any

   > buy a new picture taking camera (I have to do this anyway!) and operate in 2x2 binning if needed to reduce effective resolution of the image and smooth out the guiding errors' effects on the pictures taken) -- I don't do binning > 1x1 with the Atik camera now because its chip is already tiny.

   > none of the above as the multipoint guiding will reduce the error so much that the mismatch between guiding and pic-taking cameras will be of no consequence

As always, thanks much

[Bruce Waddington]

Hi Stefano, see below.

 

From: open-phd...@googlegroups.com [mailto:open-phd...@googlegroups.com] On Behalf Of Stefano O
Sent: Monday, November 22, 2021 7:26 AM
To: Open PHD Guiding <open-phd...@googlegroups.com>
Subject: Re: [open-phd-guiding] Re: Poor guiding with new CEM70g' embedded guiding camera

 

Hello,

 

here's an update out of the meager 1 day of clear skies in the past few weeks (with no hopes in the near term to have a few more...).

 

While I didn't get to use the dedicated polar alignment tools and procedures available (I found out there are 3 in the docs, not just the classic drift alignment), I did give extra care this time to making sure the plate-solving tool provided by the CEM70 for PA was kept honest.  
So in essence, the divergence between RA and Dec (and their continuous attempt to correct on one side only) disappeared. Even the general scope alignment for goto needed very little corrections, and the calibration process didn't show any of the oddities seen the past 2 attempts -- the moral seems to be, don't trust the PA plate solving CEM70 out of the box:  my assumption was that it would not show you the target to hit if the star field doesn't match the neighborhood of the Polar Star, but it turns out I was quite wrong?

 

That said, here's the log:

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

 

I also was seemingly able to finally see the large RA sways that have been afflicting me apparently corrected by the latest repairs, and apart from the loss of tracking at the end of the first chunk of the log (due to meridian crossing -- more below on this), the mean error during tracking stayed well below 1", especially after I loosened the aggressiveness in RA. 

 

Questions:

- the first chunk of the log shows, if I read the Viewer charts well, still the RA drifting, meaning no too good PA yet. Is that correct? 

 

I don’t see this.  If you use the LogViewer tool, there’s a “drift” option as part of the normal statistics display.  You don’t have any drift problems that I can see and your polar alignment was apparently very accurate.

 

- it may also suggest I was too aggressive in correction? Incidentally, while I wanted to attempt Phd2''s own suggestion on the best guiding params to use, I was caught by the unfolding of the night and didn't get to try query Phd2 for the optimal config...

 

You should leave the parameters at their default values unless you’ve done a careful off-line analysis of the guiding and have a clear view of what you’re doing.  Stabbing around in real-time rarely works– see the appendix in:  https://openphdguiding.org/tutorial-analyzing-phd2-guiding-results/

 

-  back to the PA,   the second chunk of the  guiding   session was started after hitting the meridian and then re-centering the target (M36, which was quite high in the sky for most of the observing session). I didn't re-calibrate, but the log after this passage seems to show no drift in RA...  If my reading is correct, does that make any sense? Slewing to the other side of the meridian shouldn't affect the PA...

 

I really don’t see any drift problems and your polar alignment was fine.  I think you can safely put those things behind you and concentrate on your current guiding performance.  Keep in mind that drift in RA is more often caused by things like flexure rather than polar alignment error.

 

- yet, the resulting pictures were generally better in the first (pre-meridian) chunk of the guiding session; the post-meridian session, assuming I'm right in reading that it shows no drift in RA, ended up producing stars that were slightly but noticeably elongated in the RA direction (the pics from the first part of the guiding showed a bit of that too, but overall less the the second part). 

 

The problem you have now is probably the disparity between the Dec and RA RMS values.  Before the meridian flip, they were pretty close: 0.62” and 0.78”, so you should have been getting nice round stars.  After the meridian flip, the values diverged – 0.46” and 0.72” – so you were probably getting elongated stars for that reason.   That’s likely to be a result of the periodic error in the RA system:

 

 

As I recall, trying to do a periodic error correction on iOptron mounts is problematic.  If so, you can use the PHD2 PPEC guiding algorithm for RA to improve the RA guiding.  Give it an initial period length of 348 seconds and let it run.

So is this result on the pictures to be expected, considering the lower mean errors of the second guiding effort, and most of all considering that the mean errors were in both cases well below the single-pixel resolution the  picture taking camera was operating under? (1.25" for the camera, and > 0.9 for the mean errors in the first chunk of guiding, later down to 0.7 in RA and ~0.5 in Dec)
Is this perhaps the price to pay for having the internal guiding   camera operate at 6.4 arcsec/pix vs the scope going at 1.25  (the OTA has 2000mm focal, plus a 0.63x reducer, and the camera is an old Atik Titan with 7.4 micron pixels), ?

- the CEM70 is per se able to track beyond the meridian:  beside "Reverse Dec output after meridian flip", is there any other param to consider to continue guiding across the meridian?

 

I don’t recommend that you keep imaging for an extended time in a counterweights-up configuration.  It doesn’t affect the guiding because there is no meridian “flip”.  It’s flipping the scope to the other side of the pier that forces PHD2 to adjust the calibration data.  Meridian transit (cross-over), which is what you’re talking about, has no implications for PHD2.  But again, I think you are better off doing the flip, it isn’t difficult.

 

-  finally: I have upgraded to the latest gratest Phd2, and see the multi-point guiding option now available. I'm eager to try that the first chance I have.   If you don't detect any other major issues from my feedback in this post, I tend to think my next main issue on the road to being able to guide well over at least 15 or 20 mins exposures is to address somehow the mismatch between guide camera resolution and picture camera resolution.  I see a number of options, maybe you can indicate which are the best, whether or not included in the following list:

    > invest time in PA at the beginning of each session (I dont' have a fixed position, and unfortunately each session is setup + teardown)

   > get a scope with a shorter focal (I wouldnt't go for a Newtonian though, it's often humid here, and I don't want to have to do mirror cleaning or collimate often), hopefully still 10" aperture if any

   > buy a new picture taking camera (I have to do this anyway!) and operate in 2x2 binning if needed to reduce effective resolution of the image and smooth out the guiding errors' effects on the pictures taken) -- I don't do binning > 1x1 with the Atik camera now because its chip is already tiny.

   > none of the above as the multipoint guiding will reduce the error so much that the mismatch between guiding and pic-taking cameras will be of no consequence

 

To be honest, I think your best option is to abandon the embedded guider – the image scale is too coarse and there will be differential flexure between it and the main imaging scope.  If you read some informed reviews of the mount, that’s the common and expected conclusion.  It’s probably ok for short focal length, lightweight imaging scopes but is otherwise not up to the job.  I recommend getting a high-quality, binnable guide camera and an OAG assembly so you can guide through the main scope.  I think it’s worth the initial trouble of learning how to use the OAG and getting the guide camera well-focused, which is a one-time thing.  With the larger, more sensitive sensors used in modern guide cameras, finding stars for guiding is mostly a problem of the past.

 

Good luck,

Bruce

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/b0b5d802-2a22-46ad-8efb-231b05e1a746n%40googlegroups.com.

[S O]

Bruce,

thanks much.

This is to acknowledge most of your observations, and request a clarification or two:

• great to hear that you think that major mechanical shenanigans are cleared, and also that the PA is after all good with the approach I've taken
• I'll take another look at https://openphdguiding.org/tutorial-analyzing-phd2-guiding-results/ , but will keep in mind your recommendation not to manually pivot guiding params -- I was planning to use the estimator provided by Phd2, but got caught up in the excitement of seeing the general behavior finally under control and so tried to get the most pictures squeezed out of the time I had
• the elongated stars were oddly more pronounced in the second session when the error was overall less... still not sure how that came to be.  More variance around the RMS? If so, I don't think there's any such assessment promptly ready in Phd, is there?
  
• I used the PPEC in Phd2 once before, but it was at a time when the scope had those big RA jolts, and didn't do much. I'll read more about it and see to use it next time, assuming it can be worked in without compromising the other features of Phd (in particular the assessment of best guiding params mentioned above)
• the part I'm least clear about is on the meridian cross-over: so you suggest I actually do the flip when the meridian is hit, and that in that case Phd2 needs to adjust the calibration data ?  If so, I only know how to do the flip manually, and not sure at all how I should tell Phd2 in that case...
• OK on the OAG (so you think even the guide camera binnable uh?), I'm asking my the shops I'm in contact with.

Thanks many again

-s

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/001e01d7e090%2485bc94c0%249135be40%24%40earthlink.net.

[Bruce Waddington]

See below…

 

From: open-phd...@googlegroups.com [mailto:open-phd...@googlegroups.com] On Behalf Of S O
Sent: Wednesday, November 24, 2021 9:29 AM
To: open-phd...@googlegroups.com
Subject: Re: [open-phd-guiding] Re: Poor guiding with new CEM70g' embedded guiding camera

 

 

Bruce,

thanks much.

This is to acknowledge most of your observations, and request a clarification or two:

·        great to hear that you think that major mechanical shenanigans are cleared, and also that the PA is after all good with the approach I've taken

·        I'll take another look at https://openphdguiding.org/tutorial-analyzing-phd2-guiding-results/ , but will keep in mind your recommendation not to manually pivot guiding params -- I was planning to use the estimator provided by Phd2, but got caught up in the excitement of seeing the general behavior finally under control and so tried to get the most pictures squeezed out of the time I had

·        the elongated stars were oddly more pronounced in the second session when the error was overall less... still not sure how that came to be.  More variance around the RMS? If so, I don't think there's any such assessment promptly ready in Phd, is there?

Take another look at what I said:   The problem you have now is probably the disparity between the Dec and RA RMS values.  Before the meridian flip, they were pretty close: 0.62” and 0.78”, so you should have been getting nice round stars.  After the meridian flip, the values diverged – 0.46” and 0.72” – so you were probably getting elongated stars for that reason.   That’s likely to be a result of the periodic error in the RA system:

So I don’t see anything odd about it, it’s what we’d expect.  If you look at the statistical report in LogViewer, you see three values: RA rms, Dec rms, and Total rms.  In the case of your post-meridian-flip results, the RA rms was approaching 2x the Dec rms which puts you in danger of getting elongated stars.  There’s no hard and fast rule for this, it depends on the two image scales and the absolute values of the RMS numbers.

·        I used the PPEC in Phd2 once before, but it was at a time when the scope had those big RA jolts, and didn't do much. I'll read more about it and see to use it next time, assuming it can be worked in without compromising the other features of Phd (in particular the assessment of best guiding params mentioned above)

·        the part I'm least clear about is on the meridian cross-over: so you suggest I actually do the flip when the meridian is hit, and that in that case Phd2 needs to adjust the calibration data ?  If so, I only know how to do the flip manually, and not sure at all how I should tell Phd2 in that case...

I’m recommending that you don’t try to image “upside-down” for an extended period.  You should force the flip either at the meridian or shortly thereafter.  If you’re using an automation app like SGP, it can force the meridian flip for you.  It’s nothing more than slewing to the same target with the scope moving to the opposite side of the pier.  Since you’re using an ASCOM mount connection, PHD2 will know when a meridian flip has been done and it will adjust things for you – you don’t have to do anything.   If you’re running the session manually, just wait for the target to cross over the meridian, stop guiding, re-slew the scope to the same target coordinates that you started with, and resume guiding.

·        OK on the OAG (so you think even the guide camera binnable uh?), I'm asking my the shops I'm in contact with.

It’s best to have the flexibility of a guide camera that can bin.  You will probably buy something that has tiny pixels and you might end up in a situation where you are guiding at less than 0.5 arc-sec/px or you may find that the potential guide stars are very faint.  If you can bin the guide camera 2x2, you will deal with both problems.  It’s like everything else in the hobby, you don’t get more than you pay for but too frequently get less.

Good luck,

Bruce

Thanks many again

-s

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/CAH416NksXLYNbxrWHTNnaxnyS7bz5bKBKNWDkyCORuPj6JTHYA%40mail.gmail.com.

[S O]

Bruce,

Everything makes sense, thanks much once more.

stefano

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/005101d7e1b1%24949e43e0%24bddacba0%24%40earthlink.net.