AM5 not able to correct RA periodic error even with aggressive phd2 settings

kaiyung

@ASIMount@ZWO @Walf@ZWO @Tech@ZWO

I am trying to troubleshoot my AM5 guided via the ASCOM driver with phd2. From the screenshots below, my RA periodic error is roughly 40 arc-sec over one period of ₄ minutes, which translate to ₀.16 arc-sec per second. As you can see from my phd2 guide log graph, even at very aggressive correction settings, AM5 is not able to correct the error. I am aware that there is a bug that does not allow me to set the mount's guide rate (I assume it is fixed at 0.5x). Since the sidereal rate is around 15 arc-sec/sec, the mount should be able to adjust the rotation speed with a proper guide pulse. Is my mount defective? What is the hard-coded guide rate for the mount that I currently cannot adjust? Your help is greatly appreciated.

Kai

w7ay

kaiyung From the screenshots below, my RA periodic error is roughly 40 arc-sec over one period of 4 minutes, which translate to 0.16 arc-sec per second.

0.16"/sec (the average slope) is not the worst case error, since the peridoc error rate of change is not a constant. You need to look at the worst case slope of the periodic error, not the peak-to-peak value divided by 430.82 seconds.

Peak-to-peak is important only if you want to do unguided visual imaging. For guiding, you need to be able to keep up with the first derivative (how fast the error is changing). If you cannot keep that first derivative number low, it does not matter how small the peak-to-peak error is. I.e., peak-to-peak is irrelavant to guiding if you have high harmonic terms in the error curve (in layman terms, "curve that is not smooth").

Notice the second screenshot that you posted. An ideal mount would have a perfectly sinusoidal curve (since the worst case first derivative is also sinusoidal). But your mount has a very large third harmonic, and that is causing the first derivative of the error to be much larger than your stated 0.16"/sec value, at where those slopes are large, and I suspect that is where you cannot keep up.

You are using the white line below as the worst case slope; it is not. You mount's worst case slope is closer to the orange line:

