james_lan replied to the topic 'Driver OnStep (LX200 like) for INDI' in the forum. 1 week ago

You worry about being 'slow' when everything I see has been within a day or two. :lol:

Seriously, thanks for dealing with that, and especially pushing it up to master, because git is both wonderful, and evil. (I hope you aren't thinking that my comment about pushed to you is any implication of anything other than an explanation, or intended as any sort of complaint what so ever. It's not.) I really hope your internet gets fixed soon, because that is really annoying.

As another thing that I'm just pushing up: Adding Sync error messages. Hopefully this will help ID the problem that shows up on the OnStep Mailing list. Vs the silent fails currently.

If you want, I can see about a pull request for merging OnStep to libindi/master as I see there seems to have been some confusion with the other pull request, if that would be helpful.

Read More...

james_lan replied to the topic 'Driver OnStep (LX200 like) for INDI' in the forum. 1 week ago

Pushed to Azwing: Extended goto error codes.

Given that there were issues with sync and movement, I was having issues that showed as under horizon limit, while at zenith. I finally spent the time to check over everything like timezones and such, and finally realized the :MS# command wasn't returning 3 so I modified what was needed for it to show. (Which touched the other lx200telescope and lx200driver, but after looking all of them over, they will just show what they did before if anything is out of the 0,1,2 range as before.)

So for example, before tracking was enabled, I'd get a return of 3 (Controller in standby), which got squashed in the Slew function, and read back as Object below Horizon. Anything you get back will be tagged with OnStep slewError: _____ and should be correct. (Can't believe it took me that long to figure out! I implemented the slewError function, and it took that giving me the same error to figure out it was squashing it since it would print RES <3> right before it. Argh. Any time you are feeling smart, try programming and debugging. ;) )

Hopefully, that will help anyone having any goto errors to report it better, once it's merged upstream.

Read More...

james_lan replied to the topic 'Driver OnStep (LX200 like) for INDI' in the forum. 2 weeks ago

Yeah it's kind of a quick hack, one of the problems is the limited space, and to be honest, the existing Align items are kind of a hack that I'm not super happy with. Unfortunately, there's not anything like a multi-line text display except that sort of multi-line hack used for Align. (Or at least I'm not aware of it, and I just went through and double checked there weren't parameters in the Text parameter. :( )

I'd love comments on how people would suggest it be useful:

Option 1:
As is for MP, in the info box. Advantage, aside from changing text, it's done!
Option 2:
Repurpose the same sort that's already with the Align module, name it explicitly instructions, and add a button to switch instructions. (Manual Align, Sync Align or MP)
Disadvantage instructions may be out of order.
Advantage: Anyone not looking at the info box can see instructions.
Option 3:
Use info for a more complete instructions and do a basic instruction. (Kinda like step 2)
Advantage, we can be more verbose in INFO, but still have basic info available for everyone.
Option 4:
(Possible with Option 1): Just link a page with instructions.
Advantage: Easy to update
Disadvantage: Offline or constrained data usage.

Other thoughts, suggestions of options?

Read More...

james_lan replied to the topic 'Driver OnStep (LX200 like) for INDI' in the forum. 2 weeks ago

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.

Button two issues the :MP# command.

Any suggested wording changes?

Fun thing printing right now is a end of counterweight vixen holder based on seeing a picture and going... that looks like something fun: www.hbastro.com/Telescopes/DualAstroGraphProject.html ;)

Read More...

james_lan replied to the topic 'Driver OnStep (LX200 like) for INDI' in the forum. 2 weeks ago

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.)

Read More...

james_lan replied to the topic 'Driver OnStep (LX200 like) for INDI' in the forum. 2 weeks ago

kbahey wrote:
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.


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.)

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 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.


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.

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.)


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.

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?

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.


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.

Read More...

james_lan replied to the topic 'Driver OnStep (LX200 like) for INDI' in the forum. 3 weeks ago

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.)

Read More...

james_lan replied to the topic 'Driver OnStep (LX200 like) for INDI' in the forum. 3 weeks ago

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.

Read More...

james_lan replied to the topic 'Driver OnStep (LX200 like) for INDI' in the forum. 3 weeks ago

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. )

Read More...

james_lan replied to the topic 'Driver OnStep (LX200 like) for INDI' in the forum. 2 months ago

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.)

Read More...

james_lan replied to the topic 'Driver OnStep (LX200 like) for INDI' in the forum. 2 months ago

Unfortunately, there's not really a good way to have that done, the best way is the automatic one, where Ekos will issue a goto while imaging. (There's no request meridian flip function, it's literally a goto)

Set it to autoflip, no stop at home. Set the preferred side to east.

I can see about adding in a manual :MN# (Which does not guarantee a flip, you also have to set the limits right.) (Literally in OnStep's code, (unless changed) all it does is assume preferred east and issue a goto)

Read More...