Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Position & Time for Grab‘n‘Go Use #219

Open
jscheidtmann opened this issue Aug 22, 2024 · 2 comments
Open

Position & Time for Grab‘n‘Go Use #219

jscheidtmann opened this issue Aug 22, 2024 · 2 comments
Assignees

Comments

@jscheidtmann
Copy link
Contributor

jscheidtmann commented Aug 22, 2024

Use Case: An observer at a fixed location wants to use PiFinder for a Grab‘n‘Go telescope.

Requirements:

  1. A configuration option „Grab‘n‘Go“ shall be created, that:
    1.0 reads the previously stored position from the configuration file
    1.1 presents position and time at startup and
    1.2 allows to edit position and time
    1.3 upon confirmation the position is stored in the config file and
    1.4 that position and time is used by PiFinder.
  2. If PiFinder‘s WiFi is in client mode, time should be synced using ntpd and read at startup from the system.
  3. Once a GPS lock is achieved, this observer position should be stored in the configuration file (every 10-15 min) and only if the last stored position is different by more than 5 km (?) distance

Follow the „Observing time is precious“-principle: Whenever PiFinder is unsure about something that can degrade pointing performance (e.g. position or time), this information should be used only after user confirmation.
Rationale: Avoid users believing in the automatisms we implemented, only to discover after 1/2 h hour of weird behaviour and lost observation time, that some setting was cached and reused.

@brickbots
Copy link
Owner

Thank you for laying out some actual specifications after the Discord discussion. This looks good as a general feature set... but I think it using any non-GPS location should always start with some user action. I.e. we can store and cache the last position, but I'd like choosing to use this to be a step that people actually invoke rather than having it try to do this on start up.

The primary reason being we don't know if the last position is correct and if people don't know the system is using the cached location, they may be confused when things don't work properly.

Determining the reliability of time is easier as we can see if the unit is online and able to get to an NTP server.. so we can automatically use this data if it's available.

@jscheidtmann
Copy link
Contributor Author

Updated with feedback from Brickbots.

@mrosseel mrosseel self-assigned this Sep 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants