×

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

Bi-monthly release with minor bug fixes and improvements

Read More...

lx200ap possibly detecting wrong LX200_FORMAT on GTOCP4 box?

  • Posts: 105
  • Thank you received: 30

lx200ap possibly detecting wrong LX200_FORMAT on GTOCP4 box? was created by Michael Fulbright

I am trying to track down a problem with my Mach1 with a GTOCP4 control box.

When I sync the command sent to the mount (CM# or CMR#) is in the short LX200 format.

I have a VM now where I can build the master branch of indilib.

I read about debugging drivers but I am having trouble getting a breakpoint that will fire with checkLX200Format() is called.

I was able to determine it believes the LX200 format is short - but the return values from ":GR#" is
SCOPE   44.216251 sec   : CMD <#:GR#>
SCOPE   44.256457 sec   : RES <20:57:42.4>

and from ":GD#" is
SCOPE   45.539812 sec   : CMD <#:GD#>
SCOPE   45.557633 sec   : RES <+90*00:00>

which would seem to indicate the mount is using the long format.

I also cannot see any of the lx200generic initialization DEBUG output (like the debug output in checkLX200Format()) in any of the logs created when I put the lx200ap driver into DEBUG mode using the INDI control.

I know how to start the indiserver in gdb with the proper command line to follow the child:
gdb --eval-command="set follow-fork-mode child" --args indiserver -v indi_lx200ap indi_simulator_ccd

I put a short sleep() in lx200generic.cpp::ISInit() so I could break and set a breakpoint on checkLX200Format() once the driver is loaded but then I couldn't seem to connect to the indiserver any longer as Ekos said no remote server was listening on the proper port.

I feel like this must be a normal scenario where you want to debug the initialization of a driver so if there are instructions on how to do this I'd love to see them so I could debug this issue and supply a patch.
6 years 9 months ago #17555

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

Replied by Jasem Mutlaq on topic lx200ap possibly detecting wrong LX200_FORMAT on GTOCP4 box?

Watch the 2nd video here: indilib.org/develop/developer-manual/163...ent-environment.html

It shows how to debug a driver in QtCreator. Let me know if this is sufficient.
6 years 9 months ago #17556

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

  • Posts: 105
  • Thank you received: 30

Replied by Michael Fulbright on topic lx200ap possibly detecting wrong LX200_FORMAT on GTOCP4 box?

Thank you qtcreator seems to do the trick.

I have been able to set a breakpoint in LX200AstroPhysics::updateProperties() and it is hit when I connect to the driver.

However I don't seem to be able to catch the driver calling lx200driver.cpp::checkLX200Format() when I load the indi_lx200ap driver.

Is it possible this is not called - digging some more...
6 years 9 months ago #17563

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

  • Posts: 155
  • Thank you received: 10

Replied by Dan Holler on topic lx200ap possibly detecting wrong LX200_FORMAT on GTOCP4 box?

Since we use the AP driver, I should like to ask what specifically is the problem you are having? Are you saying KStars does not Sync the position? Slewing issue?

Dan
6 years 9 months ago #17564

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

  • Posts: 105
  • Thank you received: 30

Replied by Michael Fulbright on topic lx200ap possibly detecting wrong LX200_FORMAT on GTOCP4 box?


When the Alignment model of Ekos SYNCs (mapped to RECAL) the mount the INDI driver is using the Meade SHORT FORMAT so the precision of the sync'd value is lost.

I give details here:

indilib.org/forum/ekos/2339-first-night-...questions.html#17512

What I am trying to do is see how the indi_lx200ap driver determines the format to use.

There is a function called checkLX200Format() which parses the output from the mount to autodetect this.

With my GTOCP4 mount it seems to end up setting the format to 0 which is the short format.

At this point I'm not even sure the fuction checkLX200Format() is used by the indi_lx200ap driver.

I'm just learning this code base so hopefully after a couple more sessions I'll be able to figure this stuff out on my own.
6 years 9 months ago #17565

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

  • Posts: 155
  • Thank you received: 10

Replied by Dan Holler on topic lx200ap possibly detecting wrong LX200_FORMAT on GTOCP4 box?

I guess I still do not fully understand. I am curious to ask what application specifically are you doing which requires arc second pointing accuracy? Do I understand this correctly, the routine is truncating the arc seconds, thus pointing accuracy might be off by as much as 1 arc minute? Depending on the telescope's size, I would seriously question whether the gearing engages and maintains tracking in arc second precision after any given slew.

I will mention we are only using a 14" for imaging with a AP1600GTO, but even a Mach 1, I would question if KStars correctly calculated the position the mounting could point to arc second accuracy. In our case, our camera field is sufficient we never noticed this error.

Dan
6 years 9 months ago #17566

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

  • Posts: 105
  • Thank you received: 30

Replied by Michael Fulbright on topic lx200ap possibly detecting wrong LX200_FORMAT on GTOCP4 box?

I am using the Alignment tab in Ekos to precisely slew to a target position using plate solving.

Essentially the way it is working now it is truncating the arc-seconds field of the plate solved position. So it could be off by 59 arc-seconds, which in RA is a big error.

Basically it makes the precise slew feature useless as it will forever loop trying to get closer but since the short format is used it just oscilates back and forth.

It is easy to fix since the AP can handle the long format and so why not use it?

I don't know if you image much but it is trivial with a good mount like the AP to use plate solving to point to within 20-30 arcseconds.

Remember 59 arc-seconds in RA is not a small angular distance depending on your DEC. If I am doing math correctly at DEC=0 then 1 arcmin of RA is 1/4 of a degree angular distance.
Last edit: 6 years 9 months ago by Michael Fulbright. Reason: Made software used more specific.
6 years 9 months ago #17567

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

Replied by Jasem Mutlaq on topic lx200ap possibly detecting wrong LX200_FORMAT on GTOCP4 box?

I pushed a simple change to lx200ap and it might help in your case. I made it explicitly call checkLX200Format since the parent (LX200Generic) one wasn't being called as it was in getBasicData which is never used by LX200AP. Check if this makes a difference.
The following user(s) said Thank You: Michael Fulbright
6 years 9 months ago #17569

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

  • Posts: 105
  • Thank you received: 30

Replied by Michael Fulbright on topic lx200ap possibly detecting wrong LX200_FORMAT on GTOCP4 box?


So I think that is a move in the right direction - it now autodetects LONG FORMAT.

But I don't think it is completely correct yet.

The AP "protocol G" docs show the format for setting DEC is:
:Sd sDD*MM# or :Sd sDD*MM:SS#

but when using the lx200 LONG_FORMAT the function used for syncing (lx200driver.cpp::setObjectDEC()) formats it as
:Sd sDD:MM:SS#

Note the AP spec says a '*' goes between DD and MM, while the generic lx200 code uses a ':'.

At the moment when I sync with your change things act oddly and I wouldn't recommend anyone using it.

Note when doing a slew the AP driver overrides the generic case and write out the coordinates properly, look at LX200AstroPhysics::Goto.

I suspect a similar change is needed for slewing (and any other time coordinate are sent)?
Last edit: 6 years 9 months ago by Michael Fulbright. Reason: Wrong function specified
6 years 9 months ago #17570

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

  • Posts: 105
  • Thank you received: 30

Replied by Michael Fulbright on topic lx200ap possibly detecting wrong LX200_FORMAT on GTOCP4 box?

I think I have a working solution.

1) We can probably lose the checkLX200Format() call - I don't think we want to leverage any of the routines in the mainline lx200 driver to send coordinates because of the issue with DEC coordinates I brought up in the previous post on this thread. A quick look at the lx200 telescope drivers seems to show these routines were only used in GOTO and SYNC methods.

