Sky Safari GOTO limits

Robert Benward

Hi All,
I am in the process of integrating my Onstep with my Losmandy.  So far so good, with a 10:1 planetary &24V, I can achieve a decent 2deg/sec.  I also have it running "goto"s from Sky Safari on my iPad.  This is where I run into the problem.  For some reason I cannot "goto" any object that is below the altitude of the NCP.  It doesn't generate any errors, it just sits there and does nothing.  The target coordinates show up on the status page, but nothing else.  If I hit stop and then select another target, above the altitude of the NCP, it goes there no problem.

I am not sure which settings I need to adjust. 

All from the Smart Webserver;
From the config page:
Horizon and Overhead limits -10deg & +90deg

Under Advanced:
RA  limits -160 min pos & +160 max pos
DEC limits -90 min pos & +90 max pos

How do I read this?  Will this give me plus or minus 160 deg from "up" or my home position?  I think even this is too  much, I probably don't want my RA any lower than 110 from vertical (meridian limits are +/-15).
For the DEC, don't I need more than +90 if I go from the zenith and continue doing down, south of the NCP?

I then set the RA limits to +/-180 and uploaded.  It improved slightly, but I still cant get to anything below a horizontal line that intersects with the NCP.

I checked the wiki and maybe I missed it, but I couldn't find anything that would help.



In SkySafari under Settings/Scope Setup do you have following settings:

Scope Type: Meade LX200 Classic
Mount Type: Equatorial GoTo (German)

Can you try other planetarium app, just to check if the problem is in the controller or in SkySafari?

Robert Benward

Yes. Both of those are set.  I am navigating the entire sky, except for that area under the pole.

Good idea.  I will see what alternate program I can download.


I think I may found what is the problem here.

First of all, you need to check values set in SWS (advanced axis config) because they will took over. To me, it looks like values set by config.h are not applied after re-upload, but the values from SWS are instead. And pay attention that after changing these values in SWS manual restart is required.

And second, it looks to me that these values are not counted for 0 (wedge down) but from most east and most west position. I wanted to set the same limits like I have in EQMOD, but when I set -120 and +120 it effectively only goes 30 degrees east and west, which is equal to 2 hours RA (or 1 hour in clock dial). In order to make RA axis goes from 8-4h (as RA circle is imagined as a clock dial), so I needed to set limits to -210 and +210.

Default values of -180 and 180 would represent 9-3h. Your values -160 and 160 would be something like 10-2h.

Ken Hunter

Bob... Remember that EVERYTHING is SOUTH of the NCP.
You would move to an object "below" the NCP by moving East or West if your limit setup allows.

Robert Benward

Yes, I am aware of that.  But in this case, SkySafari is giving a set of coordinates to Onstep.  It is Onstep's job to move the scope there.  The question is: what are the limits representing?
Remember the message about the "Home" function?
If I want to change that default, I would add a define statement under "sensors":
#define AXIS1_HOME_DEFAULT   90   
#define AXIS2_HOME_DEFAULT   6

  • For a German Equatorial Mount (GEM) the counterweight should be down at |HA| = 6 hours
