RA & Dec rates differ - Mesu 200 mount

[alanhi...@gmail.com]

I have been using PHD2 with my Mesu 200 mount for several years now.  However, over the past 2 months I have been getting the alert 'The RA & Dec rates differ by an unexpected amount'.  

I am using the current version of PHD2 2.6.4dev5 and I wondered if anyone can point me in the right direction to resolving this annoying problem.  

The latest DebugLog and GuideLog are attached.

[Andy Galasso]

You've got a beautiful uniform orthogonal calibration, but the calibration data indicate that your RA guide rate is  4.22 arc-sec/second (~ 25% sidereal rate) and your Dec rate is 7.98 arc-sec per second (~ 50% sidereal rate).   Is it possible that there is some setting in the mount that is providing different guide rates on RA and Dec?

Another interesting observation is that in your Guiding assistant run you have a very uniform RA drift (2 arc-sec per minute) which implies the RA drive is not tracking at exactly sidereal rate. That again would indicate perhaps a setting in the mount controller could be set to a non-sidereal rate?

FWIW, although the calibration rates are unexpected in the sense that PHD2 is expecting the RA and Dec rates to be the same and is warning you that something could be amiss, PHD2 is perfectly capable of guiding with different RA and Dec rates and when the warning about the different rates is shown you have the option to select "Do not show calibration alerts of this type",

Andy

[Bruce Waddington]

Hi Alan.  Just a point of clarification on what Andy said.  The “unexpected” part of the alert is because the guide speeds  reported by your ASCOM driver are the same for both axes (8 arc-sec/sec) but the measurement shows the RA axis is moving at about 50% of that rate.  So it looks like either the reporting in the ASCOM driver is in error or the mount is behaving in a way the driver doesn’t know anything about.   As Andy said, PHD2 will handle different guide speeds on the axes, so no alert would have been generated if the RA rate had been reported by the driver as being 4 arc-sec. 

 

Hope this helps you track down the problem,

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.
For more options, visit https://groups.google.com/d/optout.

[alanhi...@gmail.com]

Hi Andy and Bruce,

Many thanks for looking at this for me.

An email to Lucas Mesu with the problem may shed some light on it.

I have been using PHD2 for a number of years with the Mesu Mount and not had a problem before and as the mount is so complicated I tend not to play around with its Config.  Having said that I have recently updated its firmware, perhaps therein lies the problem.

Regards

Alan

[alanhi...@gmail.com]

Hi Andy,

I have conducted further tests on the RA/Dec rate difference and have found that using ASCOM Pulse Guiding there is a difference in guide rates (Calibration alert details: Expected ratio at dec=3.2 is 0.998, actual is 0.485).  However, using ST4 guiding there is no such reported error.  I also note that there is a difference in direction for the RA drift rate between ST4 and ASCOM guiding.

I have been in contact with Lucas Mesu with the problem and he is also looking into it.  A further email has been sent to Dan Grey (Sitech), I am awaiting his reply.

In the mean time I would appreciate your advise on this issue.

Kindest regards

Alan

[bw_msgboard]

Hi Alan.  Andy is away from the forum for a while but I can probably answer your questions.  See below…

 

---

From: open-phd...@googlegroups.com [mailto:open-phd...@googlegroups.com] On Behalf Of alanhi...@gmail.com
Sent: Thursday, December 28, 2017 1:55 PM
To: Open PHD Guiding
Subject: Re: [open-phd-guiding] RA & Dec rates differ - Mesu 200 mount

 

Hi Andy,

 

I have conducted further tests on the RA/Dec rate difference and have found that using ASCOM Pulse Guiding there is a difference in guide rates (Calibration alert details: Expected ratio at dec=3.2 is 0.998, actual is 0.485).  However, using ST4 guiding there is no such reported error.  I also note that there is a difference in direction for the RA drift rate between ST4 and ASCOM guiding.

 

The sanity checking and guide rate alert can only be done using the ASCOM interface.  The ST-4 interface provides no useful information about mount guide speeds or anything else, which is why we encourage people to move away from it.  The question is whether the actual RA and Dec rates that PHD2 computes are different depending on whether you’re using ASCOM or ST-4.  If you look in the guide logs, each guiding session has a header with a bunch of information.  There’s a line there that starts with ‘Mount =’ – that line will contain, among other things, values for xRate and yRate.  When you used ASCOM guiding, your values were different by roughly 2x.  Is the same true for ST-4 guiding?  If the answer is ‘yes’, that means the guide speeds in the mount really are different by 2x between the RA and Dec axes.  If the answer is ‘no’, that implies the problem is perhaps in the ASCOM driver – it might simply be reporting the values incorrectly.

 

