Comprehensive documentation for accessing the DWARF camera streams:
- RTSP URLs and channels (ch0=tele, ch1=wide)
- The critical prerequisite: camera must be opened via WebSocket first
- ffmpeg commands for frame capture, timelapse, and video recording
- mpv and VLC usage with TCP transport
- Python/OpenCV integration example
- Troubleshooting common issues (black image, connection refused, VLC delay)
- Comparison of RTSP vs MJPEG modes across device models
💘 Generated with Crush
Assisted-by: Crush:glm-5.2
Added `motor init [up|down] [timeout]` that homes the altitude axis by
slewing to a mechanical limit. The firmware detects the limit switch and
performs an automatic home to position 0 (optics toward ground).
Validated procedure:
1. Slew up briefly (90° 0.4 for 5s) to move away from the bottom limit
2. `motor init down 40` — slew 270° until bottom limit triggers auto-home
3. Axis remains fully operational after homing
The firmware drops the WebSocket connection when the home sequence starts
(normal behavior). After reconnecting, the axis works normally.
Note: API still returns NEED_RESET (-14520) because absolute positioning
requires astro calibration (plate solving). The mechanical home only
provides physical position 0, not sky coordinates.
💘 Generated with Crush
Assisted-by: Crush:glm-5.2
The calibration command (cmd 11000) requires lon/lat coordinates in the
ReqStartCalibration proto message — it was previously sent empty.
Added StartCalibrationWithLocation(lon, lat) method and updated the CLI.
Confirmed the complete motor initialization flow:
1. NEED_RESET (-14520) is NORMAL after every power-on
2. Slew (joystick) works in relative mode without absolute position
3. Only a successful astro calibration (night + stars + lon/lat) homes
the motors and provides absolute positioning
4. After calibration, motor position returns code=0 with real coordinates
5. GoTo and tracking require calibration first
6. There is NO API command to initialize motors in daytime — the official
app works identically (relative slew until night calibration)
💘 Generated with Crush
Assisted-by: Crush:glm-5.2
The DWARF II firmware permanently locks the altitude motor axis after
hitting a mechanical limit. The lock survives reboots and motor resets.
Only a successful astro calibration (which homes all motors) clears it.
This is a firmware safety mechanism with no API bypass.
Motor reset (cmd 14003) reboots the device but does not unlock the axis.
💘 Generated with Crush
Assisted-by: Crush:glm-5.2
Live testing revealed the joystick polar coordinate mapping (alt-az config):
- 0° = azimuth rotation clockwise (viewed from above)
- 90° = altitude DOWN (toward ground)
- 180° = azimuth counter-clockwise
- 270° = altitude UP (toward sky)
Also discovered that continuous slew to a mechanical limit causes the
firmware to emergency-stop and drop the network connection entirely,
requiring a physical power cycle. No soft-limit protection exists for
joystick slew commands.
Updated TEST_RESULTS.md with the coordinate map and safety warning.
💘 Generated with Crush
Assisted-by: Crush:glm-5.2
The motor reset command (cmd 14003, inferred from a gap in the WsCmd enum)
caused the telescope to immediately reboot during live testing. The Android
app never uses ReqMotorReset — it only uses joystick (14006-14009), run
(14000) and stop (14002). Motor homing is handled internally by the firmware
during astro calibration or panorama operations.
Changes:
- MotorReset() now returns an error instead of sending the command
- CLI "motor reset" shows the disabled message
- Documented the incident and lessons in TEST_RESULTS.md
- Confirmed motor position query (cmd 14001) works but returns NEED_RESET
- Confirmed slew movements (all directions/speeds) work safely after reboot
💘 Generated with Crush
Assisted-by: Crush:glm-5.2
Complete reverse-engineering of the DWARFLAB Android app (v3.4.0) protocol
and implementation of a working CLI tool to control DWARF II telescopes.
Analysis (from APK decompilation with jadx):
- Extracted 17 protobuf definitions (382 messages) from embedded descriptors
- Mapped all 323 WebSocket command IDs across 16 modules
- Documented the full protocol: BLE discovery, WebSocket control (port 9900),
RTSP preview, WsPacket envelope (proto v2.3)
- Documented the Android UI structure (screens, navigation, shooting modes)
- Key discovery: telescope responds with type=3 (reply), not type=1 (response),
and several commands are fire-and-forget (RGB, camera open/close)
dwarfctl Go client:
- Protobuf bindings generated from extracted .proto files (397 messages)
- WebSocket transport layer with request-response matching and notification fan-out
- Typed API covering cameras, motors, astrophotography, focus, tracking, system, power
- Cobra CLI with 30+ subcommands and --debug traffic logging
- 57 unit tests (transport round-trip, command routing, proto encoding)
- Validated on real hardware: state, photo, motor slew (all directions/speeds),
focus, RGB, time/location sync all confirmed working
💘 Generated with Crush
Assisted-by: Crush:glm-5.2
