FLI16200 Updates?



Is SGP doing anything to update the FLI driver (RBI pre-flash / Bias working at “0” exp time)?


Not at the moment. FLI was planning on releasing an ASCOM driver that supported this better. I’m not sure where that’s at.



As far as I know the ASCOM initiative is stalled and in Limbo. Do you guys (FLI/SGP) ever consult and try to come up with a plan to improve the native driver? Can’t understand why FLI wouldn’t treat that as a priority seeing the ever increasing popularity of SGP to the imaging world.


Yes, we actually talked at NEAIC back in late April about exactly this and it sounded like they were well on their way to getting the ASCOM driver out. Last we heard they were needing some testers for it. May want to reach out and ask them about being a tester if you’d like it now.




I have not received word back from FLI about their ASCOM driver development and assume that it may be some time if and when they release one. Given this, it would be very beneficial for us who wish to use SGP with the FLI ML16200 (and any of their other cameras) if you could update your existing FLI USB driver.

I have been using your FLI USB driver for quite some time and have made studies of its behavior in comparison with both FLIGrab (FLI’s own capture program) as well as MaxIm DL, which uses a plug-in driver developed by FLI. From what I can tell your SGP driver works well with no issues other than the following:

(1) No RBI flood control. The options section of your driver shows this capability used to be there, but now it’s greyed out. I’ve determined that there is pre-flash occurring when switching between download speeds, but otherwise there’s no control over pre-flash. I wish to elaborate on this point below.

(2) Interpretation of 0 duration time (such as using for bias frames) seems to just give back frames with 0 level data. This is not a show-stopper, but it would be nice to have this behave in similar manner to other cameras and interpret 0 as the minimum exposure limit.

There seems to be some consensus built that RBI is not an issue with the ML16200. This may be true of RBI itself, but there are other issues that may be present that require or at least benefit from pre-flushing the chip prior to exposure. For example, pre-flashing may provide a more consistent loading of trapped charges that makes calibration easier. In order to test this properly, it would be good to have the ability to operate the pre-flash options again. This would require turning the feature on and off, setting the number and duration of flashes.

The flashing that occurs when switching download speeds is still a good step and in my opinion need not be changed with perhaps the option to turn it on and off. More user control is always better, particularly when one is diagnosing issues.

Please consider updating your driver and I would be happy to test it out for you as well as including comparison with other drivers.

Thank you!

Best Regards,


I would also like to see the SGP FLI native driver be updated to include RBI flood control and have that “0” exposure time allow the camera to actually take a real Bias frame. Would be two very worthwhile additions to this driver.




+1 on the above last two posts. Unsure where this particular driver came from - was it a previous FLI ASCOM driver? I suspect several individuals (myself included) have contacted FLI without getting them moving on an updated ASCOM driver that suits working with SGP. Another query (reminding them of your conversation at NEAIC) from Ken/Jared might work to everyone’s advantage.

Hope you guys can follow up…or if this driver is your own…then perhaps you can give it the time required to make the above suggested changes.

Thanks in advance for any help - either way.


I’d like to see an updated native driver as well. I use the ML8300 and there are a few bugs (including the aforementioned ones). Some times when aborting any type of integration, it will appear to have been aborted in SGP, but the shutter hasn’t closed (i think). I must take a frame a focus image or else I end up with a ghost image of the canceled image on my next integration attempt.

It doesn’t happen all the time, but I’ve just resorted to doing this now for safety’s sake.

I’ll try to remember to replicate the problem and post some logs when the clouds are gone.


I’ll reach out to FLI and see if we can get a test camera again and also see where they’re at with their ASCOM driver.



Thank you, Jared. I appreciate you following up on this.


Thanks Jared.

Following up with ML8300 issues:

The shutter not closing on abort: the image that is canceled seems to not be cancelling. The image will continue until its intended exposure time or until I force a new short exposure… to flush for lack of a better word… the canceled image in progress.

Also, Cool down when camera connects checked, [Cool down to -20c in 5 m] leaves the camera at around 0c at the end of the run. I click set on the cooling panel after that it cools down to -20c no problems.

Sorry for the piggish sequence and log. M27 cannibalized a mosaic as I finished it up. And I’ve kept the sequence going since last night. Still going strong! Testament to .92 stability.

m27.zip (918.9 KB)

Fit is example of canceled image. I think a few seconds in to the initial exposure I canceled. Moved RA to the west then started another Frame and Focus. Shared below (google device download)