The RA drift rate direction can change depending on the underlying problem.  I assume you’ve kept the guide camera orientation (angle) unchanged.  Most RA drift problems that I’ve seen come from flexure or sagging in the guide camera/guide scope assembly – often because of some slop in a focuser.  The same came happen when an OAG is being used.  This slight movement results in a net drift of the guide star on the camera sensor when guiding is disabled.  If this is the underlying cause, the direction of the drift will depend on whether the scope is on the east or west side of the pier.  In other words, it will reverse direction after a meridian flip.  None of this has anything to do with the ST-4 vs. ASCOM guiding interface – it’s simply a matter of watching how the star moves on the camera sensor with guiding disabled.  

 

Hope this helps,

Bruce

 

I have been in contact with Lucas Mesu with the problem and he is also looking into it.  A further email has been sent to Dan Grey (Sitech), I am awaiting his reply.

 

In the mean time I would appreciate your advise on this issue.

 

Kindest regards

 

Alan

On Thursday, December 14, 2017 at 5:07:43 PM UTC, Andy Galasso wrote:

You've got a beautiful uniform orthogonal calibration, but the calibration data indicate that your RA guide rate is  4.22 arc-sec/second (~ 25% sidereal rate) and your Dec rate is 7.98 arc-sec per second (~ 50% sidereal rate).   Is it possible that there is some setting in the mount that is providing different guide rates on RA and Dec?

 

Another interesting observation is that in your Guiding assistant run you have a very uniform RA drift (2 arc-sec per minute) which implies the RA drive is not tracking at exactly sidereal rate. That again would indicate perhaps a setting in the mount controller could be set to a non-sidereal rate?

 

FWIW, although the calibration rates are unexpected in the sense that PHD2 is expecting the RA and Dec rates to be the same and is warning you that something could be amiss, PHD2 is perfectly capable of guiding with different RA and Dec rates and when the warning about the different rates is shown you have the option to select "Do not show calibration alerts of this type",

 

Andy

 

--

[alanhi...@gmail.com]

Hi Bruce,

Many thanks for picking this up.

I have checked the logs for last nights test and it does indeed show that the rates under ASCOM are ~2x (xRate=1.245; yRate=2.566), but using ST4 the rates are fairly similar (xRate=1.341; yRate=1.246).

At the moment I can live with the drift rate, but would really like to get to for the Calibration difference.

Regards

Alan

[bw_msgboard]

Hi Alan.  This is very good information, I think it should make it much easier for the mount/controller guys to see what’s happening.  Let’s recap what we know for sure:

 

1. Using the ASCOM interface, the mount *really is* moving at the two different speeds.  Even though PHD2 reads the guide speeds from the mount and uses those for sanity checking, it doesn’t use that speed information for actually doing the calibration.  So the x and y rates are calculated purely from measuring how far the star moves in each dimension using the same-sized guide pulse.
2. As you have found from the guide log, the measured rates are roughly the same using the ST-4 interface.  So we know in that case the mount really was moving at the same speed on both axes.
3. The difference in behavior must be coming from either the ASCOM driver or something in the mount controller that depends on how it’s receiving guide commands.

 

Yesterday I speculated that maybe the ASCOM driver was just reporting the speeds incorrectly, but this can’t be the case.  We know the guide speeds in the mount are actually different between the two interfaces.  Perhaps the ASCOM driver is setting the mount guide speeds incorrectly or maybe the problem is further downstream in the mount controller.  Hopefully they will be able to find it quickly with this new information.

 

Please let us know how this gets resolved – cheers,

Bruce

[Harry Page]

Hi

I also see this problem , did you manage to find what the problem is ?

Thanks

Harry

[bw_msgboard]

Hi Harry.  We didn’t hear of a resolution from Alan but I think he was pursuing the issue with the mount vendor.  The evidence seemed to point in the direction of a firmware update that he’d applied not too long ago – did you also update the firmware?

 

Bruce

 

---

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

Sent: Sunday, January 07, 2018 2:15 PM
To: Open PHD Guiding

