×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

Driver OnStep (LX200 like) for INDI

  • Posts: 19
  • Thank you received: 1

Hi!
Thanks for the information!
Would you be able to share your configuration (Onstep limits and Ekos settings for "flip after..." so I can test it on my own setup before bringing it out under the stars? I'd like to get a feel for how it works.
4 years 10 months ago #39337

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

  • Posts: 257
  • Thank you received: 22
Thought I'd mention this just because I thought it was neat when someone shared the tip with me... When I'm imaging across the meridian, pretty much always due to trees, I turn off all the auto flips and set the mount to east facing west, then "back" it over to east to pick up the high target, watching for mount clearance. That way I can track all night and don't have to reset everything when it flips.
4 years 10 months ago #39340

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

  • Posts: 19
  • Thank you received: 1

I got this working, thanks!
My settings for testing:

Onstep preferred pier side: East, Autoflips ON, no pause at Home
Onstep meridian limits : 12 minutes (I suspect, as long as this value is more than that in Ekos, it should be fine. Just make sure Onstep doesn't flip before Ekos does)
Ekos "Flip if HA >" : 0.1h (6 minutes. May be more in practice)

The mount flips as desired when the countdown timer in Ekos reaches 0 :)
The following user(s) said Thank You: Alfred
Last edit: 4 years 10 months ago by Wong Sy Ming.
4 years 10 months ago #39353

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

  • Posts: 322
  • Thank you received: 31

So, all that is needed is to have the Ekos setting less than OnStep's setting?
4 years 10 months ago #39356

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

  • Posts: 161
  • Thank you received: 39
Pretty much as well as pier side to east or preferred (not west)

OnStep has as I recall 3 settings that are important:
Minutes? past meridian East = how far east to move to east if a goto is done (= Greater than Ekos setting)
Same West, either autoflip or stop tracking (=Whatever, this should Not be the trigger)
Autoflip (=on)
Preferred meridian side (=e)
stop at polar home (=off)

Ok, 5
We want to be in the range of E > ekos > W limit
As long as ekos' goto triggers the flip, we are good. (I think it has been corrected, but a while back it wouldn't wait for the flip to be done.)
4 years 10 months ago #39358

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

  • Posts: 19
  • Thank you received: 1

Yes, as well as "Preferred Side of Pier" being "East" instead of "Best (default)". I think this is the important step, because Ekos will simply send a Goto to the same coordinates, which, since Onstep is on the West side of the pier (ie not preferred) it will then set itself on the "preferred" side (at least that is my understanding). If left at "Best", it may not do anything if it determines that the current side of the pier is "reachable".
4 years 10 months ago #39364

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

  • Posts: 19
  • Thank you received: 1

Ekos shows "Waiting for meridian flip" in the Mount tab while the mount is slewing, so I take it that it works now..
4 years 10 months ago #39365

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

  • Posts: 19
  • Thank you received: 1
I note that the Onstep driver sets the mount to guide at 1X sidereal, is there any way to change this behaviour? E.g. setting it to 0.5X?
4 years 10 months ago #39433

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

  • Posts: 161
  • Thank you received: 39
So, after looking through the OnStep code again, here's how it does it with slight differences if pulse guide is on, due to this I can't easily see a method of separating it (actually scratch that, but don't expect it today, as I'm working on a few things with regards a cool feature, along with updated error codes and some other things) Also there's a bug I found which disallows the 0.25x rate, but that'll be in a fairly decent sized batch of changes, and I don't want to try to submit just that.

