ajobacho You say that +2 in Stellarium is the zone time, but it isn't, it is the TIME.

That "+2" value is actually called the "UTC Offset."

https://en.wikipedia.org/wiki/UTC_offset

However, none of that (UTC, UTC Offset, Local Time, Local Solar Time) is important.

The important number is the Local Sidereal Time, shown as LST in your screenshot.

You can obtain your current LST from a number of places (US Naval Observatory web site, etc). But if you have an iPhone or an iPad, there are many iOS apps at the Apple App Store that will show you the LST by automatically using the time, UTC offset and location of your iOS device. There is no need to worry about DST and all that, the apps all use the iOS system call (NSDate) to get the current UTC.

Check the LST from the app with the LST of your mount and LST of the controlling program. Make all those three instances agree (by changing UTC offset and local time on the mount), and you should have a consistent system clock. Do not change Longitude, since that will cause other problems. Just remember that Local Sidereal Time and Longitude need to be correct -- nothing else matters.

Notice that when the Right Ascension of the target is exactly equal to the Local Sidereal Time, your OTA will be pointing at the Meridian (i.e., the Hour Angle of the mount is zero). This is how the time for Meridian Flips is determined.

I don't know if ZWO's mount has a way to display LST. My mount shows LST in its hand controller.

If ZWO's mount has no means of displaying what it thinks is the Local Sidereal Time, slew the mount until the RA is equal to the LST. A level that is placed on the OTA should show that the OTA is pointed at the Meridian. If it is 15º off from level, the ZWO mount has a problem with recognizing Daylight Saving Time.

In any case, your misery should be over at the end of October (if you are in Europe) or a week later (if you are in the USA). Only to begin again in Spring, unless ZWO starts to use LST as the absolute reference instead of some ficticious local solar time.

