[Feature Proposal] Step-count based mount control tools for step-driver mounts (OnStep): Step Jog, Mount Calibration, and related sequencer items

[HNishimura0504]

Motivation

Budget step-driver mounts (e.g. OnStep conversions of older mounts such as the Vixen GP) often lack GPS, encoders, and precise goto ability. Before plate solving can take over, users need a reliable way to make coarse and fine pointing adjustments. NINA's existing manual mount control (MoveAxis at a rate for a duration) is not reproducible on these mounts: the same button press can produce different displacements depending on timing.

Since step-driver controllers ultimately count motor steps, controlling movement by step count instead of rate × time gives deterministic, repeatable motion. I have built a working prototype of this idea on top of develop (3.3.0.1047) and would like to ask whether any of it is of interest for NINA core, or whether a plugin is the better home for it.

Proposed features (prototype implemented)

1. Step Jog panel (Imaging tab) — jog the mount N/S/E/W by a configurable number of motor steps per click.
2. Mount Calibration — builds a calibration map between commanded step counts and actual sky displacement (measured by plate solving), so step-based moves can be translated to arcseconds and vice versa.
3. New sequencer instructions — GuidedSlewToRaDec, GuidedCenterTarget, MoveAxisBySteps: slew/centering that iteratively corrects pointing using the calibration map and plate solving.
4. Camera rotation alignment panel — measures current rotation angle via plate solving and interactively guides manual rotation of the camera to a target position angle (similar in spirit to the manual rotator flow, but as a live Imaging panel with a compass-style display).

Important caveat: firmware dependency

Features 1–3 rely on custom commands added to OnStep firmware (a small patch adding step-count telemetry and step-based move commands). Stock OnStep / standard ASCOM drivers do not expose these. I am fully aware this is a significant constraint for core inclusion — this is exactly what I would like guidance on:

• Would this functionality be acceptable in core behind a capability check, or
• Should this live as a plugin (possibly together with the firmware patch), and if so, is there any interest in a generic "step-based mount control" abstraction in core that such a plugin could build on?

Feature 4 (camera rotation alignment) has no firmware dependency and only uses plate solving; if there is interest, I can split it into its own proposal/PR.

Implementation status

Working prototype, built and in nightly use on my own setup (Vixen GP + OnStep, Canon EOS 6D). ~30 files touched/added on top of develop. Screenshots and diffs available on request; I did not want to open an unsolicited PR before discussing direction here, per CONTRIBUTING.md.

AI disclosure

Per the contribution guidelines: the majority of the prototype code was written with substantial AI assistance (Anthropic Claude). I understand that I remain fully responsible for the code and for defending it during review.

Questions for maintainers

1. Core vs. plugin — which is appropriate for the step-based features?
2. Is the camera rotation alignment panel worth proposing separately for core?
3. If plugin is the answer, any pointers on the preferred way to expose mount-specific extended commands would be appreciated.

[isbeorn]

Hey, thanks for the detailed proposal.
The first three items are quite specific to custom OnStep firmware, so they would be a better fit for a plugin rather than NINA core. A common abstraction is unfortunately not practical here, since the vast majority of mount drivers are ASCOM drivers and do not expose this functionality.

[daleghent]

I would add that another user has created an "OnStepX Tools" plugin for NINA that appears to contain several utility functions for OnStep mounts. You may wish to contact the author of that plugin and discuss any further OnStep-specific functions it could deliver. On NINA's Discord, their username is crockettandtubbs

[daleghent]

Just an observation, from an ASCOM perspective, the MoveAxis API was originally created to allow applications to approximate the function of a hand-held controller for the mount, with its North / South / East / West buttons. I do not have the impression that it was ever intended to be a high-accuracy way to control and position a given axis.

For the purposes of doing a plate solve and sync to orient the mount early after it has been powered on, the mount should be slewed to somewhere in the East or West part of the sky, far enough away from the meridian to remove any positional ambiguity in the RA axis due to any time drift in the mount. But it need not be precise positioning, just adequate. Since this is usually a manual operation because the mount does not yet know how its two axes are oriented, it is expected that the user judges such manual positioning based on their observations of the mount. A plate solve and sync at that location will orient the mount's controller to where its axes are pointing and, typically, that's all you need to do. The mount should subsequently know how to goto slew to a celestial or topocentric coordinate after that point.

[MichelMoriniaux]

@daleghent summoned me here, ("OnStepX Tools").
While I see a use for this feature ( and would be happy to implement it provided the required commands become available in OnStepX ), I do not think the way you want to use it would be the right one. IMHO the only use for such a feature would be fine tune steps/degree not general purpose mount movements.
OnStep assumes you did your prep and have already measured the correct steps configuration (what you put in Mount Calibration). Usually the process consists of

• from available data determine your stepper steps / rotation (usually 200 or 400), microsteps amount, your reduction ratio, will usually give you your ballpark steps/degree (OnStep has a spreadsheet that does it for you)
• build your firmware with that value
• goto anywhere in the sky, platesolve and sync, goto another place one full PE cycle away (one worm rotation), plate solve and diff the coordinates, how much your mount has actually moved will give you your steps/degree
• use guiding assistant in PHD2 to validate your value (the drift in HA will usually give you a good notion of what is going on, ofc compensate for PE)

It's an iterative process but gives excellent results