Onstep gets :Rg! (0 <= g <= 9) (There are some alphabetic values, but they all map to a number.) This in INDI is the Max Slew Rate slider. Since Guides and manual slews are treated the same in OnStep, You can use Slew/Guide interchangably, but PulseGuide may be a separate thing. (Set in the configuration file, unless enabled there, it can't be set at runtime.) Goto Slews are treated a bit differently in how they are reported and such.

There's custom support for timers in :RA and :RE (useful for things like Satellite tracking) which ignore/override that Max Slew Rate. Otherwise: 0=.25X 1=.5x 2=1x 3=2x 4=4x 5=8x 6=24x 7=48x 8=half-MaxRate 9=MaxRate

So when it gets the value, it calls setGuideRate, which will set the Slew/Guide rate, and if there are certain conditions, set the PulseGuide rate to g. The conditions on pulse guide are ((g<=GuideRate1x) && (currentPulseGuideRate!=g))

So what that says is that the PulseGuideRate will always be at or under 1x, and it is set via the Guide/Slew speed.

So to set it at 0.5x:
To confirm this, if you go to the status, you'll see something like: nNpHz/Eo250 (3rd number from the right is the PulseGuide)
Under the motion tab, change it to 0, 1, 2 (Yes, it should allow 0, it doesn't) which are 0.25, 0.5 and 1x
Go back to the status: nNpHz/Eo110
Change the MaxSlew
And Status changes to: nNpHz/Eo160 (PulseGuide=1=0.5x and MaxSlew is 6=24x)

Note that the PulseGuide is saved to NVRAM so the above needs to only be done once, and as long as you don't go below 3, you shouldn't have to set it again.

(MaxRate should probably be updated from :GU# as well, but isn't currently. )
4 years 9 months ago #40596

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

  • Posts: 161
  • Thank you received: 39
Ok, I got git cooperating (for now) I just pushed some minor changes to azwing (Always good to have some review, as when messing with git, I did them in the wrong branches, made a mistake on a copy/paste and I think I've got the fixes up)

Error codes updated, and moved to case statement allowing unknown errors
MaxSlewRate goes to 0 (0.25x) as prior post
TrackingCompensation button added for single/multi-axis (Which relies upon the Compensation Tracking Not being OFF)
Status is displayed as Single,2-Axis,N/A
Write Alignment to EEPROM moved to different line. Text updated.


Did not implement setting MaxSlewRate from status just yet. (:gu# will be better)

Major things I'm working on include the checksum and alignment issues, but I'm not done with them (for the checksum, that's going to be pulling in a lot of code (at every level there's a write function, as well as stuff writing directly to the device, so no function to override there), and I think I've identified most of it.)

As far as the alignment, I'm going to use the INDI alignment system ( www.indilib.org/api/md_libs_indibase_ali...ent_white_paper.html ) and a math module hopefully able to match and download coordinates to OnStep. So far that's been somewhat frustrating, as in some code I've got a wrongness with my test vs what OnStep does. Even if it doesn't, the existing math model would give us some better goto abilities, but wouldn't do the really awesome things that OnStep does with some of the compensation.

One thing I do have is a python script to upload a set of coordinates and solved values to OnStep and let it chew on them. (Idea for the math model is to match that.)

Just to give an idea of how much difference there is in processors math capabilities for alignment, using the same data, and removing restrictions on things like the Mega, with the same coordinates (might have increased the solution resolution, I can't recall, but the test was for the same resolution for all) with a 9-star align:
Mega: 6:46.317029
STM32 2:13.729435
Esp32: 0:27.962810

Note that the Mega also differed, but only very minorly (I think one value was 3 vs 4, another was 68 vs 69, I'm assuming because of precision with the Mega.) Unfortunately, I don't have a teensy to test vs that. That's given me an interesting idea to see about doing that calculation on a SHC (w/esp32 or teensy) Though that would require a fair bit of work. So if hooked up to something like RAMPS, it could do more than the 3 (older + beta) or 6 point (current Alpha) align. Just a thought for the future.

On the errors, it will display the same as the webpage on ESP, except for any like ERR_GOTO_ERR_UNSPECIFIED Mine: "Goto Unspecified Error" Web: "Goto Unknown Error" While if there's an unknown error it will show: "Unknown Error" as I wanted a difference between error 11, ERR_UNSPECIFIED and something we don't recognized thus 'Unknown' vs 'Unspecified', and continued it with the above. I don't use the web page much. So YMMV.

Anyway, I'm probably done for the day, azwing can merge/comment and then push it to main. If someone can check that nothing broke, who isn't on Alpha, that would probably also be good.
4 years 9 months ago #40600

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

  • Posts: 322
  • Thank you received: 31

I have a similar script, and tested it with 9 points on the STM32. Results were inconclusive whether this is beneficial or not.

Are you saying that you want to do the alignment (plate solved vs. OnStep), and do the calculations in KStars (fast CPU), so you can upload to OnStep the Alt and Az corrections?

If so, that would be great, since it will allow more than 9 points, which is the limit of doing it within OnStep.

You can also look into reusing <a href="github.com/RTS2/rts2/blob/master/man/gpoint.txt">gpoint, which already does the calculations needed in Python. Code github.com/RTS2/rts2/blob/master/scripts/gpoint">here and github.com/RTS2/rts2/blob/master/python/rts2/gpoint.py">here.

On the other hand, if you just want to use the existing Alignment module, then OnStep already has support for that: when an :An# command is sent, but the number of stars are not reached, then a Sync will add the alignment point in OnStep and advance to the next star. When the number desired stars is reached, the alignment is calculated. So no need to add anything, if that is all you want to do.

Thanks for all the work, past, present and future.
4 years 9 months ago #40602

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

  • Posts: 161
  • Thank you received: 39
Pretty much that's my idea, if you read the indi driver, I'm going to try to implement something compatible.

One thing that has kinda been a little interesting and also annoying is that OnStep uses it's own system. Most are similar to each other, but use different names. I think I've looked at that python code before.

As far as the :An# that mostly works, unless you have a belt break, but not look like it broke, and is just loose.

I did make some changes to that, but messed up on a check (no functionality issues, just instructions saying done before it's actually done.) Mainly adding 7/8 star support, probably never used, but it did simplify that a bit. (Which I thought I'd done before.)
4 years 9 months ago #40619

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

Time to create page: 1.341 seconds