FLI Driver Issue

General:

Thanks for posting the picture. Are you certain this is really a shutter issue? Do these trails persist at fast download speed with any exposure time including longer ones, or just shorter ones? I had trails similar to this at fast download with a previous ML16200 camera, but that was not a shutter issue. They appeared at any exposure time, and mine were worse when a bright star was positioned close to a certain dead column that ran down the middle of my FOV. When a bright star was positioned further away, the trail was less prominent. The other interesting thing was that my trails were not exactly straight but danced around a little - looked like tadpoles. Your trails are (I think) oriented along the read direction of the columns.

I sure had my share of problems with the previous camera, but I’m happy to not have those problems with the current one and let you guys have your turn.

Ben

Hi Ken,

Thats a good point. I’ll try them out at longer exposures. From what I remember you are correct in that they are always N/S in orientation.

If you guys have these spikes…would you accept that or should I be sending it back to FLI? I’m sure when it comes to reselling this camera it might be an issue to the buyer??

Those trails look as if the camera is starting download before the shutter is closed. They stop when the shutter is fully closed.

A short delay somewhere in the camera low level driver or the ASCOM driver might allow enough time for the mechanical shutter to fully close before the download is started. This isn’t something that SGP should do.

It’s difficult to say if FLI is responsible without knowing who wrote the various bits of code and what the functionality is.

What General is showing is what my star tails/trails look like. Orientation is always as shown. My long exposure images at 2mhz show no evidence of this problem.

General:

I would engage with FLI on this. I recommend that you run some cases through FLIGrab to see if you can capture the star trails there. I think you can switch download speeds with FLIGrab. The reason to use this software is that FLI will have better confidence in the results.

Ben

Will do. I was hopeful that those trails would disappear with this new shutter…so maybe it is something in the ASCOM driver? Is everyone using Harmuts driver for their ML16200??

I am using the SGP provided driver (FLI USB Camera). I also see the vertical star trails in fast mode. I don’t think they are quite as long as on your images. (Can’t check - camera not connected at present). Like Gunny01 - this has no effect (does not show) on normal images downloaded at 2 mhz.

Okay…seems to be something in the design. Glad it has no effect on things :slight_smile:

Anyone else still surprised that FLI hasn’t come out with a clean, polished driver for its cameras??

I’m a little slow in figuring this one out, but now I’m on board thinking this is indeed a shutter issue. I ran this problem by an expert friend of mine, and he helped me understand what’s probably going on.

The shutter is sticking, slow, or something like that, and in fast download speed there is enough lag that the shutter remains partially open at the beginning of the readout. This means bright star signal is still illuminating the sensor, and this will appear as a streak along the column as the data is moved along during the read. This is now my understanding of what’s probably going on. In slow mode this issue is not as apparent. And it’s possible that any sticking is occurring just prior to read in the slow mode and there may even be no streaking at all. Take a real close look at slow download frames and see if you have any trails at all or maybe really short ones.

You are all seeing different line lengths simply because each shutter has a slightly different performance issue on closing, sticking, or whatever else the physical problem is. One thing is that it could be those little springs. When the shutter closes they are at their weakest position towards the end of the close.

It sounds like it’s happening with the SGP and the ASCOM driver both, so that probably means this is solely a hardware issue. One last check ought to be done with FLIGrab, particularly when dealing with FLI.

Anyway, it sound like this is not anything that SGP or Hartmut can fix as it appears to be a FLI issue. And you all will need to decide for yourselves if the problem is bad enough to do something about it. I had a similar issue (among several others) and sent my camera in for servicing.

Best Regards,
Ben

Oh, and note to SGP developers: please don’t forget my original reason for posting here was to mention the tendency of your FLI driver to reset itself into fast download mode only!

This has burned several people according to the chatter here. I uploaded my log files capturing the event (look towards the beginning of this thread) and could see exactly what was happening. I almost got hit by this again the other night, but luckily I checked it before running my sequence.

Thank you for your attention to this matter.

Ben

Oh yeah…something I forgot to mention is that these trails did eventually start to show up on brighter stars, although not as pronounced, in Normal (2MHz) mode! I’m guessing they would have continued to get worse over time? Didn’t have a chance to find out though as the shutter fried itself shortly after I started to notice them in my images.

What did Fli do to correct the problem Ben?

As I recall I got new springs. I don’t recall if I got a whole new shutter, but probably not. This was part of a larger service that required replacement of the sensor as well as new electronic boards, and so those changes had more of my attention at the time.

Since this appears to be mostly a mechanical issue that you and the others are facing, I’m guessing that FLI can either instruct you on how to adjust or replace the springs or will want to do it themselves. Contacting FLI about it sounds like the best thing to do right now as a start.

Ben

Thanks Ben.

This was already corrected.

OK, Ken, thanks! I just saw the update. Appreciate the fast response …

Ben