ajobacho Stellarium has the time and coordinates correct, the mount and NINA has the coordinates wrong.
Mounts will stop tracking when they have reached the Meridian Limit. In the case of the AM5, I surmise that the Meridian Limit is today fixed at the Meridian itself.
After a target has transited the Meridian (i.e., when Local Sidereal Time minus Right Ascension has turned into a negative number), a GOTO command that is sent to a German mount will cause the mount to perform a Meridian Flip. I.e., a German mount will perform a Meridian flip upon receiving a GOTO command when the mount discovers that the target and the OTA are on the same side side of the pier.
If your mount has stopped, that means that the mount thinks that it has reached the Meridian Limit (in this case, the Meridian itself). This is based on the Local Sidereal Time of the clock that is in the Mount.
If the mount does not autonomously flip when it hits the meridian limit, then it is up to the controlling program to issue a GOTO (to the same target coordinates), after the mount has reach its Meridian Limit,
There are a couple of reasons for a Meridian flip to not happen.
One reason is that the computer program is assuming that the mount is autonomously flipping once it reaches the Meridian Limit. Some mounts' Meridian treatment allows you to set it to autonomously flipping. The AM5 does not do that (at least today, as far as I can tell -- I do not have an AM5 to check). For these mounts, the computer program is responsible to send a GOTO command to the mount. Check for that GOTO command in your log -- no GOTO, no flip for the AM5.
Another reason for not flipping is that the Local Sidereal Time (LST) clock in the computer program is different from the LST clock in the mount. Confusion with Daylight Saving Time is the usual culprit for this. That is why it is important to check if the two LST are the same. If there is a 1 hour delay in the computer program's LST clock relative to the mount's LST clock, the GOTO command (thus the flip) will be late by 1 hour.
The stars don't care what the UTC is, what the UTC offset is, what your local time is, what your longitude is, or whether you are observing Daylight Saving Time (DST). The stars only care about Local Sidereal Time. If the Local Sidereal Time is not properly computed based upon UTC, offset, longitude and DST, then there will be problems (we see this in ASIAIR all the time, and that is why mounts that are connected to the ASIAIR need to have DST turned off).
Another possibility is that the mount has not accounted properly to syncing with the stars. This can happen when the mount is not perfectly level. A difference of 1º of east-west leveling can cause a 4 minute (in time) difference between when the mount thinks a target has reached Meridian to when the computer thinks the mount has reached Meridian. If the mount is not accounting for leveling (this is usually done by the mount's model when it is synced to the stars), then you can also experience a delay if the computer program uses plate solves to determine the Transit time of the target. Some mounts allow you to accurately set this parameter so that you can depend just on the mount's index mark (and not require star syncing), see for example the procedure for the RainbowAstro mounts (I don't remember reading of such a procedure in the AM5 manual):
https://www.youtube.com/watch?v=7IC1j8i-1H4
Chen
