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.

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)

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

Kring

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

Kring

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

This is a synopsis of what I have found so far re Sync and GoTo bug.

1) the problem appears to be mount independent. RainbowAstro, NexStar/SynScan protocols all can fail to do a Sync and GoTo, complaining that the star is below horizon. I have not tried Meade or iOptron protocols, but I suspect the bug is in some code that is common to all mounts.

2) by watching the commands that ASIAIR sends to the mount, I have determined that ASIAIR is the one that is making the mistake that the star is below horizon. Mounts have Horizon Limits, but in the Sync and GoTo case, it is something internal to ASIAIR that is the problem. When Sync and GoTo is pressed, ASIAIR correctly sends the solved plate center to the mount. But ASIAIR then throws a bogus "below horizon" error even before it attempts to send a GOTO command to the mount. The mount does not even have a chance to check the GOTO's Horizon Limit.

3) the bug seems to kick in at some specific point in time (I have not yet figured out if it is related to Local Sidereal Time, UTC, or Local Time).

Before that certain time, Sync and Goto appears to work for all stars. Circumpolar or not circimpolar, east or west of the Meridian. They all work.

After that certain time, circumpolar stars appear to continue to work correctly. However, all other stars will suddenly, report that they are below horizon. Bam! It does not matter if a star is west or east of the Meridian, or how far the star is from its Meridian transit.

My conjecture is that about 12 hours after the time when Sync and GoTo fails, it will suddenly start working again, only to fail after another 12 hours. Whether it is 12 hours, or if it is 11 hours 58 minutes (half a sidereal day) or if it kicks in at a different time for two different longitudes will depend on whether the bug is triggered by UTC, Local Time, or Local Sidereal Time.

Chen

I did my first quick test this morning before work. I figured let me start from scratch and test your 12hr theory Chen. And AAP is still upside down and it's been more than 12 hours, running on approx 20hrs.

• Capella which is just rising for me, shows it's at Meridian and setting which is exactly 90 degrees off from where it should be...
• Matar shows it's below horizon when it rose a few hours ago, again about 90 degrees off
• Vega had just passed meridian within the hour and right at Zenith, but AAP shows it's below the horizon and not scheduled to rise for another 5 hours. this seems like it's off by more than 90 degrees

I'm going to shut everything down and check around noon EST, which should be past the 24hr mark to see if it fixed it's self.

Here is something else I noticed, that may be part of the issue... if you search in AAP goto for a star, like Vega, the Altitude chart is incorrect as we're previously discussed, but it's more than just off by it's charted red line, the time markers at the bottom are also wrong.. it's starting at 18:00hr for me and running to 06:00 tomorrow... but it's 10:00hr here on US EST time and the AAP has the correct time... Shouldn't this chart start at 10:00hr or close to it?, not 18:00hr well past current time? With the current numbers, my current time of 10:00hr is completely absent from the chart, literally off the chart!

It seems like AAP is having a fight with it's self on where it's getting it's date & time... my guess is part of the code is referencing current date/time of the iPhone device, part of the code is getting it from the mount's date/time, part of the code is getting time from the AAP Raspberry Pi OS, and part of the code might be getting time from something hard-coded for China, maybe a developer dropped in a hard-code during testing that made it out....

That's the only explanation I can come up with on why AAP is having different times in different parts of the app.

More to add! U ready for this - If I click on Vega in AAP, which is charted BELOW the horizon right now according to AAP charts (but actually close to zenith in my sky) and click GOTO - AAP actually guided it correctly to a straight-up position... so the goto catalog is wrong, but now somehow AAP still figured out it was a visible star..... this is really screwy. I did GOTO for Matar and Capella as well, both had incorrect charts.. they slewed to the correct sky position.

So maybe Chen your 12hr theory might be right for AAP to self-resolve the GOTO, since that's now working... but it wasn't enough time to fix the broken catalog, lets see if that snaps back inline later today.

Also, my home position was correct when I connected AAP, yet it's still holding bad home information and sends it about 15 degrees West on RA... and 5 degrees off on Dec from what the mount HOME is set to and the starting position when I first connected AAP to the mount.

Kring but it wasn't enough time to fix the broken catalog, lets see if that snaps back inline later today.

Remember the old saying that a man with two watches never really know what time it is? (The saying came before GPS, of course.)

I think we may have a case of a man in a lunatic asylum with 5 watches, instead of just two :-) :-)

