INDI Library v1.9.3 Released (11 Nov 2021)

Bimonthly Stable INDI Library release introduces new drivers and fixes for existing ones. Some highlights:

Driver OnStep (LX200 like) for INDI

  • Posts: 283
  • Thank you received: 32
OnStep with <strong>OnStepX 10.03k</strong>

I am starting testing OnSteX and even if things seem to work so far there is an annoying thing with polling.
The polling interval stays at 16s whatever setting I use under "Options" "Polling Period".

The same driver does behave normally with <strong>OnStep 4.24j</strong> polling 1s or even 500ms if I want.

I would like to know if somebody else observed this or is working on that issue before I start changing the code.

here the log and in orange the long time after cmdDatehhmmsssecondsdelta stotal s  

Date           hh    mm  ss      seconds    delta s    total s        
[2021-10-01T    14    0    39,870    0        0,000     0,000   CMD    <:GR#> "
[2021-10-01T    14    0    39,887    1,887    1,887    1,887    RES    <19:29:46> "
[2021-10-01T    14    0    39,887    1,887    0,000    1,887    VAL    [19.4961] "
[2021-10-01T    14    0    39,887    1,887    0,000    1,887    CMD    <:GD#> "
[2021-10-01T    14    0    39,888    1,888    0,001    1,888    RES    <+90*00:00> "
[2021-10-01T    14    0    39,888    1,888    0,000    1,888    VAL    [90] "
[2021-10-01T    14    0    39,888    1,888    0,000    1,888    CMD    <:GU#> "
[2021-10-01T    14    0    39,891    1,891    0,003    1,891    RES    <nNpHEo150> "
[2021-10-01T    14    0    39,891    1,891    0,000    1,891    CMD    <:Gm#> "
[2021-10-01T    14    0    44,903    6,903    5,012    6,903    CMD    <:%BD#> "
[2021-10-01T    14    0    44,910    6,91     0,007    6,91    RES    <0> "
[2021-10-01T    14    0    44,911    6,911    0,001    6,911    CMD    <:%BR#> "
[2021-10-01T    14    0    44,920    6,92     0,009    6,92    RES    <0> "
[2021-10-01T    14    0    44,921    6,921    0,001    6,921    CMD    <:GX90#> "
[2021-10-01T    14    0    49,933    11,933   5,012    11,933    Guid    e Rate: 1.000000 "
[2021-10-01T    14    0    49,934    11,934   0,001    11,934    CMD    <:GX95#> "
[2021-10-01T    14    0    49,940    11,94    0,006    11,94    RES    <0> "
[2021-10-01T    14    0    49,941    11,941   0,001    11,941    CMD    <:GX96#> "
[2021-10-01T    14    0    54,946    16,946   5,005    16,946    CMD    <:GXE9#> "
[2021-10-01T    14    0    54,953    16,953   0,007    16,953    RES    <60> "
[2021-10-01T    14    0    54,954    16,954   0,001    16,954    CMD    <:GXEA#> "
[2021-10-01T    14    0    54,962    16,962   0,008    16,962    RES    <60> "
[2021-10-01T    14    0    54,962    16,962   0,000    16,962    CMD    <:GX9A#> "

Last edit: 2 months 3 days ago by Alain Zwingelstein.
2 months 3 days ago #76204

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

  • Posts: 295
  • Thank you received: 24
OnStepX is still really far away from being usable. Last time I tried it (a few months ago), it did not even compile. Howard made changes and it did compile, but did not work at all. Motors did not move.

That is on the S6, which is not the platform that Howard is using for development.

But as long as things are in flux, I would not bother with it.

Join the onstep-dev sub group and report what you find there. It is where Howard responds for OnStepX stuff.
2 months 3 days ago #76221

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

  • Posts: 148
  • Thank you received: 35
I can reproduce that, on the own-goto branch. I also have a faster-timeout-fixed, that have both been merged into my master, including swapping the :GX90# over to the new lower timeout commands:

I'll make a pull request indi main either later today, or next week.

One nice thing is that with this, the startup time seems limited mainly by Kstars/Ekos. As checking most (3,4, X) of them when kstars is up it's 3-7 sec after hitting start in Ekos to everything being good. When it's the first startup that's more like 10-20.

I'm on a current pull as of just a bit ago (10.03k), I don't see the :%BD# causing an issue. What version of OnStepX are you on? (Mind you this is all testing with a Mega not hooked up atm.)
2 months 3 days ago #76223

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

  • Posts: 283
  • Thank you received: 32
@ Khalid and James,

I am just playing around to test some things. If it can help to discover here and there some parts not working well I guess it could help.

In my logs the 5 sec time is more related to Gm#, :GX90# and :GX96# but the issue is for sure (but I may be wrong) related to the driver itself not to OnStep.
I will try to investigate around that.

Now one thing is sure, OnStepX is far from "production" state but looks very promising.
I experienced also a lot of thing and reported to Howard and he fixed vert quickly.
But here it is really Indi Driver related I believe.

2 months 3 days ago #76227

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

  • Posts: 295
  • Thank you received: 24
Because INDI is very chatty, sending lots of commands every poll interval, it may uncover things that would not be uncovered using another OnStep client.

I have no intelligent comment to add other than there are significant differences between 4.x and X.

For GX90, OnStepX does the following:
sprintF(reply, "%0.2f", rateSelectToRate(settings.pulseRateSelect));

While 4.x does:

dtostrf(guideRates[currentPulseGuideRate]/15.0,2,2,reply); boolReply=false; break;// pulse-guide rate

For GX96, OnStepX does the following:

case '6': reply[0] = "EWB"[preferredPierSide - 10]; reply[1] = 0; break; // preferred pier side

While 4.x does:

if (preferredPierSide == EAST) strcpy(reply,"E"); else
if (preferredPierSide == WEST) strcpy(reply,"W"); else strcpy(reply,"B");
2 months 3 days ago #76228

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

  • Posts: 148
  • Thank you received: 35
Take a look at the code in the branch, I think I left the old call commented out. I added a few functions (which touch indi base) which is partly why I delayed until after 0.9.2, but reduce timeouts and build on those in OnStep. I think it's getCommandStringorSingleCharResponse (Which is similar to two others but a bit different)

With all of that, it reduces it from 5 sec to 0.2 sec. (Though I'm not sure where the 5 sec timeout is, as I recall before I started playing OnStep was 2 & lx200 was 3 sec?) So reduces the update rate with 50 (ms) polling (usually takes ~100ms + the polling rate) to about 2-3 a sec.

One of the VERY NICE things about OnStepX is with something like EpoxyDuino, it can actually be run as a process on a Pi. (Right now I don't have it working quite yet with INDI, (which was due to EpoxyDuino's serial handling) but the timing needed for OnStep is within the capabilities of a Pi or Hopefully a PiZero.) Right now it will compile with some modification of EpoxyDuino, but all I can get is some debug, I can't seem to communicate with it.
The following user(s) said Thank You: Alain Zwingelstein
2 months 3 days ago #76232

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

  • Posts: 283
  • Thank you received: 32
I found three issues:

:Gm# is not anymore implemented and replaced by :GX96#

:GX96# does not return a value since threr is may be a typo in OnStepX "Goto.command.cpp (Confirmed by Howard Dutton and corrected in OnStepX)
case '6': reply[0] = "EWB"[preferredPierSide - 1]; reply[1] = 0; break; // preferred pier side

:GX90# must effectively be called by
getCommandSingleCharResponse(PortFD, GuideValue, ":GX90#"); //old getCommandString

with these modifications it works fine , everything responds in "real time"

Just need to check if it doesn't broke OnStep 4.xx : Checked intensively Both OnStepX and OnStep 4.xx, both work fine
The following user(s) said Thank You: james_lan
Last edit: 1 month 4 weeks ago by Alain Zwingelstein. Reason: OnStepX modification agreed by H. Dutton and tests concluant
2 months 2 days ago #76262

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

  • Posts: 148
  • Thank you received: 35
Just a FYI with regards to :GX90#, getCommandSingleCharResponse will break that call since it returns a function call based on a double return, not an integer. It's a bug with the current. Tried to make a pull request for Howard, but messed up somehow with github's stuff so I just sent it to the list.

I've got it called with the (new) getCommandSingleCharErrorOrLongResponse which has a short timeout (200ms), and if for some reason it isn't working, I've got it falling back based on :GU# which may not be correct if a custom rate has been entered.

And FINALLY, I think I have everything where status gets set. I just had to override/replace/catch so many things, so I may have missed them. Last one I think was manually doing EQUATORIAL_EOD_COORD which was getting set to IPS_BUSY (aka goto) when called in (base) Telescope. Which I think finally kills the issue of KStars/Ekos detecting the end of a slew. (I hope anyway.) I added some things to kstars as debug/try to fix, so double checking with a clean copy that those aren't the only reason it works. (None of it was triggering those changes.)

I got so used to the Blur-Beep, with the default sounds (slew started/sync. That my mind is now expecting it while testing out the alignment. LOL, It happened right as I was considering if to post this, or wait, expecting things to go bad. Fortunately, The cause wasn't OnStep though, Ekos initiated a Meridian flip which caused the dreaded (by me at least) "Slew detected..." message.

I haven't tested all versions again, but so far it seems good, so I'm declaring victory for tonight.
1 month 4 weeks ago #76391

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

  • Posts: 148
  • Thank you received: 35
After checking with V3, V4, V5 & OnStepX (aka V10) everything seems to work well, and I've started a pull request for it to main.

(github's diffs seem broken so especially if looking at the TrackState & similar code, I'd highly suggest just looking at the file instead of diffs.)

The KStars/Ekos Align issue is solved and hopefully any others where a Slew is detected as ending immediately, as I finally found one place that EqNP was set that I missed somehow. (Shouldn't have, but finally.)

kstars/logs$ cat 2021-10-05/* | grep -c "Slew det"
kstars/logs$ cat 2021-10-06/* | grep -c "Slew det"

This is mostly the result of the align module (testing various versions, ~20 for each version tested), the two that happened today were both Meridian Flips triggered by Ekos. This is with 300+ Slews/Gotos in each day's tests. (Full is: "Slew detected, suspend solving...")

I'll let people know when it's accepted, then please try to break it before INDI 1.9.3.

Also OnStepX has the :GX90# fixed in git.
The following user(s) said Thank You: Alain Zwingelstein
1 month 4 weeks ago #76398

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

  • Posts: 148
  • Thank you received: 35
The pull request has been merged, and it looks like the PPA for nightly is updated. Please let me know if there are any issues! (I see one person with bluetooth issues in another thread, but I suspect that's unrelated (and the changes likely won't affect it.))
1 month 3 weeks ago #76462

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

  • Posts: 283
  • Thank you received: 32
Hi James,

I have a strange behavior with OnStep.
1) Site Management Tab
2) Set a Site name
3)When selecting another Site Onstep Crashes

I am trying to debug but found nothing so far
Any idea?

kstars 3.5.6 Beta
INDI Library: 1.9.3
Code v1.9.2-21-g2ea67102f. Protocol 1.7.
OnStep 4.24.k
Last edit: 1 month 2 weeks ago by Alain Zwingelstein.
1 month 2 weeks ago #76688

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

  • Posts: 148
  • Thank you received: 35
Sorry for not replying, this was getting annoying to track down. It's not directly an OnStep issue, but seems to be a more general LX200telescope one.

There are 2 ways to fix it.

First a description of the problem:
It's these two lines in lx200telescope.cpp @about 684:
IText *tp = IUFindText(&SiteNameTP, names[0]);
IUSaveText(tp, texts[0]); IDSetText(&SiteNameTP, "Site name updated");

It will then crash when these lines are called about 870, actually on the IDSetSwitch(&SiteNameTP, nullptr) when it tries to send it out, but the reason is:
if (isSimulation())
IUSaveText(&SiteNameTP.tp[0], "Sample Site");
else {
getSiteName(PortFD, SiteNameTP.tp[0].text, currentSiteNum);

Now, The reason it crashes is that IUSaveText will reallocate the string length to strlen()+1 (for null) It's originally allocated as (about 1225):
SiteNameT[0].text = new char[64];

IUSaveText does this (literally the only line function):
tp->text = strcpy(realloc(tp->text, strlen(newtext) + 1), newtext);

So as long as the getSiteName method of calling the pointer directly (SiteNameTP.tp[0].text) is used, and no IUSaveText is, it's good. When it's used as the getSiteName, (Changing sites) it has a shortened string, and dies when trying to send the XML out. Which is why it only dies only after a change of site, and fetches the changed to site's name.

First fix is to avoid reallocation in the set function :
IDSetText(&SiteNameTP, "Site name updated");

The Second is to modify the getSiteName to also use IUSaveText:
if (isSimulation())
IUSaveText(&SiteNameTP.tp[0], "Sample Site"); //Update this as well? Under sim, it doesn't seem to crash.
else {
//getSiteName(PortFD, SiteNameTP.tp[0].text, currentSiteNum); //Original Call
char temp_site_name[64] = {0};
getSiteName(PortFD, temp_site_name, currentSiteNum);
IText *tp = IUFindText(&SiteNameTP, "Name"); //Should change the line ( IUFillText(&SiteNameT[0], "Name", "", "");) so it's not just 'Name'?
IUSaveText(tp, temp_site_name);

@knro, Any preference on which way is more proper/better for INDI? It looks like lx200pulsar2.cpp uses the getSiteName method and if the 2nd solution is chosen it would need to be updated as well. I'm inclined to use the first solution, as it's simpler, and there seem to be a few
The following user(s) said Thank You: Alain Zwingelstein
Last edit: 1 month 1 week ago by james_lan. Reason: Stupid formatting!
1 month 1 week ago #76974

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

Time to create page: 1.096 seconds