You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Use Case: An observer at a fixed location wants to use PiFinder for a Grab‘n‘Go telescope.
Requirements:
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.
If PiFinder‘s WiFi is in client mode, time should be synced using ntpd and read at startup from the system.
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.
The text was updated successfully, but these errors were encountered:
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.
Use Case: An observer at a fixed location wants to use PiFinder for a Grab‘n‘Go telescope.
Requirements:
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.
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.
The text was updated successfully, but these errors were encountered: