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 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.
Sure. I would be helpful. For readout speed, you can use the download above. Still working on RBI mitigation. Appreciate it.
@jbalsam Actually, not sure where the link went, you can find the readout speed test build here:
https://dl.dropboxusercontent.com/u/24325878/SGPro_FLI_ReadoutSpeed2.zip
@Ken - Couple of items -
First, thanks again for working on this for us FLI users. I really appreciate your taking the time to help this small population of your user group.
- Normal Speed seems to apply to “frame and focus” images. These images should use High Speed if possible.
- If I change the settings for one of the readout modes and click “Take One” in the frame and focus module while the Sequence window is still open, the exposure doesn’t work correctly - it takes a long time for the shutter to click open (as if it were doing RBI flushes).
- It looks like, from a first glance, you’ve implemented the RBI flush protocol. I’ll be able to test that better in a few hours, but can you verify what the RBI Mitigation checkbox is doing? I assume it’s taking and flushing a few RBI images using the “Normal Speed” readout mode. Is that accurate?
Thanks again for your help.
I’m not sue if this is true. @mstriebeck has shown that this feature almost works as expected. Did you follow the instructions I sent on the PM? Is your “Fast download speed” option in the camera tab checked?
This is probably because you are not using high speed readout (above). Since your camera boots up in “fast mode” and you are using “normal speed” for FF, it takes about 20 seconds to switch from fast to normal.
I have done no work for RBI except implement a radio button that does nothing.
Thanks @Ken. You’re right - I hadn’t followed your original instructions and checked the high speed download box. The time lag that that I had associated with the RBI flush process happening was the lag you mentioned when switching readout modes. I had never noticed that lag before (I don’t switch between modes very often), but I validated that it’s also present in the other imaging software that I use.
Your instructions said to take a few frame and focus frames and a few light frames. Is there a way to take light frames without running a sequence?
Kind of. As you have discovered yourself, unchecking the “Highspeed download” option will put you camera back in “normal readout mode” (so long as your FLI options distinguish between the 2). So…
- Check high speed in the camera panel and take images with FF (should notice very little delay)
- Uncheck high speed in the camera panel, take images with FF (should notice ~20 sec for the mode switch)
- Check it again to put the camera back in high speed mode (there is no delay going from normal to high… just high to normal)
Greetings!
I found this 2.5 year old thread and wanted to follow up about the current status of applying RBI pre-flash to FLI ML16200 cameras in SGP. I can tell that when I switch between fast and slow download modes there’s a delay during which I assume there is a pre-flash. Is this correct?
What I would really like to have is the ability to do a pre-flash between acquisition flats, perhaps as a selectable checkbox or something like that.
Not having that ability at this time, is there a way that I can automate the flash between acquisition frames? I can’t think of one myself.
Thank you.
Best Regards,
Ben
Ben, isn’t your pre-flash controlled by the FLI ascom driver? With my Moravian G3-16200, preflash is built into the driver so it fires before each frame. I don’t actually use it though.
Hi, Joel! Here is a screen capture of the FLI ML16200 driver options as accessed through SGP:
As you can see at the bottom left corner the “RBI Mitigation” option is grayed out. It is set to “off” and I have no ability to turn it “on”. Additionally, I can adjust the flush count setting (I set the high quality flush count to 1), but there is a boldface note that this setting will not affect newer FLI cameras. I can confirm this is the case with my camera, that these settings do nothing.
What I do note is that there appears to be a flush when switching between taking a frame with high speed or low speed downloads. When this happens, there is a long pause that is then followed by the next requested frame. I believe there is a flash going on, however as you see I have no control over this.
Can the “RBI Mitigation” setting please be activated, and in addition to setting the flush count, can a flush duration setting also be made available?
Thank you for these considerations, and I hope that the changes can be made quickly and easily. I’m happy to help you test out any updates.
Best Regards,
Ben
I believe I am correct in saying that sgp has no control over this. FLI will have to enable that setting in the ascom driver in order for sgp to use it.
Personally I question whether preflash is a good thing anyway, especially if you aren’t deep cooling (colder than - 30c).
Whether or not using preflash is a good thing is actually the question I wish to answer and would prefer to use SGP for that study. There are several active discussions going on about this very point. Others state that RBI has benefit even under more modest cooling.
Who developed this dialogue window that I posted? Was that created by somebody at FLI or Main Sequence Software? I note it was developed using FLI’s SDK version 1.104. Looking at FLI’s documentation I see several functions in the library that involve preflash or “continuous flashing”. I’d like to know if this functionality is truly available for this camera. If so, perhaps it could be “exposed” through SGP.
Thanks!
Ben
I was wrong. I believe that the dialogue you posted was created by SGP because SGP has native control of the FLI camera, not through the FLI Ascom driver.
Jared or Ken will have to weigh in on this now because I’m not sure if SGP has access to “RBI Mitigation”.
As for the benefits of RBI vs not, I’m sure that will be somewhat dependent on the particular camera. Where I have come out is that the benefits of dithering far outweigh the benefits of deep cooling and not dithering with RBI preflash. Or maybe I’m just too lazy to bother with it…
@BenKolt Yes, the UI exists for this feature, but we have never found time to implement for FLI. In general, we are averse to touching the FLI driver because we have no way to test the changes (I know we have volunteers, but this is a very time intensive way to develop). SO… Unfortunately, we do not have FLI gear, there is no FLI sim and getting a loaner from FLI takes a long while and we can only keep it for a week or so.
That said, we will try to get to this.
Ken,
I very much appreciate your efforts on this. I know there is much controversy and no small amount of confusion among us enthusiasts about RBI, but having this capability in SGP could be very helpful in coming to better conclusions on the matter.
My offer still stands to help as I can.
Best Regards,
Ben