--

[Harry Page]

Hi

Thanks for the reply

I have only been using th mesu with phd for a few month , have noticed this for a while , but phd guides ok still

so was only a bit concerned :)

I will try and contact Alan direct and see if he has any news , I am afraid I have not found the mesu sitech controller to be very bug free and there re many

small problems with it

Again many thanks

Harry

[alanhi...@gmail.com]

Hi Bruce,

As you are aware from other posts in this form, the problem has been identified and a fix published by the vendors of Sitech. I haven’t been able to test the fix as yet (weather in the UK is lousy), but it would appear from others that it works and that DEC compensation is not applied through Sitech, so I will try using DEC compensation in PHD2.

Anyway, I would like to thank you for all your help in trying to resolve this problem

Many thanks

Alan

[alanhi...@gmail.com]

Hi Harry,

You may be aware that Dan at Sitech has identified the problem with RA and Dec rates and has issued an update (0.92ge) which should have corrected the problem. I am yet to test the fix, he has also indicated that Sitech does not apply a Dec compensation as PHD2 manual suggests, so I will check the Dec compensation box in PHD2 to see what happens.

Alan

[bw_msgboard]

Hi Alan. I got an off-forum message last night from Richard about this, and
it contains some more good information. For example, the SiTech controller
apparently does *not* do automatic Dec compensation if the guide method is
ASCOM. But it evidently *does* do Dec compensation for ST-4 guiding.
Pretty complicated and hard for users to know what to do IMO, but there it
is.

Regards,
Bruce

Here's the full text of the message from Richard:

Hi Bruce,



All Dan Grey (The author of the Scitech driver used on the mesu) says is:



I found the trouble, I was doubling the declination guide position.



The readme for the new version says much the same.



I also used the star-cross test in phd and that now works fine too (it used
to produce crosses with unequal arms).



You may also find this interesting (quoted from a post by Dan Grey); I
always thought that the driver did dec compensation so I had it turned off
in phd but apparently it does not!



Hi guys,
So, in SiTechExe, I've never enabled the dec cosine guiding for the pulse
guide method. It seems all guiding software has the option, so if you're
guiding without using the guide inputs, you need to turn on the dec cosine
guiding in your guide software.

The check boxes in sitech config don't do anything if you're not using the
guide relays.
I say "not using guide relays" to let DonW know that if you're not using
guide relays, then you're using the pulse guide method.

Ok, how SiTech performs the pulse guide method:
Let's say SiTech receives a pulse guide command to guide North for 100
mSecs. Your guide rate is 5 arc seconds per second (set using ServoConfig)..
SiTechExe says "DecSetpoint=DecSetpoint + (5 * 0.1).
Now SiTechExe will move the mount north by 0.5 arc seconds.

Because we change the ra and dec setpoint, there's a few MUSTS in the
SiTechExe configuration.
1. If you want declination to guide, then you must not have "Freeze
Declination" checked.
2. There's a feature called "Track Only Sidereal (Don't use PXP)". This
must be UnChecked too.
3. In the Encoders tab, you must NOT have the "Drag Mode" checked..

-----Original Message-----
From: open-phd...@googlegroups.com
[mailto:open-phd...@googlegroups.com] On Behalf Of
alanhi...@gmail.com
Sent: Thursday, January 18, 2018 7:25 AM
To: Open PHD Guiding

[bw_msgboard]

A small correction: if you're guiding with an ST-4 cable, you'll need to
disable Dec compensation in PHD2. If guiding through ASCOM, you would leave
the PHD2 option enabled. Or so we hear from the SiTech driver developer...

Regards,
Bruce

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

alanhi...@gmail.com
Sent: Thursday, January 18, 2018 7:29 AM
To: Open PHD Guiding

[richard martin]

Doh! it's a case of RTFM for me. The sitech manual clearly says:

Since Sitechexe does “equal area panning and guiding”, do not use the option in your autoguider program to correct for scope declination if you are using relay guiding or a direct guider input from your camera (like from an SBIG cable connection)  or you get twice the proper correction!  

However, if you are using “ascom guiding” (i.e. your autoguider is connected via ascom, this is not true, so for ASCOM guiding, it’s best to do the declination correction from within your autoguider program. 

Richard

On Thursday, 14 December 2017 13:11:51 UTC, alanhi...@gmail.com wrote: