Hello,
I am still new to this mount and it sure is quirky. 
I have "Mount updates KStars" for Time and Location option selected in KStars.
But after the mount is synced with KStars I cannot use custom/manual locations.

Under "Location" menu item of RST-135 there's a list of locations which I thought was for manual entries:
My Home
Hubo Lab
Site 1
Site 2
---
GPS base

I select say Site 2 - it has Korean coordinates.
When I run KStars/Ekos those coordinates get replaced with my home location.
Looks like KStars updates the mount. It shouldn't do this.

Any idea anyone?

Thanks!
 

You can disable KStars updating mount in Settings --> Configure KStars ---> INDI

Yes. And I did. I have "Mount updates KStars" for Time and Location option selected in KStars.

Well,
I took my RST-135 out from home to a dark site for the first time.
It didn't update the time/location in KStars.
KStars was using the time/location from previous session which was at home.

Warnings in INDI Control Panel:
- Failed to get site latitude
- could not process mount date and time

KStars is set to "Mount updates KStars"

I was getting the same when was playing with time/location at home.

RST's hand controller acquired GPS successfully.

Am I missing some checkmark somewhere?

Thanks!

Max,
I stumbled upon this issue as well. I think there's a bug in the driver.
As far as I understand rainbow.cpp calls the function "getSiteLatitude" in lx200driver.cpp, where the parsing of the string fails and returns "-1" which throws the error you posted defined in rainbow.cpp's corresponding function.

I think this communication should be directly implemented into rainbow.cpp instead of lx200driver.cpp since there are some differences in string formatting (see below). Unfortunately I'm really struggling with string formats, so I cannot fix it myself.

RST-135 protocol​​​​​ & answers (which I reverse engineered from a serial connection // answers are edited for personal data protection):

• getSiteLatitude
  • command = ":Gt#"
  • answer = ":Gt+48*02'22.9#"
  • parsing in lx200driver.cpp:577
    • sscanf(read_buffer, "%d%*c%d:%lf", dd, mm, ssf)
    • this string format does not work with RST's answer!
• getSiteLongitude
  • command = ":Gg#"
  • answer = "Gg-011*30'01.0#"
  • parsing in lx200driver.cpp:650
    • sscanf(read_buffer, "%d%*c%d:%lf", ddd, mm, ssf)
    • this string format does not work with RST's answer!

Regarding time & date I did not fully understand what goes wrong...

• "getLocalDate" in rainbow.cpp > calls > "getCalendarDate" in lx200driver.cpp
  • command = ":GC#"
  • answer = ":GC05/17/21#"
  • parsing in lx200driver.cpp:424
    • sscanf(date, "%d%*c%d%*c%d", &mm, &dd, &yy)
    • should work?
• "getLocalTime" in rainbow.cpp > calls > "getLocalTime24" > redefined to getCommandSexa(fd, x, ":GL#") in lx200driver.h:122
  • command = ":GL#"
  • answer = ":GL12:57:14#"
  • parsing in lx200driver.cpp:???
    • I don't understand this part

Maybe Jasem can help? 

Christopher
 

Christopher -
Thanks for looking into this!
Looks like this could be an easy fix for someone familiar with these matters.

The getCommandSexa() function uses a function defined in indicom.c:195 to parse three doubles separated by a non 0-9 character, see here www.indilib.org/api/indicom_8c_source.html

Should be fine, too.

Looks like it just need to skip the first 3 bytes and it should process them OK... perhaps the functions need an override.

Actually not only skipping the first 3 bytes – the delimeter in between arcmin and arcsec is different as well:
answer = ":Gt+48*02'22.9#"
parsing in lx200driver.cpp:577 = sscanf(read_buffer, "%d%*c%d:%lf", dd, mm, ssf)

>> Maybe the following would be correct? sscanf(read_buffer, ":Gt%d%*c%d%*c%lf", dd, mm, ssf)


And likewise for Longitude:
answer = ":Gg-011*30'01.0#"
parsing in lx200driver.cpp:650 = sscanf(read_buffer, "%d%*c%d:%lf", ddd, mm, ssf)

>> Maybe the following would be correct? sscanf(read_buffer, ":Gg%d%*c%d%*c%lf", ddd, mm, ssf)

But in this case this would have to be implemented directly into rainbow.cpp since otherwise the general LX200 protocol won't work anymore.


// edit:
@Grimaldi:
Likewise the first 3 bytes are very likely the problem why getCommandSexa() and getLocalDate() throw errors as well.

@ِAstrophy Great! Do you think you can submit a PR to fix this?

Working on a pull request. I will not be able to compile and test it, price point for RST-135 is just too high (nice machinery, though).

@krno done! #1460

Ups: did a master -> master merge request.