Please use this thread to consolidate traffic on the beta. Thanks!
Thank you for the beta release of the updated FLI driver with RBI mitigation.
Can you please clarify what the code is doing āper cycleā?
Is this a single RBI flash followed by set number of flush cycles? Or is a cycle a flash followed by one flush and then repeated for so many cycles? I hope itās the former case. There should be no need for more than one flash as its duration can be controlled. And then it is recommended to follow with multiple flushes to clear out the register. Thanks for the clarification.
Ben
I tried it in one of my PC, but it closed when the program is being loaded.
The log file is attached.sg_logfile_20181224071531.txt (971 Bytes)
I finally had the chance to test the new beta release. Everything started up fine. It then clouded over, which was good for testing, became Unsafe and SGP ran the end of sequence actions. SGP then immediately threw an error saying āError! Camera TEC is warming up. Cannot start a sequence when the camera is warming up.ā. Which I presume is as it started the sequence again ready to start when conditions would allow as per the new functionality. Obviously when I clicked OK on the error dialog box the sequence was stopped. I donāt have the log file ready for uploading yet, I will add it as soon as possible, but thought I would raise the issue immediately.
Log file: Dropbox - File Deleted
Happy Christmas to you all !
I think you win for āshortest valid SGP log!ā Iāve added some additional exception reporting that will be out in the next Beta to try and capture this.
Easy enough to duplicate. Iāll take a look.
Happy Holidays!
Jared
Would it make sense to keep equipment connected and hold the TEC at temp until dawn?
If youāre using the Restart on Safe then yes, youāll certainly want to keep equipment connected. As for the TEC, youāll want to disable the warm up for now until the issue mentioned above is addressed. Then it should be up to you.
Thanks,
Jared
Jaredā¦can you please reply to this particular question aboveā¦I would also like to be sure on what is happening in the updated driver.
Thanks ā¦ā¦Kinch.
Thanks for the backup, Kinch!
Jared:
Looks like both Kinch and I got confused with the wording in the release notes about the FLI driver updates. There was some ambiguity about whether or not the driver performs just one flash (which is desired) vs. multiple flashes, one per cycle (which is not desired).
Iād like to start using this feature but need to be certain what procedure is being used. Please clarify it for us.
Thank you!
Ben
Hey all,
Just had a bit of a play with the āNotification Centerā feature and I have to admit I do like it, great Idea and very informative.
What I didnāt like was that every time an image completed capture It kept putting up this notification box in the bottom right. I would personally like to some kind of options/settings box in there where you can choose which types of notifications are displayed.
This feature actually did bring up one interesting question though. I set up a quick āSimulatorā sequence in the house today to see what it did. When I ran the sequence it failed and stopped. I dived into the Notification Center to see what happened and there it wasā¦Cant remember the exact terminology it said but it was to the tune of āThe mount was unable to start trackingā. Interesting but nothing to give me a clue as to why !
After a few re-runs and the same result I discovered why the mount could not begin trackingā¦In EQMOD I have limits set to āXā amount of degreeās below the horizon on both directions on the RA axis, this was from a tutorial I saw on the website and seemed like a good insurance policy to do. Today, I picked out M42 as a target as it was the first in my head, into the F & M wizard and I was ready to go. BUT, as it was daytime here, M42 was way below the horizon LOLOL The sequence failed because the āASCOM Simulator mountā hit one of these limits below the horizon on itās way Slewing to M42ā¦What a clot !
Anyway, EQMOD showed/stated that one of these limits was met, is this txt exposed to SGP ?, the message given to me by the āNotification Centerā was great but would be even greater if an EQMOD critical situation like above could also be included.
Have a fantastic new year everyone
Paul
Judging by the notifications at the bottom left side of the SGP window, it certainly looks like the flooding is being repeated with each cycle. I am not aware of a use for multiple floods like this. Please correct me I am mistaken about the FLI driverās behavior.
Unfortunately, if I am correct, this gets in the way of performing multiple flushes following a single flood. Thatās very much something that needs to be done as a single flush does not necessarily clear the register to prepare for the next acquisition. Iāve learned recently that residual charge can remain after a single flush, a kind of back slosh event, and that two or more flushes are recommended.
I recommend that you perform just one flood of variable duration followed by variable number of flushes. If others have requested multiple floods for reasons unknown to me, then I recommend you define that as another option.
I do very much appreciate having the option to perform multiple flushes alone without pre-flooding as that may be of utility for me.
Thank you!
Best Regards,
Ben
I too was using the beta version with updated FLI driver last night and noticed the same. As a trial, I had set the flood / flush to 2 cycles but when I saw what was happening, turned it off again. It was obvious that it initiated two floods but unsure if that was followed by two flushes or just oneā¦it happened so quickly. But agree with Ben: āI recommend that you perform just one flood of variable duration followed by variable number of flushes.ā
I donāt believe that gets ābubbled upā to us. Itās pretty much up to EQMOD at that point to throw us an error and the text and information in that error can vary greatly between mounts. And to be honest if it did have good information Iām not sure if it would make it into the notification. Iād have to double check on that.
Yes, agreed, right now I feel itās a little āchattyā. Having āinfoā things get muted would be beneficial.
Yes, it seems that there is a 1:1 with a Flood/Flush currently. Iām not completely familiar with the RBI flood processā¦so Iāll need some guidance on what is needed here. Is there a need to flood multiple times? Would you ever want to do something like flood - flush - flush : flood - flush - flush or is a single flood and multiple flushes adequate?
Thanks,
Jared
I had a very good session with the restart on safe feature last night. Conditions were patchy, which meant that the sequence ended due to Unsafe on multiple occasions. I have turned off the option to warm the TEC on sequence end, so that issue was avoided and the system sat waiting for Safe to Resume, which it duly did every time very efficiently when the clouds passed. Brilliant!
Eventually the target end time arrived (I only had one target active) and the sequence ended. However, there are still events to run in the active target and I was expecting the sequence to be waiting to resume when the target start time came round again and conditions were safe. However, the sequence has completely ended, is inactive and the sequence window button is on Resume Sequence, waiting for me to press it to do anything. Is that normal behaviour?
I havenāt uploaded a log file as Iām not sure that anything has gone wrong. I just want to understand the expected behaviour when all target end times are passed in a night yet there are still events to be run. Thank you.
Seems that the restart function works great for me 
To make SGP even more automatic would it be possible to have a startup script function to turn on power to gear before SGP connects to them? (this could also be used to turn on gear automatically when conditions are safe so SGP could in theory run by itself for days and turn gear on/off with scripts as conditions change)
My mountĀ“s driver-software does not have any options for limiting tracking to avoid hiting the pier (AP Mach 1), therefore I have to rely on SGP to do it.
Two nights ago my sequence consisted of 2 objects, with 1 1/2 hour delay between them due to some trees in the way.
The mountĀ“s flip was supposed to ocurr sometime during that delay but it did not happen until the second objectĀ“s sequence started and, lucky me, with only about Ā¼ of an inch to spare before hitting the pier.
Am I doing something wrong or it is the way the sequence is supposed to be?
If this is the case then one cannot program that kind of sequence to avoid an accident with the mount.
Is there another place in SGP to set this differently?
Thanks,
Renan
You might want to park between targets, itās under event options
1 Like
Thank you Xplode, did not know that.
Wii try it tonight
Thanks for the response, Jared, and Happy New Year!
I recommend that you set the RBI Mitigation routine to do only a single flood of defined exposure time followed by a defined number of flushes. For example, one might want to have a single 1-sec flash followed by 3 flushes. Or, say, a single 3-sec flash followed by 2 flushes.
I would maintain your options for flood only (again, that would be just one flood) or flush only (allowing for multiple flushes). Those options may be of interest to people running diagnostics or special configurations, so it doesnāt hurt to maintain them.
I am not aware of any need to have multiple sequences of flood and flush cycles as you described. If nobody else has requested such a feature, I would keep it simple and not include it.
I would also like to have an option to turn off the notifications of frames completed. Iāve found that the little windows can obscure the rest of the screen, particularly when taking short exposures. I can see that they could be handy at other times.
Thanks!
Best Regards,
Ben
So Iāve used the vastly improved access to ālogā data in the notifications center to measure how much time is spent between frames. For SGP it is a SIGNIFICANT amount of time spent āsettling the autoguiderā. I set my autoguider settling time to 1 second for a very high RMS (it always meets it except when dithering). If I am not dithering every frame it STILL āsettles the autoguiderā after every frame. For my setup, this ends up being an average of 6 seconds per frame. Thatās the 1 second to settle per the settings and then 5 additional seconds on average āWaiting for the guider to report it is done settling.ā I donāt need this to settling between every frame if Iām only dithering every 3 frames. If i reduce the setting for settling to 0 seconds, or uncheck the box it doesnāt settle at all after a dither and the frame after it is ruined. It would be nice to turn settling off between frames that arenāt dithered. That lost time isnāt significant when the frames are long, but when taking lots of shorter frames it becomes a significant amount of lost sky time. I love all of SGPās other features and would rather not go searching for replacement software but I also donāt want to lose so much sky time if imaging braodband w/ my fast telescope. Iād hope this is an easy enough fix to get into this releaseā¦?