2) My solution was to improve LX200AstroPhysics::Sync() to handle things correctly.
- When the "CM" command is used I replaced the existing call to the lx200generic SYNC method with the proper code to send the coordinates using the setAPObjectRA() and setAPObjectDEC() calls.
- I modified the existing code handling the "CMR" command by changing the existing calls to setObjectRA()/setObjectDEC() to the AP specific ones.

Only tested it inside by it seems to work properly. Hopefully we will have a clear night soon and I can run a session with it.

I based this code on the master branch.

I believe the code could be refactored to be simpler - I just wanted to keep it simple so I could see what was going on.

If there is a way you prefer to receive patches please let me know:
bool LX200AstroPhysics::Sync(double ra, double dec)
{
    char syncString[256];
 
    int i = IUFindOnSwitchIndex(&SyncCMRSP);
 
 
    if (isSimulation() == false && (setAPObjectRA(PortFD, ra) < 0 || (setAPObjectDEC(PortFD, dec)) < 0))
    {
        EqNP.s = IPS_ALERT;
        IDSetNumber(&EqNP, "Error setting RA/DEC. Unable to Sync.");
        return false;
    }
 
    if (i==0)
    {
        if (isSimulation() == false && APSyncCM(PortFD, syncString) < 0)
        {
            EqNP.s = IPS_ALERT;
            IDSetNumber(&EqNP, "Synchronization failed.");
            return false;
        }
    }
    else
    {
        if (isSimulation() == false && APSyncCMR(PortFD, syncString) < 0)
        {
            EqNP.s = IPS_ALERT;
            IDSetNumber(&EqNP, "Synchronization failed.");
            return false;
        }
    }
 
    currentRA  = ra;
    currentDEC = dec;
 
    DEBUGF(INDI::Logger::DBG_DEBUG, "Synchronization successful %s", syncString);
 
    DEBUG(INDI::Logger::DBG_SESSION, "Synchronization successful.");
 
    TrackState = SCOPE_IDLE;
    EqNP.s     = IPS_OK;
 
    NewRaDec(currentRA, currentDEC);
 
    return true;
}
Last edit: 6 years 9 months ago by Michael Fulbright.
6 years 9 months ago #17571

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

  • Posts: 155
  • Thank you received: 10

