How to setup meridian flip in AVX?: Page 3

How to setup meridian flip in AVX?

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

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

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

stevesp

For now I found a meridian setting in HC and default is do nothing
I set west preferred so yesterday it started avoiding the flip.
There is a both side selection that should solve the issue but I didn’t try it
I’ll let you know when I will make the test

w7ay

stevesp For now I found a meridian setting in HC and default is do nothing
I set west preferred so yesterday it started avoiding the flip.

To prevent accidents, the Meridian Limit and Horizon Limit of a mount should be set to halt tracking. Ignore it at your equipment's peril.

As for the Meridian Limit itself, choose a safe angle where none of your equipment has the opportunity to hit the pier.

If you want to use the auto meridian flip function in ASIAIR, set the time to "Stop tracking x min before Meridian" to be a minute or two before the Meridian limit that you have set in the mount. And set the "Do AMF x min after Meridian" to be a couple of minutes after both the mounts Meridian Limit and the Meridian itself (whichever is more westward).

I.e., choreograph it so that ASIAIR stops autoguiding and tracking (that first ASIAIR parameter) first. The world then waits for the mount to reach its own Meridian Limit (where it also disables tracking) and wait for further commands. And finally, when ASIAIR's clock reaches the second parameter, it will issue a GOTO to the mount. The idea being at that time, the star should have moved to the opposite side of the Meridian, and the GOTO therefore will cause the mount to execute a Meridian flip.

Be sure to level your mount in the east-west direction since that can affect where your mount thinks the Meridian is. If it is not level to 5 degrees in the wrong direction, the Meridian could be late by 20 minutes in time. Lots of people complain that their Meridian Flip is late and/or takes multiple tries (the ASIAIR pauses for a minute of time before it tries to issue another GOTO, to see if the mount flips). One of the reasons for this lateness could be their mount is not east-west leveled (4 minutes of time for each degree of error).

If the mount is not level, you would at least need to do an accurate star sync to "teach" the mount where the meridian really is. It is much easier to just level the mount with a cheap digital inclinometer while it is not dark enough yet to do star alignments.

Chen

Kring

Wanted to share that this is still an issue making it impossible to use the ASIair Pro. I've had 3 more failed nights, and 5 more failed indoor testing attempts... still 100% failure. the Sync & Goto continuously fails by saying every object is below the horizon. I've submitted in-app feedback 4x for each issue I experienced.

I'm convinced there is more than one issue at play, I can think of 4 distinct bugs that are causing this:

- As Chen pointed out above, there is an issue with LST or mis-match of where AAP is getting it's time and location from causing the sync and goto to fail. AAP is making up erroneous information or is pulling different information in different parts of the app, and they don't align. This appears to effect everyone, every mount.
- The Celestron Mounts driver is ABSOLUTLY BROKEN. It's always out of sync, home is wrong and doesn't match the mount, you can't set home, you can't set guiding rate, AAP doesn't read the data of the mount and makes wrong assumptions, it doesn't support the USB connection or WiFi,
- AAP has started to report the WRONG time of the day... (See Picture) My phone says 10:25, My Mount says 10:25 - Connect to the mount in ASIair and it reports the mount as saying it's 11:25.. off by an hour and clearly out of sync.. it's reading the mount incorrectly.. an hour is a substantial error. DST is off, but even turning it on for testing in never fixes.
- The goto catalog is having issues with certain objects and time, it may be related or an additional symptom to the first issue.. but bottom line is that the altitude charts are completely wrong.. at 10:25 am, the chart only shows 13:00 to 06:00 the following day.. so you can't see any altitude for the real & current time of day, and often the altitude charts are inverted and they show the object setting when it actuality it's rising.. so it's off by half a day.

I really hope ZWO can take a look at this as soon as possible and fix these core issues that shouldn't be that hard to fix, these are minor errors. I would be happy to test as well if there are beta's to confirm.

PMTeam@ZWO

Kring Hi！Try synchronizing in the AIR first and then calibrating using the handle

Kring

@asiair@zwo#44848

OK, I'll try that next, thx.

can you help us make sure this thread of issues is making to the Dev team, it looks like we've confirmed there are some errors based on this thread and extensive community testing.

PMTeam@ZWO

Kring Yeah, thank you for your feedback. We will fix the known errors in time

Kring

@asiair@zwo#44900

Fantastic! very excited for this... having two AAP's and been struggling with both, I feel like you are so so so close to it all just working! Once the time-sync issue is fixed, If you focus on the top mount compatibility and some enhancements to the Focuser for SCT's you'll have everything working consistently! going to be a great summer!

And thank you for listening to feedback and brining to the development team.

Desmond

Did this get resolved? Is there another thread that picks up where this ended?

ArthurKay

I am having the same (or similar) issues as described here with the AVX mount and ASI air pro after meridian flip. It seems that tracking causes the corrections to be backwards of what they should be. Flipping the calibration doesn’t help. So, every time I flip the meridian I have to recalibrate. I thought it was something I was doing wrong but it appears to be a bug. Any advice on how to resolve this?

w7ay

ArthurKay So, every time I flip the meridian I have to recalibrate.

The next time you have a chance to, do a guide calibration with a star east of the meridian. Check the Calibration Data (the circumscribed "i" icon) and note down the directions of the blue and red vectors that are drawn on top of the camera's x-y coordinates (white cross).

Then perform a GOTO to a star west of the meridian; this should move to the star through the pole (i.e., where a German mount performs a pier flip). Do not slew to the star on the west. Do a real GOTO. A slew will not do a pier flip.

Now do a guide calibration on the star on the west.

Check the calibration data picture again. Did both the blue and red vectors reverse directions, or did only the blue vector reversed direction?

There are two (perhaps 4) mappings between two spherical coordinate systems that will maintain continuous motion at the pole.

In one of the possible mappings (used by the majority of mounts), only the RA motor's direction is reversed after the pier flip.

In the second mapping (more rare in mounts), both the RA and the declination motors are reversed.

When you manually flip (with the flip switch in the Calibration Data panel) or when ASIAIR flips after an "auto meridian flip," the behavior is to only reverse (flip) the RA motor.

If both the blue and red vectors in the Calibration Data change directions after a pier change, you cannot just do a simple RA reversal. You need to reverse both motors.

During the v1.6 Beta program, ZWO added an option to also apply a declination motor reversal. But for some reason, that option vanished in the released version of ASIAIR v1.6.

Instead, what now appears is a "Recalibrate Guiding after AMF" switch in the "Meridian Flip Setting" window that you open from the Telescope Settings window (even though the window has nothing to do with the Telescope; it only has Mount settings).

You probably need to select this option for your mount. It takes more time than a simple "reverse both RA and declination motor" option, but at least you don't have to say awake to do it manually yourself.

Chen

ArthurKay

w7ay thanks for your detailed explanation. I hope I can try this weekend.

« Previous Page