Dome slaving moves back and forth just before meridian flip

[fcasarramona]

Extracted from Indi forum Topic
https://indilib.org/forum/domes/8909-dome-slaving-just-before-meridian-flip-with-lx200-10micron-mount.html

When the mount has hour angles just before the meridian flip the dome starts going back and forth between the currently required position and, evidently, the position it should be in after the meridian flip.

These 30 odd degrees roughly is the position where the dome should be after the meridian flip (we confirmed that by performing it) and these 335 odd degrees is where it is supposed to be before the flip (when the log was taken).

Since this is happening with the dome simulator driver I think I can rule out my own driver as the problem, the only difference is that it is actually in reality starting to go crazy.

Desktop (please complete the following information):
The version we used are, from ppa:mutlaqja/ppa:
INDI Library: 1.8.8
Code 1.8.8-tgz. Protocol 1.7.
kstars 3.5.1 Stable
Raspberry PI

Log Files
INFO 902.046243 sec : Dome reached requested azimuth angle.
DEBUG 902.539657 sec : JD: 2.45927e+06 - MSD: 10.394
DEBUG 902.539715 sec : MC.x: 0 - MC.y: 0 MC.z: 0.45
DEBUG 902.539738 sec : HA: -10.8837 Lng: 10.8328 RA: 329.999
DEBUG 902.539751 sec : Active Snoop, driver: LX200 10micron, property: TELESCOPE_PIER_SIDE
DEBUG 902.539768 sec : OTA_SIDE: 1
DEBUG 902.539782 sec : OTA_OFFSET: 1 Lat: 49.8328
DEBUG 902.539795 sec : OC.x: 0.957603 - OC.y: -0.22015 OC.z: 0.264175
DEBUG 902.539812 sec : Mount Az: 2.76338 Alt: 43.0728
DEBUG 902.539826 sec : OV.x: 0.0352179 - OV.y: 0.729638 OV.z: 0.682927
DEBUG 902.539845 sec : Calculated target azimuth is 29.89. MinAz: 4.78, MaxAz: 54.99
DEBUG 903.696934 sec : JD: 2.45927e+06 - MSD: 10.3943
DEBUG 903.696951 sec : MC.x: 0 - MC.y: 0 MC.z: 0.45
DEBUG 903.696956 sec : HA: -10.8834 Lng: 10.8328 RA: 329.999
DEBUG 903.696959 sec : OTA_SIDE: -1
DEBUG 903.696962 sec : OTA_OFFSET: 1 Lat: 49.8328
DEBUG 903.696965 sec : OC.x: -0.957578 - OC.y: 0.220212 OC.z: 0.635877
DEBUG 903.696969 sec : Mount Az: 2.76413 Alt: 43.073
DEBUG 903.696972 sec : OV.x: 0.0352272 - OV.y: 0.729634 OV.z: 0.68293
DEBUG 903.696977 sec : Calculated target azimuth is 335.31. MinAz: 309.91, MaxAz: 0.72
INFO 903.696980 sec : Dome is moving to position 335.31 degrees azimuth...
DEBUG 903.696988 sec : Dome is syncing to position 335.31 degrees...

[fcasarramona]

Asking if the change in pier side was due to telescope driver, the reporter said:

I just checked the log from the lx200 10micron driver to see what the mount reports. It always reports 'E' in the #Ginfo# for pier side so this is apparently correct. You can also check that yourself, it's in the logs attached in the first post. And the single line updating the telescopes pier side in the driver is also pretty clear I think:

setPierSide((toupper(Ginfo.SideOfPier) == 'E') ? INDI::Telescope::PIER_EAST : INDI::Telescope::PIER_WEST);

[fcasarramona]

