stevesp At the end it tried to move west a bit

Steve (?), this is interesting.

The reason is this: ASIAIR does not really perform Meridian Flip. The mount is the one that does the meridian flip.

With pretty much every German mount that can perform GOTO, the mount has to know which side of the pier the declination axis is located. The mount will try to maintain the state where the declination axis is on the opposite side of the pier from the star it is asked to perform a GOTO.

What ASIAIR does with an "Auto Meridian Flip" is simply to choreograph (I don't know what other word to use...) the meridian flip. I.e., while the mount is tracking a star, and the star has reached the time "Stop tracking x min before Meridian" (a parameter in the Mount Setup), ASIAIR pauses AutoRun, it then stops autoguiding, and also stops tracking.

Meridian is basically the point where the RA of the star is equal to the Local Sidereal Time (LST). In general, ASIAIR stops a little before this time, to make sure the exposure time of a frame does not go past this "Stop tracking" parameter.

After stopping everything, ASIAIR does a countdown until the time when the second parameter in Mount Setup called "Do AMF x min after Meridian" is reached, i.e., ASIAIR twiddle its thumbs until the RA of the star has reached LST plus this second Mount Setup parameter.

When this second time is reached, ASIAIR sends a GOTO command to the mount, with the assumption that the pier side of the star is now also the pier side of the declination axis!

If the mount also thinks that the star and declination axis are both on the same side of the pier, the mount will execute a Meridian Flip -- i.e., it moves to the same RA, declination coordinates, by traversing through the pole, but repositioning the pier side of the declination axis.

After the mount has stopped moving (the state that ASIAIR can get from the mount's communication protocol), ASIAIR takes an image to plate solve. If the ASIAIR senses that mount has meridian flipped (probably by looking at the camera angle from the plate solve, although many mounts also have a command to fetch the pier side), it centers the star on the plate, and then resumes tracking, then flip the auto guiding calibration (that flip switch in the calibration setup info in the autoguiding window). It then chooses a new guide star, then start autoguiding. It finishes the choreograph by resuming the AutoRun sequence. (What ASIAIR has to do is "As Easy as 1,2,3." The Mount is the one that has to compute the actual path to move the RA and declination motors.)

From the above, you can see why I had called this a choreography :-).

I believe what is happening to you is that when ASIAIR issues this GOTO, the mount does not think the star has yet moved to the other side of the meridian. The RA axis moved west by a little bit (good observation!) because tracking has earlier been stopped, so the GOTO would move the mount "normally" to make up for the tracking time loss since the star has drifted by a little bit from where it should be had tracking not been turned off.

All indications is that the LST and/or RA in the ASIAIR is not in sync with the LST and/or RA in the mount.

Unfortunately, while mount's LST is available in hand controllers, you cannot find the LST that the ASIAIR GUI, so we cannot tell if LST is really in sync. However, LST should be directly related to UTC and local Longitude.

The next time the mount refuses to Meridian Flip. Check to see if the UTC time and Longitude agrees with the UTC and Longitude on the hand controller. There are a number of iOS apps that will display the UTC in the operating system, and ASIAIR should be using the same system call to obtain the UTC. I have even found a lot of iOS apps that will display LST.

There are a number of people who refuse to sync their mount to the ASIAIR time and longitude. This typically is the cause for time and longitude between the ASIAIR and the mount not being in sync. But this usually creates only a few minutes of time difference between Meridian crossing, and ASIAIR will retry the GOTO (after a 1 minute timeout) over and over until the time on the mount has caught up and it performs a Meridian flip.

But, if the mount happens to be off by an hour (for example, if the Daylight Saving Time is turned on in the Mount -- recall that ASIAIR does not observe DST) you may have to wait an hour before a Meridian Flip occurs.

A good sanity check is to try to perform a GOTO to a star from ASIAIR (using coordinates obtained from a planetary program like SkySafari) that is as close as possible to Meridian (or just enter the RA of the Meridian in the GOTO panel), then use a bubble level to check if the OTA is pointed towards the Meridian. You can do this in daylight. (I have one of these cheap Amazon digital inclinometers that I often put to use for such purposes -- pointing at Zenith is one way to align a Takahashi mount without needing to use stars).

If you have to wait a long time for a Meridian Flip, it is very likely that there is a longitude or time disparity between ASIAIR and the mount. I actually expect a lot of that happening this week to US hobbyists, since we just went into Daylight Saving Time just a day ago, and then next Sunday night in Europe :-).

