Re:Driver OnStep (LX200 like) for INDI

@ Blueshawk,

Thanks for your input ... especially for the IMO ... I have really problems with acronyms also in French!

More seriously, I asked also Howard about the -/+ and the here the answer .

There is also support in the interface to store settings to file, just a matter of thinking about what needs to be stored.
I really would like to work on both sides, Firmware modification to allow Sync, Reverse, Speed control as well as stting saving.
But to reach the goal I must be sure both Sides are happy whith the modifications.
Seems on Howward side there is agrreement on that.

A propos Focuser speed control, did somebody experience with that?

Posted the suggested change here as an issue: github.com/indilib/indi/issues/866 (And I'm about 50% done with the pull request)

The takeaway from reading through all the things that implement focuserinterface and the focuserinterface is that, 20 bits is all that's used aside from OnStep and OnFocus and to go through that, even at 1 step/millisecond and 20 bits is a 17 minute focus!

Also, everything communicates with the mount as if it's already a signed integer, fixing it to actually act like the documentation would be more issues than the reverse. (gcc, which is almost certainly the compiler used for INDI, will let you call printf(%d) with an unsigned integer, not give you a warning, and output it as a signed integer, which is part of why everything works for me. Actually, based on a quick look, so will Microsoft's compiler. There is only a single driver that actually treats it with the proper %u, and that's only for warnings not for output to the focuser.)

Internally, focuserinterface actually uses signed integers in it's calculations.

Most drivers also represent it internally as well, and I'd say that aside from one using an unsigned short (16-bit), and a few using uint32_t, most use signed doubles. Our current implementation relies alone on the FocuserInterface, and the INDI number variables are doubles. (Frankly I see a lot of unnecessary code in many many drivers. ie, lots of bounds checking, and because I looked at other drivers initially, I did that too.)

FocuserInterface also needs to have support for more than 1 focuser, but that's a separate issue. (And it should be pretty simple to handle, now that I've gone through things.) There's also the rotator interface, which can be used for OnStep.

----

As far as speed control: That isn't something that's going to matter for Absolute positioning.

A brief overview as to why that exists, and why I ignored it:

LX200 was designed when there were only DC motors, so you'd have a speed + time + direction. You can see this still reflected in www.indilib.org/api/classINDI_1_1FocuserInterface.html with MoveFocuser, which gives you reasonable control over DC, and you REALLY need to be able to control the speed for fine vs coarse focusing. The methodology aside from computers was a hand controller with a few speeds and buttons for each direction.

This translates into the LX200 commands, which were the only ones for a while: In, Out, Halt, Fast, Slow, %speed www.meade.com/support/LX200CommandSet.pdf Looking at the newer protocol specification, www.meade.com/support/TelescopeProtocol_2010-10.pdf added some more like time for pulse and such.

However, OnStep uses steppers, with given positions. So instead of trying to use the above, there are more useful commands, where we can tell the focuser go to position X, and barring mechanical or electrical interference/problems it will. There's no need to go at 1mm go for 5 ms In/Out. When you can go: Make 2 steps. It is limited by the rate specified per axis (default is 8ms/step at least on Megas, probably lower on others) (Ok, it's actually defined as micrometers theoretically, along with a conversion factor between steps and physical motion. I personally just set that to 1 micrometer/step, as trying to calculate that on at least one of my setups was probably inaccurate and would require disassembly of the focuser (again). I'd say that's the best method, unless for some reason you know the proper physical conversion and want it to be stored like in the FITS header, I don't see much of a point.)

So I have left speed out of the implementation, because IMO it's useless for anything from within INDI. It might not be for a hand controller (I know some people have SHCs with focusing. Frankly there I'd use absolute.) Frankly, if allowed, I wouldn't have done anything with MoveFocuser, if it weren't a required function. (I used relative movement, ignoring speed, and using the duration as ticks) same as MoveRelFocuser). Relative moves update the Abs position in OnStep, so there's no issue.

So unless you have a reason to want to implement focuser speeds (and I honestly can't think of any good reason, unless you want compatibility with really old lx200 software, but that wouldn't be going through INDI) I would just ignore them completely.

Hi James,

