×

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: 48
  • Thank you received: 6
James,

Thank you for your work on this.

I'm sure I have made a mistake somewhere in my testing but I don't understand your comment about not using park.
When one powers off OnStep whether it has been sent to a park position or not doesn't it come up in a Park state?
Then you would have to unpark it in Ekos before you would be able to slew. That is all I was trying to do in the
last log I sent you.

Anyway, I like azwing think that with the added complexity of the future OnStepX leaving the older driver as is -- call
it OnStep_Classic (old soft drink reference, sorry), and forking to a more complex OnStepX driver would be a good idea.

For those clamoring for the driver to handle both focusers I'm thinking they can use the Android app. Usually (I think) only one
focuser is used frequently during an imaging session - that's how I use it anyway, everybody is different I guess.

Thanks again,
Jack
2 years 9 months ago #71788

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

  • Posts: 452
  • Thank you received: 71
@Jack

Parking is a feature where one can choose a convenient (arbitrary) position to move the telescope (or observatory) when session is finished.
When parking occurs telescope moves to this predefined position and everything is at rest (motors not powered ....).
When in this position before any movement / action can be taken a "unpark" command must be issued, which just put the telescope in ready to operate state (tracking is started).
2 years 9 months ago #71796

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

  • Posts: 48
  • Thank you received: 6
Thanks Alain,

That is my understanding of Park as well.

Jack
2 years 9 months ago #71804

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

  • Posts: 257
  • Thank you received: 22
So would you say the focuser is a bit out of "scope"?  :-P
 
Last edit: 2 years 9 months ago by Ray Wells.
2 years 9 months ago #71839

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

  • Posts: 161
  • Thank you received: 39
Parking seems only to be for the pointing.

I had thought it saved PEC position, but that doesn't appear to be the case. (Or if it does, it appears to do it before a move which... doesn't really work for saving the position.)

As far as the OnStep vs OnStepX. Right now I think there's 0 point. Or maybe 0.002 sec of a point (how long it takes to probe for the focusers on a mega, sans stupid programming mistakes by someone. Theoretically it's 0.0026 sec, but rounding errors, and batched serial communication over USB) There's still a lot that the INDI driver doesn't support, or needs to be looked at: PEC, Outputs, Weather, etc.

But we've got issues with the compatibility, like (and I don't mean this to be any slight at @azwing, I just looked at it most recently) the outputs for example, there's two commands :SXX____ for the current stuff (currently implemented, for some outputs) and :SXG____ for things older than ~Oct 2020 (Currently not implemented. I didn't narrow the date down too much) Which gives rise to what we want to support. Do we want to have that fall back to the old command? Another recent example is the High precision location, which I do have it falling back, and that's a change that's < 1 year old. The fallback there was easy. Should we add the :SXG commands as a fallback? Which I think would require rewriting the detection function or just go: "Upgrade!"

Which kind of gives us a dilemma on what we should consider for the INDI driver, for any changes in a project which can be easily downloaded and reloaded onto the microcontroller? Thoughts on maintaining compatibility with old versions? Which is in some ways necessary with commercial stuff (*insert flashbacks of aggravation in trying to re-flash Meade controllers*) due to difficulty (or impossibility) of flashing newer versions. (Though they are starting to get their act together with regards to that.) as opposed to something where to even have it work it has to have an easy path to flashing.

It'd be nice but somewhat impractical, if OnStep just stored config.h and could spit that out. It's 26KB alone, at least on my machine and while I've added a little, I strongly suspect it's less than 1KB. Though that might be something on large flash sized controllers like the ESP32.

Somewhat philosophical questions aside, looking at the outputs, It seems like it'd be better to do it via separate handlers for each type because of the differences, and simply display them on the OUTPUTS tab, rename to FEATURES or leave as OUTPUTS?

Current list from constants, and some documenting for reference later.
#define SWITCH                      1
#define ANALOG_OUTPUT               2
#define ANALOG_OUT                  2
#define DEW_HEATER                  3
#define INTERVALOMETER              4
#define SWITCH_UNPARKED             5

SWITCH is an output switch (might be named digital_output to be a bit less confusing, as that seems to imply you can trigger it, but anyway)
Format :SXX_,V_#
First _ is output number 1-8
Second _ is value 0 or 1
If the pin is assigned to a DS2413, it will turn the sensor on or off.

ANALOG_OUTPUT is an pwm output
Format :SXX_,V_#
First _ is output number 1-8
Second _ is value 0-255 which is passed to AnalogWrite (see arduino for details)

