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. )
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:
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.
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.
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.)
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.
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
Telescope should move off the target, so you can center it via manual adjustment.
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.
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.
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).
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.)
Alright, right as I was trying to name it, Howard did.
I have added it to the align tab, with a pull request to azwing to push upstream. (Sorry about all of them.) Who merged it.
Interface is two buttons, button 1 prints this to INFO.
2019-07-04T05:19:20: [INFO] Optional: Start a new alignment.
2019-07-04T05:19:20: [INFO] Step 4: Using the mount's Alt and Az screws manually recenter the star. (Video mode if your camera supports it will be helpful.)
2019-07-04T05:19:20: [INFO] Step 3: Press Refine Polar Alignment.
2019-07-04T05:19:20: [INFO] Step 2: Make sure it is centered.
2019-07-04T05:19:20: [INFO] Step 1: Goto a bright star between 50 and 80 degrees N/S from the pole. Preferably on the Meridian.
The steps are displayed in reverse order. That confused me for a few minutes.
As for wording, the Android app is constrained in screen space, but we can expand the text a bit:
Step 5: Optional: Repeat the alignment.
Step 4: Using the mount's Alt and Az screws, manually recenter the star. Use the camera's LCD and grid, if available.
Step 4: Press the Refine Polar Alignment button.
Step 3: Center the star perfectly. You can use Plate Solving and Slew To Target for this.
Step 2: Goto a bright star due north, or due south, but having a Declination of more than 50 and less than 80 degrees. Preferably near the Meridian.
Step 1: Start and alignment on 3 or more stars.
If we are using the info area, then for the rest of the alignment, we should use that too. Or, change the new Refine PA to use the scheme that is already in use on the Align tab (all text shown). Point is: consistency of the UI. I don't have a specific preference, but the info area tends to scroll and only 3 lines show up at most on my older astro laptop.