@Alain,
Just a comment

The original lx200driver did not support non whole integer offsets (%03d), this was corrected in the base driver update (%+04.01lf).

The main GIT OnStep Command.ino also supports non whole integer offsets but limits what it will accept to :00, :30 and :45
It requires the exact strings if the ':' is included, e.g. ":00", ":30" and not :0 or :3

Now Meade command set does not cover the :45 offset directly only closely

en.wikipedia.org/wiki/List_of_UTC_time_offsets

What would be chance of adding the :00/:30/:45 capability in the OnStep overrides driver?

Disclaimer: I am not an OnStep user

Observation: Until issue 1604 the indilib community did not seem to suffer from the whole integer only offsets but if you are inside OnStep code

Gene

@gene,

it is possible and I checked in Kstars "Settings/Geographic" and effectively there are Countries having offsets of 30' or 45'
At least I learned something today! I didn't remember Nepal having +05:45 or Western Australia +08:45 ... and I visited both countries !!!
Time modifying, doing testing and then push for review!

@gene,

I fixed the UTCOffset so that now hh:00, hh:30 and hh:45 are supported.
I found a strange thing, UTC offset is rouded on 1st decimal so that 0,75 is 0,8 so I had to workaround that.
Not happy with it but it works

Any Idea?

PS: changes on github.com/azwing/indi

Thank you so much Alain for fixing this!
I will be testing tonight.

Hi.
I have a problem that the internal time of OnStep cannot get by INDI.

Set the location and date and time in OnStep.
(My OnStep uses GPS so it's automatic.)
Then connect OnStep to INDI and look at the INDI Control Panel in Ekos.
UTC is not get correctly.
Is there a solution to the cause of this problem?

OnStep is version 4.24q.
INDI is 1.9.5 running on a Raspberry Pi.
Uses the LX200 OnStep driver.

I tested it and it works for most scenarios, except negative fraction numbers , like -1.5.
Here is the fix:
utc_min=abs((offset-int(offset))*60);

@Alex,

I get old .... I will make the change and issue the pull request.
By the way, any idea where comes the round up of offset (When Offset of location it n,75 Indi considers offset as n,8 ?

@Norikyu,

may be setting time source in Kstars solves your problem.
I cannot test, have no time source in OnStep,

Select "Mount Updates Kstars"

Pull request issued, waiting for merge in master:

Current versions:
OnStep 4.24p
INDI Library: 1.9.5
indi_lx200_OnStep 1.15
kstars Version 3.5.8 Stable

Wonderful!

Not sure about this particular issue, but in general, floating point math is very imprecise.
You may get some really unexpected results, e.g. instead of 2x2=4 you may get 3.999999008
The whole idea of pushing floating number back and forth for this use case is totally wrong and probably requires much bigger refactoring.

Thank you for the hint.
But, I couldn't solve that.

I tried setting "Time & Location Updates" in the KStars INDI option to "Mount updates KStars".

When I tried it with Celestron AVX, I can get the location information and date and time of the AVX controller settings. And KStars will display the stars where the AVX is placed.

For OnStep Driver, the time will always be "UNIX Epoch-1 second", so KStars will display the wrong stars.
It looks like it is failing to get the internal time of OnStep.
Does the INDI OnStep Driver not support getting the OnStep internal time?

@Alex,

I don't think this is due to Floatint Point Math but rather to some obscure ftoa() and atof() somewere between kstars / Ekos and Indi but I am not able to track it ...
By doing tests if I enter for example 3,75 into control panel everything is ok.
If I enter the same value via Geographic settings I get 1,8 in control panel and Indi

So must be in Ekos / Kstars but I can be wrong as many times