Eclipse Sequence Generator

[joeytrotz]

LK, this is absolutely amazing work and I know is going to make this eclipse much more enjoyable.

But one question - can you explain the Baily's Beads Capture Offset in the Interval settings? And what's your recommendation?

Thanks again for the great work.

[linuxkidd]

can you explain the Baily's Beads Capture Offset in the Interval settings? And what's your recommendation?

Hi joeytrotz,
The intention is to provide a separate collection plan for Baily's Beads ( the few seconds just before and just after totality, where sunlight is peeking through craters on the surface of the moon ).

The +/- seconds times is used to give how long before C2, and after C3 to run the Baily's Collection Plan.

It was suggested to also allow selection of a number of seconds after C2 ( and before C3 ) to allow the Baily's Collection Plan to operate. The idea being, since perfect prediction of the exact moment of totality begin/end very difficult due to the surface irregularities of the moon, the Baily's Beads Collection Plan should run a bit into totality to ensure the event is fully captured. My solution to this, instead of making the UI even more complex, those who want this type of extra collection inside the predicted totality window can instead adjust the C2/C3 times provided to the tool, then extend the Baily's Beads Capture Offset to achieve the desired affect.

For me personally, I'll likely tweak the C2/C3 times inward by 10 seconds each, then use a 30 or 45 second 'Baily's Beads Capture Offset'.

Let me know if this helps.
LK

[linuxkidd]

Hi all,
With the release of SharpCap 4.1.11922, I think the script and SharpCap are now both feature complete for eclipse sequence capture!

Also, in my recent test, I see there's a prefix to each ser file generated by the sequence, so this will completely eliminate the risk of name collision during the eclipse!

THANK YOU, Robin.. so much for your work on making SharpCap even better for this purpose!

Please test and review, and let me know if there's anything I should add/change to make the Eclipse Sequence Generator even better!

Thanks,
LK

[linuxkidd]

I've tweaked things a bit, and added some new features as well.

• Pre eclipse capture occurs at (C1)-60 seconds
• Last 'Partial Collection Plan' kicks off at (C2) - ( Bailys Offset ) - 60 seconds
  Thus, giving a 60 second buffer for the last Partial collection to end, and camera to card write buffers to catch up, ready for Baily's collection to begin.
