add an external sync acquisition / readout mode, particularly for Hamamatsu cmos#1441
add an external sync acquisition / readout mode, particularly for Hamamatsu cmos#1441barentine wants to merge 4 commits into
Conversation
| (stops then) starts exposing a frame every time an | ||
| external hardware trigger is received by the camera. | ||
| Allows timing the camera frames entirely off an external | ||
| clock. |
There was a problem hiding this comment.
A little unclear exactly how this works. Does the exposure start on the rising edge and end on the falling edge? Or end on the next rising edge?
Does the next exposure start on a rising or falling edge?
Looking at the docstrings associated with the changes to the orca class, it seems like it might start the next exposure on the falling edge. If so, that should be documented here. If this is the case, it might also make sense to call this, e.g. MODE_HARDWARE_TRIGGER_CHOPPER or similar, as this is likely to be one of the few/only scenarios where it makes sense to be triggering at twice the trigger frequency (a normal frame clock would typically be as described in the first sentence of this comment).
|
Hi @David-Baddeley , sorry for the delay on this. Exposure starts on a rising edge (depending on what you have the polarity set to) and stops on the next rising edge (when a new exposure starts). So, in the case where you're triggering with a 50% duty cycle chopper, you get one 50% duty cycle laser pulse per frame. |
|
Hmm, what happens to the dead time / readout time - does it do stop, readout, start (i.e. exposure starts with a short delay after edge)? Does this effect initial and subsequent frames differently? |
|
Yeah, this definitely gets into the weeds of the manual a bit! This is covered in the It's a rolling shutter camera, so it starts exposing the top row first, then the next row, etc. til the end. You can use the No difference between the first frame and subsequent frames is mentioned in the manual. That said, the delay between receiving the rising edge and exposing (or stopping and starting exposing) the first row is twice as long in this mode as the delay before starting the first row exposure in the standard edge trigger mode (the delay goes from 3H to 6H, where H is the delay between subsequent rows starting to expose). H changes depending on the readout speed (fast, normal, ultra quiet). This 6H delay between external rising edge and starting the first row exposure is, in my use case with a chopper, relatively moot, because I need to set a larger, user-settable external trigger delay (this PR also adds the method for this) anyway so that I can sync up the phase of my chopper with the part of the frame exposure I want (because the sync-out pulse has no clue where I position my beam). All that's to say, if I had to guess whether there was a difference between the first frame and subsequent frame exposure times, given a perfectly periodic external trigger, I would guess it's 3H or less, and given that the jitter spec is <=1H anyway, my guess is most folks aren't going to worry about it (I toss the first frame of my series anyway). Anyone using these features will of course need to to be spending some time with an oscilloscope to make sure they're synchronizing things at the level they care about. Last thing to mention is that this sort of clobbers the integration time / cycle time we grab from the camera metadata. To get around that, and since I'm setting a pulse length for something in an acquisition protocol, I'm currently grabbing the period of the chopper sync-out from an oscilloscope measurement (Haven't PR'd, because my oscilloscope implementation is currently just grabbing the measured period so it's quite niche). I appreciate you handling my PR's on all these trigger tweaks! It's been super useful for my experiment to be able to e.g. get an output trigger on the last row read out, with some specified delay. |
Addresses issue I needed to synchronize my acquisition with a chopper, and the chopper drive I have doesn't have a phase-locked loop, meaning it has to be the clock for my entire acquisition.
The modifications here allow me to run the camera such that the chopper sync-out edge sets the time barrier between frames (stops then starts the next exposure), and to set an appropriate delay between receiving that trigger and performing that start/stop so I can chop my beam at the appropriate time relative to the (rolling shutter) frame exposure.
Is this a bugfix or an enhancement?
Proposed changes:
SetTriggerDelaymethod, currently just to the HamamatsuOrca classHARDWARE_TRIGGER_SYNC, to denote this acquisition mode with hardware trigger and a trigger to start/stop each frames.Some of these things should likely end up in the base class at some point, potentially as properties w/ setters, e.g. trigger_delay
Checklist:
much simpler if this is kept separate from functional changes. The auto-formatting performed by some editors is particulaly egregious and can lead to files with thousands
of non-functional changes with a few functional changes scattered amoungst them]
If an enhancement (or non-trivial bugfix):