×

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

Bi-monthly release with minor bug fixes and improvements

Ekos sends wrong latitude/longitude to mount

  • Posts: 322
  • Thank you received: 31
Here is a rewrite for the longitude function that seems to work, mostly.

It is off by one minute in some cases.

For example, when I use -80:12:00 in KStars, it sets it to 080*11 (not 12). If I use -80:12:20, then it uses 080*12 correctly. Don't know why.
// This override is needed, because the Sky Sensor 2000 PC requires a space
// between the command its argument, unlike the 'standard' LX200 mounts, which
// does not work on this mount.
int LX200SS2000PC::setSiteLongitude(double Long)
{
    int d, m, s;
    char temp_string[32];
    double longitude;
 
    if (Long < 0)
    {   
        // Long is negative in KStars, so west of Greenwich
        longitude = abs(Long);
    }
    else
    {   
        // Long is positive, so east of Greenwich
        longitude = 360 - Long;
    }
 
    getSexComponents(longitude, &d, &m, &s);
 
    snprintf(temp_string, sizeof(temp_string), ":Sg %03d*%02d#", d, m);
 
    return setStandardProcedure(PortFD, temp_string);
}
6 years 3 weeks ago #24672

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

Just use LX200 function and add the space, that's it.
6 years 3 weeks ago #24673

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

  • Posts: 322
  • Thank you received: 31
That does not work.

For 80:12:34 West, that does this:

"[SCOPE] CMD <:Sg 279:47#> "

And hand controller gets +080:13:00 (which is east of Greenwich!)
6 years 3 weeks ago #24674

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

  • Posts: 322
  • Thank you received: 31
This PR is now updated with the almost working code.

github.com/indilib/indi/pull/546

It is still off by one minute for longitude if I use xx:yy:00. yy will be yy -1. This is what getSexComponents() returns.

Since I enter the minutes and seconds in KStars, this is no longer an issue.
6 years 3 weeks ago #24676

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

In LX200, it's 360 - Longitude that is sent. So updateLocation(...) has INDI's longitude which is for your location this --> 279:48:00

279.8, then longitude that is sent is = 360 - 279.8 = 80.2 or 80:12 which is what ends up being sent to mount.
6 years 3 weeks ago #24677

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

  • Posts: 322
  • Thank you received: 31
That makes sense on paper.

The issue is that the hand controller now has +080:12 (i.e. east of Greenwich), instead of -080:12 (west of Greenwich). Having +080 totally messes up pointing.

My pull request works well on the coordinates I tried, both in KStars/INDI as well as the controller. It is off by one (80:11 instead of 80:12) if I don't put seconds in the longitude in KStars.

I wish Camiel Severijns would test and corroborate the findings, then comment here ... Maybe he moved on to another mount ...
6 years 3 weeks ago #24678

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

wait I don't understand, if you send this command:
:Sg 080*12:00#

Then the mount controller display +080:12 ?!!
6 years 3 weeks ago #24679

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

  • Posts: 322
  • Thank you received: 31
No.

As I said in a previous comment:

Sending

:Sg 080*12#

Works well, and sets the hand controller to -080:12, which is how Vixen says it should be, west of Greenwich.

Sending

:Sg 279*48#

Which is what the default code does in the lx200driver.cpp file, sets the hand controller wrongly to +080:12, which is east of Greenwich.

So, can't use the default code.

The code in the PR works for both cases (east or west of Greenwich)
Last edit: 6 years 3 weeks ago by Khalid.
6 years 3 weeks ago #24681

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

Ok so I was said above is correct. Take a look at the current LX200Telescope code:
bool LX200Telescope::updateLocation(double latitude, double longitude, double elevation)
{
    INDI_UNUSED(elevation);
    if (isSimulation())
        return true;
 
    if (!isSimulation() && setSiteLongitude(PortFD, 360.0 - longitude) < 0)
    {
        LOG_ERROR("Error setting site longitude coordinates");
        return false;
    }
...

Do you see what's happening?

For your case it's going to be this:
longitude = 279.8
setSiteLongitude( PortFD, 360 - 279.8 ) ---> setSiteLongitude(PortFD, 80.2)

Now let's go check setSiteLongitude
int setSiteLongitude(int fd, double Long)
{
    DEBUGFDEVICE(lx200Name, DBG_SCOPE, "<%s>", __FUNCTION__);
    int d, m, s;
    char read_buffer[32];
    getSexComponents(Long, &d, &m, &s);
    snprintf(read_buffer, sizeof(read_buffer), ":Sg%03d:%02d#", d, m);
    return (setStandardProcedure(fd, read_buffer));
}
It receives longitude = 80.2, then getSexComponent would return d = 80 and m = 12, and what gets sent is this:
:Sg080:12#

So in your case, the difference is the space, and maybe you need to add the seconds parts? That's it, the rest it the same.
Last edit: 6 years 3 weeks ago by Jasem Mutlaq.
6 years 3 weeks ago #24682

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

  • Posts: 322
  • Thank you received: 31
Ok, got it.

Before passing the longitude, it is subtracted from 360.

Tested and works fine, east and west of Greenwich.

PR now changed to reflect this.

github.com/indilib/indi/pull/546
6 years 3 weeks ago #24684

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

  • Posts: 322
  • Thank you received: 31
Pull request merged into main repository.
The following user(s) said Thank You: Jasem Mutlaq
6 years 3 weeks ago #24762

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

  • Posts: 6
  • Thank you received: 1
Hi

It looks like I have similar problem with latest INDI.
INDI-driver for gpsd deamon indi-gpsd-0.5-5

My real LAT/LONG as per gpsmon is : 42.0xxxxxxx /-88.0xxxxxx

When I connect GPSD in Indi my LAT/LONG is as below 42:xx:xx / 271:xx:xx
My EKOS test configuration is minimal. Just QHY camera and GPSD.

Can you help me please to resolve this problem?
Last edit: 3 years 6 months ago by euklides69.
3 years 6 months ago #61884
Attachments:

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

Time to create page: 0.402 seconds