I agree from a technical standpoint, speed control is not necessary.
But soon or later one will come and ask why it is not feasible since OnStep allows it!
And now that DC motor is supported I am pretty sure many people will go for that since it far cheaper, and does the job (I went to stepper because OnStep didn't support DC!)

At least the situation where we are now allows anybody to use the focuser within Ekos and that is the most important.

As we say ... Rome wasn't built in one day!

@all

It is abit complicated for me to follow and keep track in an efficient manner of all the reports and suggestions concerning the Driver.
Using Indi's GitHub issues was an option but I think we shoudnn't use it for "loud thoughts".
So finally I beleive the " OnStep Fork " is the right place to use since it will use only OnStep user's time.

@James,
I believe your Focuser Interface is at the right place since it is more indi related than pure OnStep, but leave up to you to open an issue as reference.

Regards

Hello everyone !

Thank you again for the great job you all did on the indi_onstep driver!
Bravo, without you we never had a driver for indi !!!!

I come to solicit you again to create a new driver that will be a copy of the driver indi_onstep but slightly modified.
The goal would be to create the indi_teenastro driver!

The developer is ready to help and then to maintain it.

Unfortunately I can not help because I already develop the "NAFABox": github.com/Patrick-81/NAFABox

The project teenastro is a project of simplification and personalization of Onstep to make it accessible to the greatest number.
link: github.com/charleslemaire0/TeenAstro

@Dragonlost,

looks a nice project too.
Unfortunately I am still busy with my observatory, still not motorized ...
An many other things on the fire (Retired people never have time
I will take a look on Teenastro at least to see how it is similar in terms of protocol.

Regards

dragonlost wrote: I come to solicit you again to create a new driver that will be a copy of the driver indi_onstep but slightly modified.
The goal would be to create the indi_teenastro driver!

The developer is ready to help and then to maintain it.

Unfortunately I can not help because I already develop the "NAFABox": github.com/Patrick-81/NAFABox

The project teenastro is a project of simplification and personalization of Onstep to make it accessible to the greatest number.
link: github.com/charleslemaire0/TeenAstro

I personally think that instead of effectively forking OnStep into many projects and many drivers, it is better for us to convince Howard to move OnStep to a more friendly and simpler configuration. I wrote the Online Configuration Generator as one way to avoid editing the files. Me, as well as Charles, have advocated for this.

For example, instead of compile time values, we should have things that are run time (e.g. mount type: GEM, Alt-Az, Fork, ...etc.; motor steps per rotation, GR1, GR2, worm wheel steps per rotation). Using a USB tool (a Python program on the desktop, or the SHC), these values are configured, and Steps Per Degree, ...etc. are all calculated internally).

Charles even wrote a Teensy program loader.

Howard so far has been reluctant to entertain the idea. However, with enough voices calling for these changes, perhaps he will be convinced.

If we have this, we can have one universal binary for each MCU architecture and users will not even have to install the Arduino IDE at all.

Instead of addressing the symptom, let us go for the root cause.

Anyone else facing issues with the latest packages from Jasem's repository?

I got this a week ago: indi-bin 1.7.7~201904141646~ubuntu18.04.1

When using OnStep as the driver, the refresh on KStars and CdC is very sluggish (lags by 5 seconds or so).

When I change the driver to LX200 Basic, everything works fine.

Any ideas what changed?

kbahey wrote: Anyone else facing issues with the latest packages from Jasem's repository?

I got this a week ago: indi-bin 1.7.7~201904141646~ubuntu18.04.1

When using OnStep as the driver, the refresh on KStars and CdC is very sluggish (lags by 5 seconds or so).

Found the problem.

This is a process trace of the INDI driver.

You can see that the :GXEA and :GXE9 commands above are timing out, after 5 seconds each.

They are for getting minutes past meridian east and west.

This configuration is for a fork mount, and the INDI driver requests this information regardless of the mount type.

So, the driver must check GU's output and only do these commands if there is an E in it, otherwise, these commands should not be issued at all.

Hi All,

I implemented a new feature in INDI driver: support for driving output ports.
It adds a new tab "Outputs" which allows entering values for 10 outputs.
Both binary and analog values can be passed to Onstep controller.
Onstep will interpret the values accordingly:

• if output is binary, then any value above 0 will toggle the output to high
• if output is analogy, the analog output will be set per the input value

With my RAMPS based Onstep I can toggle output 6 as binary and set values between 0 and 255 on port 7.
This code intentionally does not impose any validations on values, passed to Onstep in order to support future enhancements in Onstep, e.g. implement more than 8-bit resolution.

I see that someone already started working on a similar concept, which introduces a couple of toggle switches, but looks like it is not finished. I used the same tab in INDI UI for my feature.

Here is a pull request for this change:
github.com/indilib/indi/pull/926

Please review, test and merge.

Alex

Alex,

thank you for the Output tab implemen,tation.
Could you please explain how to use this feature?
and how to set-up on Onstep side?

Thanks

Alaine,

Using this feature is very simple: enter a number into a box and push the set button. As a result of it, the following command would be sent to OnStep:
:SXG7,10#
where 7 is port and 10 is value to be sent there.
The ports to be used are board specific. My Ramps based board has PWM analog output on port 7. I use this output for driving flat panel so I can change the brightness of it.
I have no idea which ports are available on other boards.

Here is the corresponding code in OnStep in Command.ino: