SGP’s FLI driver has surreptitiously reset itself a couple of times now such that it reverts to a setting to only download frames in “High Speed” mode. I use a FLI ML16200. My preference is to set the “Normal Speed” at 2 MHz, which is the slow download mode for acquisition frames, and “High Speed” at 12 MHz, which is the fast download mode for plate solving, frame and focus, etc. Unfortunately, if I do just about any tweak of the driver settings, both high speed and slow speed are set to the 12 MHz speeds. I’m obviously expecting those settings to never change on their own.
Is it possible to make those options robust and not change unless actively done so by the user? As it is now, it is not sufficiently idiot proof, as this idiot has corrupted several nights of imaging data and now a full night of test frames!
This hit me during my last imaging session, and I did not notice until I was just about done that all my acquired frames had been downloaded with fast mode. On my camera, this utilizes an entirely different set of electronics that are by definition not optimized for clean, low read noise data. I ended up with a horribly corrupt background that for a short while left me with the frightful conclusion that my camera was defective and in dire need of repair. Luckily I discovered that it was the driver working against me.
If this description is not sufficient for you to investigate and fix the issue, please let me know and I’ll be happy to explain further and send you snapshots of the settings. Thank you very much!
Interesting post Ben. I was struggling with the last images taken with my FLI 16200 but put it down to high humidity and bad seeing. I was getting so fed up, I even tried going down to 9 minute subs thinking that perhaps, that might help SNR. As it is, I have changed over cameras now and can’t test if perhaps the driver was doing as you suspect. However, I do recall that I was pleasantly surprised that whatever was happening with newer versions of SGP, my image downloads went down to 10 secs - from about 18 secs. Now you have me wondering!
This just an FYI – a developer named Hartmut Bornemann has produced a set of ASCOM drivers for FLI cameras, filterwheels and focusers. I don’t own any FLI products so I can’t do any testing but it might be worth giving them a try:
I’ve captured this error now in a log file an will upload it shortly. I was able to confirm before that the download mode was indeed being reset, and now I see the sequence of events that leads to it.
You are right in that if you can see yourself that the download speed has increased, then you’ve likely encountered this issue. Beyond that you can compare the quality of, say, a dark frame acquired and downloaded fast vs. one downloaded slow. Looking at their respective histograms, they will likely have obviously different offsets and even more apparent you’ll see that the fast download curve is notably wider than the slow download one, meaning higher error.
It looks like this one ought to be fairly easy for the SGP folks to fix …
I captured this issue in a log file. Here is a link to my Dropbox folder:
In the folder I also put a PDF with some screen captures and notes to help understand the sequence of events.
It looks like the problem arises if I access the camera options when the camera is not connected. If I change something like RBI settings and then connect the camera, I see that the download speed options are now blank. Left this way, the driver reports an error and sets the download speed to 0 (fast) by default. I’m not aware this is happening behind the scenes having thought previous settings would have been honored. This only seems to happen if I change settings before connecting the camera. If I only change settings when the camera is connected, then the same settings will persist when I connect to the camera the next time.
One way you may wish to fix this is to prevent the user from making any camera changes at all before connecting. Otherwise, an obvious fix is to enforce that the speed settings are persistent. I understand there may be problems if a user switches cameras with different speed options, but connection of the same camera again ought to honor the previous settings.
Looking at the log files, Line 173 shows the camera reports it has download speed setting -1. This is happening when the options are in their blank state. The options are actually 0 (fast 12MHz) and 1 (slow 2MHz). I then acquire two bias frames. Line 183 and 184 show that an error is reported in that the mode value -1 is wrong, and it defaults to 0 (fast mode). The next two acquisitions are downloaded in fast mode.
I then actively set the modes in the camera options. Line 447 shows the camera now reports mode 1 (slow), Line 457 confirms this again.
I hope this all helps. Thanks for your prompt response to this issue.
Thanks for that update/explanation Ben. The camera is off the scope at present but I should be able to go back and check darks taken before and after I saw the increased download speed. In any case, looking forward for what you put together for Jared & Ken and even more so, to their reply.
As a side issue, I’d like to ask if it would be possible to include more information about the FLI camera settings in the FITS header of acquired files. This information would be a good record to have not just for diagnosing problems but simply in recording and later identifying the camera’s operating conditions for each image taken.
The settings that come to mind, which SGP does not presently record, are: Download speed mode, RBI Mitigation settings including mitigation option (no mitigation, flash + flushes, flushes only, etc.), pre-flash duration, number of flushes, flush binning. This information would be a welcome addition to the FITS header.
It’s been about a year or more ago now, but I helped Hartmut update his FLI ASCOM camera driver. We ran into some issues at the time, but I did manage to get it working with my ML16200.
Soon after SGP updated their driver, and I have been pleased with its performance. This issue that I’ve brought up here is a subtle one, but still I’ve been burned by it a couple of times, so I wanted to bring it to attention to be mitigated.
I particularly thank you for posting these links because the repository I used for Hartmut’s files is now gone.
Just to add to Ben’s comments, this issue has bitten me as well when I found out that dozens of hours of subs I had taken in December 2019 with my FLI ML16200 using SGP version 3.0.3.169 had ended up being downloaded at the 12 MHZ Focus Mode speed rendering them very noisy and in essence unusable as it is impossible to process out the noise. When I first got the camera I set the high speed to 12 MHZ Focus Mode for only focus/platesolve (i.e. temporary frames) and the slower 2MHz speed for actual data subs (non-temporary) taken during a sequence, but unbeknownst to me these settings defaulted back to fast i.e. 12 MHZ Focus Mode for all subs downloaded. Yes, my bad for not noticing earlier that the subs were coming down in 2 seconds instead of 6 or 7 seconds, so I am partially to blame, but it’s all water under the bridge as my main concern is to see the issue remedied going forward so I can trust SGP again. Considering how rare and precious clear, moonless nights are for most of us, I consider this a disaster and implore the SGP development team to address the issue. As was requested it would be nice if SGP generated fits headers that contain the download speed from the FLI camera so the issue can at least be monitored sub by sub. The FLIgrab utility provided by FLI does this in its fits files, so can it be added to the header on a fits file produced by SGP? For now I will look into the FLI ASCOM drivers.
This issue messed up hours of acquisition for me last time I imaged, which was back in November. Given the lousy weather since then I went ahead and processed the data, purposely taking dark frames at fast download speed to compensate. Given how noisy the data was, I was amazed that I could arrive at, well, mediocre results, but certainly nothing to be proud of!
Anyway, moving forward, I want to assure users of the SGP FLI driver that it ought to still work just fine as is, but we need to make sure those download speed settings are defined properly before each acquisition run. I’ve determined the sequence of events that might cause the mode to reset, and it’s simply a matter of being vigilant. I’m sure the SGP developers can come up with an easy fix soon so that it doesn’t happen again.
I didn’t seem to have a problem with the ascom drivers in voyager. I was trying voyager on trial, but I found the gui a bit confusing and had problems with it working on my mount.
BTW, I just got a 16200 from FLI and so far I’m not noticing the problems with downloads that you are. I’m using version 3.03.165. I do have a problem with star tails. I’ll PM you thru CN. I think it may be a shutter problem.
I also get those star trails when using the fast download mode (12 MHz) - and this with a brand new shutter just back from FLI - seems to be inherent to this camera for some of us - as I had the same issue with the previous shutter.
Also, I notice that in SGP there is also an FLI USB camera driver - which of the drivers is the preferred one?
Could you please post an example of these star trails? I like to see what they look like. Are the trails oriented with direction of the iris pieces? Or are they horizontal / vertical only? Do the trails persist with change of driver? Sounds like a mechanical issue, but maybe could be linked to a specific driver issue with when and how the shutter opening is triggered (you never know).
