SharpCap Forums

Hi,

I'm working with a group of folks preparing for another citizen science experiment for the upcoming 2024 total solar eclipse.

We've decided to use a standard software package to take a sequence of four exposures in rapid succession during totality; in 2017 we used a hardware trigger to define the exposure times. In 2017 we squeezed 8 images of different exposure times into 2.1 seconds with only a few tens of milli-seconds of delay between each frame... we're not aiming for that level in 2024, but would like to repeat the exposure sequence as fast as possible.

I ran some tests with exposure times of 1.3, 0.13, 0.013 and 0.0013 seconds, sequencing through 6 cycles, with an ASI178mm on USB3, full frame... storing 16-bit FITS files to a SSD. I was happy to see that SharpCap was faster than Firecapture, NINA or DMXCapture... taking an average of 3.6 seconds for each cycle.

However, when we tested the script during the recent lunar eclipse (8 Nov), some of the frames seemed to have higher flux values than expected: in particular, the 1.3 millisecond frames, which followed the 1.3 sec exposures, seemed too bright. We're running through more testing now to see if the exposure times remain correct or not.

Does anyone have any experience with taking rapid sequences like this?

Actually I see some intensity jumps in 1.3sec exposures taken without looping and with the four exposure HDR loop.

I wonder if this is the ASI178 camera? Hoping to test with a Player1 camera soon; same IMX 178mono chip.

Line is the mode of the image intensity for 6 1.3sec exposures in a simple loop with constant exposure; the starred line is the mode of the image intensity for 6 1.3sec images that are within the 4 exposure HDR loop. Seems to show some strange jumps between 14000 and 15000 counts. This is at night looking at a defocused wall with room light; thinking that 1.3 sec exposures would average over any light flickering.

Will repeat this test on blue sky tomorrow.

Hi,

one thing immediately jumps to mind on this - when a camera (pretty much any camera brand) is running in live video mode, there may be a number of frames 'in progress' at any one time. That means that, for instance

* The camera is exposing one frame
* The previous frame is currently being transferred to the PC over USB
* The frame before that is being handled by the camera driver/software on the PC
* The frame before that has actually made it to SharpCap and is ready to be shown or saved.

What this means is that when you change the exposure, the results are not always instant - you may have a number of frames come through at the old exposure value before the change takes effect (same for other camera settings like gain). SharpCap has to deal with this itself in the sensor analysis and will wait for up to 5 frames after making a setting change before assuming that the change has taken effect.

If you take the camera out of live mode then the issue will go away, but you will probably also find that the whole thing takes longer as each frame has to be specifically requested from the camera in still mode.

cheers,

Robin

Yes, going into "Still" mode produces much more consistent results. Now seeing about +/- 1.5% intensity fluctuations, which might also be real, using a test setup with a lamp. Will be testing on the solar disk image as soon as we get some clear skies

The loop time seems to be very good, at about 3.5 seconds. Have switched to the Player1 camera with the mono 178 chip.

Going back into "Live Video" mode and trying to run the script with the Player1 camera results in very strange intensities.

Certainly have more testing to do, but thank-you for the suggestion. I'm working on a script for a practice observing run that we will be doing in Australia in April 2023 for the solar eclipse there.

Is there a command to put the camera into "Still" mode from a script?

Hi,

glad to hear that the still mode idea gave improvements. You can certainly get SharpCap into still mode from a python script
Sometimes you may find it easier to use SharpCap's sequencing functionality to execute complex actions rather than write it all in Python scripting. If you can get the sequencer to do something that you want, save it to a sequence (scs) file, then you can use
to run the sequence from your python script.

You can go the other way as well (run python from the sequencer). I have no idea what would happen if you try to run python from the sequencer that is being run from python... bad things, probably!

cheers,

Robin