×

INDI Library v1.9.2 Released (14 Sep 2021)

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

Driver OnStep (LX200 like) for INDI

  • Posts: 136
  • Thank you received: 20
I upgraded driver from the stable builds and it crashes as soon as client connects with this error:
Driver indi_lx200_OnStep: *** stack smashing detected ***: terminated
Has anyone seen this?
Last edit: 1 month 2 weeks ago by Alex Varakin.
1 month 2 weeks ago #75179

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

  • Posts: 38
  • Thank you received: 0
How do i roll back to a stable driver?  My current install on my rasberry pi indi server is not usable. Ekos does not stay connected.

I dont want to waste any clear skies if i can avoid it.

Some logs if that helps
[2021-09-07T21:50:04.180 Eastern Daylight Time DEBG ][           org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] RES <911> "
[2021-09-07T21:50:04.237 Eastern Daylight Time DEBG ][           org.kde.kstars.indi] - LX200 OnStep : "[DEBUG] Align: max_stars: 9 current star: 1, align_stars 1 "
[2021-09-07T21:50:04.248 Eastern Daylight Time DEBG ][           org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] CMD <:GX02#> "
[2021-09-07T21:50:04.285 Eastern Daylight Time DEBG ][           org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] RES <0> "
[2021-09-07T21:50:04.285 Eastern Daylight Time DEBG ][           org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] CMD <:GX03#> "
[2021-09-07T21:50:04.332 Eastern Daylight Time DEBG ][           org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] RES <0> "
[2021-09-07T21:50:04.348 Eastern Daylight Time DEBG ][           org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] CMD <:FG#> "
[2021-09-07T21:50:04.566 Eastern Daylight Time DEBG ][           org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] RES <50145> "
[2021-09-07T21:50:04.613 Eastern Daylight Time INFO ][     org.kde.kstars.ekos.focus] - "Focuser error, check INDI panel."
[2021-09-07T21:50:04.629 Eastern Daylight Time DEBG ][           org.kde.kstars.indi] - LX200 OnStep : "[DEBUG] Current focuser: 50145, 50145.000000 "
[2021-09-07T21:50:04.629 Eastern Daylight Time DEBG ][           org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] CMD <:FT#> "
[2021-09-07T21:50:04.707 Eastern Daylight Time DEBG ][           org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] RES <S> "
[2021-09-07T21:50:04.754 Eastern Daylight Time DEBG ][           org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] CMD <:FM#> "
[2021-09-07T21:50:04.769 Eastern Daylight Time DEBG ][           org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] RES <100000> "
[2021-09-07T21:50:04.785 Eastern Daylight Time DEBG ][           org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] CMD <:FI#> "
[2021-09-07T21:50:04.854 Eastern Daylight Time DEBG ][           org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] RES <0> "
[2021-09-07T21:50:04.854 Eastern Daylight Time DEBG ][           org.kde.kstars.indi] - LX200 OnStep : "[DEBUG] After update properties: FocusAbsPosN min: 0.000000 max: 100000.000000 "
[2021-09-07T21:50:05.857 Eastern Daylight Time DEBG ][           org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] CMD <:GR#> "
[2021-09-07T21:50:10.862 Eastern Daylight Time DEBG ][           org.kde.kstars.indi] - LX200 OnStep : "Error reading RA/DEC. "
[2021-09-07T21:50:11.160 Eastern Daylight Time DEBG ][     org.kde.kstars.ekos.mount] - Mount status changed from  "Tracking"  to  "Error"
[2021-09-07T21:50:11.864 Eastern Daylight Time DEBG ][           org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] CMD <:GR#> "
[2021-09-07T21:50:16.867 Eastern Daylight Time DEBG ][           org.kde.kstars.indi] - LX200 OnStep : "Error reading RA/DEC. "
[2021-09-07T21:50:17.862 Eastern Daylight Time DEBG ][           org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] CMD <:GR#> "
[2021-09-07T21:50:22.181 Eastern Daylight Time DEBG ][           org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] RES <00:43:57> "
[2021-09-07T21:50:22.228 Eastern Daylight Time DEBG ][           org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] VAL [0.7325] "
[2021-09-07T21:50:22.243 Eastern Daylight Time DEBG ][           org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] CMD <:GD#> "
[2021-09-07T21:50:27.179 Eastern Daylight Time DEBG ][           org.kde.kstars.indi] - LX200 OnStep : "Error reading RA/DEC. "
[2021-09-07T21:50:28.179 Eastern Daylight Time DEBG ][           org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] CMD <:GR#> "
[2021-09-07T21:50:33.181 Eastern Daylight Time DEBG ][           org.kde.kstars.indi] - LX200 OnStep : "Error reading RA/DEC. "
[2021-09-07T21:50:34.190 Eastern Daylight Time DEBG ][           org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] CMD <:GR#> "
[2021-09-07T21:50:39.195 Eastern Daylight Time DEBG ][           org.kde.kstars.indi] - LX200 OnStep : "Error reading RA/DEC. "
[2021-09-07T21:50:40.196 Eastern Daylight Time DEBG ][           org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] CMD <:GR#> "
[2021-09-07T21:50:45.014 Eastern Daylight Time DEBG ][           org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] RES <00:43:57> "

 
1 month 1 week ago #75267

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

  • Posts: 55
  • Thank you received: 1
