×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

Ongoing Problems with Scheduler and Meridian Flip

  • Posts: 554
  • Thank you received: 138
Looking at your local time of 21:43 I would expect a meridian flip to be possible for M51 at about that time.

However the mount reports that the pier side is already East, looking West. So I don't see why one was needed and indeed the mount reports that the flip failed because the pier side has not changed. It started East and finished East.

Looking at the HA it is -0.443 so it looks as if the mount did the flip early. Is this expected?

I can't see the mount, where was the OTA? On the East or West side of the pier?

Have you set the mount so it does the flip early?
The following user(s) said Thank You: Craig
3 years 9 months ago #55019

Please Log in or Create an account to join the conversation.

  • Posts: 554
  • Thank you received: 138
That looks like the problem, I set the simulator to flip an hour early and it immediately tries to flip, but the flip fails because it's already flipped. It should do nothing.
3 years 9 months ago #55020

Please Log in or Create an account to join the conversation.

  • Posts: 1119
  • Thank you received: 182
The mount was set to flip if HA > 1.5 degrees, so approximately 6 min after passing the meridian. That would have been around 2215 h local time.
I was standing next to it, watching it flip back and forth several times until I finally stopped it, purged Kstars and reinstalled the stable version from April 25. After that it performed flawlessly. That is all contained in the longer log in the Dropbox, which I think is largely uninformative since behavior was normal.
M51 was passing the meridian around 2210 h local time, so about half an hour later than the time point you are mentioning. Plenty of time to align on the Western pier, but it was moving back and forth every time immediately after alignment had finished. In either direction.
The following user(s) said Thank You: Craig
3 years 9 months ago #55021

Please Log in or Create an account to join the conversation.

  • Posts: 1119
  • Thank you received: 182

How do you set it to flip an hour early? I only see the option to flip if HA > x degrees or y hours. I see no option to set the flip at HA < hourly angle.

Please have a look a the videos I provided the link for in my first post of this thread, the first one illustrates the same problem that is persisting.

BTW, I had tested the same installation in the simulator previously and it did NOT show that problem. I let it run through a meridian flip with the same settings and that completed normally. So I am not sure why it would behave differently when connected to a real mount vs a simulated one.

But it happened with 2 different mounts (iOptron and EQMOD) on two different computers (Pi4 and Zotac miniPC, respectively). And when going back to the older stable installation the problem is gone (which is probably also the reason why nobody else is reporting this).
The following user(s) said Thank You: Craig
Last edit: 3 years 9 months ago by Jose Corazon.
3 years 9 months ago #55022

Please Log in or Create an account to join the conversation.

  • Posts: 554
  • Thank you received: 138
I've pushed what should fix this. I was able to reproduce the problem by setting the simulator to flip early and when that happened the problem described happened, the time to flip was reported as -11 hrs or so, the pier side as East and the hour angle as a small negative value.

I've allowed for the early flips, the pier side is still East, the Hour angle negative but the time to flip is now over 12 hrs indicating that the next flip will be in 12 hours which is what is expected. As a result there is no flip attempt.

The code is in the master but will need an overnight build before it will be in the bleeding edge build.

Interestingly this problem and the other problem have different root causes, this one an early pier side change and the other one a failed park and an incorrect pier side report from the mount. The symptoms look similar but that doesn't mean that the same fix is needed.

I still need the slew tests with logs I described in the other thread.

BTW, with a round world when is overnight in the context of builds?
The following user(s) said Thank You: Jose Corazon
3 years 9 months ago #55068

Please Log in or Create an account to join the conversation.

  • Posts: 1119
  • Thank you received: 182


Which Kstars build do you need for the slew logs? You want the logs for the iOptron driver, correct? I am using the CEM60 driver, I assume that is the same as the ieqpro you are requesting. I need to check that when fire up that mount.

Please explain one thing for me, please: How do you set the mount to flip an hour early? Can this be done inadvertently and could I have introduced that problem unknowingly? Where is that setting?
It makes no sense running elaborate tests if the problem is that a simple setting in Ekos is wrong. I want to check that that is not the case.

Thanks, Jo
3 years 9 months ago #55088

Please Log in or Create an account to join the conversation.

  • Posts: 554
  • Thank you received: 138
The simulator has a flip position setting in the simulator tab of the simulator driver. It's normally the last entry on the simulator tab.
For a real driver there could be many ways. Some mounts can be set the flip early - or late. A mount that started with an hour angle error which was corrected with a sync could cause this, so coud a time zone or DST setting error. Having a different time in the mount and Ekos could have an effect.The 'elaborate' tests have nothing to do with this second problem - and bear in mind that the 30 minutes or so it will take you to run these test is far less than the time it will take me to analyse the results and work out how to implement a solution.

