×

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: 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.

  • Posts: 155
  • Thank you received: 10

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

Well, thank you Mike for spotting this. We shall look forward to hearing your progress with the new driver. As for AP, we did approach them on writing an SOP for KStars using the existing driver and they seem somewhat encouraging.

I am still not certain why we have had such good luck with the existing driver, but, I do know we never Sync unless we absolutely have to. Our SOP is always been to allow KStars to slew to the target, both, initially and using astrometry. Perhaps, our large FOV is allowing us the luxury of being almost a visual observer and our targets were small enough the problem seldom manifested itself. In any event, more accuracy is never a bad thing, especially, if we can solve faster.

Dan
6 years 9 months ago #17577

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?

Finally had a clear night and the function I suggested earlier in this thread seems to handle the SYNC problem I was seeing. I was able to have the Alignment module in Ekos use the "Slew to target" method and get to within a few arc-seconds of the requested RA/DEC.

It looks like this code has been rolled into the master branch now so I think this is resolved.
The following user(s) said Thank You: Jasem Mutlaq, nMAC
6 years 9 months ago #17588

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

  • Posts: 486
  • Thank you received: 87

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

I think that is one of the issues that it is affecting the lx200 driver running on my HEQ5 MCU Box !
Thanks, I will try the code too.
6 years 9 months ago #17591

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

Time to create page: 0.710 seconds