Thank you for the input, Sergio.

For me it also happens without setting a target. I usually start with focusing and then right away PAA from park position which is pointing to the northern pole (well, ideally). So the simulators might not give the full picture here.

What I would like to understand is, if someone else observes the different PAA results when using 3.5.6 (with Meridian flip deactivated) compared to an earlier version. My backup is 3.5.3. I could repeat that there is a difference in the reported resulting error of about 3 minutes between the versions without physically moving the mount. Is this linked to the problem to have to suppress the flip? Or independent of that because the algorithm has been revised for 3. 5.5 or 3.5.6.


Gesendet von meinem STF-L09 mit Tapatalk


I think the Idea was to set the value to delay the Flip beyond the movement needed for the polar alignment to supress that the flip is being triggered. But that would not be a value that is helpful for the actual flip in the end. I could though try to start at another angle so the Meridian would not be crossed.

Seems like the code changed on the way between 3.5.2 and 3.5.6 so the condition set for the flip became relevant. But just for the EQ6R?

And this still not explains the difference of about 3 minutes in the reported pointing accuracy when comparing the two versions.

When your mount is permanently placed, do you have the chance to compare to another software as benchmark? I need to set up the mount for every session.


Gesendet von meinem STF-L09 mit Tapatalk


Hi Bruce,
Thanks for your input. Very helpful to know that I'm not alone. Interestingly you are using the exact same mount.

The problems you are describing with rotating forth and back are exactly the same that I observed. Only when I had a bit more patience yesterday to systematically analyze what is happening I noticed that a Meridian Flip is being reported during PAA. So one of the things I tried was to dectivate what I consider is triggering the Meridian Flip in KStars/Ekos after trying a number of other things.

When deactivating the flip in 3.5.6 the error I see as a result from a PAA run is different about 3' to what it gives me in version 3.5.2. Not so far off but hopefully the development team could confirm if there has been a change which could explain thus and maybe the new version is more accurate.

With the alignment adjustments I did based on 3.5.2 I made some test shots (with 3.5.6) of M31 (knowing well that clouds will stop me) and achieved a total RMS in the guiding of around 0.6" which is the range I usually target for. So the 3.5.2 guidance for the polar alignment of the mount has been surely not too bad. I ran out of time to adjust the mount in line with the 3.5.6 PAA results to be able to compare as clouds rolled in....

Kind regards,



Hi Wolfgang,
Thanks for taking this up. Please find an analyze file attached.

I tried to activate logs and also activated the debugger. But the log directory is empty. I hope the analyze file gives you enough insights. I could download the session file if this help as well.

The current setting of my "Flip if HA>" if activated is 0.27 hours. I don't remember when and why I set it, but in the past PAA used to work ok and still does with Kstars 3.5.2 as I could confirm last night. Relevant with regards to your hint is that the setting is different to 0.

Maybe of interest: Bruce reported in this chain the same problem and he uses a EQ6R as well.
In case it is relevant: I have to slew east due to a roof inhibiting slewing west and use speed 600x. I start PAA in the initial park position. I haven't tried from other positions yet but just confirmed that 3,5,2 still works fine for me with the same settings.

Do you happen to know if the calculation of the PAA error has been refactored which might explain the different results between 3.5.2 and 3.5.6 (with meridian flip being deactivated on the latter)? I saw this entry about a major refactoring of the align section for 3.5.5. Unfortunately I couldn't use PAA in 3.5.5 as I was affected by the FOV bug.
Kind regards,


Dear All,
Just to share about some problems I experienced when using StellarMate to hopefully help to avoid that other might invest as much time I had to (OS v1.6.1+ KStars v3.5.6 & INDI v1.9.3 Stable release).

The problem are the alignment errors reported by the Polar Alignment turned out to be wrong for my setup. It guided me but the results were apparently wrong and following guiding consequently a nightmare. Some days later I had a chance to examine what happened more closely.

Quick Read. Recommendatition is to deactivate the tickbox "Meridian Flip - Flip if HA>" in the mount tab while executing polar alignment for EQMod Mount. At least this seems to cause the problem for me and I could recreate it in tests.

More details:

After having trouble with polar alignment (wrong results) after updating from 3.5.5 to3.5.6 some days ago I downloaded the latest StellarMateOS_1.6.1.img.xz from the website to ensure I got a good base. I have been lazy though and re-imported my settings (from a 3.5.5 install)

I then ran the following tests:

3.5.2 stable
I started with this version to do a polar alignment with a version that worked fine in the past. I mechanically moved alt/az until I achieved a deviation of 0'22"
I made some test exposures and the guiding worked all fine. So the reported deviation of the ideal polar alignment is likely in a realistic corridor.