What is worse is that I see other random bumps (that are larger than 1") that may have an instantaneous slope that is even worse than the orange line. You might want to first filter the curve to the frame rate of guiding (i.e., if you are guiding at 1 FPS, then you want to use a 1 Hz low pass filter) to see where the problem is really is. (In PHD2, you can try turning on the LPF2 option to see if it helps your guiding).

Chen

w7ay

kaiyung

By the way, once you have the RA axis solved, I also see a second problem from your curves.

Notice that there is a 430.82 second variation in your declination axis. If properly polar aligned, Declination axis error should not be synchronous with the RA axis error.

So, check for a cone error - make sure the RA and declination axes are orthogonal.

Another thing that can cause it is the wobble in a strain wave gear. Recall that a strain wave gear (first produced by Harmonic Drive™ Inc) does not really have a traditional output shaft. The output shaft is mounted on one of the splines. And when not machined precisely, the output shaft will wobble around a true fixed axis (kind of like the precession of a spinning top) -- if there is a large wobble, it will cause the declination axis to also produce an error in the declination axis that has the same period as the RA axis.

Chen

kaiyung

w7ay thank you for your insight. I agree that there's region where the first derivative is higher than 0.16. Let's assume that it's 10 times worse at 1.6 arc-sec per sec, this region is not the dominate feature over the 4+ minute period. For a guide speed of 0.5x sidereal of 15 arc-sec per sec, I just don't understand why repeated aggressive pulses cannot bring RA back toward neutral. I must be missing some concept on how Phd2 communicate with AM5 firmware that appears to under compensate the error. This is consistent over a period of an hour that I was troubleshooting. I wonder the bugg ASCOM driver has a very low guide rate that we cannot modify right now.

kaiyung

w7ay I will try to optimize Dec once the I am satisfied with an RA solution. Currently, my Dec error is around 0.2 arc-sec with 1 second exposure, so I can accept that. It's the elongated egg shape that I can't stand. Hope this can be resolved.

I don't understand how people using ASI air can arrive at such unbelievably good guiding performance. They must all image under perfect seeing conditions. This is a good upsale argument for me to get an ASI air, if not for the fact that I like modify open source platforms to suite my need.

w7ay

kaiyung They must all image under perfect seeing conditions.

Not really. With multiple star centroids, you do not need good seeing to get good guiding.

When seeing is reasonable and winds are calm, guiding can be quite good:

(Remember that at Bin2, the guide error is actually twice what ASIAIR displays).

The above is with my 3 year old RST-135 (a strain wave mount that uses Harmonic Drive gears; it has peak-to-peak PE of 60 arc seconds, but very low third harmonic).

Chen

kaiyung

w7ay that guide curve is what I can only dream about. Congratulations.

I am surprised that ASI air does not take take guide camera binning setting into account when displaying the error curve. Is your result with bin 1 or 2?

w7ay

kaiyung Is your result with bin 1 or 2?

The above is Bin2.

The ASIAIR does not produce fast enough frame rates for guiding with Bin1.

Cehn

kaiyung

w7ay so your actual guiding error is 0.54 arc-sec?

w7ay

kaiyung so your actual guiding error is 0.54 arc-sec?

I haven't checked lately, but if the plate scale in the ASIAIR has the same Bin2 bug as before like before, then, yes, something like 0.5" RMS.

Read my earlier positing regarding what I think about RMS measure, too. I don't think it means anything. What is more important is how long (in time) the guiding is off. RMS puts too much weight in short large errors, which do not appear on the final long exposure.

Your problem is different though, since you are seeing oval stars.

This is typical of what I get with 0.5" RMS type guiding error:

http://www.w7ay.net/site/Images/Lagoon.png

Chen

kaiyung

@Walf@ZWO @ASIMount@ZWO w7ay I believe to have found the cause of bad guiding performance when I use phd2 to guide my AM5. As you can see from the screenshot below, phd2 believes the current guide rate as reported by AM5's ASCOM driver to be a ridiculous value of 192.52x sidereal rate, which calculated to be 2800 arc-sec/sec for the expected RA and Dec guide rate as reported by phd2's calibration review panel. This must be due to the known AM5's ASCOM bug of reporting bad guide rate. Phd2 uses this value to determine the length of the guide pulse to correct the guiding error. If it believes the mount is using the guide speed of 2800 arc-sec/sec, then the correction pulse sent by phd2 would be quite small. That would explain why it is consistently under-correcting the error.

I am told that a fix for the ASCOM driver is to be released very soon. Please let me test it out to verify if this indeed fix my issue. Otherwise, my mount is just dead weight.

Kai

ASIMount@ZWO

kaiyung

kaiyung I am told that a fix for the ASCOM driver is to be released very soon. Please let me test it out to verify if this indeed fix my issue. Otherwise, my mount is just dead weight.

The new ASCOM version will be released soon, you can submit a ticket to ZWO support for a test version.

You can also refer to this post. https://bbs.astronomy-imaging-camera.com/d/14697-am5-ascom-driver/16

mfender

kaiyung As you can see from the screenshot below, phd2 believes the current guide rate as reported by AM5's ASCOM driver to be a ridiculous value of 192.52x sidereal rate, which calculated to be 2800 arc-sec/sec for the expected RA and Dec guide rate as reported by phd2's calibration review panel.

In my logs (those from AM-5 ascom driver and from ascom device hub) I see the
driver reporting the guide rate as a fraction of the sidereal rate, "0.5" for
example (regardless of the chosen guiderate, by the way).
As far as I understand the ascom standards,
https://ascom-standards.org/Help/Developer/html/P_ASCOM_DriverAccess_Telescope_GuideRateDeclination.htm
it should report in degrees per second, meaning "0.00417807421630556" in this case.
My other mounts do it like this.
The clients that rely on this value would be fooled by this huge guiding rate of "0.5 deg/sec".

Is this the "known AM5's ASCOM bug of reporting bad guide rate" kaiyung is
refering to?
Is there a fix on the horizon? The whole ascom driver needs several improvements,
frankly spoken, especially with the most rigid meridian handling (or the window handling
of the driver window(s) itself).

Matt

kaiyung

@ASIMount@ZWO#60046 @w7ay I got a great lead from an AP user with whom I shared my mount guiding issue with, as he observed that although I used a 1 second guide camera exposure, each guide correction from Phd2 to AM5 ASCOM driver takes more than 4 seconds. I dug into the AM5 ASCOM log and confirmed that it takes 3-4 seconds before the ASCOM driver acknowledge the move command, and thus I am effectively not guiding 3 out of every 4 seconds! This matches that I had reported earlier that the AM5 ASCOM driver is 1000x slower with command communication from a calling client compared with my sky watcher mount.

I really need to have a direct communication channel with the developer of this ASCOM driver to ensure that these bugs are resolved. Otherwise, poor folks like us will just spend endless days trying to track down these mount issues.

Here is a snippet from the log that demonstrate this issue. Please communicate this to the development team.

21:45:35.956 PulseGuide Set Direction: guideEast, Duration: 36
21:45:35.956 --> :Mge0036#
21:45:36.003 PulseGuide Over
21:45:36.003 IsPulseGuiding Get False
21:45:36.004 Slewing Get
21:45:36.004 --> :GU#
21:45:36.113 <-- NG0100211#
21:45:36.113 Slewing Get False
21:45:36.113 IsPulseGuiding Get False
21:45:36.114 PulseGuide Set Direction: guideNorth, Duration: 28
21:45:36.114 --> :Mgn0028#
21:45:36.145 PulseGuide Over
21:45:36.145 IsPulseGuiding Get False
21:45:37.782 --> :GU#
21:45:37.891 <-- NG0100211#
21:45:37.892 --> :GAT#
21:45:38.000 <-- 1#
21:45:41.013 --> :GU#
21:45:41.123 <-- NG0100211#
21:45:41.124 --> :GAT#
21:45:41.232 <-- 1#
21:45:43.688 Slewing Get
21:45:43.688 --> :GU#
21:45:43.799 <-- NG0100211#
21:45:43.799 Slewing Get False
21:45:43.799 IsPulseGuiding Get False
21:45:43.800 PulseGuide Set Direction: guideEast, Duration: 43
21:45:43.800 --> :Mge0043#
21:45:43.846 PulseGuide Over
21:45:43.852 IsPulseGuiding Get False
21:45:44.242 --> :GU#
21:45:44.353 <-- NG0100211#
21:45:44.353 --> :GAT#
21:45:44.464 <-- 1#
21:45:47.473 --> :GU#
21:45:47.584 <-- NG0100211#
21:45:47.584 --> :GAT#
21:45:47.616 Slewing Get
21:45:47.694 <-- 1#
21:45:47.694 --> :GU#
21:45:47.805 <-- NG0100211#
21:45:47.805 Slewing Get False
21:45:47.805 IsPulseGuiding Get False
21:45:47.805 PulseGuide Set Direction: guideEast, Duration: 70
21:45:47.805 --> :Mge0070#
21:45:47.883 PulseGuide Over
21:45:47.883 IsPulseGuiding Get False
21:45:50.710 --> :GU#
21:45:50.820 <-- NG0100211#
21:45:50.820 --> :GAT#
21:45:50.932 <-- 1#
21:45:51.482 Slewing Get
21:45:51.482 --> :GU#
21:45:51.597 <-- NG0100211#
21:45:51.597 Slewing Get False
21:45:51.597 IsPulseGuiding Get False
21:45:51.598 PulseGuide Set Direction: guideEast, Duration: 82
21:45:51.598 --> :Mge0082#
21:45:51.692 PulseGuide Over
21:45:51.692 IsPulseGuiding Get False
21:45:53.937 --> :GU#
21:45:54.046 <-- NG0100211#
21:45:54.047 --> :GAT#
21:45:54.155 <-- 1#
21:45:55.434 Slewing Get
21:45:55.434 --> :GU#
21:45:55.546 <-- NG0100211#
21:45:55.546 Slewing Get False
21:45:55.546 IsPulseGuiding Get False
21:45:55.547 PulseGuide Set Direction: guideEast, Duration: 218
21:45:55.547 --> :Mge0218#
21:45:55.765 PulseGuide Over
21:45:55.765 IsPulseGuiding Get False
21:45:55.766 Slewing Get
21:45:55.766 --> :GU#
21:45:55.876 <-- NG0100211#
21:45:55.876 Slewing Get False
21:45:55.876 IsPulseGuiding Get False
21:45:55.877 PulseGuide Set Direction: guideNorth, Duration: 33
21:45:55.877 --> :Mgn0033#
21:45:55.923 PulseGuide Over
21:45:55.923 IsPulseGuiding Get False
21:45:57.168 --> :GU#
21:45:57.277 <-- NG0100211#
21:45:57.278 --> :GAT#
21:45:57.387 <-- 1#
21:45:59.364 Slewing Get
21:45:59.364 --> :GU#
21:45:59.469 <-- NG0100211#
21:45:59.469 Slewing Get False
21:45:59.470 IsPulseGuiding Get False
21:45:59.470 PulseGuide Set Direction: guideEast, Duration: 172
21:45:59.470 --> :Mge0172#
21:45:59.643 PulseGuide Over
21:45:59.643 IsPulseGuiding Get False
21:45:59.644 Slewing Get
21:45:59.644 --> :GU#
21:45:59.754 <-- NG0100211#
21:45:59.754 Slewing Get False
21:45:59.754 IsPulseGuiding Get False
21:45:59.755 PulseGuide Set Direction: guideNorth, Duration: 42
21:45:59.755 --> :Mgn0042#
21:45:59.802 PulseGuide Over
21:45:59.802 IsPulseGuiding Get False
21:46:00.402 --> :GU#

Kai

w7ay

kaiyung

FYI, Kai:

21:45:35.956 --> :Mge0036#

Command to mount that means "Guide East for 36 milliseconds." So it agrees with "21:45:35.956 PulseGuide Set Direction: guideEast, Duration: 36"

And it looks like the next pulse command is sent 1 second later (guide north for 28 milliseconds):

21:45:36.114 --> :Mgn0028#

The next one (guide east) is 7 seconds later, however this could just be because the guide star did not move outside MinMo:

21:45:43.800 --> :Mge0043#

You can try turning MinMo down to 0.1" or something to see if you get more frequent guide pulse commands. Or, your problem could just be that it should be sending longer guide pulses than these 28 or 36 milliscond pulses.

Chen

kaiyung

w7ay the commands to sent that were 1 second apart were for the 2 different axis, (RA and DEC). The command to move East are separated by at least 4 seconds.

The pulse length is calculated by Phd2 and sent to the ASCOM driver. It is derived based on what it think is the current guide speed of the mount. So if the guide speed is 1x, then it will be shorted than that for guide speed of 0.5x by factor of 2. Since I cannot adjust the mount's guide speed because of an ASCOM driver bug, I am out of luck.

I had also turned down MinMo to a wide range of values, to as low as 0.05". But because the ASCOM driver won't respond to the move request for 3-4 seconds, MinMo won't help since Phd2 is still waiting for the driver to respond to the last request. In other word, these move commands are not asynchronous operations.

kaiyung

@ASIMount@ZWO#60046 @w7ay Sorry to be posting so frequent here, but I am now determined to find out the root cause of the guiding issue. I figured out that it's simple to control the AM5 directly via the USB/comm port. From the ASCOM driver's log, I also can figure out the communication protocol used and the communication traffic between the ASCOM driver and the AM5 firmware. There were a few weird responses I did not expect from the mount. For example, setting the LONGITUDE value with the sign flipped:

21:31:55.137 Set LONGITUDE -121[B0]48'00"
21:31:55.138 Sync Longitude to Mount -121[B0]48'00"
21:31:55.142 <-- 20:31:55#
21:31:55.143 --> :Sg+121*48:00#
21:31:55.252 <-- 1
21:31:55.252 Sync Longitude to Mount R True
21:31:55.252 Set Longitude to Mount Set Longitude to Mount successfully

For the issue I reported earlier in this thread, that it takes more than 4 seconds for Phd2 to send a correction pulse to the mount via the ASCOM driver, here is an example of the communication traffic:

21:42:00.457 Slewing Get False
21:42:00.458 IsPulseGuiding Get False
21:42:00.458 PulseGuide Set Direction: guideWest, Duration: 800
21:42:00.458 --> :Mgw0800#
21:42:01.264 PulseGuide Over
21:42:01.264 IsPulseGuiding Get False
21:42:01.721 --> :GU#
21:42:01.721 <-- NG0100211#
21:42:01.721 --> :GAT#
21:42:01.832 <-- 1#
21:42:04.841 --> :GU#
21:42:04.952 <-- NG0100211#
21:42:04.952 --> :GAT#
21:42:05.063 <-- 1#
21:42:05.152 Slewing Get
21:42:05.152 --> :GU#
21:42:05.267 <-- NG0100211#
21:42:05.267 Slewing Get False
21:42:05.267 IsPulseGuiding Get False
21:42:05.268 PulseGuide Set Direction: guideWest, Duration: 800
21:42:05.268 --> :Mgw0800#
21:42:06.073 PulseGuide Over

Notice that there is not any confirmation of a successful execution of the request being sent back by the mount or the ASCOM driver. I confirmed that with my manual invocation of this command directly to the AM5 firmware via USB, that although the mount does move, there is no feedback from the request at all. Any client making these types of requests (move or guide pulse commands) would expect an acknowledgement. If none is received, typical client logic would have a timeout before moving on to the next task.

This is very different from what the mount firmware does when I send the set longitude request above, where I do get a response of "1" as the success code.

I believe this is the root cause of all these ASCOM driver issues that I raised in this thread and other threads. Client apps like Phd2 or my star tracker issued move or pulse commands to the mount, but no feedback was received. (For these rapid move or pulse commands, they would typically just wait for the command was acknowledged to be received, not completed.) So these apps just wait until the request is deemed timeout. Each app will have different timeout settings, so in the case of Phd2, it takes 4 seconds before the next pulse command is issued.

Can the dev team confirm this? I have been developing software for quite a long time, and I hope this observation will help in getting a robust AM5 driver for us to use.

Kai

w7ay

kaiyung From the ASCOM driver's log, I also can figure out the communication protocol used and the communication traffic between the ASCOM driver and the AM5 firmware.

Kai, perhaps this will help; INDIGO documentation over at GitHub (some extensions to basic LX200 protocol):

https://github.com/indigo-astronomy/indigo/tree/master/indigo_drivers/mount_asi/docs

In general with mount protocols, not all commands have a response.

Warning: I have seen some obvious bugs in the AM5 documentation when I read through it (the :GT# one is most obvious), but I couldn't bother to report it since I don't own this mount.

Chen

kaiyung

w7ay In general with mount protocols, not all commands have a response.

Warning: I have seen some obvious bugs in the AM5 documentation when I read through it (the :GT# one is most obvious), but I couldn't bother to report it since I don't own this mount.

w7ay Where can I get hold of the AM5 documentation on the communication protocol? I am at a lost on the :GU# request. Also, if some of the commands do not expect responses, why is Phd2's pulse guide commands are 4 seconds apart? I tried 500ms exposure time and still see the 3 second delays between pulse requests, while 1 sec exposures is around 4 seconds delay. Strange.

w7ay

kaiyung Where can I get hold of the AM5 documentation on the communication protocol?

The link that I posted in my previous answer to you. Part of the INDIGO GitHub documents. You can also find the C code for how INDIGO implemented the AM5 in the LX-200 module.

In one of the two documents from my previous link, you can find the GU command documented as:

Chen