How to setup meridian flip in AVX?: Page 2

How to setup meridian flip in AVX?

Kring

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

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

w7ay

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

w7ay

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

stevesp

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

stevesp now if I don’t make a goto home it is not able to goto the correct place

Can you try to see if you can correctly GOTO cicumpolar stars?

I was doing more test with the Sync and Goto problem and it looks like after a certain Local Sidereal Time, every star (both Meridians) errors out with a "below horizon" condition, while all circumpolar stars correctly performs a Sync and Goto after a plate solve.

So far, this is mount independent, at least the RainbowAstro and the NexStar/Synscan mounts all have this "Sync and GoTo" bug. I haven't tried the mount simulator under EQMOD or iOptron protocols yet.

Chen

stevesp

I cannot, currently I’m imaging from balcony with south view

w7ay

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

Kring

Great work all on this! A strong community is so valuable to building a great product. I'm glad to see it's not just me now at this point and I can stop thinking I'm doing something wrong or regretting my new mount purchase.

So other then just trying runs that may or may not work.. Is there anything I/we can test to try to narrow down farther?

I wish ZWO would just drop a post here to say they will escalate this and look at it.. in case it wasn't clear ZWO, I have yet to have a successful imaging session, I've been able to take some pictures, but never a successful auto run and invested dozens of hours during clear skies and at home trying to solve what is a bug. PLEASE put some serious attention to this bug.

w7ay

Kring I wish ZWO would just drop a post here to say they will escalate this and look at it..

Wishful thinking, my friend. Haven't you already noticed that if you post a message praising ZWO on this forum, you get an almost immediate response. If you post a problem, you will just get silence from ZWO, or get some non-sequitur response.

Chen

Kring

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.

Kring

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.

w7ay

Kring 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...

This seems to confirm that ASIAIR is basing its horizon limits from some fictitious clock that is offset from reality by a certain amount. It may be using UTC that is pushed from the tablet to figure out the LST (perfectly legit, if your equations are correct -- I use UTC myself to derive everything I'm my mount simulator). But they have a bug somewhere. They really need to buy Jean Meeus' and read it cover to cover.

By the way, the problem, if I am correct, is stationary (to borrow a term from Probability theory). I do not think it depends on how long you have turned the mount on. I think it is based on the UTC or something that is pushed by the tablet to the ASIAIR.

However, if the ASIAIR is using the time from Raspbian, then it may actually be using a Unix time (started in 1970 sometime) without being updated by external sources (GPS, time pushed by ASIAIR app in tablet, etc etc).

I did not reboot my test ASIAIR v2 last night. This is a second ASIAIR v2 for indoor testing. I have an ASIAIR v2 in a waterproof box at the base of my tri-pier which is left outdoors under dry bags 24/7, and I have an ASIAIR v1 is an al sky camera with an ASI178, that is left outdoors all the time, protected by an acrylic dome).

I will try later to reboot the ASIAIR to see if the problem shifts with time.

Chen

w7ay

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

Kring

Since it happens to all stars at the same time (and thus not related to the hour angle, as a correct horizon limit does), it might be worth recording the UTC the horizon detect on ASIAIR is wrong and the times they are right.

We can then create a scatter plot to see if there is a pattern.

Addtionally, we may be able to determine if it is related to the local sidereal time, by comparing our data. I am located at 122.8º West Longitude, by the way. The further you are from me in Longitude, the easier it is to determine if Longitude affects when their horizon detect go bonkers. If we use UTC, we will have a common clock reference.

Don't waste time, though, if it is not out of curiosity. The workaround for Sync and GoTo (if you don't care about accuracy) is to use Auto-center, and (if you need accuracy) repeated application of Sync To Mount and GOTO.

Chen

Kring

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?

w7ay

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

w7ay

Kring

OK, we are getting somewhere...

I just tried (UTC time about 2130) Plate Solving Alpheratz and performing a Sync and GoTo, and it was still performing properly.

I then changed my iPad's time Zone to London, rebooted ASIAIR, connected to my simulator, and forced the Longitude in the Phone Info part of Telescope Settings to 0 degrees West, and synced the location info to the mount.

Tried a GOTO to Alpheratz; and got a below horizon, which is correct.. Pegasus has already set in London. I then did a GOTO to Castor, and ASIAIR sent a successful GOTO command to my virtual mount.

The plate solve with the mount simulator's display showing Castor and surround stars also worked. The twins are above the London skies.

But, when I now do a Sync and GoTo, it gave me the "below horizon error!" Keep in mind that ASIAIR had executed a direct GOTO to Castor fine, and also plate solved to a correct coordinate. So this is "our" bug.

I had earlier tried changing just time zones without changing the Longitude of the mount, and that did not cause an error (went to New York, Tokyo and London -- faster than a supersonic jet :-).

So, I am more convinced now that the failure has something to do with Local Sidereal Time, which involves both UTC and Longitude.

Instead of waiting for the time of failure to arrive, I simply moved to the time of failure (it's all relative, right? :-).

I have some chores to do now. But now that I've established that the error can be caused by changing Longitude instead of time, I can continue this experiment after dinner, instead of constantly monitoring and waiting all afternoon and evening for the time the Sync and GoTo to fail. I can simply change time and longitude by one time zone at a time.

Chen

w7ay

Kring

See post #8 here:

https://bbs.astronomy-imaging-camera.com/d/12316-sync-goto-after-plate-solve-still-fails-in-v153/2

It is definitely related to LST and your local Longitude :-).

For example, if your longitude is 119º West, the bug will suddenly pop up when LST is about 7 hr 49 min.

Instead of waiting for the time for the bug to arrive at my location (122.8º W), I went to change ASIAIR's longitude in the Mount Setup window to 119ºW, ha ha.

Chen

w7ay

Just a quick comment...

The altitude of a star (thus whether it is above or below horizon) should only depend on its Hour Angle, Declination and Latitude of the telescope.

The Hour Angle in turn depends on the star's RA and the Local Sidereal time.

The Local Sidereal Time depends on the Greenwich Mean Sidereal Time (the Sidereal Time at Greenwich after accounting for small adjustments caused by the earth not being a perfect sphere) and the telescope's Longitude.

Greenwich's Sidereal Time depends on the Julian Date. Julian Date can be estimated from Unix Time.

So, if Raspbian's Unix Time has not been properly set by the ASIAIR app on the tablet, the star's altitude can be bogus. Or it could be a bug caused by some gross misunderstanding of the coordinate system.

Chen

« Previous Page Next Page »