Incidentally, a mount slew (the directional keys in ASIAIR and hand controller) will not obey the pier side rule, you can slew a mount right through the meridian (until the optical train hits the pier :-). The mount will only obey the pier side rule when it is commanded to do a GOTO.

Chen

Chen
thanks for your great explanation, as usual
So it means I need to understand the mount setup firsi was thinking Asiair was bypassing everything and driving the motors directly

  • w7ay replied to this.

    stevesp i was thinking Asiair was bypassing everything and driving the motors directly

    The only time the Raspberry Pi in the ASIAIR controls the motor directly is when it uses EQMOD. For EQMOD, ASIAIR uses the INDI driver I believe, and the INDI driver controls the "steps" of the motor directly.

    For other mounts, ASIAIR does not slew the motors directly, does not track directly, does not guide, directly, and does not perform GOTO directly. The ASIAIR simply sends commands to the mount to do them. The processor in the mounts do the hard part of figuring out what to do with the motors.

    Pulse guiding is usually performed by sending a slow slew rate (e.g., 0.5x sidereal rate) to the mount, and then sending a slew command, followed N milliseconds later with a stop slew command -- this is the "pulse." Mounts that use 9600 baud are at a disadvantage since they are only capable of accepting commands at a rate of about 1 character per millisecond and there is a small uncertainly to the true pulse duration.

    You hear a lot of disparaging remarks about ST-4 by the Facebook crowd. But because of timing uncertainties, there are places where ST-4 is superior to pulse guiding.

    Chen

    Awesome information Chen. hoping you could elaborate a little more (if you know) what to do when things fail. I have a CGX but all this applies, and these steps are what I've been using: but I run into issues at a few points, I'll outline my experience.

    • The AAP and mount successfully get setup per your steps, confirm accurate, date, time, dst, location exact
    • In my case, I have starsense, so I run an auto align, and things come back successful
    • I send the mount to switches (since CGX has built in home), I then set "home" to match the switch position.
    • I test by sending mount to a goto, then sending it back "home" via the HC to confirm everything is working
    • I then continue to connect AAP to HC and turn on the setting switch in ASIair app and successfully connect

    ISSUE 1: So at this point I have found I sometimes run into an issue, If I use the ASIair app mount settings, at the bottom is a green go to home button, if I click that. it goes completely in opposite direction of home and tries to send the scope into the ground and mount. Clearly the AAP has BAD home information and is not using the HC home position I just set. so my work around has been after connecting the AAP to the HC I have to take these steps:

    • Do a goto from AAP
    • From HC send it back to switches
    • From HC SET HOME again
    • Via AAP do a goto
    • From HC send to home
    • Frim AAP do a goto
    • From AAP send to home

    ISSUE 2: These steps to sync only seem to work 50% of the time. Sometimes I have to power off the AAP and back on then run through this again.. Clearly something is broken with the sync of HOME on AAP, or I am misunderstanding something with how it works.

    If I make it successfully past this, I have found goto works perfect, plate-solve and tracking, I can image just fine. but when it's time for a MERIDIAN FLIP, the mount and ASIair do everything perfectly, and aligns with how you said it would.. countdown, flip, goto, plate-solve. I've now run into two issues here thought

    ISSUE 3: separate from this under an enhancement request, sometimes plate solve fails because a narrowband filter is in use so it fails to detect stars, I'm asking for a feature to set a specific filter for plate solving during autoruns.

    ISSUE 4: I've had twice now, the home change to something entirely different in AAP after the flip... so if you send it home it points down into the earth on Dec, and goes to slew limit West on RA.

    I have yet over 5 autoruns successfully had the AAP do a meridian flip and keep processing images.

    • w7ay replied to this.

      Kring I have starsense, so I run an auto align, and things come back successful

      Aha, you may want to bypass StarSense to see if the ASIAIR behaves better with the mount.

      The reason is this: From what little I know about Celestron mounts, StarSense is simply an automated way of doing star alignment. After the star alignment, StarSense would calculate what it thinks the coordinate system of the mount is. When you GOTO a star, it would calculate the adjusted location of the star and slew to that location, even when polar alignment is wrong.

      You can think of it this way: the sky follows the spherical coordinate system with poles located at the North Celestial Pole (NCP) and South Celestial Pole (SCP).

      The mount's RA and Declination axes follows another spherical coordinate system whose poles are determined by the RA axis and also rotated if there is also a longitude and time discrepancy. There are other errors that will cause a GOTO to be off, for example a cone error (the declination axis not orthogonal to the RA axis), etc.

      What StarSense (or any star alignment algorithm) does is to model how these two spherical system differs. There are typically 5 or 6 possible parameters for the simpler models, and many more if you want to take care of all possible errors in the mount. The model is then used to "map" a position on the sky to the hour angle and declination axis of the mount.

      Thus, with StarSense, you can GOTO a star very accurately after a good model is made (that is why star alignment uses multiple stars -- each one refines the model better). However, unless you have also bought an expensive motorized camera rotator, and your autoguider knows how to track field rotation (PHD2 in ASIAIR only tacks RA and declination displacements), image rotation will still exist. I.e., StarSense may be useful for visual observations, but is practically useless for taking long camera exposures.

      With a plate solving system like ASIAIR, you do not need or even want StarSense. With ASIAIR, you can just use Plate Solving, then sync the ASIAIR coordinates to the Mount, and you are done. No "third party" to further change the coordinate system behind your back.

      Toss the StarSense and see if everything works better.

      Chen

      Before connecting AAP I goto home from HC (it is in the HC menu) then AAP doesn’t fail, otherwise AAP does the goto to crazy locations

      • w7ay replied to this.

        stevesp Before connecting AAP I goto home from HC (it is in the HC menu) then AAP doesn’t fail, otherwise AAP does the goto to crazy locations

        That must be it. Could be related to pier side.

        (Perhaps the next time you are out at night, try not homing, check the pierside, then homing and check pierside again -- if it has to do with pierside, that could be very useful for ZWO to fix the ASIAIR bug for good, assuming they listen. Sometimes they don't listen, sometimes they listen but don't grok the problem. Sigh.)

        If StarSense happens to use a star on the west for the most recent star, the pierside will be left on the east. However, if the most recent star used by StarSense happens to be on the east, then the mounts pierside will be on the west. I.e., it is a coin flip.

        A Home command probably sets the mount to the the proper pierside. If Home happens to be NCP, then it can be ill defined, since an arc second of movement could move the pier side from east to west. The pierside of NCP home is only by convention.

        I have an RST-135 whose home position has the OTA pointed at the West Horizon. The pierside is therefore unambiguous and the mechanical balance is pretty stable too (clever Koreans :-).

        Chen

          Great detail again Chen, makes total sense to me what it's doing... basically accounting for bad polar alignment so it creates an off-set for all coordinates and that's why I don't need to make any mount adjustment to alt/az like we do when we're using AAP's PA.

          I my case, I did a manual PA routine with ASIair where I dialed it in to 0.08" total polar error; I should have added that is part of my initial physical setup routine. After I would run the starsense routine. Effectively the starsense off-sets are probably near zero and coordinates match the actual sky (assuming my PA is really that close to accurate)

          With 2800mm of focal length and no eye piece it's challenging to do the initial alignment, even a 1-star... I thought Starsense would be a great way to get me that initial mount alignment and home setup since AAP can't do that... Then I would roll right into the AAP for a PA run to confirm I still have a great PA, then do a goto & plate solve to make sure AAP is functioning, then it's off to imaging.

          None the less, I get your point on other possible issues with starsense and how it may not behave the same as a straight mount. I will give this a try tonight indoors to get my mount routine down, then next clear sky I'll go without Starsense and see how things behave.

          Thanks again, I appreciate the response! and I'll report back what happens!

          w7ay - I think you are hitting on something and the AAP has a bug related to pierside with celestron mounts.

          If I repeat back what I think you are saying - when I connect HC, it gets pierside, say EAST, AAP & mount are in sync. But after a meridian flip, pierside is now WEST, but AAP still thinks its EAST; AAP has become out of sync with the mount... When the AAP issues a goto (home or target), the AAP issues the wrong coordinates of a sky object, which the mount then interprets as coordinates in the dirt.

          Do you know how we can check pierside? I don't recall seeing that in any of the depths of celestron's starsense HC menu...

          • w7ay replied to this.

            Kring But after a meridian flip, pierside is now WEST, but AAP still thinks its EAST

            I assume this is the result of a manual GOTO and not the result of an auto meridian flip, right?

            After every meridian flip, the pier side should toggle. If the ASIAIR is not showing pier side changing, oops!

            You might try a couple of stars that are some 45 degrees East and West of the Meridian to see what happens. If a star is that far from the Meridian, the mount should do a Meridian Flip when you go between a star on the west to a star on the east and vice versa, when the ASIAIR sends it a GOTO command, even if the time is off by an hour due to the lack of Daylight Saving Time in ASIAIR.

            Even better, do this under dark skies, so you can use plate solve to confirm coordinates (and camera angles -- camera angles should be 180 degrees from one another (RA axis gets inverted) when flipped).

            It is a bloody shame we have to do this since we are the paying customers, and not paid beta testers, or YouTube shills. But sometimes, this is the fun part of a technical hobby.

            Chen

            I'll continue testing, trying that if I can get another clear sky... manual goto's always work (so far, fingers crossed) I can send either side and never have an issue for first half of the night... when an AUTO-FLIP happens, everything is messed up at that point. atleast for me, but it sounds like others are having issues with auto-meridian-flip during autoruns. I'm thinking the AAP isn't reading pierside (if that's a data point in the mount) or after it waits and confirms a flip happened, it's not updating it's reference that it flipped and is retaining old pierside.

            This still relativly all new to me.. so I'm trying to understand and learn - think I'm at the point of being dangerous and right just over half the time, but still learning!

            I do generally enjoy this - always been a problem solver and the troublshoot and hunt is enjoyable and I got into Astronomy & AP as stress reliever so I promised myself I will not get any frustration with this and just take my time.

            • w7ay replied to this.

              Hi guys (and anyone else watching the meridian flip saga),

              As I found out from last nights experiments, one other thing to check if your Meridian Flip is really late (other than being "one hour Daylight Saving Time" late) is your tripod's east-west level.

              There are people who tell you that leveling the tripod is not important if you do a good polar alignment and use plate solving to GOTO. These smart ones forget the details (dot the i's and cross the t's :-).

              Polar alignment will get the RA axis pointed at the pole, so that the mount can track without a declination drift. However, we live in a 3 dimensional world. There is a third axis.

              Imagine looking up in the sky and searching for Polaris (near enough to the pole to use as a casual example). You pan the eyes east-west and then north-south to look for it (this is like what polar alignment does). Lets say you have it centered in your view. And you think you are done.

              Nope.

              Notice that you can tilt you head, while Polaris is centered in your view, and the sky now revolves around Polaris, just like the pretty circumpolar time lapse photos. All the while your head remains "polar aligned" with Polaris at the center.

              Why does this matter? Aha, tilting your head is changing the reference point of your head's Hour Angle: it determines the time a star crosses the Meridian in your head!

              Having a tripod that is not level in the east-west direction is basically like tilting your head. The time a star crosses Meridian is now different.

              What is more interesting is that this time offset will be different with the OTA on the east of the pier and with the OTA on the west of the pier (a Meridian Flip changes the RA motor angle by 180 degree).

              Sync-to-mount after a Plate Solve might resolve this problem on your mount, it did not on mine.

              How do you check? Obviously, you can do that with a bubble level or a digital inclinometer. But consider the precision... A 1 degree error is very small, right? But that can be enough (if the sign of the angle makes the mount's meridian appear later than the sky's meridian) to delay the Auto Meridian Flip (i.e., the mount does not think that the star has gone past yet). 1 degree of tilt corresponds to 4 minutes worth of time. That said, a $30 digital inclinometer can probably get you to no more than one extra try (1 minute of time) of the auto meridian flip. I.e., good enough unless you are OCD like me (most engineers are, even in retirement :-). I have a couple of the iGaging brand digital inclinometer from Amazon that I have been using for years now; the second one was bought because it had backlight and USB recharging; the first one needed a flashlight to use at night.

              How to measure more accurately? ASIAIR has the plate solving tool :-). Once you think you are "star aligned," i.e., the mount knows its RA, do a GOTO to some place in the sky whose coordinates you define to ASIAIR (could just be a named star, if you can find a convenient one). Now do a plate solve. Compare the RA of the plate to the RA that you have asked ASIAIR to go to. Now do a GOTO to a star on a different side of the Meridian (go Home first, just so there is no bias). Check the RA offsets. If they are different, your mount is probably not level in the east-west direction.

              Hopefully, this gives a bit more understanding of the late and missing Meridian Flips. Note that in this case, it is not an ASIAIR bug. ASIAIR is is simply depending on the mount to do the Meridian Flip. If ASIAIR were to do its own meridian flip, then the delay will not be there.

              I found this out last night when my Auto Meridian Flips were delayed by 5 cycles of AMF retries. ASIAIR kept sending a GOTO to the mount, and the mount thinks it is still on the correct side of the pier and won't move; until the star finally crossed the mount's internal Meridian line. Turns out my mount was well calibrated (almost zero RA error) with a star on the west, but some 4 minutes of RA off for a star on the east, and I was testing with the east-to-west Meridian crossing so time on the east was all important (ASIAIR cannot do West to East meridian crossing anyway right now, ha ha).

              Checking with the iGaging inclinometer resting on my dovetail clamp in daylight this morning, I find that the mount is some 1º off level in the east-west direction.

              Self inflicted wound :-).

              Chen

              P.S., for people who are missing the West-to-East auto Meridian flips, notice that even though ASIAIR v1.5 does not know it exists, your mount does. Once the star has reached Meridian, you mount's Meridian Limit should stop tracking. At that point, manually stop autoguiding (or guiding will go bananas) and pause AutoRun. Give it an extra minute and send the mount a GOTO. If it does not flip, repeat with another GOTO a little later. Sooner or later (when the target crosses the mount's meridian), the mount will flip. That manual GOTO should also turn tracking back on (for most mounts) and you just need to turn guiding back on and resume AutoRun.

              I started a different thread here on one reason why tracking seems to stop by itself for some people. As I explained in that post, I think it is because the mount has read the west-to-east Meridian Limit and therefore stopped tracking. Since ASIAIR does not think there is a Meridian there, it keeps autoguiding, and you know what happens when you try to auto-guide when tracking has stopped. You can actually successfully auto-guide with no tracking, if the guide rate can be set to above 1x -- but ASIAIR don't let you choose a lava over 0.9x.

              I've been doing some more testing, and I've concluded there is something seriously wrong with the AAP software, unless someone can show me my massive error I'm making in how I go about setup.

              I've attached a link to a video showing how the AAP is getting all confused with which hemisphere I am in, even though information is correct and synchronized, at some point AAP gets lost and then it's sending bad information to the mount.

              OneDrive Video Link

              Workflow in the video:

              • Setup mount, power on, set date, time, location, DST off, go to switches, set home.
              • Run the mount alignment, using Sky Safari Pro (SSP) to show what's happening, exact same thing happens with HC
              • Goto in SSP works perfectly as expected, confirmed a few targets, I pick Matar since it's at my zenith on east side
              • you can see the mount is point at the right spot in the sky - pretty much strait upward where it is in my sky
              • Now power up the AAP, wait for beeps, I confirm SSP is still tracking Matar while I wait
              • Launch ASIair app from scratch, so I get start screen, select my devices and proceed
              • You can see in the video that all my date, time, location, DST are all perfectly in sync
              • now using APP, GOTO Matar, BIG ISSUE! AAP is wrong, look at the incorrect altitude chart showing it's below my horizon. and looking back over the video, AAP is has bad RA/DEC information.. it didn't get that from the mount, it made it up or has it cached from some other day.
              • If I slew to Matar, you can watch the mount in the video goto the wrong side of the sky and point the mount into the dirt.
              • Clearly not working!
              • I go back to SSP and confirm they are still in sync, which now you see SSP recognizes that AAP is sending my scope into the dirt, but APP clearly thinks it's pointing at Matar in the sky.

              I am not sure what's going on, but pretty confident this all points to a bug with AAP and shows the issues I'm having. I have (somehow) been able to get it to work correctly before. But when I did, the meridian flip would break it (as I'm mentioned earlier in the SAGA 🙂 and after flip AAP is confused about which half of the planet I'm on.

              • w7ay replied to this.

                Kring Now power up the AAP, wait for beeps, I confirm SSP is still tracking Matar while I wait
                Launch ASIair app from scratch, so I get start screen, select my devices and proceed

                This could be where the ASIAIR gets disoriented from the mount.

                My impression is that ASIAIR assumes that the mount is Homed when you connect ASIAIR to it.

                it didn't get that from the mount, it made it up or has it cached from some other day.

                This is the scary part. ASIAIR likes to make things up out of the clear blue sky, instead of obtaining the information from the mount (which is what I would have done).

                I'll keep an eye on this when I run my mount simulator. I.e., pre-position the mount (in my case, a virtual mount) at some location that is not Home, then connect ASIAIR to it, and then issue a GOTO. I have always before this (with both a real mount and with a simulator) been connecting ASIAIR to the mount when the mount is Homed.

                Could you please repeat the experiment with ASIAIR unconnected to the mount and with the mount pointed at some star (not Home), just like you did indoors. Then connect ASIAIR, but do a Plate Solve right away. This may force ASIAIR to realize where the mount is really pointed (it should be able to just retrieve it using a protocol command).

                In your case, you need to waste a clear night; in my case, the mount simulator will present an image to ASIAIR's camera just as if the camera is pointed at the sky. Using your Matar example, my simulator would display a skychart (a gnomonic tangent plane, to be technically precise) that is centered at Matar. ASIAIR does not know that the camera is pointed at the sky or a display that is drawing a representation of the sky -- a kind og virtual reality).

                I take the Mount position in ASIAIR with a grain of salt. It tells you where the mount is, but it is not clear ASIAIR incorporates that information into its own coordinate system.

                If I slew to Matar, you can watch the mount in the video goto the wrong side of the sky and point the mount into the dirt.

                OK, if we assume that ASIAIR wakes up thinking that it is pointed at Home (i.e., it is too stupid to use the Mount's current location). If you add the RA and declination change from Home take the difference in RA and declination to Matar, then add that delta to the RA and declination of Matar itself, do the numbers show that ASIAIR is moving the mount into the ground?

                If that is true, then what ASIAIR is missing is the important step of establishing the reference RA and declination from the mount when it first connects. ASIAIR code may be idiotic enough to send a sync to the mount, with Home as the sync parameter! If that is what happened, the mount now thinks its current motor position (pointed at Matar) is actually its Home.

                To be fair, many cheap mounts do not know where home is. Cheap mounts makes you manually position the motors so that the axes points to Home, and then a computer will tell it to use that position as the Home position. (The RST-135 I have has a Home command. It has sensors that detects where home is.)

                point the mount into the dirt.

                At least your video shows just the dovetail plate pointing to dirt, instead of smashing an OTA that costs 10x the cost of ZWO ASIAIR and ZWO camera combined into the tripod.

                Speaking of tripods, the fear of smashing equipment is one reason I use a Tri-pier (I use the William Optics Mortar one). The best is a pier that is mounted into the ground like in real observatories, but a tri-pier does have more clearances than a tripod.

                Chen

                Good observations and analysis. I will continue to test, hopefully I can get some skies this weekend. I did do the same thing just a bit ago, where I started at home instead of Matar and same thing happened. I wanted to try a few more things, but AAP is stuck in wrong hemisphere. I also have an EQ6R Pro, AAP works flawless with that mount so far, so I’m pretty certain this all is still pointing to a bug in AAP with celestron mounts. I’m going to connect that next and see if I can flush a stuck setting.

                Also, I did do a home after the video and it went about 15 degrees off on RA and about 5 degress off on Dec - so not enough to account for entirely otherside of planet - so to answer your thought there, delta from actual home to AAP home does not account for why it pointed where it did. Also note that even without the mount doing anything the entire catalog is on the wrong side of the planet.. i.e. I can see capella tongiht, but AAP says it’s below horizon, so it’s confused.. even rebooting AAP I’m stuck at the moment.

                One really fundamental thing missing from the AAP when connecting to Celestron mounts is the option to “set home” so there’s no quick button to over-ride whatever AAP thinks (wrongly) is home. but really, like you said.. AAP should just read the mount RA/DEC and home position not guess or make things up, it has all the right information available and it would never be out of sync if it just read the mount.

                Hopefully ZWO is paying attention, they are usually active here.. but we are really hitting on a major bug/issue with celestron mounts… and because I get different results every time , I think that’s why some people say it works fine… they just havn’t run into the random issues or fallen out of sync. ZWO, you really should rewrite the Celestron mount interface, and upgrade it to USB or SkyPortal wifi access while at it (both are standard ascom)

                • w7ay replied to this.

                  Kring so not enough to account for entirely otherside of planet - so to answer your thought there, delta from actual home to AAP home does not account for why it pointed where it did.

                  OK, I will poke around some more.

                  So far, with the simulator, I have not yet seen a failure with "Sync and GoTo" yet. Interestingly, when Sync and GoTo is pressed, ASIAIR sends my mount (the simulator) a Star Sync command (the center of the solved plate in ASIAIR), followed by a GOTO.

                  GOTO in RST-135 is done using three steps. You first send it the RA of the target. You then send it the declination of the target. Finally you send it a "slew to target" command.

                  Now, here is the funny part: if I do a manual "Sync Mount" from ASIAIR, and then a manual GOTO from ASIAIR, I get the exact sequence as I do when I use "Sync and GoTo." And yet, last night for me (and most of the time for you), a "Sync and GoTo" gave a "below horizon" error, while the manual sequence will work! They can't come from the same code path.

                  Since I haven't been able to provoke the problem when simulating the RST-135, I decided to switch to simulating the CGX (the mount in your video).

                  Immediately, I notice that once connected, ASIAIR tells me my longitude is E 237º 11' , while my longitude is W 122º 48'. They are the same angle as you go around the 360º circle from Greenwich, but I am going to some further tests now to see what is actually happening with this bug (which also has been floating around for more than a year now, with no resolution).

                  For what its worth, when ASIAIR connects to the mount, it sends the local latitude and longitude (which it gets from the tablet's OS) to the mount. Next, it send UTC offset and Local Time. I am currently on Daylight Saving Time (UTC offset for PDT is -7) and when I was watching, the time was 8:39 PM local time. As expected, since ASIAIR does not understand DST, ASIAIR sets the mount to UTC offset -8, and local time 19:39 (i.e., both are Pacific Standard Time values, instead of Pacific Daylight Time). Both should resolve to the correct Local Sidereal Time, so there should not be a problem as long as the DST flag in the mount is also turned off. But why ASIAIR does this Rube Goldberg exercise instead of obeying time specifications (a single "DST" switch) is beyond me.

                  Anyway, I am now going to take a short digression to check out the East/West longitude bug while I have the CGX simulator running.

                  Oh, by the way, ASIAIR does require that your mount is Homed when first connecting. Upon connecting to my CGX simulator, ASIAIR flashed this alert on the (iOS) tablet:

                  "The mount must be turned on at Zero Position and did the one Star Align."

                  Chen

                  WHOA!

                  Regulus, which was fine with Sync and Goto an hour ago, now fails with a "Cannot GoTo. The current position of the target is below horizon, can't Goto."

                  I can set some breakpoints and logging statements in the Simulator now to see who is determining that Regulus is below horizon!

                  Regulus' Hour Angle is currently 1h 17m (a little more than one hour before Transit).

                  So I went to Denebola, which also worked fine earlier today, but also had problems last night, and sure enough, it too is reported by Sync and GoTo to now be below horizon.

                  For reference, Local Sidereal Time is about 8h 50m. I will start monitoring Regulus tomorrow starting at about 5h LST to see if any of this is related to time. But I will go check now to see if the mount is being told to go to a bogus coordinate (to get a below horizon response).

                  Stay tuned. News at 11.

                  Chen

                  OK, ASIAIR is determining that the star is below horizon by itself. The mount has nothing to do with the error.

                  I executed this sequence:

                  1) Told ASIAIR to GOTO Regulus.
                  2) ASIAIR asked Mount (simulator, ha ha) to GOTO the target; the RA and declination looks good.
                  3) Told ASIAIR to Plate Solve. Also worked fine. The plate solve gave a location just a few seconds of arc from Regulus (the Mount Simulator has no mechanical parts. Everything is just math. The only error is the quantized stars on the display and on the camera sensor).

                  4) I then told ASIAIR to do a Sync and GoTo.
                  5) ASIAIR sends a Sync star command to Mount. The coordinates in the command is as close as I can tell, the same as the plate solve center.

                  5) without even sending a GOTO to the mount, ASIAIR makes the pronouncement that the star is below horizon. So, the mount is not the one telling ASIAIR that it cannot go to a bad coordinate. It is a figment of ASIAIR's imagination.

                  Regulus was fine just a couple of hours ago. So it has to be some bug (yet another) in ASIAIR's coordinate system that has to do with the Local Sidereal Time.

                  Without the source code for ASIAIR, this is all I can do about this problem now. But we know that Plate Solve worked, and ASIAIR even Synced the correct plate center to the mount. There is some checking before ASIAIR sends a GOTO (the second part of Sync and GoTo) and that is where the error is. This is why a manual GOTO works fine. The bad code is in Sync and Goto , between Sending the Sync to the mount and where it checks for horizon limit before sending a Goto.

                  Chen

                  I may be wrong but I remember that with old firmware versions with my AVX I was running a goto to sync and then connecting Asiair
                  from that point AAP could manage the goto
                  now if I don’t make a goto home it is not able to goto the correct place

                  • w7ay replied to this.