FLI RBI Mitigation Issues with Beta 3.1.0.316

Sequence Generator
1

Greetings!

Thank you, Ken, for adding lots of additional diagnostic output for the FLI driver in this latest beta version of SGP! I am attaching the log file from the test I just performed. I can confirm that when a delay is requested between frames, it is now properly inserted after a frame is finished downloading and before the RBI mitigation of the next frame.

I had already informed Ken about an issue I was facing with RBI mitigation with the FLI driver, hence his adding all the diagnostics. I’d like to ask other FLI camera users to please test taking frames with RBI flood and flush turned on. The settings are not important. I tested with a 5s flood to be followed by 3 flushes taken with 2x2 binning.

What I am observing both with the progress messages at the bottom of the screen as well as in the log files is that the flushing (register buffer reading / clearing) is occurring in essentially zero time, and in actuality not occurring at all. The messages flash so quickly that you can barely read them, and the log files show no physical time is passing between flushes. I can also tell from the downloaded frames that the buffers are not being cleared after the flash as they should be.

It would be helpful if others could verify whether or not this is happening with their FLI cameras (of various models) and not just mine. Mine is a FLI ML16200.

One possibility could be the request for a zero-time flush confuses the underlying FLI driver or firmware into thinking that no flush is actually being requested, hence it is actually not performed. I wonder if it were to be set to a small but finite value like 0.01s or 0.03s (which to my knowledge is the minimum exposure time for the ML16200) if it would behave normally? This is just a guess on my part.

Interestingly, the very first frame captured after powerup and with RBI mitigation turned on appears to be operating normally. I can see the flush messages appear on the screen for a couple of seconds each, and the downloaded frame appears more normal. However, all subsequent frames have the no-flushing behavior that I’ve described.

Finally, I’d like to add a couple of additional comments to ask the developers to please fix or consider for future development:

  • I notice that the little up/down arrows next to the RBI flush exposure setting on the driver configuration screen don’t work most of the time. I can edit the value in the field, but those little arrows act strangely. The arrows for the number of flushes field seem to work fine. This bug is not a show stopper, but an annoying one that could please use your attention.

  • Would it be possible to expand the options for binning to independent values for vertical and horizontal binning? There are some modes of operation where this would be of value. It appears from the logging that the RBI binning has mixed binning, but my request goes to full user control for all operations of the camera. I would rate this as a low priority need, but one I’d like the developers to please consider for the future.

**sg_logfile_20191019192346.txt (17.7 KB) **

I am happy to help with any testing that you may need during development.

Best Regards,
Ben

2

@BenKolt

I think you attached the wrong logs… that one just shows opening SGPro and no attempt at a sequence frame to invoke RBI mitigation

3

Sorry about that! Here is the one I intended to upload before:

sg_logfile_20191019195138.txt (823.1 KB)

Ben

4

@BenKolt

Well, lots of logging, but no insight. The camera is not returning any kind of error… seems to just be assuming it doesn’t need to read. That may even be camera specific. The FLI docs do not have any mention of a “minimum exposure length”. A couple things:

  • I think the camera driver will write a debug log to the root of your C drive. Something like FLIDBG.txt or similar. It would be a good idea to cross reference one of the flush attempts with those logs… maybe there is insight waiting to be had there.
  • The next beta will accept an override value, in seconds, for the flush exposure length. You can experiment with some custom values here without us having to make a new release each time. When you expand the gear selectors (on the sequencer window), there will be a text field at the bottom titled “Variables”. In that fields paste this:
    fli_camera_flush_exp_length=0.01 or whatever you want to experiment with. The logs will show if this value has been found and used.
5

Ken:

Yes, I found where the FLI driver spews out even more detailed logging. The file is FLI_DEBUG_LOG.txt, which is located in my …\AppData\Local\SequenceGenerator directory.

I can correlate that, with the exception of the first frame, there are errors present for the flushing events. I will attach the latest SGP log file plus this FLI debug file.

The debug file has lots of hexadecimal output, but the lines in question are these:

WARN< 142.613:0D94:11A4>: URB status:0x00000000 ep:82 t:3 l:65024
WARN< 142.613:0D94:11A4>: I/O operation lengths differ, fe00 (desired) != 0003 (actual)
INFO< 142.613:0D94:11A4>: IOR ep:82 len:fe00 : ff ff ff 00 00 00 00 00 00 00 00 00 00 00 00 00
INFO< 142.613:0D94:11A4>: ret:01 len:0003 dtime:00.000724
FAIL< 142.613:0D94:11A4>: Transfer did not complete…

This is still pretty cryptic, maybe having to do with exposure time, but I really can’t tell. Can you please tell me what are all the inputs that you are required to send to the camera to initiate and flush?

When the next beta update comes, I’ll be sure to test out the exposure time option. Thanks!

Ben

FLI_DEBUG_LOG.txt (628.9 KB)

sg_logfile_20191020211237.txt (119.5 KB)

6

Just FYI, new beta is out