Skip to content

Commit be424f8

Browse files
knroknro
authored
Merge pull request #2466 from nitr57/feat/proxisky
Add Proxisky UMi telescope driver (indi_lx200_proxisky)
2 parents c080e7d + a450ff4 commit be424f8

6 files changed

Lines changed: 2384 additions & 4 deletions

File tree

‎drivers.xml‎

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -43,9 +43,9 @@
4343
<driver name="LX200 OnStep">indi_lx200_OnStep</driver>
4444
<version>1.27</version>
4545
</device>
46-
<device label="UMi" manufacturer="ProxiSky">
47-
<driver name="LX200 OnStep">indi_lx200_OnStep</driver>
48-
<version>1.27</version>
46+
<device label="UMi" manufacturer="Proxisky">
47+
<driver name="Proxisky UMi">indi_lx200_proxisky</driver>
48+
<version>1.0</version>
4949
</device>
5050
<device label="EM31Pro" manufacturer="Emcan Astro">
5151
<driver name="LX200 OnStep">indi_lx200_OnStep</driver>

‎drivers/telescope/CMakeLists.txt‎

Lines changed: 3 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -83,7 +83,8 @@ add_executable(indi_lx200generic
8383
ioptronHC8406.cpp
8484
eq500x.cpp
8585
lx200_esp32go.cpp
86-
toup_sh20.cpp)
86+
toup_sh20.cpp
87+
lx200_proxisky.cpp)
8788

