There was a post in the SkyTools Imaging forum a few months ago indicating that he is working on a XML export of a schedule created by SkyTools that could be ingested into sequence automation software such as SGP. Is that something you’re aware of, and if so, is that something that SGP might pick up? It looks like it is slated for SkyTools 4.1, although no release date that I’ve seen so far.
I haven’t read about XML for the upcoming 4.1, only about NINA integration.
According to an official post in the Discord, release date should be next week.
It’s on the SkyTools forum, first thread under “Important Threads” in SkyTools 4 Imaging General Discussion. He had a PDF posted with a first cut at a format for the XML export, but I don’t know if that’s current. It was from April 2023.
Yes, absolutely, SGPro’s existing import system makes import of things like this quite easy for us to implement.
If anyone comes across an export please post it here and we’ll take a look.
As soon as SkyTools 4.1 is out I’ll post an export.
The author has a PDF on his forum that describes the file format, although it doesn’t look like a PDF can be attached here. What’s the best way to get something to you?
Sure. Sorry for the inconvenience. The forum tends to become very expensive if we accumulate a lot of historical attachments. Please email it to firstname.lastname@example.org
Email has been sent. One thing SkyTools’ calculations rely on is being able to schedule start/stop times not only based on target but also based on filters within a given target depending on its altitude among other things. I know SGP doesn’t have start/stop times on a per filter basis (at least not that I’ve seen), but I’ve done it in the past by setting up multiple copies of the same target with just one event in each to implement the per-filter start/stop time.
On one hand my skies are so poor that I don’t know if it makes a difference. And on the other hand, my skies are so poor that maybe I need all the help I can get.
Thank you. Received.
I am releasing the beta of the SkyTools 4 Target Importer now (in SGPro 4.3). A few notes:
- There is an example in the XML spec doc, but I suspect there are variations of the export that are not yet accounted for. If you encounter one, please report a new issue and provide the XML to us. Most issues will be extremely simple to fix.
- The sequencing model present in SkyTools doesn’t exactly match the model used by SGPro, but it’s pretty close. See discrepancies below.
Feel free to test it out.
- Target Start Dates: SkyTools exports a specific date for the sequence. SGPro will ignore this and make a target that starts today and then, for subsequent days, you can choose to either time or altitude lock the target’s start time.
- Target Start Times: The SkyTools export has a notion of start times for both slew actions and individual images. SGPro does not have this distinction and, as such will interpret any encountered start as follows:
- Slew start times: This is mapped to the SGPro target’s start time
- Image start times: If this start time is encountered on the first image after a slew action, it will override any start time found in the slew action. Image start times found in SkyTools images that are NOT the first image are ignored.
- Target End Times: The SkyTools export has a notion of end times for individual images. SGPro does not have this distinction and, as such will search for the most permissive end time for all images in that slew group and use that as the SGPro target’s end time.
- Number of frames to capture: SkyTools supports the notion of “capture infinite frames” as long as an end time is specified. SGPro event’s always have a non-infinite value here.
- Dither every N Frames: SGPro does support this feature, but not as it relates to individual images. You can introduce this functionality into your sequence in the Control Panel’s Auto Guider tab.
Sequence Generator Pro 22.214.171.1243 (BETA) is Released for Test - Releases - Main Sequence Software
I’m not opposed to other translation options of this data, but the import is, as of this moment, pretty standard. See my “discrepancies” list.
That’s great, thanks! SkyTools 4.1 was just released as well so I did try this out this evening. One suggested change and one oddity I saw.
The suggested change is that it appears right now SGP uses the start time of the first filter as the start time for the sequence. I’d suggest that the tag be used as the starting point for the sequence.
The oddity is that I created a fairly simple LRGB schedule in SkyTools with two targets and tried to ingest it. The first target ingested fine - notwithstanding the suggestion above, the start time of the sequence was equal to the start time of the first filter and the end time for the sequence was equal to the latest time. No problem there. For the second target, the starting time was good but the ending time appears to have picked up the ending time of the second filter rather than the fourth. That also happens if that second target is the only one in the file as well. I’ll email a copy of the XML file to you.
It is using the either:
- The time of the slew
- Or the time of the first image (this has priority)
Can you calrify what you mean by “tag”?
I’ll take a look at the end times.
The tag for the slew start time.
Ok, thanks for the new export. I have corrected the end time bug.
So… it is your opinion that, in terms of start time mapping, that individual image start times should be ignored when the slew action carries a start time? I’m ok with either… my decision here was arbitrary and it may depend more on the SkyTools experience anyhow.
My opinion, yes, I would start the sequence with the Slew start time so SGP starts slewing to the target when SkyTools expected it to.
The SkyTools conops is to figure out the optimum time and duration to image through each filter. It has fields where you enter all the overheads of your system like slew time, dithering time, image download time, etc and it accounts for all of that in building its schedule. If you wait to slew until the first filter’s imaging start time then you’re losing those few minutes that it takes for the slew, plate solve, etc. In the grand scheme of things it probably doesn’t really matter a whole lot, you’re talking plus/minus a few minutes. But for the SGP sequence to match the expected SkyTools schedule I think it should start the sequence and the slew at the time SkyTools outputs into that schedule.
Seems reasonable to me. I’ll modify to reflect that.