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)




Have you gotten any word back from FLI? Have they loaned you a test camera so that you can develop a dedicated ASCOM driver? I’m sure looking forward to having full functionality of my FLI camera through SGP.

Best Regards,


Same here. With any luck my 16200 should be arriving early next week :slight_smile:


Hope the camera works out well for you. I’m looking forward to seeing your images.


Congrats on your purchase! I love my ML8300. FLI build quality is top notch. Cooling is deep and stable. And noise levels are considerably better than my ST-8300. You will love yours as well I am sure.


Got the camera and all is working fine so far. Haven’t had a chance to image but should get some decent wx later this week. So nice to have a camera again, will definitely be getting another of some sort as a backup.


I know this is hammering on a flush nail, but I’ve discovered some interesting differences between Hartmut’s FLI ascom FLI driver and the SGP FLI driver.

I was rather disappointed when my sensor had a section halfway down to about 2/3’s down with diagonal banding. No other defects. FLI could not see this noise when they had my camera for shutter repair. I thought it was electrical noise related to somewhere in my hardware and went so far as to isolate date and power cables and added ferrite cores. The problem persisted.

I have only ever used SGP with my FLI camera, but I’ve recently started using Hartmut’s ascom driver, and the problem went away.

Fits downloads


SGP Driver

ASCOM driver



That’s a sweet set up, General. I can’t tell from the picture - what is your scope?

I’ve got a Tak FSQ-106EDX4 with the NiteCrawler. You’ve got something bigger there, but I can’t identify it.



Homer, that’s very interesting!

Are you showing individual bias frames here? Does the diagonal pattern always look the same or does it shift around?

I do not see this kind of diagonal banding with the SGP driver. Rather, there are issues with Hartmut’s driver that show up when you examine a master bias. It’s been several months now, so I have forgotten several of the details, but I believe the issues are not as apparent with individual bias or dark frames.

Can you post a master bias produced by Hartmut’s ASCOM driver? Thanks.

Best Regards,


Hi Ken,

Its a TAK 150B. I still haven’t been able to do any serious imaging with it yet but I did do about 1/2 hr on the Wizard just to see how things look. I have some distorted stars in the corners which I am attributing to the soacing between the 67 Flattener and the camera. I will be tackling that issue in the next few days. But so far the integration with SGP and the FLI 16200 has been absolutely painless - heres hoping it continues that way!! :slight_smile: