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. 

That's great – thanks Grimaldi! I'll try this out as soon as it's merged.

The other thing is regarding date & time. The following error is reported in the logs:
<code>2021-05-18T19:58:54: [WARNING] Could not process mount date and time: :GC05/18/21T00:00:00 </code>
As far as I understand the string datetime = ":GC05/18/21T00:00:00" is concatenated in rainbow.cpp:1316 out of "cdate" + T + "ctime". The log shows that variable "cdate" falsely includes ":GC" and "ctime" is completely 0. The reason for that is very likely the same, because RST-135 answers with a leading ":GL" into getCommandSexa(). Do you have an easy to implement fix for that as well?

I actually checked out indilib as well and was working on a solution by directly sending serial commands inside of rainbow.cpp and processing it there instead of using lx200driver.cpp. Your's is definitely more elegant and professional.   And by the way: Never worked with git and pull requests before.

Built and tested Grimaldis fix on RPi4 with RST-135 mount: Location pull from mount seems to work now, but there is another fault I think. Obviously KStars/Ekos writes back into the mount after connection process and overrides location information into the EEPROM of the mount, although KStars/INDI is set to "Mount updates KStars". Seems like updateLocation() is called somewhere after starting Ekos. Simply disconnecting and connecting devices in Ekos does not override location in mount, but a restart of INDI Profile and reconnecting does.
Or is this a correct behaviour which I am misunderstanding?

Yes, that's another issue.
All my custom/manual locations eventually got overwritten with KStars location while I was testing...

There‘s probably a couple of other locations in code where „%*[^0-9]$ or some such needs to be prepended to the sscanf, to ignore repetition of the command. I‘ll have a look later today.

Thank you guys so much for looking into this!
Unfortunately I don't have appropriate skills to contribute... : (