Open AlaskanAstro opened 3 weeks ago
Interesting, I recall reading a discussion on the Allsky github about sunset being after midnight. I do not know if this would affect indi-allsky.
What is your timezone? I added the timezone as part of the support info about a week ago, but it is just not in your version.
Timezone is Alaska, uhhh AKDST? GMT-8 right now. We really should have like 3 timezones across the state. My transit time this time of year is around 2:30PM so not only is my sunset late because of being far north it's also very offset because I'm far west into the timezone.
I have the same issue happening since a few days ago. Lat 58N here, GMT+1 with DST (Oslo time)
After thinking about this, obviously the problem is the sun never reaches the altitude to trigger the day/night transition, which is what generates the timelapse.
Now that I fully understand the problem, I am considering options.
Two things on that: 1, I could test that tonight with a night trigger of -1 degree if you'd like. 2, How finely does INDI All Sky calculate sun altitude? My trigger was -3 degrees and I believe my true sun alt went as low as -3.9 or even 4 on the first night I noticed it didn't trigger.
indi-allsky performs its astrometric calculations using pyephem, so the raw floating point value is used for the Sun's altitude for the current timestamp.
I went ahead and wrote a script to calculate the Suns min/max altitude for a given day at any lat/long, as well as the overall min/max on the solstices. 5 days ago, the Sun's minimum altitude was -2.713 degrees for your location. The precision is not limited, it is just limited in the log messages.
This is definitely a problem in any case. I need to implement a failsafe to prevent this from happening.
$ ./testing/sunAltMinMax.py
WARNING:root:Latitude: 62.9
WARNING:root:Longitude: -160.0
WARNING:root:Now - 2024-06-07 18:31:36.086857+00:00
INFO:root:2024-06-07 22:39:03.879051: Max 50.0
INFO:root:2024-06-08 10:39:03.879051: Min -2.7
WARNING:root:Solstice 1
INFO:root:2024-06-20 22:41:48.101761: Max 50.5
INFO:root:2024-06-21 10:41:48.101761: Min -2.3
WARNING:root:Soltice 2
INFO:root:2024-12-21 22:38:30.713792: Max 3.9
INFO:root:2024-12-22 10:38:30.713792: Min -50.5
Cool well I look forward to implementing the fix.
Edit: I'm not sure why but that script disagrees with Stellarium's sun altitude I'm getting. Even today which should be lower I'm seeing around -3.5° minimum alt. Is it possible that script is having an issue with the midnight thing too and pulling an altitude at midnight?
When I was first writing the test script, I also noticed a discrepancy between pyephem and skyfield. Skyfield is supposedly the more modern replacement to pyephem and has the same author. I may open a ticket with that team to find out if I am doing something wrong.
I tried several combinations of lat/long and in most cases the minimum altitude is within 0.2 degrees for both libraries, but for some reason, your latitude can have a difference of more than a degree.
WARNING:root:Latitude: 62.9
WARNING:root:Longitude: -160.0
WARNING:root:pyephem Now - 2024-06-07 19:30:40.486816+00:00
INFO:root:2024-06-07 22:39:03.879051: Max 49.977
INFO:root:2024-06-08 10:39:03.879051: Min -2.713
WARNING:root:pyephem Solstice 1
INFO:root:2024-06-20 22:41:48.101761: Max 50.550
INFO:root:2024-06-21 10:41:48.101761: Min -2.270
WARNING:root:pyephem Solstice 2
INFO:root:2024-12-21 22:38:30.713792: Max 3.857
INFO:root:2024-12-22 10:38:30.713792: Min -50.536
WARNING:root:skyfield Now - 2024-06-07 19:30:40.486816+00:00
INFO:root:2024-06-07 22:39:03.915149+00:00: Max 49.964
INFO:root:2024-06-08 10:39:09.749678+00:00: Min -4.194
WARNING:root:skyfield Solstice 1
INFO:root:2024-06-20 22:41:48.131156+00:00: Max 50.537
INFO:root:2024-06-21 10:41:54.591994+00:00: Min -3.665
WARNING:root:skyfield Solstice 2
INFO:root:2024-12-21 22:38:30.655583+00:00: Max 3.660
INFO:root:2024-12-21 10:38:15.721727+00:00: Min -50.540
And I have the answer... Apparently, pyephem is accounting for refraction at the horizon, so the sun is visually at a different altitude than it is physically. skyfield does not account for refraction below -1 degrees. Setting the atmospheric pressure to 0 disables the refraction calculation and makes the numbers exactly the same in both libraries.
https://github.com/skyfielders/python-skyfield/discussions/974
Back to the issue at hand...
My plan is to add a drop dead time limit for daytime and night time. If the day/night Sun altitude is not hit, the drop dead time will trigger generating a timelapse for the previous period. Normally, indi-allsky expects a day then a night then another day, but this will introduce the concept of back-to-back days during summer, and back-to-back nights in winter.
This introduces another challenge... the dayDate
classification. The way indi-allsky classifies images for a timelapse is the dayDate
attribute. The drop dead limit for day and night cannot be midnight/noon, it needs to be meridian/anti-meridian. However, timezones being as they are, the anti-meridian sometimes occurs the following day (during summer). Due to this "misalignment", it means some daytime images that fall after midnight need to be associated with the previous dayDate period. My current method for calculating dayDate needs to be refactored.
Edit: That was a terrible explanation, but the complexity I have to deal with is for higher latitudes, as stated previously, night does not start until after midnight. Therefore, under the indi-allsky rules, that "night" is technically within the dayDate
for the previous day.
Well I'm excited to see your ideas on this. Thanks so much for tackling it. Sorry I broke your project. 😄 Will definitely be buying you a coffee with the link at some point.
I went ahead and pulled the trigger on this merge #1340 . This should properly handle higher latitudes now. The solar meridian is now considered the hard stop between consecutive nights, and the anti-meridian for consecutive days.
There may be gremlins in this code. I have tested many cases with this, but the behavior is unique to the different timezone and latitude/longitude combinations.
Deployed, I'll let you know how it plays out :)
As someone not super familiar with Git, how do I update this without it being part of a main release?
Hello all, if you upgraded to fix the previous issue, I introduced a problem which caused the wrong timelapse to be generated. Merged #1348
Please upgrade to the latest release to fix this issue.
@AlaskanAstro Unfortunately, I have a very simple release management process. I generally do not maintain separate feature branches. With a change like this, do generally develop it on a separate branch for the initial integration, but try to quickly merge to dev/main as quickly as possible.
Got, figured it out and followed your simple wiki instructions. Thank you!
Hello, recently got this project running after migrating over from TJ's all sky. I'm currently trying to sort through my issues and the first is that it doesn't seem to be creating timelapses or keograms automatically.
I can however use the Generate page to create a timelapse and keo so the hardware seems capable. Here's a short summary of my circumstances and my guesses what may be up:
Raspi 4b 4GB, ASI678MC, 15s day subs, I live at 63N and night time mode is not triggering at all.
Some guesses from things that have caused issues with other programs:
Again this is a bit confusing because the manual generation does work (even if takes like 1-2 hours to output). Please let me know if any extra logs would be helpful. Really enjoying the program so far.
/home/nina/indi-allsky/misc/support_info.sh: line 61: warning: command substitution: ignored null byte in input #################################
indi-allsky support info
#################################
indi-allsky config (passwords redacted) 2024-06-10 10:14:05,926 [INFO] MainProcess config._dump() [868]: Dumping config
#################################
end support info
#################################