-
Notifications
You must be signed in to change notification settings - Fork 58
Add a feature to camera control, so that "noon" can be used as a sentinal value which will calculate the local solar noon in camera time #701
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
base: prerelease
Are you sure you want to change the base?
Conversation
g7gpr
commented
Aug 3, 2025
|
|
Oh, so clever! merging into alpha1 and testing. |
|
If you think that makes sense, could you also update the default camera_settings.json as part of this PR? |
markmac99
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See my comment on the Issue about the necessity of first setting the camera TZ and clock to match the station.
Also given the appropriately simple approach for computing local noon in UTC, i'd probably not bother with a function and just use station_noon_in_utc = 12 - int(config.longitude/15).
Personally, i'd also ditch the other function and just inline the required three lines, i can't see anyone needing to improve the code and it'd make it simpler to read.
|
I think Mark is right. If you set the time using the set time command, time zones do not matter. If you use the camera's NTP client, then it does matter. Since folk might use the NTP client, we should take that into account. Did I get that right? So, I have three options.
So it's a choice between 1 and 2. Personally, I think 1, because it is the least invasive, but happy to hear other folks thoughts. All the other comments about inlining, sure, happy to do. |
|
Right, I think if we want to support NTP and non-NTP, and don't want to alter the camera TZ, then option 1 it is:
There was also Mark's idea to reboot a moment before night capture starts. Should the target only be noon? Should dusk be an option? Then there's also the option to deadman reboot: always attempt to push back reboot to the next hour except for the reboot hour if any (requires a watchdog process). Edit: actually maybe it doesn't need a watchdog, just send the command moving back reboot to the next hour every hour. If the command doesn't land, camera reboots. |
|
We should not set the camera time as part of this command. A command to set the reboot to noon has a bug if it changes anything other than the reboot time. An operator might have set the camera time to some time, for some reason that we do not know, and we should not be changing it, unless explicitly asked. All we need to do is compute the time of station noon, and transform that into camera time, and schedule a reboot at that time. We could reboot at dusk, but that adds complexity, and I'd like to keep the simplicity of this piece of code. The other problem with dusk, is that dusk does not happen everyday everywhere on a planet. Polar regions can go for hundreds of hours without a dusk. I do not consider planets with multiple stars for this pr. As for resending commands, that is already taken care of. I set the reboot time at each transition to night mode, and I think other code keeps resending the transition to night mode. |
|
Fair point about not setting time first, but then when we do set time or set tz, should it trigger a new noon computation automatically?
Whut? We just had a request from someone on Tatooin ;)
Sorry, I'm not following. |
|
This is the line I'm referring to |
|
Hey guys, |
|
Not ready to merge. Waiting for help on the timezone function. |