I checked the code in indidome.cpp and saw a bug. This is the relevant code:

   LOGF_DEBUG("HA: %g  Lng: %g RA: %g", hourAngle, observer.lng, mountEquatorialCoords.ra);

    //  this will have state OK if the mount sent us information
    //  and it will be IDLE if not
    if(CanAbsMove() && OTASideSP.s == IPS_OK)
    {
        // process info from the mount 
       if(OTASideS[0].s == ISS_ON) OTASide = -1;
        else OTASide = 1;
   }
    else
    {
        //  figure out the pier side without help from the mount
        if(hourAngle > 0) OTASide = -1;
        else OTASide = 1;
        //  if we got here because we turned off the PIER_SIDE switches in a target goto
        //  lets try get it back on
        if (CanAbsMove())
            triggerSnoop(ActiveDeviceT[0].text, "TELESCOPE_PIER_SIDE");

    }

    OpticalCenter(MountCenter, OTASide * DomeMeasurementsN[DM_OTA_OFFSET].value, observer.lat, hourAngle, OptCenter);

    LOGF_DEBUG("OTA_SIDE: %d", OTASide);
    LOGF_DEBUG("OTA_OFFSET: %g  Lat: %g", DomeMeasurementsN[DM_OTA_OFFSET].value, observer.lat);
    LOGF_DEBUG("OC.x: %g - OC.y: %g OC.z: %g", OptCenter.x, OptCenter.y, OptCenter.z);

This part is wrong:

       // process info from the mount 
       if(OTASideS[0].s == ISS_ON) OTASide = -1;
        else OTASide = 1;

OTASideS[0] is the switch for east side, and OTASide variable meaning is 1 for east and -1 for west.

So the correct code must be:

       // process info from the mount 
       if(OTASideS[0].s == ISS_ON) OTASide = 1;
        else OTASide = -1;

I did not debug this, but seems related.

[knro]

@fcasarramona Thanks!! Do you plan to submit a PR for this? or should I just apply your change?

[fcasarramona]

I'm not sure if my change is ok. I need to debug first. May be there something more ...

[fcasarramona]

I tried to reproduce this bug with KStars 3.5.2 for OSX with a telescope simulator and dome simulator with no success.
Maybe the bug has some relation with LX200 10 micro implementation particularities or maybe only happens in some slow computing environments, like Raspberry PI.

[jpaana]

This might be related to similar behavior I had a couple of years ago and forgot I crudely worked that around then. The symptom was that near meridian the dome occasionally moved to the other side as if the mount had switched side and then immediately back sometimes causing ruined subs. This was possibly when the mount was already pointing over the meridian, but mount hadn't yet flipped or vice versa when I "pre-flipped" the mount to already on the east side before the target crossed the meridian. I have different equipment (ScopeDome dome and EQMod / EQ8 mount) and run on a small x64 computer so I don't think this is an issue in the driver or hardware but the Dome base class.

The hacky workaround which "fixed" this for me was to just always use the mount reported pier side and not one derived from pointing info at all, namely the diff is:

diff --git a/libs/indibase/indidome.cpp b/libs/indibase/indidome.cpp
index 0252801e..18443ab3 100644
--- a/libs/indibase/indidome.cpp
+++ b/libs/indibase/indidome.cpp
@@ -1297,7 +1297,7 @@ bool Dome::GetTargetAz(double &Az, double &Alt, double &minAz, double &maxAz)
 
     //  this will have state OK if the mount sent us information
     //  and it will be IDLE if not
