×

INDI Library v2.0.7 is Released (01 Apr 2024)

Bi-monthly release with minor bug fixes and improvements

Dome slaving just before meridian flip with lx200 10micron mount

  • Posts: 8
  • Thank you received: 1
Dear all,
before I continue let me please state that I am incredibly impressed and very grateful for the developement of the INDI Framework.
Over last couple of weeks I developed a driver for the dome of our observator which drives the (very old and constant speed) motors of the dome with a Raspberry Pi. I also wrote the appropriate INDI driver which turned out to be comparatively easy when looking at other drivers for reference.
Now dome motion control is working fine. I also configured slaving with the proper parameters and this is also working fine (the shutter of the dome is very large and forgiving, although the fact that the guide scope is on the outer edge of the OTA makes things a bit more difficult).
We are only experiencing a single issue when it comes to completely autonomous operation of the entire thing with the 10micron GM4000 HPS mount: 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.
I immediately suspected that my own driver is the problem so we tested the same procedure with the dome simulator and the behavior is indeed the same. Having a look at the log of the dome simulator driver these interesting lines show up:
DEBUG   872.603872 sec  : JD: 2.45927e+06 - MSD: 10.3856
DEBUG   872.603930 sec  : MC.x: 0 - MC.y: 0 MC.z: 0.45
DEBUG   872.603951 sec  : HA: -10.8922  Lng: 10.8328 RA: 330
DEBUG   872.603965 sec  : Active Snoop, driver: LX200 10micron, property: TELESCOPE_PIER_SIDE
DEBUG   872.603982 sec  : OTA_SIDE: 1
DEBUG   872.603996 sec  : OTA_OFFSET: 1  Lat: 49.8328
DEBUG   872.604009 sec  : OC.x: 0.958235 - OC.y: -0.218538 OC.z: 0.265535
DEBUG   872.604026 sec  : Mount Az: 2.74314  Alt: 43.0684
DEBUG   872.604040 sec  : OV.x: 0.0349626 - OV.y: 0.729702 OV.z: 0.68287
DEBUG   872.604060 sec  : Calculated target azimuth is 29.88. MinAz: 4.78, MaxAz: 54.98
INFO    872.604073 sec  : Dome is moving to position 29.88 degrees azimuth...
DEBUG   872.604109 sec  : Dome is syncing to position 29.88 degrees...
and half a minute later
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...

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.

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

One note here: We didn't have INDI 1.8.8 installed from source but only 1.8.6, so I used this to link my own driver against. But as I said, in the above testing procedure, this wasn't used, the dome simulator was.

All the other logs are attached.

I would be very grateful for any help.

Ciao,
Philipp
The following user(s) said Thank You: Jasem Mutlaq
3 years 1 month ago #67770
Attachments:

Please Log in or Create an account to join the conversation.

Welcome Philip to INDI forums. Great work on the custom dome driver! It looks like that you indeed come across a legit bug in the INDI::Dome behavior when meridian flip is performed. Let me consult with Ferran first since he knows the dome code inside out.
3 years 1 month ago #67772

Please Log in or Create an account to join the conversation.

  • Posts: 79
  • Thank you received: 25
Hi Phillipe,

Nice to see you join to our community.

The change in Dome position from 29 degrees to 335 degrees was due the change of the OTA_SIDE property from 1 to -1.

This property can be changed by the telescope driver or by the user pressing the OTA Side button (I discard the second case for obvious reasons).

So, the question is why the telescope driver changed this property?

A nice test to be done would be to check your dome driver (or dome simulator) with the telescope simulator.

On the other hand, OTA pier side is a confusing concept when the telescope point to circumpolar stars, and this can cause programing bugs.

In my particular observatory, because my mount do not report the pier side, I always set this property manually, so I never seen this problem, of course.

Regards,
Ferran
3 years 1 month ago #67774

Please Log in or Create an account to join the conversation.

  • Posts: 8
  • Thank you received: 1
Hi Jasem and Ferran,
thank you very much for your quick replies.
if you are referring to
DEBUG   902.539768 sec  : OTA_SIDE: 1
and
DEBUG   903.696959 sec  : OTA_SIDE: -1
I can see it myself know, thank you for pointing this out.

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);
So actually there is no possiblity that the pier side is set incorrectly from the mount driver, correct?
I just remembered something additional: This odd behavior only occured when "doing" something with the mount, particularly guiding. When we just let it sit there, with guiding deactivated and no exposure active, everything was fine. But as soon as we activated guiding or told the mount to slew a bit higher because we couldn't find a star due to the bad transparency the pier side was reported as "-1". Having a look at the piece of code in INDI::Dome I can see that the pier side is only taken from the mount if
OTASideSP.s == IPS_OK
If this is not the case it simply takes this information from the hour angle which is calculated from the time, the observers longitude and the right ascension of the mount which in this case would imply that the flip is already done.
So, is it possible that when guiding or slewing is happening then
OTASideSP.s
is not
IPS_OK
and therefore the calculated pier side is taken which is on the other side?

Philipp
Last edit: 3 years 1 month ago by Philipp Weber.
3 years 1 month ago #67777

Please Log in or Create an account to join the conversation.

  • Posts: 79
  • Thank you received: 25
I will take a look this weekend. It's a long time since I wrote this code.
3 years 1 month ago #67783

Please Log in or Create an account to join the conversation.

  • Posts: 79
  • Thank you received: 25
Hi, I checked the code 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.
I have bad weather here, so I don't know when I could debug this.
3 years 1 month ago #67920

Please Log in or Create an account to join the conversation.

  • Posts: 79
  • Thank you received: 25
The following user(s) said Thank You: Philipp Weber
3 years 1 month ago #68071

Please Log in or Create an account to join the conversation.

  • Posts: 8
  • Thank you received: 1
Thank you very much for your effort!
In case it is useful, I can always perform a "dry run" under the closed dome, even during the day.
3 years 1 month ago #68080

Please Log in or Create an account to join the conversation.

  • Posts: 79
  • Thank you received: 25
I tried to repreduce the bug with the telescope simulator + dome simulator, but I can't.

Maybe is dependent on the procesing speed of the computer. Can you reproduce the same behavior with both simulators in the Respberry Pi?
3 years 1 month ago #68081

Please Log in or Create an account to join the conversation.

  • Posts: 8
  • Thank you received: 1
Okay, we aren't using a Raspberry Pi at all but a desktop computer wirh an Intel Core i7-9700 and 32GB of Memory.
Do you think that this might be an issue?
Yesterday when doing observations we didn't think abour it and forgot to deactivate dome slaving before the HA went above zero and the same happened again. With your real equipment this behavior is completely reproducible.
I'm wondering, is there any way I can supply you with better diagnostics?
3 years 1 month ago #68388

Please Log in or Create an account to join the conversation.

  • Posts: 79
  • Thank you received: 25
I'm working in a new version. I will do a basic test in my observatory, but my mount doesn't report pier side, so I can test it this part. When my tests were done I will ask you to test ti on your observatory.
3 years 1 month ago #68427

Please Log in or Create an account to join the conversation.

Time to create page: 0.212 seconds