×

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

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.

  • Posts: 322
  • Thank you received: 31

Agree. The other thing that is helpful if this gets implemented, is that alignment can be done on 20 stars or so, for more accuracy.

It would be very interesting to see whether OnStep and KStars come up with the same alignment results from the same data or not.


I have been using the Sync method of plate solving align for perhaps 8 months now.

When I started using it, it was from the Alignment module. Then I found that it is tedious (to find and select stars in a drop down list). Sometimes it got stuck on a star for some reason (in older releases of KStars).

So lately, I have been just clicking on the general area that I want to align in (even if KStars says empty sky), right click Slew, then Capture and Solve, then move to the next point. Much faster that way.


I also found that I never use the INDI user interface for alignment. I just start the align from the Android App, and also use it for PEC on/off, Tracking speed, ...etc. One reason is that if I try more than 6 stars, INDI messes up and acts weird re: total stars, current star, ...etc.

The Android App became much easier to use after Howard added the ability for OnStep to join your home WiFi network, and fall back to its own AP if it can't.
4 years 9 months ago #40625

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

  • Posts: 161
  • Thank you received: 39

Yeah, it would be cool, It's one of those, when I have time to look back at it. (Also, when I've forgotten enough about what I did to be able to look at it with fresh eyes, due to the issues I was having.)

Yeah, and the Ekos alignment should be able to do that, but sometimes it seems to misbehave on detecting when it's where it needs to be. (Goto/Slew/Tracking detection not being an issue) I tend to do similarly lately, because of just wanting to image things, and lack of clear nights that I'm able to do things.
Can you describe this a bit better, it should work the same*. Though it might be good to define which UI is being talked about. The INDI Control panel Align tab, the Ekos Align Module?

I have such an issue with the wireless, that I've given up on it multiple times. (I tend to use Serial as there's already the computer next to the telescope for camera control.) I tried it a few days ago, but still had an issue. I may try again at some point, but it's somewhat frustrating.



---
*Provided I don't make bugs, which is unfortunately common, as of late.

azwing has merged the last pull request, I introduced a bug (for which I just sent another pull request, as it introduced a bug) With the alignment marked as done before it was. (Functionality was all there, just the text changed.) Another major one was not updating RA and Dec unless the status updated. Ooops. (It's fixed in the current pull request.) Again, everything still worked.

Another thing the current pull request does is also use TELESCOPE_SLEW_RATE so that the buttons in for example Ekos' Control panel for rate will do something. It is labled, as 0.25, 0.5, 1 .... Half-Max, and Max so that people have an idea. It is essentially the same as the existing Max Rate, which was kept as it corresponds to OnStep's standard rates. It does not currently map back to it from the status updates but the two do map to each other. (Ie, using the Slew Rate or Max Rate assumes the commands work and updates both.)

Also, I added Guide rates GUIDE_RATE_NS & GUIDE_RATE_EW support to OnStep, which is currently read only, but it does flow through to PHD2. (In PHD2, It doesn't update on the fly, so you've got to close the window, like calibration for it to pick up changes.) Hopefully, that will be helpful to people.

I've seen you mention :MP, and I'll probably add that soon, but I wanted to verify the workflow:
Align as normal
Go to a bright star or other target
Issue :MP
Telescope should move off the target, so you can center it via manual adjustment.
Ideally, done

Non-ideally: Do another align which should have massively reduced or eliminated polar alignment error.

If so, would just having an :MP/Manually Clear Polar Align button available on the align tab be good, or would something else be needed? (Aside from taking pictures, and operating screws?)

----
Also Asking people to weigh in: I have thought about, but have mixed feelings about adding a manual command interface, and return value?

It's something that could work well, but could also mess it up unintentionally. The bugs above with alignment thought to be done already were due to a simple not checking if one command was done before another, so because it was still in the buffer, it was giving things like 1616 when the response should always have been 3 digits.
4 years 8 months ago #40713

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

  • Posts: 322
  • Thank you received: 31

There is a relatively new feature in OnStep, and it is undocumented. It allows you to change the number of maximum align stars. To do this, you need to add this in your config file:

#define MAX_NUM_ALIGN_STARS '9'

MaxPCB already supports 9, so this is mainly for my STM32 which by default has a maximum of 6 stars only.

When I add this, and then from INDI issue an align for more than 6 stars, you will see things go wrong, and the result of :A?# not being what you expect 919, but something else.

As I said, I just start the align from the Android App.

Open the web page, go to WiFi, enter your password (or see the Wiki on how to reset it from the IDE).
Then enter your WiFi network's SSID and password, and check Station Mode. Uncheck Access-Point mode.

Doing this makes OnStep connect to your home network if it finds it, but if it cannot connect, it will fallback automatically to the Acess Point mode (i.e. ONSTEP). Very convenient, and allows me to control the mount from inside using the phone.
4 years 8 months ago #40723

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

  • Posts: 322
  • Thank you received: 31
Thanks for all the fixes ...


The way I do it is:

1. Start an align 3 (or more) stars

2. For each star, right click and slew, then do a Capture and Solve with Sync as the action

3. Now OnStep calculates the offset in Azimuth and Altitude, and uses that for go tos

4. Slew to a star that is due north (or south in the southern hemisphere) and on the same side of the meridian. I used Kocab/Kochab which happens to be above Polaris these days, and not obstructed by the trees and houses. I did use Cassiopeia before.

5. Do a Capture and Solve on it, but with Slew to Target as the action

6. OnStep will try until the star is perfectly centered, with only 10 arc second error (in my case)

7. I then issue the :MP from a Python program over WiFi. OnStep then moves to where the star should be without the alt/az corrections

8. Using only the Alt and Az knobs, center the star the best you can

9. The program then does a Return Home

10. Another 3 or more star align is needed

So, it can be done in two ways:

a. A button that issues an :MP
b. A walk through that includes the manual steps and instructions into account.

My vote is on simple, so you can proceed with (a) above. On the page, there can be text describing the steps needed before (n-star align, then Slew to Target) and after (using only alt/az knobs center the star, then Return home and repeat the align), but nothing else from a programming point of view.

KISS: Keep it Simple ...




That would be handy and very dangerous too.

Here is another idea: can we connect to OnStep over WiFi? I know it can be done from my Python program, using the IP address and 9999 port. Can INDI do the same? If so, then it is one less cable (provided the WiFi is reliable).
4 years 8 months ago #40724

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

  • Posts: 161
  • Thank you received: 39
That's probably fixed by the other things I did. Alignment either :A+# or :Ax# returns a code which wasn't being checked, then #A?# was being called right after which is good for producing the 0616 returns or similar. So probably can mark that as ALREADY_FIXED. (I hope!)

Yeah, I've done that with the wifi, but no luck it always goes back to acting as an AP. I seem to have annoying luck with esp8266s. (And esp32s work just fine, so maybe it's the router or something.)
4 years 8 months ago #40725

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

Time to create page: 1.325 seconds