As I said the two problems have diferent causes and need different solutions.
3 years 9 months ago #55091

Please Log in or Create an account to join the conversation.

  • Posts: 1119
  • Thank you received: 182
I just want to make sure that I understand the parameters to the extent my meager cognitive abilities allow.

But thanks for explaining. DST is definitely a possibility, since I did not observe this over winter. I will hint for that setting.

It may affect my iOptron mount, since there I must route the connection to the Pi4 through the handset. And I definitely did NOT change the DST setting there recently.

Thanks for that important pointer!

Jo

PS: will try to get you the logs ASAP, but may be weekend as in Wouter’s case.
3 years 9 months ago #55092

Please Log in or Create an account to join the conversation.

  • Posts: 1119
  • Thank you received: 182
I looked into the time settings being potentially the problem but I don't think this explains the persisting "wrong pierside" alignment problem at least for my Atlas Pro mount.

That mount has not seen a hand controller in over 18 months, it has been solely controlled by Indi and Ekos, and Ekos is set to update time and date on the mount. Also, my mount is in perfect Park position, with the counterweight shaft straight down, no deviation from vertical that I can detect and the DEC axis is also set straight ahead at 0 degrees. I cannot possibly do any better. This is also the position in which polar alignment is started and thus the initial sync position of the mount. So the mount should know exactly where it is when it starts out slewing towards the first target.

Historically, the first slew of the mount to any target has been approximately 2 degrees off. Recently, however, i.e. sometime during the last 3 months or so, this has changed dramatically and now the mount is more than 11 degrees off target after its first slew and before first sync.

To emphasize again, no changes were made to the mount, the park position is exactly the same as it has been for almost 3 years now that I have had that mount, and there have been no updates of any kind to the mount using the hand controller, that has not been connected for the at least 18 months. So whatever changed there must have come from Indi or Ekos.

I am suspecting that as a result of this mismatch in the mount model, the mount ends up on the wrong side of pier when aligning to a target close to the meridian (M51 in my case for the last few nights), pointing West already with more than -30min of HA remaining before it passes the meridian. In other words, the mount thinks it sits a lot further East than it actually does.

The geographical coordinates for longitude and latitude are set correctly (derived from the location database in Kstars by city name anyway, not set by me), so the only explanation I can see is that the mount receives the wrong time upon which it bases where it thinks the meridian is and points to accordingly.

Local sidereal time in the EQMOD control panel is calculated correctly, however, but I am wondering whether the mount may be basing its HA calculation on [(Greenwich Sidereal Time) - (Time Zone)] instead of [(Greenwich Sidereal Time) - (Longitude W)]. It is too far off target for this to be explained by bad initial positioning of the mount, especially since the mount is sync'd during polar alignment. It seems to me that the mount must be receiving the wrong instructions for performing its initial slew to target.

The problem may not be apparent to observers with locations close to full multiples of 15 degrees (like Chris and Jasem), but for someone like me, who is sitting right in the middle between 90 and 105 degrees West the deviations in alignment and thus the propensity of the mount to collide with the tripod becomes very apparent.

Does this make sense or am I completely off base here?

Jo

PS: Here the relevant log parts:

File Attachment:

File Name: AtlasLogM51662020.txt
File Size:729 KB
Last edit: 3 years 9 months ago by Jose Corazon.
3 years 9 months ago #55199
Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 1208
  • Thank you received: 559
Jo,

re your Atlas Pro change ("used to slew to within 2 degrees, and now it's 11 degrees off"):

This happens to me from time to time, especially after system crashes, as I often run with new software.
Whenever the mount seems off like that I run through this procedure: stellarmate.com/support/faq/mounts.html?view=faq&faqid=33
which is, in summary: (1) Manually put the mount in park position, (2) go to indi control panel → eqmod → site management → park options → purge data
(3) disconnect indi/kstars. (4) power cycle mount, (5) with it still pointing near polaris, restart indi/kstars.

Of course, also make sure that your system clock is correctly showing local (Dallas) time, and that your location (Dallas) is correct in KStars --> Settings --> Startup Wizard,
and also in the Indi Eqmod mount --> Site Management (check the lat/lon).

Make sure also that you can now: unpark, slew somewhere far from park position, then select "Park" and it returns to pointing near Polaris.
If not, repeat the procedure from my