8889
if(NOT CMAKE_SYSTEM_NAME MATCHES "OpenBSD")
8990
if(CMAKE_SYSTEM_NAME MATCHES "FreeBSD")
@@ -119,6 +120,7 @@ execute_process(COMMAND \"${CMAKE_COMMAND}\" -E create_symlink indi_lx200generic
119120
execute_process(COMMAND \"${CMAKE_COMMAND}\" -E create_symlink indi_lx200generic \$ENV{DESTDIR}${BIN_INSTALL_DIR}/indi_eq500x_telescope)\n
120121
execute_process(COMMAND \"${CMAKE_COMMAND}\" -E create_symlink indi_lx200generic \$ENV{DESTDIR}${BIN_INSTALL_DIR}/indi_lx200_esp32go)\n
121122
execute_process(COMMAND \"${CMAKE_COMMAND}\" -E create_symlink indi_lx200generic \$ENV{DESTDIR}${BIN_INSTALL_DIR}/indi_touptek_sh20)\n
123+
execute_process(COMMAND \"${CMAKE_COMMAND}\" -E create_symlink indi_lx200generic \$ENV{DESTDIR}${BIN_INSTALL_DIR}/indi_lx200_proxisky)\n
122124
")
123125
set_target_properties(indi_lx200generic PROPERTIES POST_INSTALL_SCRIPT ${CMAKE_CURRENT_BINARY_DIR}/make_lx200generic_symlink.cmake)
124126

‎drivers/telescope/doc/lx200_proxisky/index.md‎

Lines changed: 248 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,248 @@
1+
# Proxisky UMi
2+
3+
## Device Overview
4+
5+
[Proxisky](https://www.proxisky.com) UMi mounts (UMi17X, UMi20S and relatives) are compact
6+
strain-wave star trackers / GoTo mounts. They run **OnStep-derived firmware**, so all of the
7+
standard telescope behaviour — slewing, tracking, guiding, parking, alignment, meridian flips, the
8+
focuser and rotator interfaces — is exactly OnStep's and is handled by INDI's existing
9+
`LX200_OnStep` driver.
10+
11+
`indi_lx200_proxisky` is a thin subclass of that driver. It adds only the vendor-specific `:P...`
12+
serial commands that Proxisky layered on top of OnStep and that stock OnStep does not implement:
13+
travel limits, the anti-collision system, the servo PID gains, and a handful of board settings.
14+
15+
**If you are looking for how to slew, track or guide, the OnStep driver's documentation applies
16+
unchanged** — see the [OnStep project documentation](https://onstep.groups.io/g/main/wiki) and
17+
INDI's own `LX200 OnStep` driver page. This page covers only what the Proxisky layer adds.
18+
19+
## Features
20+
21+
Everything below appears on one of four `Proxisky *` tabs in the INDI Control Panel. Each control is
22+
published **only if the mount answers the corresponding query**, so the panel reflects what your
23+
particular model and firmware actually support (see
24+
[If a control is missing](#-if-a-control-is-missing) — this detection has one important caveat).
25+
26+
| Feature | What it does |
27+
|---|---|
28+
| **Model / firmware** | Reports the mount's own identification string, e.g. `UMi20S\|1.0.6` |
29+
| **RA travel limits** | Left/right rotation limits in degrees, plus an enable switch |
30+
| **Dec travel limits** | CCW/CW limits in degrees, plus an enable switch |
31+
| **Anti-collision (ACS)** | Enable, per-axis sensitivity thresholds, collision counters, counter reset |
32+
| **Servo PID gains** | Four gains per axis (angle Kp/Ki, speed Kp/Ki) for RA/Azm and Dec/Alt |
33+
| **Supervised GOTO** | Enable plus a tolerance in degrees |
34+
| **Supervised Home** | Enable (see the [caveat](#supervised-home-may-be-refused)) |
35+
| **Dec second home** | Enable |
36+
| **Status LED** | Turns the board's status LED on or off |
37+
| **Auto tracking** | Whether the mount starts tracking by itself |
38+
| **Power-loss memory** | Whether the mount restores its position after a power cut |
39+
| **ASIAIR homing** | Compatibility behaviour for ASIAIR controllers |
40+
41+
## Installation
42+
43+
The driver ships with INDI core. There is nothing extra to build and no dependencies beyond INDI
44+
itself.
45+
46+
No additional udev rules are needed. UMi mounts present themselves through a standard USB-serial
47+
adapter, which Linux exposes as `/dev/ttyUSB*` and INDI detects automatically.
48+
49+
To run it directly:
50+
51+
```shell
52+
indiserver -v indi_lx200_proxisky
53+
```
54+
55+
In KStars/Ekos, choose **Proxisky › UMi** in the profile editor.
56+
57+
### Migrating from an older profile
58+
59+
**Read this if you used a UMi with INDI before this driver existed.**
60+
61+
The `Proxisky › UMi` catalogue entry previously launched the generic `indi_lx200_OnStep` binary
62+
under the device name **`LX200 OnStep`**. It now launches `indi_lx200_proxisky` under the device
63+
name **`Proxisky UMi`**.
64+
65+
INDI keys saved settings by *device name*, so nothing carries over automatically:
66+
67+
| What | Old location | New location |
68+
|---|---|---|
69+
| Driver settings | `~/.indi/LX200 OnStep_config.xml` | `~/.indi/Proxisky UMi_config.xml` |
70+
| Park position | `~/.indi/ParkData.xml`, `<device name="LX200 OnStep">` | same file, `<device name="Proxisky UMi">` |
71+
72+
Practically this means: **re-select the port, re-save your configuration, and re-set your park
73+
position** the first time you connect. Your old files are not deleted and the old driver still works
74+
if you select `LX200 OnStep` manually — you simply get no vendor controls.
75+
76+
## Configuration
77+
78+
### Connection
79+
80+
| | |
81+
|---|---|
82+
| **Serial** | Default. **9600 baud, 8N1** — this is what the mount uses; leave the baud rate at its default unless you have a specific reason. |
83+
| **TCP/IP** | Supported (inherited from `LX200_OnStep`) for network-attached mounts. |
84+
85+
Connect as usual from the **Main Control** tab. Vendor detection runs once during connect and adds a
86+
second or so on serial.
87+
88+
### The Proxisky tabs
89+
90+
| Tab | Contents |
91+
|---|---|
92+
| **Proxisky Settings** | Model, Status LED, Auto Tracking, Power-loss Memory, ASIAIR Homing, Supervised Home, Dec Second Home |
93+
| **Proxisky Limits** | RA and Dec travel limits and their enable switches |
94+
| **Proxisky ACS** | Anti-collision enable, sensitivity, collision counters, counter reset |
95+
| **Proxisky Advanced** | Supervised GOTO and tolerance, RA/Azm and Dec/Alt PID gains |
96+
97+
### What Left / Right and CCW / CW mean
98+
99+
The travel-limit fields use **the vendor's own terms**, taken directly from the Proxisky Windows
100+
tool. Nothing in the protocol establishes a mapping to East/West or to any sky direction, and the
101+
mapping may well differ between mount models and between EQ and Alt-Az configurations.
102+
103+
**Determine empirically which way each limit points before relying on it**, with the mount somewhere
104+
safe and nothing attached that can collide. The driver reports what the mount stores; it does not
105+
reinterpret it.
106+
107+
### Value ranges
108+
109+
The driver enforces the same ranges as the vendor's own tool:
110+
111+
| Setting | Range |
112+
|---|---|
113+
| RA limits (left, right) | 1 – 180° |
114+
| Dec limits (CCW, CW) | 90 – 200° |
115+
| ACS threshold, RA | 10 – 59999 |
116+
| ACS threshold, Dec | 100 – 59999 (note: **not** the same floor as RA) |
117+
| Supervised GOTO tolerance | 5 – 30° |
118+
| PID angle Kp/Ki, speed Kp | 11 – 1999 |
119+
| PID speed Ki | 11 – 80 |
120+
121+
These come from the vendor tool's validation, **not** from the firmware. An in-range
122+
value can still be refused by the mount — which is why every write is read back and verified. If the
123+
mount refuses or stores something different, the property turns red (`Alert`) and the log says what
124+
the mount actually holds.
125+
126+
## Usage & Tips
127+
128+
### ⚡ Settings that need a power cycle
129+
130+
Some settings are stored immediately but only take effect at the next power up. For these the
131+
property goes green (`Ok`) — the write itself succeeded — and the message says the rest:
132+
133+
> *Status LED will be enabled after the mount is power cycled.*
134+
>
135+
> *RA/Azm PID gains stored. Power cycle the mount for them to take effect.*
136+
137+
**Power cycle required:** Status LED · Auto Tracking · both PID vectors.
138+
139+
**Effective immediately:** Power-loss Memory · ASIAIR Homing · Supervised Home · Dec Second Home ·
140+
Supervised GOTO · RA/Dec limit enables · ACS enable and thresholds.
141+
142+
This is why the panel can legitimately disagree with the mount's current behaviour: it shows what is
143+
*stored*. That is deliberate, not a bug.
144+
145+
### PID gains
146+
147+
Changing PID gains is a genuine servo-tuning operation and can leave the mount unable to track if
148+
you get it wrong. **Write down the values before you change them.**
149+
150+
Two behaviours to expect:
151+
152+
- **The driver refuses to write while the mount is moving.** The commit command restarts the axis,
153+
so writes are only accepted with the mount idle or parked and no manual motion in progress.
154+
- **A brief pause after committing.** The axis restart makes the mount report all four gains as zero
155+
for roughly 70 ms. The driver waits this out before verifying, so you will not see a spurious
156+
mismatch.
157+
158+
Gains take effect after a power cycle.
159+
160+
### If a control is missing
161+
162+
This is the most likely surprise, so it is worth understanding.
163+
164+
Most of this protocol has **no capability query**. The only way to find out whether a mount supports
165+
a feature is to ask for its current value and see whether anything comes back. An unsupported
166+
feature and a *dropped reply* therefore look identical.
167+
168+
Detection runs **once, at connect**. The driver retries each query once before giving up, which
169+
makes a spurious miss unlikely — but if a control you expect is absent:
170+
171+
> **Disconnect and reconnect.** That re-runs detection.
172+
173+
The log records every feature that stayed silent, at `Warning` level:
174+
175+
```
176+
[WARNING] Dec second home did not answer (:PsDgb#), even after a retry;
177+
its control is hidden. Reconnect to probe again.
178+
```
179+
180+
If a control is *consistently* absent across reconnects, your mount or firmware genuinely does not
181+
have it.
182+
183+
Note also that Proxisky's own documentation labels some features "UMi17X only" that a UMi20S
184+
demonstrably seem to support.
185+
186+
### Supervised Home may be refused
187+
188+
On at least some UMi20S firmware, the mount **answers** the Supervised Home query — so the control
189+
is published — but **refuses every attempt to change it**:
190+
191+
```
192+
[ERROR] The mount refused the Supervised Home change.
193+
```
194+
195+
The driver is behaving correctly: it reports the refusal and puts the switch back to what the mount
196+
still holds. There is nothing to fix on the INDI side; the firmware is declining the write.
197+
198+
### Anti-collision counters
199+
200+
The collision counters are read-only and polled in the background (every fifth status cycle, so
201+
roughly every five seconds at the default polling rate) while ACS is enabled. If the mount stops
202+
answering the counter query, the driver stops asking for the rest of the session rather than
203+
stalling every status update — reconnect to resume.
204+
205+
### Simulation mode
206+
207+
**Simulation mode exposes no Proxisky properties at all**, and this is deliberate.
208+
209+
Every vendor property mirrors a value read back from real hardware; in simulation there is nothing to
210+
read, and inventing values would mean the panel showed settings that no mount holds. In simulation
211+
you get the standard OnStep simulated telescope and nothing else. This is not a bug.
212+
213+
### Do not use the plain "LX200 OnStep" driver
214+
215+
A UMi will connect and work under the generic `LX200 OnStep` driver — you simply get none of the
216+
vendor controls, with nothing in the UI to indicate they exist. If your Proxisky tabs are missing
217+
entirely, check which driver your profile actually selected.
218+
219+
Conversely, do **not** select `Proxisky UMi` for a non-Proxisky OnStep mount. The vendor commands
220+
are meaningless to stock OnStep firmware.
221+
222+
### Logging
223+
224+
To see the raw vendor exchange, enable debug output on the **Options** tab, or:
225+
226+
```shell
227+
indi_setprop 'Proxisky UMi.DEBUG.ENABLE=On'
228+
indi_setprop 'Proxisky UMi.DEBUG_LEVEL.DBG_DEBUG=On'
229+
```
230+
231+
Every vendor command and its reply is then logged, along with the reason any probe concluded a
232+
feature was unsupported.
233+
234+
Note that `indiserver -v` does **not** relay driver messages to its own output — they go to
235+
connected clients. Read them in the KStars INDI log window, or with a client such as
236+
`indi_getprop`.
237+
238+
## Tested against
239+
240+
| | |
241+
|---|---|
242+
| Mount | Proxisky UMi20S |
243+
| Firmware | 1.0.6 |
244+
| Transport | Serial, 9600 8N1 |
245+
246+
All 19 vendor properties, every write path, the refusal and out-of-range paths, and connect /
247+
reconnect / disconnect were exercised against this hardware. TCP transport and models other than the
248+
UMi20S are supported by the same code but have not been tested on hardware — reports welcome.

0 commit comments

Comments
 (0)