RBI flood for FLI camera

I have a FLI PL 3200. It’s a front illuminated camera and has a pretty strong RBI. FLI cameras have a capturing mode (RBI flood) that floods the sensor before taking the image. Is there any way to enable that from SGPro?

Thanks
MarkS

If I’m understanding this correctly that would mean we would have to take 2 images. 1 for the flood (which would be discarded) and another of the actual frame.

I can’t really find much on the exposure length for the flood. If I understand what’s happening it has an IR lamp which will turn on and effectively “wipe” the CCD removing any ghosting. However I’m unsure how long this exposure needs to go for.

So, yes, it’s likely possible to add this. However since we don’t have an FLI camera that supports this handy for testing it may be a little problematic.

I’ll do some more research and see what I can come up with.

Thanks,
Jared

I don’t know about the FLI cameras but the ASCOM driver for the Apogee cameras has an option to do the RBI flood at the start of each image. The start of the image acquisition is delayed for about 0.5 seconds while this is done.

The option to enable this is in the setup dialog so once it’s set every image will have this.

Was this feature ever added? I have a Proline 16803, and I like to use the RBI flood feature. The camera has the option to read out at either 1MHz or 8MHz, and either mode can use RBI flooding. I don’t see an option to set the readout speed of the camera, or to turn RBI flood on/off for different sequence events (for instance, turning it on for all saved frames, but turning it off for focus frames or plate solves, and setting the readout mode to 8MHz for focus frames/plate solves, but leaving it at 1MHz for sequence frames).

If those features aren’t available, I suppose this post should be in the “Feature Request” category.

Thanks for your help.

-Josh

I think some of the SBIG cameras allow this too, although I have not found that I have needed it.

Neither of these are implemented in our FLI driver. There are a couple issue we have to hurdle:

  • We don’t have an FLI camera for testing (unless we request it from FLI… a fairly lengthy process)
  • None of the developer documentation makes any note of conducting RBI flood or adjusting readout speed (it is about 10 years old though)

I have emailed Jim at FLI to see if he has any advice. We will keep you posted.

The ASCOM driver doesn’t have an option to control RBI flood.

What I did in the Apogee driver was to put this in the setup dialog, if set all exposures are started with a RBI flood.

Chris

1 Like

Thanks Ken and Chris.

The folks at FLI are always very responsive to my inquiries. Let me know what Jim has to say. If it comes down to needing an FLI camera to do some tests, I would be surprised if they wouldn’t send you one. If it turns out that they won’t and that is the limiting factor, let me know. Maybe we can work something out.

1 Like

@jbalsam

Yes, they have always hooked us up with loaners in the past, just takes time with all the shipping (and sometimes the loaners are not available so we have to wait on others).

Anyhow… I heard back from Jim and he has explained how to conduct RBI flushing and adjust readout speed. It seems reasonable (in terms of complexity). It would probably be faster for me to send you untested code with lots of logging if you are willing to play that game (don’t feel bad if you’re not).

He also recommend we implement overscan for FLI cameras, so we are looking at that too.

Can you open SGPro, connect to your camera and send me that (very short) log? We print out some data on FLI cameras that I need to take a look at for the 16803.

Thanks,
Ken

On Thu, May 28, 2015 at 9:56 PM, Ken forums@mainsequencesoftware.com wrote:

Ken <http://forum.mainsequencesoftware.com/users/ken>

May 29

@jbalsam http://forum.mainsequencesoftware.com/users/jbalsam
jbalsam:

I would be surprised if they wouldn’t send you one

Yes, they have always hooked us up with loaners in the past, just takes
time with all the shipping (and sometimes the loaners are not available so
we have to wait on others).

Anyhow… I heard back from Jim and he has explained how to conduct RBI
flushing and adjust readout speed. It seems reasonable (in terms of
complexity). It would probably be faster for me to send you untested code
with lots of logging if you are willing to play that game (don’t feel bad
if you’re not).

He also recommend we implement overscan for FLI cameras, so we are looking
at that too.

+1 on that one!!! I’d be more then happy to test that out for you.
… sneaky Jim: I am talking to him fro a few months now if he could add
overscanning to the FLI ASCOM driver/settings screen. I bet he proposed to
you that you should look into that :slight_smile:

Can you open SGPro, connect to your camera and send me that (very short)

I’ll send you the log file when I get home. I’ve never looked for a log file in SGP before. Is logging turned on by default?

I’d be happy to test out any code you want to send me. As far as overscan goes, I know that the FLIGrab software lets you read the overscan area on the CCD, but I’ve never had a reason to use it. My understanding is that it’s most useful for characterizing cameras (e.g. for measuring the read noise independent of other noise sources such as RBI). From mstriebeck’s response it sounds like there are other people who would find it useful though, so I’d be happy to test the functionality.

-Josh

Yes, just go under Help/Open Log Folder

Or

navigate to C:\Users(user)\AppData\Local\SequencGenerator

and the log files will be there.

Several of the Kodak Interline chips (11002, 16070…) can generate
bias-like signals. Unfortunately, they aren’t correcteable with bias or
darks as they depend on ambient temperature… The only way to correct them
is to use overscanning and use the overscan area for a bias-like correction.

 Mark

sg_logfile_20150530082458.txt (17.4 KB)

Here’s the log file. There are two lines in there that state the available camera readout modes (8MHz and 1 MHz). I don’t see anything about RBI flood. It also has the full CCD dimensions (e.g. with overscan) stated and the visible CCD dimensions. Neat.

@Ken
Any insight from the log file I posted?

Yes, thank you. I will try to have a test build out in the next few weeks.

Great, glad to hear it. Thanks for taking the time to work on this feature.

@mstriebeck Would you be able to connect to your FLI camera and post those logs too? I am curious to see the differences in how FLI cameras report on their capabilities. A little contrast would be a great help here. Thanks.

Ken,

No problem - is attached.

Mark

sg_logfile_20150603231036.txt (18.4 KB)

@Ken if it would be helpful, I may be able to do similar log file tests using a few other FLI cameras (a microline 8300, another microline 694, and a proline 29050). If that would be helpful, let me know. If it would just be redundant, I won’t bother.