After doing those things, my Atlas Pro has always returned to is old 2-degree slew accuracy.
Hy
The following user(s) said Thank You: Jose Corazon
3 years 9 months ago #55208

Please Log in or Create an account to join the conversation.

  • Posts: 554
  • Thank you received: 138
Your mount alignment problems are nothing to do with the pier side. They are mount alignment problems.

I've had a look at your log. I can see the UTC time being set on the mount, with a difference of -5 hours. Is that correct for Dallas?
There's a solve:
[2020-06-06T21:06:06.505 CDT INFO ][ org.kde.kstars.ekos.align] - "Solution coordinates: RA (18h 53m 12s) DEC ( 88° 35' 17\") Telescope Coordinates: RA (17h 54m 53s) DEC ( 90° 00' 00\")"
What I can see about this is that the mount is at the pole, dec 90 and the solution is only 1.5 degrees away. The Ra differs by an hour, this may be significant and an indication that the time is not set correctly, could be DST.

The mount seems to be doing a polar align.
first solve
[2020-06-06T21:06:29.356 CDT INFO ][ org.kde.kstars.ekos.align] - "Solution coordinates: RA (18h 54m 00s) DEC ( 88° 35' 16\") Telescope Coordinates: RA (17h 55m 08s) DEC ( 90° 00' 00\")"
second solve
[2020-06-06T21:06:56.028 CDT INFO ][ org.kde.kstars.ekos.align] - "Solution coordinates: RA (16h 55m 19s) DEC ( 88° 35' 35\") Telescope Coordinates: RA (15h 59m 23s) DEC ( 90° 00' 00\")"
third solve
[2020-06-06T21:07:22.914 CDT INFO ][ org.kde.kstars.ekos.align] - "Solution coordinates: RA (14h 55m 56s) DEC ( 88° 35' 09\") Telescope Coordinates: RA (14h 02m 39s) DEC ( 90° 00' 00\")"
And the PAA says the mount is 3 arc minutes off.
After what looks like an alignment - why bother? 3 arc minutes is great. The mount parks, then unparks.
Now another PAA process.
First solve
[2020-06-06T21:11:34.829 CDT INFO ][ org.kde.kstars.ekos.align] - "Solution coordinates: RA (18h 55m 27s) DEC ( 88° 32' 24\") Telescope Coordinates: RA (18h 00m 12s) DEC ( 90° 00' 00\")"
Second solve
[2020-06-06T21:12:02.452 CDT INFO ][ org.kde.kstars.ekos.align] - "Solution coordinates: RA (20h 46m 10s) DEC ( 88° 32' 38\") Telescope Coordinates: RA (19h 52m 14s) DEC ( 90° 00' 00\")"
Third solve
[2020-06-06T21:12:30.583 CDT INFO ][ org.kde.kstars.ekos.align] - "Solution coordinates: RA (22h 43m 33s) DEC ( 88° 33' 07\") Telescope Coordinates: RA (21h 50m 44s) DEC ( 90° 00' 00\")"
The PA error is now one arc minute
And another PAA is started
First Solve
[2020-06-06T21:13:33.217 CDT INFO ][ org.kde.kstars.ekos.align] - "Solution coordinates: RA (18h 57m 28s) DEC ( 88° 32' 25\") Telescope Coordinates: RA (18h 02m 13s) DEC ( 90° 00' 00\")"
Second solve
[2020-06-06T21:14:00.148 CDT INFO ][ org.kde.kstars.ekos.align] - "Solution coordinates: RA (16h 59m 26s) DEC ( 88° 32' 25\") Telescope Coordinates: RA (16h 02m 50s) DEC ( 90° 00' 00\")"
third solve
[2020-06-06T21:14:27.361 CDT INFO ][ org.kde.kstars.ekos.align] - "Solution coordinates: RA (15h 02m 59s) DEC ( 88° 32' 40\") Telescope Coordinates: RA (14h 05m 16s) DEC ( 90° 00' 00\")"
PA error still 1 arc minute.
Slew to M51,......... solve:
[2020-06-06T21:26:34.450 CDT INFO ][ org.kde.kstars.ekos.align] - "Solution coordinates: RA (14h 16m 55s) DEC ( 45° 42' 59\") Telescope Coordinates: RA (13h 30m 45s) DEC ( 47° 05' 41\")"
There's a sync and a slew and eventually another align
[2020-06-06T21:33:45.244 CDT INFO ][ org.kde.kstars.ekos.align] - "Solution coordinates: RA (13h 30m 04s) DEC ( 49° 49' 59\") Telescope Coordinates: RA (13h 30m 45s) DEC ( 47° 05' 41\")"
Much closer, another sync, slew and align
[2020-06-06T21:34:12.676 CDT INFO ][ org.kde.kstars.ekos.align] - "Solution coordinates: RA (13h 30m 48s) DEC ( 47° 05' 51\") Telescope Coordinates: RA (13h 30m 47s) DEC ( 47° 05' 41\")"
another go
[2020-06-06T21:34:30.076 CDT INFO ][ org.kde.kstars.ekos.align] - "Solution coordinates: RA (13h 30m 45s) DEC ( 47° 05' 42\") Telescope Coordinates: RA (13h 30m 45s) DEC ( 47° 05' 41\")"
And this is within an arc second!