So there is a mix here in degrees and hour angles.  At 0hours the DEC shaft is horizontal.  So is that where zero starts for the degree limits?  It shows +/-180 as a default, but that would mean that at 0 to -180 the DEC axis would from horizontal, sweeping up, where the shaft and weights are pointing straight up, then back down to horizontal.  So default should look more like 0 and +180, that would make it from horizontal to horizontal (pointing to zenith, then meridian flip, to zenith again.

You show a trigonometric compass rose, for navigation, zero would be up.  But using your reference, +/-160 is a 320deg sweep, so that would be from approx 9:40AM to 8:20PM.  +/-180 would be from 9AM to 9PM.   +210 to -210 is overlapping.  With DEC at the horizontal (pointing at the zenith) HA =0.  So limits might look like 0HA & 12HA.  That would be DEC axis horizontal at both limits/extremes.  If we were talking about hour angles it would make more sense, and we also must differentiate hour angle in the home position(6hr) vs hour angle when the scope is point up (zenith=0hr).

Now, for the update.  It seems to be moving below the NCP.  I did not change anything, I even returned the values to +/-160 and it still goes below the NCP.  Weird.  I reset it (reboot) several times last night, so I know both the +/-180 and +/-160 values were in the program and re-initialize if that is required.

Regardless if it is working now, I am still not quite clear on where the limits are point to.  What does -180 "Minimum position" vs "Maximum position" +180 mean?

On the upside, the Onstep and the new motors are behaving quite well, and the interface between SkySafari and Onsteps seems to be working quite well also.  I think I might be ready to put hte mount back outside and do some full up testing.

Thanks for all your comments and feedback.


In my case it looks like it counts 210 degrees from west most position CW and 210 degrees from east most position CCW which results in 8-16h. Minus/plus sign is just direction indicator and possible range (90-270) makes sense then. These are the data i came to by testing withy mount.
Maybe you didn't setup properly location or something like that.


For instance, if your latitude is zero, then everyone below polaris is basically below horizon. Have you checked what kind of general error is displayed in SWS when it refuzed to work?

Robert Benward

No error is reported.  I went back and checked again, and it seems +/-180 covers the whole sky.  +/-160 does not.  I am just not clear where zero is.  Is that at the Zenith? 

If you use +/-210, that is more than 360 degrees,  That overlaps and I am not sure why you would need to do that, or even if Onstep will accept those numbers.



Nothing is overlapping in my config. I hope this diagram will make it more clear, as this is how I see it. From the comment in config.h, these values can be in range 90..270 and -90..-270:
-270° and 270° would be a full circle (whole dial)
-180° to 180° would be half of a circle (9-3), which is also the default for GEM.
-90° to 90° would exclude any motion of that axis.

The complication is probably here because this same constant is used for both AZ and RA calculation.

Robert Benward

Thanks for your diagram.  Maybe I'm dense, but that doesn't make sense to me.  How can you have two zeros, especially if you invoke HA (hour angles) in your limits definition? 

I stand corrected, I thought the limits could not cover more than 360deg.  The allowable limits do cover more than 360deg, but at +/-270, you are pointed into the ground.  On an equatorial, you can't swing 360 in RA, but I guess on a fork mount you can.  On a fork, you can be at DEC 85deg and swing all around the pole. On an Eq, you'd smash the scope into the tripod and mount.

From what I interpret, the zero in config.h is on the meridian.

#define AXIS1_LIMIT_MIN              -90 //   -180, n. Where n= -90..-270 (degrees.) Minimum "Hour Angle" for Eq modes.
#define AXIS1_LIMIT_MAX               90 //    180, n. Where n=  90.. 270 (degrees.) Maximum "Hour Angle" for Eq modes.    

After doing a lot of reading, this is my understanding:
The hour angle of an object is negative as it approaches the meridian, and positive as you retreat from the meridian.  According to definition, 0HA and 0deg is the meridian.  The smallest figures permitted in config.h do not allow the scope to descend below the horizontal or to cross the meridian.  The largest figures will allow you to point your scope at China (I live in NY).  Ideally, the names should be "Axis_Limit_Neg_HA" or "Axis_Limit_Pos_HA", just as left or right is not a min or a max value.  The second diagram shows the movement that the smallest figures (+90 & -90) in each limit will permit. 

When you make the RA limits to +/-6HA, then the DEC can only move radially away from the NCP within the hemisphere that is bound by RA=+/-6HA, centered on the meridian.  You can't, or shouldn't be able to move DEC the other way using the controller (you can physically), it would violate the limits programmed.  The moment you go over 90 (over the top) to the other side, you've added 12 hours to the HA (180deg).  So, unless you are willing to turn your scope upside down, you shouldn't be able to slew to objects below the NCP (the red lines that make +/-6HA in the second diagram).  If you notice, when you are traveling down to the celestial equator, your scope will point into the ground. 

So, this is how I understand it, I could be, and may very well be 100% wrong, but this is what makes sense in this thick skull of mine.



Horizon/overhead limit and axis limits are two independent things. First one is automatically calculated based on time and location, it's adjusted on runtime, and the later is constant. I was refering only to second one and only to RA axis. DEC has nothing to do with it.

On Sun, Nov 28, 2021 at 12:58 AM, Robert Benward wrote:
#define AXIS1_LIMIT_MIN              -90 //   -180, n. Where n= -90..-270 (degrees.) Minimum "Hour Angle" for Eq modes.
#define AXIS1_LIMIT_MAX               90 //    180, n. Where n=  90.. 270 (degrees.) Maximum "Hour Angle" for Eq modes.

May I ask you what happen when you set these values? Because when I do so, my RA axis won't go anywhere and it's in the limit at the very moment when it's only pointing to celestial pole.

If you imagine this constant is an imaginary limit switch, you may look at it in two different ways. One way to look at it is range when switch is on (limit reached) and the other way is to look at it like the range when switch is off (limit not reached). I don't think we are looking at it the same way, although for some cases (like default -180 +180) it is essentialy the same thing.

I imagined this "two zeros" model because it helps a lot when using negative longitude, and when RA is rotating CW. For example, if you have different + and - (say 10-17h), only switching zeros will preserve limits, otherwise they would be also reversed and then you would have 7-14h instead 10-17h.

Robert Benward

The line I posted from config.h are Axis 1 limits, not the horizon and overhead limits.  Axis limits are based on HA.  

I don't agree with your last sentence. If you use only positive HAs, your scope will never cross the meridian.  Switching zeros only works if the software agrees with your interpretation, but I guess that is what we are discussing here.

The HA of the scope (not an object) does not change.  6HA points at the West horizon and -6HA points at the East Horizon.   If you look at +/-1HA, the the scope must transit the meridian to get from one to the other.  If you insist the scope never goes lower that the DEC weights, then you must perform a  meridian flip when moving from the "plus" HA quadrant to the "negative" HA quadrant.

I just got my mount back outside and on the tripod.  I need to diligently perform these measurements, but it's been really cold the past few days.  What I have programmed in right now is +/-90deg.  That means my scope should never point below my celestial horizon.  It gets more complicated when you add in the horizon/overhead limits.  Those seem to be only on the SWS, I could not find horizon limits in config.h  But unlike your scope where you plugged in +/-90, my scope goes over most of the sky.  I have not tried pointing below the NCP.


Robert Benward

So, I ran the scope today.  With the limits I posted the other day, +/-90 deg in RA, I can spin the scope 360 degrees through RA.  I don't think it's supposed to work that way.  Also, I have set -10 for horizon, and 90 for overhead.  It seems like the limits are not working or I am missing something.

Howard, Khalid, can either one of you chime in, am I missing something?  Is there another switch or setting somewhere?  Can you speak to the limit diagram I posted a few messages below?


This is my config.h:

#define AXIS1_LIMIT_MIN              -90 //   -180, n. Where n= -90..-270 (degrees.) Minimum "Hour Angle" for Eq modes.      Adjust
                                          //         n. Where n=-180..-360 (degrees.) Minimum Azimuth for AltAzm mode.
#define AXIS1_LIMIT_MAX               90 //    180, n. Where n=  90.. 270 (degrees.) Maximum "Hour Angle" for Eq modes.      Adjust
                                          //         n. Where n= 180.. 360 (degrees.) Maximum Azimuth for AltAzm mode.
#define AXIS2_LIMIT_MIN               -50 //    -90, n. Where n=-90..0 (degrees.) Minimum allowed declination.                Infreq
#define AXIS2_LIMIT_MAX                90 //     90, n. Where n=0..90 (degrees.) Maximum allowed declination.                 Infreq

And my SWS:

Howard Dutton

On Mon, Nov 29, 2021 at 01:04 PM, Robert Benward wrote:
Howard, Khalid, can either one of you chime in, am I missing something?  Is there another switch or setting somewhere?  Can you speak to the limit diagram I posted a few messages below?
1. This is a functionality I consider well tested.
2. If a bug were discovered I doubt I'd patch it in a release.
3. OnStepX has a complete rewrite of limit handling, so this discussion would likely have no bearing on it.

1. Your depiction appears to be correct from what I can make of it.  Vladimars is not.
2. Be sure the min/max limits are set in the website config page (or advanced settings are disabled.)  It may override Config.h changes.
3. Start an align or unpark to be sure limits are enabled.  Limits are disabled to allow free movement (for homing mounts without clutches) until that happens.
4. If trying to use axis1 limits of min -90 and max 90 you are pushing things right to the fine edge of working.  If that doesn't work for your use pattern/hardware, don't use -90 and 90.
5. Make sure your site information and date/time are correct.  The difference between what you expect and OnStep's reality might cause confusion.

Telescope is east of the pier pointing into the western sky.  This is showing the Meridian Limits East (dark) and West (dashed) and the exclusion zone under the pole due to Axis1 Min -160 and Max 160.

Khalid Baheyeldin

On Mon, Nov 29, 2021 at 04:04 PM, Robert Benward wrote:
Howard, Khalid, can either one of you chime in, am I missing something?  Is there another switch or setting somewhere? 
I don't have much to add here ...

But I have a few observations:

- I am surprised by this problem report, since I have never seen anyone reporting it before.
Usually, when someone hits a wrong limit, it is because they have one or more of time/location/UTC offset wrong.
Once they fix those, the problem goes away.

- I have never needed to change any of the parameters mentioned by you or Vladimir at all.
Defaults work here, and they don't need to be changed at all.

Maybe you want to initialize the EEPROM, so it starts from a fresh known state.
See the FAQ page entry for how to do that.
And while you are at it, start with a fresh Config.h and edit only the board and axes info.
Or use the Online Configuration Generator.

See if the above helps in anyway ...

Robert Benward

I am sure this problem is mine, not SW.  I know something is wrong, I just can't put my finder on it.

Date,Time and site, is checked every time I power up Onstep.  I am using an RTC, so site and Date/Time are always updated.

I exercised the mount last night, but it was a patchy session due to clouds.

I increase the limits to +/-105° in SWS from +/-90° in the config.h, and left the overheard and horizon to 90° and -10°.  I later increase the horizon to -15°.  I now seem to have problems leaving home, it will not perform a GOTO from the NCP.  I need to move it slightly off NCP to get the GOTO to execute.  No errors are reported.  With these values encoded, I did not see limits being encountered.  I also could not seem to get Park to work last night.  I am not sure why, it just didn't seem to do anything.  

I may try and download your Sky Planetarium and try that instead of Sky Safari as test.  I like the ability to see the limits as programmed.

Regarding OnstepX, I would weigh that upgrade carefully, I honestly don't know much about it.  Once I get Onstep 4.2.4 working and mostly stable with my mount, I might consider the upgrade.

I will try and reinitialize the NVM and see how that works.

It may be a few days before I can uncover the scope again.  It was supposed to be clear this week, but that went down the tubes last night with a new forecast.


Khalid Baheyeldin

On Tue, Nov 30, 2021 at 11:17 AM, Robert Benward wrote:
I will try and reinitialize the NVM and see how that works.
And use a freshly downloaded Config.h, so all values are default except for the pinmap, and axis1/axis2 parameters.

That way, we know that you are on known good defaults, and what you are seeing is not triggered by something you changed for a seldom used parameter.

The other thing is the UTC offset. Note that the western hemisphere is positive.

Robert Benward

That config.h is very personal to me, I don't know if I can let it go... 

I will generate a new one and then do a file compare with my current one to see if there are any of those "trigger" parameters that you mentioned.   

Yes, I am using a positive value for UTC.  It took me a while but I stopped using daylight savings time.

It will be a day or two before I can get to it.


Khalid Baheyeldin

On Tue, Nov 30, 2021 at 06:32 PM, Robert Benward wrote:
That config.h is very personal to me, I don't know if I can let it go... 
The issue here is that there are changes from one version to the next, and carrying over values
from an older version may not work for certain seldom changed parameters.

You do have some of those, from what you said ...

Therefore, starting fresh will guarantee that there is no version clash or something like that
causing what you see.

I will generate a new one and then do a file compare with my current one to see if there are any of those "trigger" parameters that you mentioned. 
What I am recommending is a minimal Config.h with only three segments changed: pinmap, axis1, and axis2.
That is it, nothing else.

Then, together with an NVRAM reset, let us see if you still see the symptom or not.
Then after that, we move on to your changed parameters, one by one, and see if any specific one triggers it.