Replied by Dan Holler on topic lx200ap possibly detecting wrong LX200_FORMAT on GTOCP4 box?

Thanks Mike for you explanation. I believe I have seen your mount behavior in the past on some slews. We always thought it was something we were doing incorrectly. But, I seem to recall making some changes to our procedure which apparently allowed us to work around it. I will have a look next time I am at the observatory and check on this.

As for imaging, we definitely image, but not to arc second accurate fields. We always use the Ekos Alignment tab for slew to target, and, it works just fine. KStars, for us will center any target within the center of our camera FOV. (~18 x 23 minutes) Astrometry typically will only take <4 or maybe 5 iterations to achieve acceptable centering.

Now, I must admit, we are fixed observatory. We know the mount 'sweet spots', so we are generally imaging above 30 degrees of our local horizon. This might explain why we might not have seen this behavior in recent years. Typically, we are imaging targets which have DEC angles not approaching zero.

Dan
The following user(s) said Thank You: Michael Fulbright
6 years 9 months ago #17574

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

  • Posts: 105
  • Thank you received: 30

Replied by Michael Fulbright on topic lx200ap possibly detecting wrong LX200_FORMAT on GTOCP4 box?

I'm glad to hear other people with AP mounts are using INDI. I had originally asked AP about it and they said it wasn't on their immediate horizon so I didn't pursue it further. Then a few local club members started to tinker with it and I discovered the indi_lx200ap driver.

The problem with SYNCs wasn't necessary easy to spot. The GOTO code was handling coordinates properly but the SYNC code wasn't. But due to a fortuitous set of circumstances it was falling back to the SHORT FORMAT which just happens to almost do the right thing - someone doing visual might have just written it off and manually nudged the scope to center an object. When you are doing automated imaging, however, it is a disaster!

I think there are a few tweaks it could use and then the AP mount support will be in really good shape. I saw a commit yesterday to support pier side, which explains why PHD2 didn't seem to handle flipping the guide calibration automatically when I was testing it.

Michael
6 years 9 months ago #17575

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

Time to create page: 0.766 seconds