I see very little to complain about here. And I repeat THIS IS NOTHING TO DO WITH MERIDIAN FLIP.

What I do see is that the initial mount Ra and the solution Ra differ by an hour. When I see that I think of DST setting, especially as it's the beginning of june and you say it started about three months ago, when the clocks changed. One thing to bear in mind is that there is no DST setting in the indi time management so this needs to be handled by changing the offset. I might simply set everything to UTC and forget about time zones, DST etc.
What I'd do is set up the mount, forget about the PAA stuff, your mount started very well polar aligned.
Then unpark and slew to somewhere away from the pole and do a solve. Do this away from the pole so the effect of being close to the pole doesn't affect things. Look at the difference in Ra and dec separately. If this is portable then you should be within a few degrees in dec and a few minutes in Ra. The accuracy will depend on how accurately you have set the mechanical position of your mount. Given that the first polar align error was 3 arc minutes you seems to have something good.

I would also be less fussy, particularly with the polar alignment. Your first polar alignment was already very good, especially for a portable mid range mount.

The mount slewing to the East early could also be a symptom of a time zone error, the mount may think it's 15 degrees East of where it is.
The following user(s) said Thank You: Jose Corazon
3 years 9 months ago #55209

Please Log in or Create an account to join the conversation.

  • Posts: 1119
  • Thank you received: 182
Chris and Hy,

Thank you both! I will try Hy's procedure first tonight, see if that makes a difference. But I suspect Chris is correct, there is somewhere a setting in the mount software that makes the RA differ by one hour. I just can't figure out where!!!

As I wrote, the mount has not seen a handcontroller in 18 months, so I don't know where the DST setting would come from, I do not see it on the EQMOD settings tabs anywhere. Geographical settings are correct within a few miles (they are shown in the log as well, I am not using GPSD, just the general coordinates for the city that are being populated by Kstars). I always update the mount to UTC at the beginning of the evening when I start it up, but it is always already set at that. The LST that shows in the EQMOD settings tab differs from the one I obtain using the Polar Align app on my iPhone (which uses accurate location data, not the city coordinates from the Kstars data base) by a mere 5 seconds, so that does not explain anything. So, for all I can see, the mount should know EXACTLY where it is. It should not be one hour off, if the LST is correct, right? Longitude and Latitude are both correct (within < 2 or 3 arcmin).



I understand that that has nothing to do (anymore) with the meridian flip, Chris fixed that problem and I can confirm that it went away. With the exception of the mount being on the wrong side of pier when it aligned to and started tracking M51, it performed flawlessly.
I know that the alignment was very good to start with, since the mount has been out in the backyard for the last 3 nights and except for it expanding and contracting in the heat and the cooldown at night, it should stay right on the NCP. Yes, 3' is very good, but I always go through the routine of realigning, since I want to get a feel for how much flexure there is in the setup. That was also the reason why I aligned to the West and to the East, ending up with 1' error in both cases. So the error induced by flexure is probably somewhere between 1' and 2 ', which is not too bad, I would say.

So, if someone who is using that same mount could just tell me WHERE the mistake of 1 hr in RA is coming in, I would be very happy. I just can't figure that one out and it is driving me nuts!

Jo


Chris wrote: "The mount slewing to the East early could also be a symptom of a time zone error, the mount may think it's 15 degrees East of where it is. "

Yes, that is what I also wrote. The mount thinks it is a lot further East than it is. But WHY? Where does it get that information from? I mean, yes, this is America, the land of fake news, but the mount still tells me that it knows perfectly well 1) where it is, and 2) what the correct Greenwich time is. So, I have to put that ball back into the court of you Brits. Maybe you messed up the time here??? :) :evil: :P
Last edit: 3 years 9 months ago by Jose Corazon.
3 years 9 months ago #55212
Attachments:

Please Log in or Create an account to join the conversation.

Time to create page: 0.927 seconds