-    if(CanAbsMove() && OTASideSP.s == IPS_OK)
+    if(true || (CanAbsMove() && OTASideSP.s == IPS_OK))
     {
         // process info from the mount
         if(OTASideS[0].s == ISS_ON) OTASide = -1;

My guess is that OTASideSP.s goes to busy during a guide pulse or something which would cause using the wrong info for a while. So this is what worked for me, but would need a bit more testing and clean up.

[fcasarramona]

This might be related to similar behavior I had a couple of years ago and forgot I crudely worked that around then. The symptom was that near meridian the dome occasionally moved to the other side as if the mount had switched side and then immediately back sometimes causing ruined subs. This was possibly when the mount was already pointing over the meridian, but mount hadn't yet flipped or vice versa when I "pre-flipped" the mount to already on the east side before the target crossed the meridian. I have different equipment (ScopeDome dome and EQMod / EQ8 mount) and run on a small x64 computer so I don't think this is an issue in the driver or hardware but the Dome base class.

The hacky workaround which "fixed" this for me was to just always use the mount reported pier side and not one derived from pointing info at all, namely the diff is:

diff --git a/libs/indibase/indidome.cpp b/libs/indibase/indidome.cpp
index 0252801e..18443ab3 100644
--- a/libs/indibase/indidome.cpp
+++ b/libs/indibase/indidome.cpp
@@ -1297,7 +1297,7 @@ bool Dome::GetTargetAz(double &Az, double &Alt, double &minAz, double &maxAz)
 
     //  this will have state OK if the mount sent us information
     //  and it will be IDLE if not
-    if(CanAbsMove() && OTASideSP.s == IPS_OK)
+    if(true || (CanAbsMove() && OTASideSP.s == IPS_OK))
     {
         // process info from the mount
         if(OTASideS[0].s == ISS_ON) OTASide = -1;

My guess is that OTASideSP.s goes to busy during a guide pulse or something which would cause using the wrong info for a while. So this is what worked for me, but would need a bit more testing and clean up.

Thanks Jarno,
This explains why simulators don't show this issue, because telescope simulator always flips the mount to the "correct" side.

I will try the telescope simulator to guide across the meridian to see if this happens.

[fcasarramona]

No, simulators don't show this behavior after crossing the meridian just tracking.

[knro]

Thank you all for the follow up. What's the best course of action right now? Should we add some sort of settle period to ensure the OTA side was really switched and it wasn't just some noise?

[fcasarramona]

@knro I was thinking about this and concluded pier side determination was somewhat confusing.
Dome driver determines pier side using 3 different methods depending on different circumstances: User defined, as reported by the mount or from hour angle.

I think it would be better to let decide to the user what to use, adding this in the indidome.cpp:

    IUFillSwitch(&OTASideS[0], "DM_OTA_SIDE_EAST", "East", ISS_OFF);
    IUFillSwitch(&OTASideS[1], "DM_OTA_SIDE_WEST", "West", ISS_OFF);
    IUFillSwitch(&OTASideS[2], "DM_OTA_SIDE_MOUNT", "Mount", ISS_OFF);
    IUFillSwitch(&OTASideS[3], "DM_OTA_SIDE_HA", "Hour Angle", ISS_OFF);

This way, pier side determination will be always consistent and predictable.

I could program the change but I'm having difficulties setting up a debug environment.

[knro]

@fcasarramona What's your difficulties exactly? I'm more than glad to help.

[fcasarramona]

I created a pull request (#1373) solving this issue. I debugged with the simulators, so some test with real equipment was required.

[knro]

@jpaana Can you please check? I can only test with simulators as well.

@fcasarramona from the options above, which one is default? Mount?

[fcasarramona]

@knro Yes, default to Mount is safe, because if Mount don't report pier side it will behave as Ignore.

[jpaana]

@jpaana Can you please check? I can only test with simulators as well.

Sure, it seems to be a cloudy night so can't image anyway :)

[jpaana]

Did some quick testing and it seems there are a few issues left to fix.

At first I tested the basic case that target is slightly west of meridian, OTA is on the east side. Setting meridian side option to west and east worked in relation to the target, west being the one where the OTA would point out of the shutter correctly. Then I set it to mount and it seems to be backwards, ie. it assumed the OTA was on the west side and moved the shutter to wrong position. Setting to hour angle had the same issue, ie. shutter was on the wrong side. My target was at around azimuth 190 degrees and when the OTA is on east side, the shutter should end up at around 167 degrees, but it ended up at about 224 degrees, which would be correct if OTA was on the west (ie. "wrong") side of pier.

Then I pointed the OTA to a target east of the meridian, but forced the mount to stay on the east side too. Setting to mount was still switched, hour angle resulted in the right position this time (as it seems to be switched).

Then I flipped the OTA to west side pointing to the same target east of meridian. Both modes were wrong way around like before.

Last I moved to west of meridian target, but forced OTA to stay west of pier and the results were the same as before.

So it seems that mount and hour angle modes have the pier sides swapped in this version. I'm also not quite sure if the forced east and west settings should be based on the target or mount side, I think I'd prefer mount pier side as that is what the setting is about. So I'd change the label to Telescope pier side and flip the east/west around. And the mount and hour angle modes need to be swapped around too.

[jpaana]

Also the setting doesn't seem to get saved, which might be an issue, not sure.

[fcasarramona]

Solved in #1373