I also had a lot of problems with the version that came with Indi 1.9.1.
I compiled the version of Azwing (github.com/azwing/indi), then just replaced indi_lx200generic in my existing installation (in /usr/bin/).
That works well.
I think it must be possible to also recompile version 1.9.0 and replace indi_lx200generic
1 month 1 week ago #75438

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

  • Posts: 38
  • Thank you received: 0
I gave this a shot and the driver does appear to be more stable. It recognizes if i have a focuser or not on my OnStep controller. That is new. The older drivers just loaded all parts and did not check the OnStep controller if they existed.

I still do not have good communication with the OnStep controller. My first problem i encounter is it says it cannot get site info and it cannot write UTC offset.2021-09-12T13:08:17: [ERROR] Error setting site longitude coordinates
2021-09-12T13:08:17: [ERROR] Error setting UTC Offset.

If i request a 3star align it says error.
2021-09-12T13:19:14: [INFO] Align Status response Error, response = >
2021-09-12T13:19:14: [INFO] Getting Max Star: response Error, response = >
2021-09-12T13:19:14: [INFO] Sending Command to Start Alignment
I am connecting to the web manager of OnStep and that website is running correctly.  It is only my local wifi network.

I also see that the driver has a blank page on OnStep status.
 
1 month 1 week ago #75459
Attachments:

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

  • Posts: 38
  • Thank you received: 0
My issue was i had port 9999 entered. This gave me a partial working interface.

The port really needs to be 9998. Can some text be placed on the driver page were people type this in to remind them that the default port is 9998.

Thanks!
1 month 1 week ago #75483

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

  • Posts: 235
  • Thank you received: 29
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 weeks 6 days ago by Alain Zwingelstein.
2 weeks 6 days ago #76204

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

  • Posts: 249
  • Thank you received: 22
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 weeks 6 days ago #76221

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

  • Posts: 127
  • Thank you received: 31
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:
github.com/james-lan/indi

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 weeks 6 days ago #76223

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

  • Posts: 235
  • Thank you received: 29
@ 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 weeks 6 days ago #76227

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

  • Posts: 249
  • Thank you received: 22
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 weeks 6 days ago #76228

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

  • Posts: 127
  • Thank you received: 31
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 weeks 6 days ago #76232

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

  • Posts: 235
  • Thank you received: 29
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: 2 weeks 2 days ago by Alain Zwingelstein. Reason: OnStepX modification agreed by H. Dutton and tests concluant
2 weeks 5 days ago #76262

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

Time to create page: 1.073 seconds