DEW_HEATER is a  heater output
Format :SXX_,?_#
First _ is output number 1-8
The ? and second _ depend (Only 1 can be used at one time, so to set all 3 you'd need to make 3 calls):
V_ : 0 = Off, 1 = On
Z_: -5.0 to 20, "Zero"
S_: -5.0 to 20, "Span"

(I would need to look into Zero and Span, as Dew Heaters haven't been a huge priority of mine.)

INTERVALOMETER is a camera trigger output, holds the output high while an exposure is going on.
Format :SXX_,?_#
First _ is output number 1-8
The ? and second _ depend (Again Only 1 can be used at one time, so to set all 3 you'd need to make 3 calls):
V_ : 0 = Off, 1 = On (I believe this starts it)
E_: 0.0-3600.0 Exposure length
D_: 0.0-3600.0 Delay (I presume between pictures)
C_:0-255 Count

SWITCH_UNPARKED is a switch tied to if the mount is parked/unparked. It can be called as a switch, but will return nothing and possibly cause a 5 sec timeout, if not implemented well.

I'd suggest that we look at doing those as separate interfaces, if detected. (With the :GNY, it should give use the values, which the current code adds onto the end.)

(The intervolometer would be great for some of my cameras which don't support bulb mode (Nikon D5100, D3200) if tied in with the gphoto photo port trigger. Though that needs modification in OnStep for IR (which is how I use it, via another arduino with an IR led and the Arduino NikonRemote program, or my phone.)) Anyway this post is already way too long.

 
2 years 9 months ago #72017

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

  • Posts: 161
  • Thank you received: 39
Still in the process of getting the outputs done.

I went hunting a little, and found a few things that could be improved. They are now in main repository. (There was a timeout after tracking On/Off, Parking?, The OnStepX focuser type checks had an issue on V3, so I fixed that as well, it'll timeout once there.)

There may be more, I need to look at some of the replies, the main issue is the use of some of the lx200 functions which expect a # string, and OnStep returns either a single character vs a # terminated string, or in some cases times out. I think I've gotten most of them, with V3 to V5.

I also changed the high precision to be off, and implemented the most basic version checking. It will turn on High precision on connect if it sees OnStep, or On-Step and V4 or V5 or in the case of OnStepX. Otherwise it's off with no timeout caused. If you are using an old version of V4/V5 it might not support that in which case it will cause a timeout (once, effectively the same behavior before the changes).

Timeouts that I don't see a way around:
TMC_SPI detection currently is 2 seconds to check for it's presence and a timeout if not present. (This actually will likely go up, as it appears that TMC_SPI which used to be RA+DEC Both or None is per axis now) 


Copying my old todo:
1. Changing the MaxRate replacement (degrees per sec)
2. Intervolometer support
3. Focuser Changes
4. Dew heater
5. Weather support. (Read BME280/etc)
6. Tangent arm support (Plate solve then adjust?)
7. Check backlash values (Changed to allowed to 3600)
8. DC Focuser support (Not sure if that works already or not?) Might need someone who has one to help with this.
9. TMC_SPI reporting support. (I got one for testing, and finally went to put it in on this cloudy night. I unfortunately missed the: You have to have both axis be SPI if one is, so this will be working at some point, but when is a big question. Oops.)
10. Equivalent of MoveAxis support to allow for following satellites. (Kstars issue more likely than OnStep directly, as the custom rates are added in, but Kstars doesn't have a way to send the rates/information, AFAIK)
11. PEC Import/Export
12. Check uses of getCommandString and replace any which might not return with the replacements (getCommandSingleCharResponse/getCommandSingleCharErrorOrLongResponse)
13. Implement checksum for packets See: onstep.groups.io/g/main/topic/27153325

Also, @Jack I just was able to duplicate and found the cause of the Unparking issue, and submitted another pull request a minute ago. It had been set to only read it from a clean state only from when it first connected. After that it would read only specific things depending on the state. (I suspect an artifact from a long time ago, maybe before :GU# had everything including Park status?) I got rid of the conditionals (there is no extra scope communication) so it updates it every update. (Which also isn't perfect (there was/is? a timing bug with KStars on alignment, if it sees a move start, but the status updates), but eh.)

In that case, dome lock was on, so the unlock would fail, but the state would get set to not parked (don't recall what it was, and doesn't matter) but that was/is tracked in the telescope class so it'd go: Hey, you are already unparked. I'll look into it a bit more, in case it's a problem for someone else.
 
2 years 9 months ago #72298

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

  • Posts: 174
  • Thank you received: 27
Hi James,

Would it be possible to prioritize PEC Import/Export?
Also, there is an issue that I am running into once in a while during precision slewing, where if the mount needs to slew very little (~ 1' ), it gets stuck and I have to stop the slewing using the INDI panel.
Any thoughts on how to solve this?

Alex
2 years 9 months ago #72299

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

  • Posts: 23
  • Thank you received: 2
Hi All,

Does anyone know the OnStep version shipped with the current kstarts 3.5.3 update for the astroberry (rPi)? I updated (system update) a couple of days ago, and I found out that it is not an updated driver, since it does not have rotator support (something I was waiting for, thanks James for adding it!). Besides, PHD2 fails to connect to the mount and crashes. Driver info shows the same values than the previous one (version 1.9 & interface 1.4.1)

I have gone back to the previous version where everything works (except for rotator support... I will continue waiting). Perhaps this problem is not related to this specific driver, but just in case... 

Thanks a lot for your help.

Jordi.
2 years 9 months ago #72729

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

  • Posts: 322
  • Thank you received: 31
Jordi,

I can't comment on the rotator, since I don't have one.

But I got an INDI update today and installed.

Very basic testing shows that OnStep works as before.

Here are my package versions. I am on Ubuntu 18.04 LTS on a laptop.

indi-bin 1.9.1~202106261410~ubuntu18.04.1
indi-gphoto 3.0~202105061228~ubuntu18.04.1
indi-qhy 2.7~202105011731~ubuntu18.04.1
libindi-data 1.9.1~202106261410~ubuntu18.04.1

kstars-bleeding 6:3.5.3+202105061458~ubuntu18.04.1
kstars-bleeding-data 6:3.5.3+202105061458~ubuntu18.04.1
kstars-bleeding-dbg 6:3.5.3+202105061458~ubuntu18.04.1
2 years 9 months ago #72731

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

  • Posts: 161
  • Thank you received: 39

As regards the PEC I/E, I will work on it when I can, but unfortunately, my mount messed up so I don't have one with PEC (Not that it's going to be required for it, but I can't test it.)

As far as the tiny slews, I think I recall that being due to acceleration/deceleration, and a note about that in old config files? I can't seem to find it right now, but you might go browse old git versions. This seems like something that's going to be more an OnStep issue, than the INDI interface. Though if you've got logs those would be good to know. The INDI interface should reflect the state of the driver.

I have had little time lately, (which unfortunately may drop to near 0 again) but did manage to work on two things (incomplete! I haven't even merged them into my master branch yet):
1) Reducing timeouts even more, and general code cleanup.
2) Checksummed commands (which has been working with one of the OnStep Specific things, but trying to convert to a better layout caused a crash that I haven't gotten to look at. Whee!)
The following user(s) said Thank You: Jordi Sesé
2 years 8 months ago #73138

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

  • Posts: 161
  • Thank you received: 39
INDI 1.9.1/OnStep v 1.10 should have all of the things up to this point. (Should show driver version under the Connection tab) 1.9.0 / 1.9 will not

It's possible it isn't being detected (and won't show up if it's not), If it's 1.10, can you enable debuging, and search the log file for :rG#, then paste to see if it's detected (example where it isn't):
[2021-07-03T01:19:31.251 CDT DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] CMD <:rG#> "
[2021-07-03T01:19:31.251 CDT DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] RES <0> "
[2021-07-03T01:19:31.252 CDT INFO ][ org.kde.kstars.indi] - LX200 OnStep : "[INFO] No Rotator found. "

If you can figure out, the log on where it's crashing I can take a look at it. (PHD2 seems to just crash randomly sometimes on me, but I'm pretty sure 99% of the time, it's related to my temperamental camera, and when I've dug into logs it's seemed to be that.)
The following user(s) said Thank You: Jordi Sesé
2 years 8 months ago #73139

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

  • Posts: 23
  • Thank you received: 2
I downloaded a new update today on the rPi, and now OnStep driver shows the 'Rotator' tab (thanks again, James).

PHD2 (2.6.9dev5) keeps crashing when connecting to the mount, but it does the very same when connecting to the Telescope Simulator driver, so it's not driver related. Hope to solve it soon to be able to test the whole thing...

Regards,

Jordi.
2 years 8 months ago #73153

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

Time to create page: 1.339 seconds