Chen

w7ay To add to the oddity of this issue.. I noticed earlier that items in the catalog are mixed degrees of inaccuracy some are accurate, some are off by 90, some off by 180. I'll get some examples tonight when I boot it back up... I had some good news, the sky just cleared out, looks like a stellar night ahead! I'll do some testing but then probably try to catch some pics in the later hours.

For testing, what would be the most important thing I could do tonight?

• keep checking goto and note the time and objects that break horizon or goto?
• see how the flip goes during autorun? (set to favor West in HC, make sure Luminance filter is in use at meridian)

Help me on the how to test: I want to make sure I don't waste a night of data by a simple goof on my part:

• Set my HC to UCT zone but override the time by -4hrs, i.e. @ 7pm EST tonight, I would set HC to 11pm UCT?
• Best way to capture data? where are the logs/info? Is there anything to save or send when I do this (other then ZWO submit) I want to make sure I don't loose data. If I just need to take notes?

Kring keep checking goto and note the time and objects that break horizon or goto?

That would be useful, just for chuckles. Right now, there is nothing else we could do since the system is not open sourced. We have already pinpointed that the error is is some step ASIAIR is using to determine altitude of stars, in between a Sync and a GOTO. Pinpointing if it is LST of UTC or Longitude related might actually be useful since it may clear up their other bugs too. But it is ZWO's job to fix the problem (implicit contract in exchange for us giving money to them for an advertised function. It is not our part of the contract to help them find the problem -- we are not even obligated to send them any error logs in exchange of their fixing flaws in the product.

see how the flip goes during autorun?

I think that is a function of different time offsets between ASIAIR and the mount, assuming there is no east-west tilt in the mount leveling that could affect the true hour angle of the mount (the real hour angle of RA motor plus unaligned east-west leveling of the mount). At least that is what I found with my RST-135 mount. If your mount does not eventually meridian flip automatically, there might be some underlying bug having to do with the NexStar protocol in ASIAIR.

All I can suggest right now about the meridian flip problem is to do a simple GOTO (from ASIAIR) to the star that is East of the meridian. Do a plate solve, but do not sync yet. Check the RA of the plate center (the solution of the plate solve) with the RA you asked the mount to GOTO. If the RA is different, that will be the amount of extra time you may need to wait for the mount to finally flip. Just remember the 15º per hour sidereal rate, thus 15 arc minutes per minute of time. So if the plate solve and mechanical RA are different by 15 arc minutes in one direction, you may have to wait an extra minute of time for the mount to move. And if the plate solve and RA are different in the opposite direction, the mount can reach its Meridian Limit and stop tracking before the ASIAIR starts its auto meridian flip. I.e., there will be streaks in the last one or two plates before ASIAIR itself starts the meridian flip choreography.

Set my HC to UCT zone but override the time by -4hrs, i.e. @ 7pm EST tonight, I would set HC to 11pm UCT?

I think the easiest process to ensure times are in sync (since ASIAIR confuses thing by not following Daylight Saving Time) is to check meridian crossing. Do a manual GOTO to an RA that is a few minutes to the East of Meridian (you can select the RA field and enter it yourself, instead of using the RA of a star), by using the RA of a star from something like SkySafari. Then change the GOTO RA to just west of the Meridian, without changing the declination and again tell ASIAIR to send a GOTO command. If the mount makes a short direct slew between those two locations, your mount's time (or east-west level) is not is sync with the sky (i.e., mount's zero hour angle is not on the Meridian). The mount should take the long route through the pole (meridian flip). You can increase the distance from east and west of the meridian (binary chop :-) to locate where the mount think its meridian is.

If this manual meridian check does not work, auto meridian flip will also not work.

You can further check if ASIAIR time is correct by comparing the time to flip with how far the star is away from meridian in SkySafari (substitute "SkySafari" with any of your favorite planetary program. I just use it as an example, since the free version of SkySafari can do all of this).

Best way to capture data? where are the logs/info?

There is an ASIAIR log (and also PHD2 log) but only during AutoRun. Open up the Samba server in ASIAIR from your desktop computer. Inside the Images folder or Udisk Images volume (if you use USB memory), you should find a folder called "log". The Autorun logs and PHD2 logs (identifiable by filenames) from the past are there. Unless you have wiped your memory clean :-).

I have never found the AutoRun log to e particularly useful though. I take my own notes the old fashioned way -- paper and pencil :-).

Chen