Chen

      w7ay You are right, it is the UTC offset, but it isn't the zone time.

        The UTC offset or local time of the mount cannot be changed, or I don't know how do it. The mount take those values from the laptop.

        w7ay
        Thank you for your help.
        I have checked my current LST from localsiderealtime.com and it is the same (aprox) of Stellarium, but the mount has one hour more

        .

          Following this thread - same issue here with Nina trying to perform meridian flip 1 hour ahead of time.
          Tried a couple of ways to sync the mount, with or without DST does not make any difference (as suggested above by w7way - very good explanations there)
          Will look into LST tonight - (not quite sure yet whether Nina reports LST but I know there is a way to see the time before it thinks it will do the meridian - that should be based on LST).
          I ran into https://indilib.org/forum/mounts/11654-zwo-am5-harmonic-drive-mount/85379.html
          That might be or not be related - but it's a similar 1hr discrepancy issue there as well (I don't use EKOS / KStar).

          ASIAir users seem to report that meridian flip happens as expected there - so the AM5 driver in ASIAir seems to be in sync in the whole stack there.

            dmicoud
            Successful AM5 meridian flip with Nina.
            What I did:

            • Slew to a target, start tracking
            • Check the time the target will cross the meridian in Stellarium
            • Check the estimated time until the meridian flip in Nina (Under scope control)

            Both matched

            I did not change anything (left DST as it was, unchecked) nor did a mount sync

                dmicoud
                Yes, DST off works almost always, it is the best solution for now. But if the capture is very long and, by chance, it coincides with the meridian change, NINA will not send the order at time, the mount will stop and flip meridian will fail.

                    Noted and bring back to the team, planned to fix this problem in the next version.

                    A test version is released after the team received your feedback, attached here. Fixed the DST problem.
                    1 Please try this version.
                    2 and set your location in the Stellarium.

                    3 and check if the Lat/Long in the Stellarium and ASCOM is the same.

                    @ASIMount@ZWO#58921

                    zwo-ascom-setup-v65110922exe.zip
                    2MB

                    I don't understand why in Stellarium the UTC time offset must be +1?. I don't live in Paris, I live in Spain and DST is on, so the UTC time offset is +2 (In Stellarium, that number is not time zone, it is offset UTC time). I have checked it, with my location an DST on, and now the coordinates agree. The LST seems agree too.

                    The issue with objects near and under meridian (M2, Haze star, etc) has not fixed.

                    Also we need that the mount doesn't stop just at meridian, 20-30 minutes after meridian is better. I suppose that this problem must be fixed in the firmware, isn't it?

                      ajobacho

                      Yes, DST off works almost always, it is the best solution for now. But if the capture is very long and, by chance, it coincides with the meridian change, NINA will not send the order at time, the mount will stop and flip meridian will fail.

                      This is Nina not AM5 - if Nina is in the middle of an exposure while the flips happens, it won't stop the exposure or do the flip and you might run into issues.
                      One way to be safe is to make sure the amount of time you set in Nina to pause your sequence before meridian flip is longer than your exposure time so you won't run into that problem.
                      When I capture 300s exposures, I set pause before meridian to 8 or 10 min to give Nina ample time to complete an exposure before hitting the flip window.

                          dmicoud
                          Yes, that is the solution, but it is a waste of time. If the captures are of 900 seconds, wich pause is necesary?
                          If the mount could rotate beyond the meridian, it was not necessary a pause and that time could be used to make captures. You can set NINA parameters to do that, with EQ6-R I didn't have any problem, the meridian flip could be performed after past merdian.
                          [https://nighttime-imaging.eu/docs/master/site/advanced/meridianflip/]

                          Although, I think that AM5 can rotate a little more that meridian, but I would like to know how much: two minutes, five minutes...?

                          • w7ay replied to this.

                              ajobacho Also we need that the mount doesn't stop just at meridian, 20-30 minutes after meridian is better. I suppose that this problem must be fixed in the firmware, isn't it?

                              I rectify: I think that 15-20 minutes is enough

                                ajobacho Yes, that is the solution, but it is a waste of time.

                                When I do my own Meridian flips, I pause imaging and guiding just before an exposure would have overlapped a Meridian transit, and immediately execute a GOTO to a target with an hour angle that is just a little past the Meridian. That will (with any German mount) execute a Meridian flip.

                                I then use the "dead time" to recenter the OTA on that virtual target, and refocus the OTA. I then wait (sometimes not even need to wait) for the actual target to also transit past the Meridian, and execute a direct GOTO to it.

                                Very short time to get there with the direct GOTO, and since the Meridian flip has been already been recentered, the new GOTO takes at most one plate solve to refine its position. Basically, the "wasted" time is taken up by the Meridian flip, refocusing, recentering, etc. So, not really wasted.

                                If the program supports scripts, programs could automatically pre-stage itself this way too.

                                I think that 15-20 minutes is enough

                                I agree. If the mount has been star sync'ed (or east-west leveled), you don't need even a minute. All that has to happen is that both the mount and the controlling program agree that the target has transited past Meridian. If everyone agrees to 1 arc second in Right Ascension, the time discrpancy just needs to be 15 seconds long on the wall clock.

                                (Don't forget the "other Meridian" too for circumpolar targets.)

                                When I do use auto meridian flips, I set up my mount to stop 5 minutes (time) before Meridian, and then set it to perform the actual GOTO 5 minutes after transit. That is plenty of time since I make sure that my mount is east-west leveled (my mount has a calibratable index mark).

                                Chen

                                    w7ay When I do my own Meridian flips, I pause imaging and guiding just before an exposure would have overlapped a Meridian transit, and immediately execute a GOTO to a target with an hour angle that is just a little past the Meridian. That will (with any German mount) execute a Meridian flip.

                                    This is not an automatic operation, it needs human intervention. I think that a script to do it can be very complex.
                                    With EQ6-R the operation is extremely simple, automatic and without dead time. Simply because EQ6-R can rotate beyond meridian.

                                      4 days later

                                      @ASIMount@ZWO#58922
                                      The issue with objects near of celestial equator hasn't been fixed. Please, don't forget it.
                                      Thank you.

                                        ajobacho
                                        Thank you for the feedback. Conveyed your feedback to the team, and planned to fix this issue in the next version of ASCOM.

                                          @Software@ZWO#59109
                                          The problem isn't with Stellarium only. When you send coordinates of celestial equator to NINA, the problem is the same.
                                          I''ll attempt that new version.