• A 60 second delay is now added after Post-Totality Baily's collection.
  Thus, Post-Totality 'Partial Collection' begins at (C3) + ( Baily's Offset ) + 60 seconds.
• Post-Totality 'Partial Collection' ends at (C4) - 60 seconds
• A final 'Partial Collection' fires at (C4) + 60 seconds.

 
I've also added:

• a configurable loop delay for Baily's and Totality collection ( look at the header for their respective Collection Plan ).
• All the parameters are dumped into the top of the sequence, along with pseudo code to explain what is going to happen.

 
Please keep the feedback coming!
LK
 
 
Sample params and pseudo code section:

Code: Select all

# Generated by:
# linuxkidd's SharpCap Eclipse Sequencer
# https://linuxkidd.github.io/SharpCap-Eclipse-Sequencer/#partial_begins=12:23:50;partial_ends=15:03:10;full_begins=13:41:13;full_ends=13:45:09;bailysInterval=10;partialInterval=0;partialCount=20;gain=26;offset=75;output=SER%20file%20(*.ser);bailysDelay=0;totalityDelay=0
#
# Generated at:
# Wed Mar 06 2024 15:16:13 GMT-0800 (Pacific Standard Time)
#
#
# (C1) Partial begins: 12:23:50
# (C2) Full begins:    13:41:13
# (C3) Full ends:      13:45:09
# (C4) Partial ends:   15:03:10
#
# bailysInterval: 10
# partialCount: 20
# partialInterval: 0
# gain: 26
# offset: 75
# output: SER file (*.ser)
#
#
# Wait until 12:22:50
# Capture one iteration of 'partialCollection'
#
# Wait until 12:24:50
# Collect 'partialCollection' every 225.65 seconds, until 13:40:03
#
# Wait until 13:41:03
# Collect 'bailysCollection' every 0 seconds, until 13:41:13
#
# Wait until 13:41:13
# Collect 'totalityCollection' every 0 seconds, until 13:45:09
#
# Collect 'bailysCollection' every 0 seconds, until 13:45:19
#
# Wait until 13:46:19
# Collect 'partialCollection' every 227.55 seconds, until 15:02:10
#
# Wait until 15:04:10
# Capture one iteration of 'partialCollection' at 15:04:10
#
#

[linuxkidd]

Lots more tweaks..

The biggest is a shift to using the Browser's in-built "local storage" to store and track changes made to your collection plan and settings!

So now, when you load the page again on the same browser, it'll restore all your prior settings and steps for you to continue tweaking.

LK

[admin]

Hi folks,

glad to see that this is all progressing so well. I thought I would just mention that the latest versions of 4.1 on the downloads page now contain the 'pad timing' step to help support the sequence generation. If there are any other steps that seem to be missing that would be helpful, please let me know ASAP so that I can add them soon!

cheers,

Robin

[admin]

Ah,

one more thing...

Maybe LinuxKidd has already thought of this, but it occured to me that if something goes wrong part way through for some unpredictable reason then you might need to restart the sequence from scratch to continue (after camera glitch, sequence error, SharpCap crash, whatever).

Unless there is another way of doing it then maybe an 'if earlier than XX:XX localtime' step would be helpful - each block could be wrapped in a step like that so that if you re-run part way through then the early blocks of captures will skip entirely.

cheers,

Robin

[linuxkidd]

Ah,

one more thing...

Maybe LinuxKidd has already thought of this, but it occured to me that if something goes wrong part way through for some unpredictable reason then you might need to restart the sequence from scratch to continue (after camera glitch, sequence error, SharpCap crash, whatever).

Unless there is another way of doing it then maybe an 'if earlier than XX:XX localtime' step would be helpful - each block could be wrapped in a step like that so that if you re-run part way through then the early blocks of captures will skip entirely.

cheers,

Robin

Hi Robin,
I think an 'if earlier that localtime' wrapper makes a lot of sense!

My expectation also is that the ' loop until later than localtime' steps would not execute if that local time has passed, but maybe that time check doesn't occur until after the loop is ran through once? 'do .... until X' loop vs a 'while X do .... ' loop?

Thanks, Robin!
LK

[linuxkidd]

Hi Robin, one other question...

Would it be possible to add an optional switch to the 'LOOP UNTIL LATER THAN LOCALTIME' and similar time based instructions... which would apply a strict enforcement?

Right now, if a collection is occurring, but that collection runs past the specified 'LOCALTIME', it'll be allowed to complete. This could cause a collection plan to completely miss baily's beads, for example.

Sample code:

Code: Select all

            GOSUB waitForEclipseStart
            LOOP UNTIL LATER THAN LOCALTIME 13:40:03
                PAD DURATION TO 225.65
                    GOSUB partialCollection
                END PAD DURATION
            END LOOP

            GOSUB waitForBailysOneStart
            TARGETNAME "BailysBeadsPreEclipse"
            PLAY SOUND Alert
            SHOW NOTIFICATION "Remove the Solar Filter!" COLOUR Green DURATION 246
            LOOP UNTIL LATER THAN LOCALTIME 13:41:13
                GOSUB bailysCollection
            END LOOP

WIthout strict enforcement, the 'PAD DURATION' segment will cause a delay of almost 4 minutes - far past the potential start of Baily's beads.

Maybe the command would be:

Code: Select all

            LOOP UNTIL LATER THAN LOCALTIME 13:40:03 STRICT 1

With a default of 0, to preserve the current behavior.

Thanks!
LK

[admin]

Hi,

will it work to combine the normal loops with the 'STOP AT LOCALTIME' step, which does enforce strict (stricter) time limits?

Essentially the 'Stop at localtime' step will do the equivalent of sending a cancel request to the steps running inside it when the appropriate time point arrives. This will try to stop the step currently in progress (some steps support cancellation part way through - usually the long running ones - others do not). As soon as the current step finishes or cancels then sequence execution jumps to the code straight after the 'stop at localtime' step. In general the delay should be fairly short (as in seconds), but not zero.

The downside of this approach is that because it can omit steps, it may leave the system in an unexpected state (still capturing for instance if you use the separate start capture/stop capture steps). This would need to be handled by the code following. On the other hand, any 'strict' loop enforcement would have to use the same basic design of cancelling the stuff inside the loop, so would face the same challenges.

Out of interest, in the fragment above, how long do you expec the 'partialCollection' subroutine to take out of the 225.65s? If the partialCollection is short then something new that signals the pad duration step to snap out of its wait phase might do the trick.

cheers,

Robin