While testing out my new FLI ML16200 using 3.1.0.170 and the built-in ‘FLI USB Camera’, I noticed what seems to be an intentional 20 second delay when switching between normal and high speed download modes. I don’t know the history or rationale for this inserted delay (I’m sure there’s a well founded reason) but I would like to propose/request either:
expose options for enable/disable of the delay, and/or perhaps control over the duration of the delay
assuming #1 is undesirable due to high hassle factor for relatively small user base (totally understandable), could the delay at least be suppressed for high speed downloads? For AF and plate solve, I’m concerned that the delay will just add unnecessary overhead and waste sky time (particularly if AF is relatively frequent)… for normal frames, the overhead is probably a non-issue.
Other than this request, the FLI USB Camera driver seems to be working great for the ML16200, nice work guys.
Let me clarify that delay for you. That’s there for an important reason in part by my request.
After switching modes, the very next acquired frame may very well have a mixture of data taken during the previous mode and data taken during the current mode. This is due to the buffer not being completely cleared. This behavior can often be seen, for example, when using FLIGrab, which doesn’t have any procedure for accounting for it. What we don’t want to have happen is messing up an important acquisition frame that is taken just after switching from fast to slow download speed!
For example, say you are using SGP’s auto focus routine, which is likely running in fast download mode, and then you want to immediately switch to slow download mode for the next acquisition. Without this flushing and clearing of the buffer, that acquisition will likely contain remaining buffered data from the fast register.
The SGP driver is performing (I now forget the exact details) at the very least a flush and “throw away” download to prevent this mixing of modes from happening. I suspect it’s also performing a flash when that has been selected as well.
My strong recommendation is to leave this alone, don’t add any complex options to it, and just wait for it to happen, otherwise you might end up messing up your first important frame! I hope this explanation makes sense to you.
I see, thanks for the explanation Ben, I understand the motivation for the delay now.
I do wonder, though, if a fixed delay is the best way to ensure that the buffer is cleared before taking the next exposure in the new mode. Perhaps a more direct way of ensuring this would be for SGP to take a throwaway bias frame under the covers before starting the real exposure? Even at normal speed, that would reduce the 20 second delay by half. I don’t know if this would completely solve the problem you’re referring to but I should be able to test this theory out soon, and will update this thread when I do.
No, this is not really a “fixed delay” or a wait. That wouldn’t work as the buffer would just sit there forever with mixed data until something is done to it.
In essence this is already doing a “throw away” frame as you suggest. Hopefully Jared or one of the other developers can respond and tell us exactly what the driver is doing when the mode is changed because I don’t recall now. The flushing could be done with 2x2 binning, and maybe that’s already being done. 20s may be the best we can get here.
Just to wrap this up, I received confirmation this morning from FLI engineering that: 1) a buffer clear is indeed required following a mode switch; and 2) the fastest way to clear the buffer is to take and download/discard a bias frame before the first “real” exposure in the new mode.
I understand that this is unlikely to be a high priority for the SGP devs, so I’m currently working on an ASCOM driver that will implement “fast mode switch”, as well as RBI related functionality. I’ll make this driver available on the FLI yahoo user group once it’s stable enough for release (reach out to me if you have any interest in beta testing it).
So, did you find the current functionality in SGP’s new FLI driver to be unsatisfactory? It seems to me that their mode switching is doing pretty much what FLI recommends. In fact, the SGP driver was developed using my recommendation, which was what I had learned earlier from FLI and an expert.
I welcome your ASCOM driver, however I recommend that you give some serious thought as to how your version will be an improvement over or provide additional functionality to what is already available through Hartmut Bornemann’s ASCOM driver and SGP’s latest driver through their beta release.
I’d appreciate you updating and clarifying me on these points.
I’m satisfied with SGP’s FLI driver with the sole exception of what appears to be the insertion of a fixed 20 second delay between mode switches, which was the basis for the feature request. From SGP logs:
[04/02/19 11:05:13.308][DEBUG] [Camera Thread] FLI Camera invoking new mode stabilization period…
[04/02/19 11:05:33.309][DEBUG] [Camera Thread] FLI Camera new mode stabilization period complete…
As I’ve now confirmed directly with FLI engineering, the fastest way to clear the buffer following a mode switch is to simply take a dummy bias frame before the first frame in the new mode. A fixed delay can also work but it has to be at least as long as the readout duration. I’m guessing that since the readout duration varies from model to model (and mode to mode), 20 seconds was chosen as a “safe” time that should be long enough in all cases (whether this is actually long enough to cover all models is a different question). The extra time that this adds during a sequence for AF and plate solves doesn’t sit well with me, given that there’s a more direct and faster way to accomplish the same thing that only takes as much time as is required for the mode switch and no more.
In any event, you are free to choose the ASCOM drivers you use - that’s the beauty of ASCOM.
