james_lan replied to the topic 'setting the backlash (HEQ5 pro)' in the forum. 3 days ago

Backlash correction is very useful. I have one mount (not on Eqmod, but OnStep (which uses different units)) where I made the DEC worm wheel, and unfortunately, due to how I mounted it (great learning experience, btw) it's got severe backlash that PHD2 doesn't handle. If I set the similar OnStep setting (and turn off ignore backlash while guiding) then the mount can guide pretty well. Otherwise PHD2 refuses to calibrate. (That's an extreme example) On other mounts (again, OnStep) it is useful to deal with most of it, and to have gotos be very accurate.

It's one of the things that Meade ETXes like to do. (Though I don't use them with a computer.) When you slew it one way or the other, it's calculating and storing the backlash.

Quite possibly, a useful feature to add to standard properties/capabilities is a backlash setup, possibly with something to train it. I actually have something similar with my (DIY) focuser, where it takes about 72 (micro) steps to get moving. I would assume that other interfaces can expose it.

Hope that helps you or anyone else coming across the topic, good luck!

Read More...

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

kbahey wrote: Thanks for the clarification. These are all great changes.

james_lan wrote: Now if I can just find what the hell is with that bug in the alignment routine. (I've somewhat narrowed it down bringing out things like wireshark, but whatever the issue is, it seems to defy my finding it. Though I've narrowed it down some as to what gets called, but that shouldn't as far as I can tell. Somehow kstars thinks that the EqNP.s is busy when as per wireshark it's not, so it goes into the case of IPS_BUSY (== Slewing) when it's actually another status, but I don't see HOW. At least I know it's not the OnStep INDI driver side (or the INDI side, or the OnStep side... I think anyway :dry: ). )


This bug is merely an annoyance.
I found it easier to just point and slew to each star, and repeat 6 times.

The reason is that populating the Mount Model tool takes a lot of time, so in the end, both methods work out to the same time.


For me, any of the automated methods work in a very short amount of time. (When playing with it, I've tried to find an option that would take a while, but everything from grid to named stars seems to populate pretty much instantly for me. The only thing I have to sometimes check for is where I have trees. In which case, I can just generate say 8 when I want 6, and kill those too far NW, or use a higher altitude.

In any case, I did some local testing and 17/25 hit it. However, I did test a timer, and that worked great to mask whatever is causing the issue, and while reporting that, had an idea which should mask it fairly easily. (Provided Settle Time > polling time) Still haven't found the cause, but maybe a bandage will get to kstars relatively soon?

Also: If anything breaks that was working before, PLEASE LET ME KNOW.


I will. Although I will not get the changes until they make it all the way to Jasem's PPA, then him building packages. So it will be a while.

I believe since it's in INDI master, it should be in Jasem's PPA.

There were a bunch of stupid spacing things that git decided a whole function constituted a change, some of which had actual changes in them, and I think I decoupled the spacing changes from actual changes, but... I'm only human, and a little bit more persistent than git. ;)


Maybe it is something more mundane? Such as tabs vs spaces?


Yep. I added a .katesettings (I think that's the name) with the tab settings. Actually that might be worth pushing up to INDI master. (Doesn't solve it for all editors, but... (Hrm, a standard for that that all editors look at would be great.))

Read More...

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

kbahey wrote:

- Changed align so the last step isn't the (Optional) Write to EEPROM


Do you mean the text of the instructions change, or there is a functionality change somewhere? If the latter, please elaborate more.


Yes, text changed.


Write align got set to Write Align to NVRAM/Flash (Actually should be EEPROM/Flash, but whatever, storage that doesn't go away with power!)

- Added support for polar adjustments, without having to redo the entire model. (:MP# command)


If you have a polar alignment that has significant errors (say > 3'), and you do the RefinePA (:MP), then you are better off re-doing the polar alignment since your gotos will off if you don't.

- Support for Full Compensation/Refraction only, and 1/2 Axis tracking

So now we have a Single and Dual button next to each of Full and Refr?

No, I did it a little differently, along with status, which shows Single Axis, 2-axis or N/A (If off)



One more thing: the units for the polar error in the Align tab are wrong. They are ' but should be ". I am sure I reported this to Alain way back when, and it was fixed. Perhaps overwritten by some other change.

See probably the first screenshot, Alain corrected this a while back. I don't think it got pushed up to the main one though. It's there now.

Thanks for your continued work on this ...

No problem, Open source is awesome.

Now if I can just find what the hell is with that bug in the alignment routine. (I've somewhat narrowed it down bringing out things like wireshark, but whatever the issue is, it seems to defy my finding it. Though I've narrowed it down some as to what gets called, but that shouldn't as far as I can tell. Somehow kstars thinks that the EqNP.s is busy when as per wireshark it's not, so it goes into the case of IPS_BUSY (== Slewing) when it's actually another status, but I don't see HOW. At least I know it's not the OnStep INDI driver side (or the INDI side, or the OnStep side... I think anyway :dry: ). )




Also: If anything breaks that was working before, PLEASE LET ME KNOW. There were a bunch of stupid spacing things that git decided a whole function constituted a change, some of which had actual changes in them, and I think I decoupled the spacing changes from actual changes, but... I'm only human, and a little bit more persistent than git. ;)

Read More...

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

I added a Qtimer for 5 seconds (likely should be adjustable) to my own local copy to test if that fixes it. If so I'll send it on up to kstars. (It's supposed to be clear tonight! HUZZAH!)

Read More...

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

It broke, but mostly because I'd been messing with enough stuff that wasn't in master. Then the stupid spaces/tabs thing. (Which is now all spaces, but Gah that was annoying!)

As azwing is having fun with his internet (/s) I just bumped the OnStep version and submitted version 1.7, with the following changes, but likely some I may have forgotten, or missed going through commits.
Version 1.7:
- Added support for Reporting Guide rate (to PHD2 among others)
- Updated Error codes to match up with Android/SHC (Unknown reserved for unknown, so Unspecified = Unknown on other platforms)
- Added descriptions to SlewRate to match, slider kept which matches OnStep values
- Support for up to 9 stars for alignment
- Changed align so the last step isn't the (Optional) Write to EEPROM
- Added support for polar adjustments, without having to redo the entire model. (:MP# command)
- Support for Full Compensation/Refraction only, and 1/2 Axis tracking
- Cleanups


I don't have the :Gu# settings done yet, or a few other things in progress, but I figured the above would be welcome by people. And gaffes about merging an old variable name aside, I think things have been fairly well tested.

Read More...

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

Do note, it unfortunately isn't fixed, yet. I thought it was, but just had it happen again. >_<

Read More...

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

There is one bug, but it's an Ekos one from what I can tell related to the mount model alignment tool, which is if there's a delay changing to slew, and it gets checked too quickly then Ekos/Kstars assumes it's done with a slew before the command even gets sent.

I've filed a bug for kstars. bugs.kde.org/show_bug.cgi?id=410094 as I believe that's where the issue lies.

And since I left this post up overnight, before hitting submit, it's already fixed (or at least looks like it) in kstars git, and if I do observing tonight, I'll see if I have any issues. Thanks Jasem!



One thing that should be good shortly, once I'm finished is the :Gu support, is that it should be a bit less talky over serial, which hopefully will reduce the time and maybe? the load on the microcontroller it takes for updates. (I've noticed sometimes that megas have a bit of a delay some times, which I presume is due to load on the microcontroller, it seems less of an issue on STM32)

Planned to be replaced by :Gu#:
:Gm# (Pier Side)
:GX90# (Pulse Guide rate, still would need to be called for any custom/non-standard rates (aka not 0.25/0.5/1x sidereal) which I'd have to play with)
:GX95# (AutoFlip)
:GX96# (Preferred Pier Side)
:$QZ?# (PEC Status)

Not Replaced (and currently called)
:%BD and :%BR (backlash, can probably be read only occasionally)
:GXE9 :GXEA (minutes past meridian)
:A? (Align Status)
:GX02 :GX03 (Can probably be reduced and only dealt with in certain situations)
:GR :GD (Not changing, Dec and RA coordinates, need to be called!)

Though I do plan on still calling :GU# for now, because it's a LOT easier to read in either the status tab or logs, even though there's everything in :GU should be in :Gu (Along with more)

One other thing is possibly to allow for higher bitrates, which may (or may not) help or hurt. Unfortunately, most all of that is in the serial connection, which gets pulled in via telescope, and as far as I can tell, doesn't allow for on-the fly, so it'd have to send the command to change :SBx# then disconnect and reconnect. (Most all LX200 derived mounts should have the ability to do that, as Meade has had it in the lx200 protocol from close to the beginning of the protocol (Or at least there's no notation of anything not supporting it, as there is with almost everything added later))

I'm still working on the multipoint thing, but that's still proving a bit annoying. (I've got a bug, or a misunderstanding of what's being done, as it's coming out fairly off compared to the mount calculations.)

Read More...

james_lan replied to the topic 'DMK41 AU02.AS : How to configure it with INDI ?' in the forum. 1 month ago

Yes. Differently packaged, but the same. For the NI5, it's the dfk72uc02. Here's my NI5 specific stuff, with links (to github instead of google code) that work.

www.indilib.org/forum/ccds-dslrs/3320-ex...eximage-cameras.html

It works pretty well.

Though since I'm thinking about it: Sometimes it shifts for a frame or two from where it should be, which I'm not sure if it's a v4l2 (I haven't observed it do it wit guvcview), long exposures, an INDI problem, a PHD2 problem (I don't think I've seen it using Kstars/Ekos), or a Mini-PC problem (I don't think I've seen it on my laptop, but I'm not certain of that). Like somewhere between 1/4 and 3/4 of the frame is off/wrapped around (and mostly out of guide star detection range, so the next frame or two it picks it up). Has anyone else seen that sort of issue with other tis cameras, or neximage cameras?

Read More...

james_lan replied to the topic 'Driver OnStep (LX200 like) for INDI' in the forum. 2 months 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. 2 months 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 months 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 months 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...