After this I did not touch the mount, i.e. the results oft the tests below vary only by the KStar versions and software settings

3.5.6 stable:
Polar Alignment made some crazy movements also with the freshly flashed card. The resulting error was calculated by the polar alignment to be 1°48'05'.
This is not realistic and a contradiction to the results reported for the exact same hardware setup by the 3.5.2 version just before. But I found in the status messages and the analyze file that the mount was initiating twice a meridian flip. The images I saw during the procedure were either showing star trails or appear to have been the same for all 3 positions. I could re-create this problem in several runs. I recorded an analyze file, if this is of interest.

3.5.6 stable - deactivated Meridian Flip
Next thing I tried was to deactive Meridian flip in the mount tab (unticked "Meridian Flip - Flip if HA>", I use the EQMod Mount driver for an EQ 6R). I then initiated the polar alignment again.  Now the resulting error was calculated by the polar alignment to be 3'31'.
Much better but still not in line what the v. 3.5.2 reported. Maybe the algorithm had been changed in the meantime?

3.5.6 stable - reactivated Meridian Flip
Now I reactivated the Meridian flip in the mount tab again. I then initiated the polar alignment. The resulting error was calculated by the polar alignment to be 1°'47'48'.

With some more runs I could confirm the behaviour was dependent on the setting of the Meridian Flip (Tick box "Flip if HA>" ) in the mount tab.

I hope this helps others to avoid such problems even I have no real solution but feels more like a workaround. I will for now deactive the Meridian flip when doing polar alignment to be able to use version 3.5.6 with my setup.

It would be great if someone could share if the polar alignment code to determine the alignment error has ben changed from 3.5.2 to 3.5.6 which would explain the deviation of the results.

And maybe the development team might extract an idea what might be the root cause for this behaviour which was not in place for me up to 3.5.4 stable. In 3.5.5 I was affected by the FOV bug that blocked polar alignment completely so I cannot judge on 3.5.5


Kind regards,


Hi Max,

Thanks for your feedback. I had the chance to continue testing today before the clouds rolled in again. Based on your feedback there must have been something odd with my installation or setup.

I could recreate the problems with a freshly flashed 3.5.6 stable (from the Stellarmate repository) BUT I have imported my settings file to not have to start from scratch.

When testing I noticed that while PAA was running the mount triggered a Meridian Flip. That seem to be the symptom of a problem.

Sountermeasure: When I deactivated Meridian Flip in the mount tab (I use the EQMod for an EQ 6R) and run PAA again, the crazy movements stopped and I got a result that was close to reality. Interestingly PAA then worked out even when I re-activated the Merdian flip in the mount tab. Even more interestingly without moving the mount mechanically the result was different at any time (and compared to a backup running 3.5.2). Clouds were stopping me though when I was about to check if I could re-create the PAA results by setting of the Meridian Flip tick box..

I will open a new topic specific for this as this might be of relevance to optimize the code.

Kind regards,



Hi Frederick,

Could you confirm this. After I updated it took about a minute or so until the display of the version number in the Stellarmate dashboard has been updated. It showed me 1.6.0 at first but then switched to 1.6.1 after a bit when I was about to check what went wrong.

Alternatively you could force the update in the Stellarmate terminal window with the following commands:
sudo apt-get update && sudo apt-get -y upgrade

Kind regards,



Polar Alignment is NOT solved with 1.6.1 stable release - at least not for me.

After several week of clouds today I gavethe latest stable version 1.6.1 (KStars 3.5.6) a try. Even the moon was shining I wanted to test the latest stable version after Polar Alignment in the stable release 3.5.5 failed for me with the message "FOV must be 19 arcmins",
Good news; The error message is gone and Polar Alignment starts with this version.
Bad news (really bad): The result of the PA and the resulting guidance is not usable - at least for my setup.

Here is what I did to hopfully help others to aoid such timely analysis
I updated via command from 3.5.5 stable to 3.5.6 stable. Confirmed today that all packages are up to date and started a test.
Started polar alignment with 3.5.6 stable - and have been surprisingly off in the first run. Though I have to set up my gear every time, I use marks on the floor and my offset is usally way below 1 degree. Now it almost reached 2 degrees. Corrected what I thought is the polar error down to 6'32"and started guiding.
Using the same settings that turned out fine with the 3.5.5 for the guiding now it was worse than ever. Calibration looked strange and usually my RMS" is below 1,  now around 8! So I stopped after the first image.

