SGPro 3.1.0.153 Beta Discussion


#1

Please use this thread to consolidate traffic on the beta. Thanks!


#3

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


#4

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)


#5

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: https://www.dropbox.com/s/8t4v40hhtvr4b23/sg_logfile_20181224170054.txt?dl=0

Happy Christmas to you all !


#6

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


#7

Would it make sense to keep equipment connected and hold the TEC at temp until dawn?


#8

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


#9

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.


#10

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


#11

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


#12

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


#13

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.”


#14

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


#15

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.


#16

Seems that the restart function works great for me :slight_smile:
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)


#17

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


#18

You might want to park between targets, it’s under event options


#19

Thank you Xplode, did not know that.

Wii try it tonight


#20

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


#21

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…?


www.mainsequencesoftware.com