I use the “Planning tools” funtion under “Target Settings” and is a really great tool. A couple of weeks back I set up a sequence whereby the first target was M83 and then I was going on to NGC 4603.
I decided to end the M83 sequence just before the meridian flip was due and to get straight onto NGC 4603.
The Planning Tools graphic said that the transit would occur at 10:15pm, so I set the M83 capture to end at 10:13pm. At 10:02:41, having just downloaded the previous frame, SGPro detemined that the next frame would be completed by 10:12:41 so that it should continue, however, it detemined that a meridian flip was required which was initiated at 10:02:42 . I was surprised when I saw the meridian flip underway so I stopped the sequence.
I checked the transit time on both TheSkyX and Stellarium and they both said it was at 22:02. Clearly Stellarium and TheSkyX were using the RA/ Dec coords for M83 from their databases and they were very similar. I checked the RA/Dec cordinates for my M83 target and these were virtually identical to those reported by the two planerarium programs. Therefore the exact positioning of my target is not a factor in the discrepancy.
Clearly since SGPro was receiving the hour angle information from The SkyX, when the need for the meridan flip was checked, it was past the Meridian and the flip was initiated.
This is a DropBox link to the pertinent files.
Included is the SGPro Logfile and a screenshot showing the projected transit time by SGPro versus TheSkyX and Stellarium.
So it appears that there is an issue with the accuracy of the projected transit time in the Planning Tools function.
The discrepancy can result in the sub optimal sequencing of targets as it did for me on this occasion.
Can you please check the information that is being used to determine transit times with a view to resolving the discrepancy.
Thanks & regards, Niall
Niall - I meridian flip can occur before or after the transit, according to your meridian flip settings (both in SGP and in TSX). You do not mention your meridian flip settings in SGP but if you had 10 minute exposures, with settling, you may have just tripped into ‘insufficient time to complete’ and it triggered a MF.
Another interesting point is that SGP used a Slew command to initiate the flip. If the target was not past the meridian this should have failed the flip as the mount should have stayed on the same pier side. However it seems that the flip was actually successful meaning that the scope was indeed across the meridian.
[05/16/21 22:02:52.318][DEBUG][Telescope Thread][SQ;MF;] ASCOM Telescope: attempting pier flip using slew
...
[05/16/21 22:06:37.695][DEBUG][Sequence Thread][SQ;] Meridian Flip successful
Hi Chris, thanks for that. Both TSX and SGP were set to zero degrees past the meridian. The issue was not that the wrong thing happened, it flipped when it should have. The problem was the inaccuracy in the planning tool. I was trying to avoid the flip and to simply change objects before the need to. But since the need to flip was earlier than I planned, reading from the planning tool, the flip was correctly initiated.
The planning tool also gets information from your user profile to determine where you’re at. Might be worth double checking the information in your User profile is accurate. I’ll see if anything else jumps out here as well.
Hi Jared, I checked my user profile and my location details are accurate.
It should be easy to verify for a bunch of objects what SGPro is saying the transit time is versus other sources, as I did.
Niall
Trying to time a meridian flip with one or two minute accuracy is probably not going to work reliably. You said SGPro’s transit time was incorrect – relative to what?
I have three applications that can show the transit time of an object: SGP, Stellarium and TheSky6. I have all three set to the exact same latitude, longitude and altitude of my observatory. Here is the transit time of M83 from each:
SGP → 10:12PM
Stellarium → 22:15
TheSky6 → 22:11
So which is correct?
Also remember that an object transits about 4 minutes earlier each night. So a target setup on Friday will be off by 4 minutes on Saturday.
Thanks Charlie,
As I related in my post, relative to The SkyX and Stellarium. All the transit times I referenced were for the date I was doing the imaging. Yes perhaps only allowing a couple of minutes was timing it too closely, but the estimate for SGPro was 13 minutes different to both The SkyX and Stellarium, which gave the same result. I have the correct latitude and longitude information in all 3 applications. I thought it might have been the RA/ Dec coords I chose for the target, but it was in the middle of the FOV and the RA/ Dec coords corresponded closely with those for M83 in The SkyX and Stellarium.
I think a 5 minute discrepancy is reasonable but not 13 minutes…as you noted that is a difference of 3 days.
Maybe I had something else wrong, as I note that today the difference is not so large,
Niall
Charlie raises a good point. The planning tool has a few small gremlins, one of which is updating from one night to another. If I set up a target one week, setting stop and start times at the limits of the dark period, when I open it up the following week, the daylight warnings do not appear until I touch the stop/start time, and then I have to modify the times until they disappear. It might be (I have not tested it) that there are other aspects of the planner that are not updated when you pull up a sequence on a subsequent day. It is simple enough to check with two screen shots, taken a few days apart.
The other thing to keep in mind is that the various catalogs have different coordinates for the same subject, especially for large galaxies and diffuse nebula. Where is the ‘middle’ of the veil nebula for example?
Hi Chris, I just checked M20 again.
Here are the respective transit times. You can see that TSX and Stellarium agree with each other that it is 1:00AM. SGPro hover tells me that the transit time is 12:48AM, a discrepancy of 12 minutes…the equivalent of 3 days in terms of the Earths travel in its orbit,
Based on your theory that it only gives the transit time for the last date it was opened or from when the Target was first created, I created a new sequence from scratch for M20 with the Framing and Mosaic wizard. It gave exactly the same incorrect transit time of 12:48AM