I decided to try to compare the exact same status of the hardware setup but now using a backup copyof the 3.5.6 Beta (Build 2021-10-06T08:29:02Z).
So no change on the orientation of the mount, just exchanging the SD card brought me from a display of the polar error of 6'32" (with the stable 3.5.6) to 2°5'45" (with the 3.5.6 Beta). Now which version to trust?

Result: Polar Alignment with the latest stable release does not seem to work for me (EQ6-R, EQ Mod Driver)
Visual problem: Using the 3.5.6 stable release I noticed that the setting to return to park (which is my default) in this release does something odd: It takes a picture, rotates by 30 degrees, returns to park position and then starts for the second rotation. Not sure if in the second rotation it does 30 again or 60. On the screen I see always the same image and in between images with startrails when the mount was moving. Not sure if this is the root cause for the wrong results but it just doesn't look right.
The 3.5.6 beta instead rotates in two steps as expected.
I then used the 3.5.6 beta (which for me caused a lot of connection losses with VNC) to redo Polar Alignment. Finally I managed to get it done when the connection was stable enough.
Then I booted again with the 3.5.6 stable (which was rock solid with regards to VNC) and voilá when guiding the same target as earlier that night the RMS" is below 1 again. So it is apparent that the calculated Polar Alignment of the 3.5.6 Beta was right.

That leaves we with a 3.5.6 stable release where I cannot rely on the polar alignment. Just after the problem I had with the 3.5. stable. Another problem I found has been the linear focuser in 3.5.6 stable that drove my motor focuser permamently in one direction claiming the RMS value becomes better though the number of stars dropped and the images apparently became worse. Stopped two attempts after 8 itearation and choose an alternative allgorithm.

I just planned to do a test today and it ended with several hours spend to find more questions than answers. Both the 3.5.5. and 3.5.6 stable releases broke things that I ticked to work fine for me before. Even I really love the integrated concept and the idea of Stellarnate to run all this on a Raspberry Pi two stable versions in a row that show massive problems make me think if this time for the system itself is well invested. The number of clear nights per year is very limited for me anyway.
And no, I did not collect log files but I took screen grabs if someone is interested.

I just downloaded an original image of the 1.6.1 to start fresh in case it has been the sequence of updates that caused these problems. But there is just little hope and clouds roll in...

A bit frustrated for tonight...

Kind regards,



Hi Jasem,

My logging is set to verbosity "Regular", the log directory which is linked in the logging dialogue is empty. The files that I attached have been fetched from kstars->guidelogs and kstars->analyze. I used the internal guiding, so the guidelogs are not based on PHD2. I hope this helps.

If other logs would be better to analyze if this is a general issue I might need to change the settings for a future session (advice what to active would be great). If there is another log file on this machine that might have been active outside the kstars directory I would need directions as I'm not familiar with the OS.




Hi Wolfgang,

Thank you for taking the time to look at the logs.

Attached the guidelogs and analyze files sorted in two folders: One ("OK") the session with successful automated flip earlier the same day. The second folder has the data of the session where after the automated flip the  guiding was not resumed.

Kind regards,


File Attachment:

File Name:
File Size: 207 KB


Hi All,

I bumped into a new problem last night. (Second night for me with the new version Kstars Stable release 3.5.5 and Stellarmate 1.60 on a Raspberry Pi  ).

I ran a job of  150 exposures and after 89 exposures it triggered the automatic meridian flip but did not resume guiding thereafter though the exposures continued.

According to the analyzer (see attached screen) slew and alignment were successful after the flip and the exposures were continued but the guiding did not resume. The graph does not even show an attempt to start guiding. And looking at the images taken after the flip the guiding was in fact off.

Did the logic of the scheduler change here in the new version? I used the scheduler for the session but did not select any of the steps like focus guiding etc at the left hand side of the screen as I followed these steps manually before starting the job to monitor what happens. I used to do it like this before but so far guiding always restarted after meridian flip and in case the resume of the guiding failed it did not resume the exposures and aborted the job.

Now it looks that there was no attempt to start the guiding but still the exposures have been resumed. The job continued to the end, mount was parked. So somewhat all good except guiding was off.

Earlier the same evening in another session I took some exposures without the scheduler to test another optic on a different object. This included a meridian flip and the guiding resumed with no problem.

Any new parameters that would have to be set in the new version when using the scheduler or was this just a glitch?




Hi Mohamed,

Thanks, I was hoping there is a way to patch or work around this for the time being. Last night was clear but the problem is still there and I stopped attempts to reboot or influence the USB connections order after some attempts.

Ok, wait and see and try to manage the polar alignment for the time being with an older version and flip SD cards in between as the latest version seems more stable otherwise ...