PHD2 Backlash Much Too Large
staffor...@gmail.com
I also see a very odd result in the GA Backlash plot. The plot starts normally with 24 N pulses (1200ms), upon which the guide star is displaced linearly in 24 equally spaced N steps. Then, there is one step (1200ms) with no guide star displacement followed by 4 more steps of N displacements of the same size as the first 24 N pulses during what are supposed to be S pulses. After these four wrong-way displacements, the guide star is displaced linearly in 20 equally spaced S steps (same size as the N steps).
I believe that if backlash was the culprit of the divergence between the Actual versus Ideal guide star displacements, the top of this plot should be flat rather than exhibiting four wrong-way displacements. Mount backlash correction / compensation is disabled.
I am achieving good guiding performance with unidirectional DEC guiding, as suggested by GA. However, since I am new to PHD2 and auto-guiding, I am wondering whether another attempt at bidirectional guiding with the "correct" backlash compensation is worth pursuing, or should I accept the very large PHD2 backlash measurement (much larger than I expect and seem to observe on my Orion HDX110 mount).
bw_msgboard
Hi <?>. I’ve embedded some comments below.
From: open-phd...@googlegroups.com
[mailto:open-phd...@googlegroups.com] On
Behalf Of staffor...@gmail.com
Sent: Monday, January 01, 2018
12:28 PM
To: Open PHD Guiding
Subject: [open-phd-guiding] PHD2
Backlash Much Too Large
When I center an alignment star at 1X slew rate (= sidereal), there is little or no detectable pause upon either DEC or RA direction reversal. However, when I run PHD2 Guiding Assistant, it reports a very large DEC backlash of 27.75px, 10652ms (guide speed 0.5x sidereal), and I believe this implies I should see 5.3s pause upon manual slew DEC reversal at 1X sidereal slew rate.
Why don’t you try setting the mount guide speed to 1x sidereal and see what the GA measures. One possibility is that you have a large Dec drift rate caused by poor polar alignment. To do this test accurately, you need to have a good polar alignment, probably 5 arc-min alignment error or less. We have an update to the backlash test coming that will better handle Dec drift due to polar alignment error but we’re not quite done with it yet. If you let the GA run for 5 minutes or so, it will report what your polar alignment error is.
I also see a very odd result in the GA Backlash plot. The plot starts normally
with 24 N pulses (1200ms), upon which the guide star is displaced linearly in
24 equally spaced N steps. Then, there is one step (1200ms) with no guide star
displacement followed by 4 more steps of N displacements of the same size as
the first 24 N pulses during what are supposed to be S pulses. After these four
wrong-way displacements, the guide star is displaced linearly in 20 equally
spaced S steps (same size as the N steps).
If you’ll attach your debug log file, we can look, but what you’re seeing is the performance of your mount. If PHD2 is reporting south pulses, that’s what’s being sent. But this apparent retrograde movement in Dec could be caused by large Dec drift, as mentioned above.
I believe that if backlash was the culprit of the divergence between the Actual
versus Ideal guide star displacements, the top of this plot should be flat
rather than exhibiting four wrong-way displacements. Mount backlash correction
/ compensation is disabled.
I am achieving good guiding performance with unidirectional DEC guiding, as
suggested by GA. However, since I am new to PHD2 and auto-guiding, I am
wondering whether another attempt at bidirectional guiding with the
"correct" backlash compensation is worth pursuing, or should I accept
the very large PHD2 backlash measurement (much larger than I expect and seem to
observe on my Orion HDX110 mount).
Don’t get too fixated on what the “correct” amount is. The PHD2 backlash comp feature is adaptive, so the initial amount is simply a starting point. It will be automatically adjusted up or down depending on how things are going. But of course it isn’t going to work well with a backlash as large as 10 sec. You can probably sanity-check this yourself by guiding in both Dec directions at 1x sidereal while leaving the PHD2 backlash comp feature disabled. When there are direction reversals, the guiding graph will show the delay in getting the axis moving in the new direction. And the guide log will show how many pulses were required to accomplish it – basically a replication of what the Guiding Assistant is doing.
Having said all that, you say you’re getting good guiding performance. Do you know that uni-directional Dec guiding is the limiting factor on that?
Bruce
--
You received this message because you are subscribed to
the Google Groups "Open PHD Guiding" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to open-phd-guidi...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
staffor...@gmail.com
On Monday, January 1, 2018 at 2:06:26 PM UTC-7, Bruce Waddington wrote:
Hi <?>. I’ve embedded some comments below.
Howdy Bruce; I also embedded some answers below, and attached DebugLog.
From: open-phd...@googlegroups.com [mailto:open-phd...@googlegroups.com] On Behalf Of staffor...@gmail.com
Sent: Monday, January 01, 2018 12:28 PM
To: Open PHD Guiding
Subject: [open-phd-guiding] PHD2 Backlash Much Too Large
When I center an alignment star at 1X slew rate (= sidereal), there is little or no detectable pause upon either DEC or RA direction reversal. However, when I run PHD2 Guiding Assistant, it reports a very large DEC backlash of 27.75px, 10652ms (guide speed 0.5x sidereal), and I believe this implies I should see 5.3s pause upon manual slew DEC reversal at 1X sidereal slew rate.
Why don’t you try setting the mount guide speed to 1x sidereal and see what the GA measures. One possibility is that you have a large Dec drift rate caused by poor polar alignment. To do this test accurately, you need to have a good polar alignment, probably 5 arc-min alignment error or less. We have an update to the backlash test coming that will better handle Dec drift due to polar alignment error but we’re not quite done with it yet. If you let the GA run for 5 minutes or so, it will report what your polar alignment error is.
I also see a very odd result in the GA Backlash plot. The plot starts normally with 24 N pulses (1200ms), upon which the guide star is displaced linearly in 24 equally spaced N steps. Then, there is one step (1200ms) with no guide star displacement followed by 4 more steps of N displacements of the same size as the first 24 N pulses during what are supposed to be S pulses. After these four wrong-way displacements, the guide star is displaced linearly in 20 equally spaced S steps (same size as the N steps).
If you’ll attach your debug log file, we can look, but what you’re seeing is the performance of your mount. If PHD2 is reporting south pulses, that’s what’s being sent. But this apparent retrograde movement in Dec could be caused by large Dec drift, as mentioned above.
I believe that if backlash was the culprit of the divergence between the Actual versus Ideal guide star displacements, the top of this plot should be flat rather than exhibiting four wrong-way displacements. Mount backlash correction / compensation is disabled.
I am achieving good guiding performance with unidirectional DEC guiding, as suggested by GA. However, since I am new to PHD2 and auto-guiding, I am wondering whether another attempt at bidirectional guiding with the "correct" backlash compensation is worth pursuing, or should I accept the very large PHD2 backlash measurement (much larger than I expect and seem to observe on my Orion HDX110 mount).
Don’t get too fixated on what the “correct” amount is. The PHD2 backlash comp feature is adaptive, so the initial amount is simply a starting point. It will be automatically adjusted up or down depending on how things are going. But of course it isn’t going to work well with a backlash as large as 10 sec. You can probably sanity-check this yourself by guiding in both Dec directions at 1x sidereal while leaving the PHD2 backlash comp feature disabled. When there are direction reversals, the guiding graph will show the delay in getting the axis moving in the new direction. And the guide log will show how many pulses were required to accomplish it – basically a replication of what the Guiding Assistant is doing.
Having said all that, you say you’re getting good guiding performance. Do you know that uni-directional Dec guiding is the limiting factor on that?
Bruce
bw_msgboard
Hi Fritz. I’m attaching an excerpt from the debug log file that shows the gory details of the backlash test. You can find these in the debug log file by searching for “BLT”. You can see pretty clearly what happened when the ‘south’ pulses started, just as the diagram showed. Your polar alignment was clearly good enough, so the retrograde motion is not caused by that. The GA measured the Dec drift rate at 0.34 px/min, so the elapsed time taken for the first 4 south moves would have been affected by less than a 0.09px drift. So I would say this is a mechanical problem, perhaps an issue with the gear mesh.
I notice you didn’t change the guide speed to 1.0x sidereal before running the test – seems like that would be worth doing if you still have doubts. It might also help to over-power any other sort of binding that might be occurring. To check the results visually, you can use the Manual Guide tool in PHD2. Set the pulse size to be 1200 ms, then issue many pulses north until you can see the guide star moving at a consistent rate. Then start issuing the same number of pulses south – you will see the delay. When using the Manual Guide tool, be sure to let each guide pulse complete, it doesn’t work if you just bang away quickly on the direction buttons.
Good luck,
Bruce
staffor...@gmail.com
The log I sent previously was from night before last (New Years Eve) to illustrate excessive backlash reported by PHD2 Guiding Assistant and described in my original Post (conducted at Guide Speed 0.5x sidereal).
Based on your suggestions from yesterday (New Years Day), I set Guide Speed to 1x sidereal, recalculated / reset guide pulse to 500ms, repeated PHD2 calibration followed by brief guiding session to observe guiding behavior at 1X guide speed (guiding performance ~same at same guide parameter settings), repeated Guiding Assistant test. See attached DebugLog.
Note that I began last night's calibration / testing by adjusting guide scope alignment with main scope / mount by adjusting guide scope mounting ring screws (i.e., no mount adjustments), and this is reflected in decrease of PA error to 3.8 arc-min (previously 4.2 arc-min).
The DebugLog shows significant improvement of PHD2 reported "backlash" to 22.7px (previously 27.75px), but this is still excessive, although it is now reduced to 4383ms at 1x sidereal guide speed. The PHD2 backlash plot still shows the same odd behavior described previously, but with only three "wrong-way" displacements.
I followed the GA test with a longer auto-guiding session to observe performance / stability, and results were good.
I then conducted the manual guiding tests to directly observe backlash upon DEC guide direction reversals. The results were consistent with what I reported previously, but now quantifiable. I issued several manual DEC guide pulses in same direction and waited long enough between pulses to observe guide star position stability over several looping cycles. I observed consistent guide star displacements with each pulse AND position stability between pulses. I then issued several manual DEC guide pulses in the opposite direction. Upon the first opposite direction guide pulse, I observed no guide star displacement (and certainly no hint of displacement in the wrong direction), and then upon the second opposite direction guide pulse, the guide star was displaced in the opposite (correct) direction by at least half of the magnitude of stable displacement in the previous direction. Subsequent opposite direction guide pulses produced consistent opposite direction guide star displacements (same magnitude as previous direction displacements) with position stability between pulses.
I repeated this test multiple times in both directions, and the results were very consistent.
Hence, I conclude real backlash at 1x sidereal guide speed is <750ms versus the PHD2 reported "backlash" of 4383ms. I suspect the cause of this PHD2 reported "backlash" inconsistency is preventing usage of bidirectional DEC guiding. I am using On-Camera (ST4) mount interface with SkyWatcher Auxiliary mount (i.e., SkyWatcher EQ8 = Orion HDX110), as I have not been able to PHD2 Calibrate with ASCOM mount interface (camera exposures and mount movements appear to not be coordinated properly).
Note all these tests and calibration were performed on the same star at ~10 degrees DEC and ~+/- 1 hour of local meridian.
Thanks,
Fritz
staffor...@gmail.com
We scientists have an annoying characteristic of developing postulates to explain our observations. So, here is my suspicion:
Even though the guide algorithm output has been disabled, I suspect the Guiding Assistant guide pulse outputs are still being shaped by the Resist Switch algorithm parameters. This does explain the three wrong-way pulses upon guide direction switch.
Thanks,
Fritz
bw_msgboard
From:
open-phd...@googlegroups.com [mailto:open-phd...@googlegroups.com] On Behalf Of staffor...@gmail.com
Sent: Tuesday, January 02, 2018
11:54 AM
To: Open PHD Guiding
Subject: Re: [open-phd-guiding]
PHD2 Backlash Much Too Large
Howdy Bruce;
We scientists have an annoying characteristic of developing postulates to
explain our observations. So, here is my suspicion:
Even though the guide algorithm output has been disabled, I suspect the Guiding
Assistant guide pulse outputs are still being shaped by the Resist Switch
algorithm parameters. This does explain the three wrong-way pulses upon guide
direction switch.
Thanks,
Fritz
Hi Fritz. I’m afraid we’re wandering very far afield from the main point, which is for you to experiment with bi-directional Dec guiding. Yes, hypotheses are good things but I think it’s better in this case to simply look at the source code and see how things work. This is an open source project, you can examine anything you want. The Guiding Assistant and backlash tests have well-established behaviors, and the backlash test issues fixed-sized pulses to the mount, no guiding algorithms are involved. So from my point of view, the observed behavior is simply a function of your mount. I haven’t looked at your latest debug log to see why your manual tests didn’t replicate what the backlash test does but I don’t think that’s important. I doubt it would convince you that your mount has both backlash and some other mechanical problem.
So let’s move on to a misconception you have with regard to bi-directional guiding:
Hence, I conclude real backlash at 1x sidereal guide speed is <750ms versus the PHD2 reported "backlash" of 4383ms. I suspect the cause of this PHD2 reported "backlash" inconsistency is preventing usage of bidirectional DEC guiding. I am using On-Camera (ST4) mount interface with SkyWatcher Auxiliary mount (i.e., SkyWatcher EQ8 = Orion HDX110), as I have not been able to PHD2 Calibrate with ASCOM mount interface (camera exposures and mount movements appear to not be coordinated properly).
In order to use the ASCOM interface to your mount, a number of parameters must be set correctly in the EQASCOM application:
https://github.com/OpenPHDGuiding/phd2/wiki/EQASCOM-Settings
We probably have hundreds of users at this point who use that interface but you can use the ST-4 interface if you prefer. The real point is that all of the Guiding Assistant output – including backlash measurements – are purely advisory. They are optional, they are available to just to help you. If you’re convinced they are wrong, you can ignore them altogether. You can choose bi-directional guiding by simply specifying a Dec guide mode of ‘auto.’ Nothing whatsoever is preventing it. If you want to experiment with Dec backlash compensation, you can turn it on and enter whatever value you want as the correction:
If you think you have a backlash value that’s accurate based on just eyeball tests, go ahead and try it. I expect it will fail pretty quickly, but you won’t have done any harm and you can go back to either uni-directional guiding or bi-directional guiding without backlash compensation. All of this is entirely under your control.
Have fun,
Bruce
Ken Self
bw_msgboard
Hi again, Fritz. I had a few minutes to look at your debug log to see why you couldn’t duplicate the GA backlash test result. It’s because you didn’t issue nearly enough guide pulses north – you have to be sure to clear all the backlash in that direction in order to get a useful result. Since you have a scientific bent, let’s try this. The hypothesis (which you’d like to defeat) is that your mount has at least 5 sec of backlash when guiding at 1x sidereal. That means, in the worst case, you would need to issue 10 north pulses of 500 ms in order to fully clear the backlash and get the mount moving. It might take less than that but you can’t know a priori. So to do the test manually, issue more than 10 north pulses – 14, 16, whatever. Then issue the same number of pulses in the south direction and see what you get. If you want to get a record of it, start a long exposure with your main camera, one that’s long enough to capture the full range of star movement. So, if you were going to move for 8 seconds in each direction, something like a 30-45 sec exposure would work. That would give you time for short pauses between guide pulses and you would probably see successive stopping points of the guide star in the final image. Try it! <g>
Bruce
From: open-phd...@googlegroups.com [mailto:open-phd...@googlegroups.com] On Behalf Of staffor...@gmail.com
Sent: Tuesday, January 02, 2018
11:54 AM
Brian Valente
To unsubscribe from this group and stop receiving emails from it, send an email to open-phd-guiding+unsubscribe@googlegroups.com.
staffor...@gmail.com
I really appreciate your patience with me.
Please do not misinterpret my ignorance. I have no preconception that my mount has minimal backlash and no other issues. I have simply not been able to corroborate PHD2 reported backlash with what I have observed manually. Certainly, if my mount has 5sec backlash at 1x guide speed, then it has major mechanical problem.
It is true I had believed that once the mount starts to move in consistent steps in the direction of the guide pulses, all backlash had been cleared. Obviously, you believe otherwise. (I am having difficulty understanding / picturing how this could be, as I have previously dealt with backlash on lathe and milling machine.) I will do the test as you suggested, and take it out to 26 N pulses to exactly replicate what GA did last night. I will also measure the guide star displacements. My next opportunity to try this will be this next weekend, Sunday weather looks good.
It is also true that after 25 year career as Master Scientist at HP - Printing Hardware, I have natural distrust of software, as the software / firmware teams always blamed the hardware / hardware supplier (ASIC / ASSP) as the cause of all problems, and then most of the time we hardware folks had to find the cause of the problems in their software / firmware.
I am getting good guiding performance with unidirectional DEC guiding, but at this point I do not have confidence in either my mount or PHD2.
I see that all are urging me to move on and attempt ASCOM bidirectional DEC guiding, but I first need to understand (and hopefully fix) any mount problem.
Thanks,
Fritz
bw_msgboard
Hi Fritz. We really are happy to help you sort through this and get comfortable with what PHD2 is doing – especially now that you’ve provided some additional context. In most cases, debug log output is very literal and simple. For example, in the backlash test, the output to the debug log is within one or two source lines of where the command is sent to the mount, and the same variables are used without any massaging. We need that ourselves during development and we typically leave it in place for user support. Once a feature has been put in a general release and has been available for a while, it’s usually going to be used by literally thousands of users and dozens of different mounts. So any remaining bugs are usually exposed very quickly and we are equally anxious to fix them. We use the development releases ourselves for imaging so you can imagine that we are extremely intolerant of bugs. <g>
Another thing that’s different about guiding is how noisy the data are. Seeing is entirely non-deterministic and different mounts can exhibit all kinds of irregular behaviors that often depend on gravitational loading and pointing orientation. That’s why back-to-back measurements like what is done in the Guiding Assistant will typically produce somewhat different results. What we call backlash is often more complex than that, particularly with less-expensive mounts. What we see as the end-product of a direction reversal can be a combination of pure backlash, stiction, binding, flexure in various parts of the gear system, slop in the bearings – the list goes on. If you’re used to working with precision manufacturing gear, you may also be accustomed to much higher manufacturing quality and tighter tolerances. A 5-sec Dec backlash with the EQ class of mounts would not be unusual at all from what I’ve seen – we see mounts with backlash that is twice that amount or even more. In some cases, users have been able to get significant improvement by disassembling and then re-assembling the mount, taking extra care to get things right. The weaknesses in some of these mounts can be due to poor assembly rather than design shortcomings, at least up to a point.
Anyway, hope that helps – and we’ll be interested to know what you find out.
Cheers,
staffor...@gmail.com
I have not yet had another chance to perform the manual backlash test to replicate what GA does, as the weather has been uncooperative. This coming weekend may provide opportunity. However, I have continued to study what I have done, what is recommended (including your PHD2 Best Practices Power Point), and log files.
The one thing that really sticks out as unexplained is the three (or four?) "wrong-way" guide start displacements upon direction reversal during GA backlash measurement. I have now determined this is also occurring during calibration.
I have also attempted to better understand how all the pieces of the system interact to produce the observed outcome, and I can point to no evidence indicating PHD2 as the culprit. There are numerous possibilities, so I have decided to attempt to rule out some of these possibilities (e.g., replace ASCOM Mallincam Driver with Windows WDM-style webcam camera driver as recommended by Rock Mallin for his SkyRaider AGm auto guider (video) camera, replace On-camera (ST4) mount driver with EQASCOM mount driver, replace SynScan Hand Controller in "PC Direct" mode with Shoestring Astronomy USB2EQ5 Direct Control mount cable).
The Orion HDX110 mount (= SkyWatcher EQ8 top of the line mount) has been very well balanced from the start. The guide scope is piggy-back mounted with Losmandy rings on a Losmandy dovetail plate, and while this is not the optimal guide scope mount, the oversize ring adjustment screws have nylon tips and are very snug. (I will be upgrading to Vixen X-Y guide scope mount soon.) The guide scope flexure is minimal as I am using Vixen 2" to 1.25" flip mirror "diagonal" that weighs 8 ounces with 2 ounce guide camera and <1cm of back focus.
I have question about your PHD2 Best Practices comment,
Thanks,
Fritz
staffor...@gmail.com
I neglected to mention this is new observatory / permanent mount that just saw first light for the Great American Eclipse, http://team.bobs-bicycles.com/photo-galleries/2017-eclipse-gallery/
The HDX110 mount sits on an 8.5" x 38" SkyShed pier, and the pier is bolted to 14" x 8' reinforced concrete footing excavated into bedrock. I had trouble getting repeatable polar alignment until I finally discovered three loose screws on the RA housing.
The mount worked fine during the late summer and fall polar alignment challenge, but when I moved on to setting up auto-guiding the winter 20F weather arrived, and the mount exhibited DEC motor binding, especially when pointing towards zenith. I decided to adjust the backlash, and this was another challenge, as it took multiple efforts between achieving even worse binding, to too much backlash, and then finally just right (I think). When I began these backlash adjustments, I found the DEC motor was not installed as pictured in the manual, so I corrected this.
I am hoping that further disassembly and reassembly will not be required, but I have no illusion that my mount has minimal backlash or any other mechanical issues.
Thanks,
Fritz
bw_msgboard
Hi Fritz. I don’t use EQASCOM so I have to rely on the user documentation they post on their web site. They describe panels in the UI for things like “RA/DEC pulse width Override’ and ‘Pulseguide Minimum Pulsewidth (millisecs). In another window – the “PulseGuide Monitor” – they have sliders for ‘RA Width Gain’ and ‘Dec Width Gain.’ Those are the things we’re talking about, and there may be more that I’m not aware of. While these things may be useful for some guiding software, they will be a disaster for guiding with PHD2. What we want with the mount driver and mount controller is that they do exactly what they are asked to do by PHD2, no more and no less. We also recommend a fairly high guide speed setting in the mount, certainly 0.5x or above. I think the default speeds in EQASCOM are very low, well below 0.5x.
Permanent periodic error correction in the mount controller is recommended for use with PHD2. Assuming the correction is done in the controller, it reduces the amount of work that has to be done by auto-guiding.
Hope this helps,
Andy Galasso
staffor...@gmail.com
The funny thing is I thought you recommended EQASCOM. It certainly has many features, some very attractive (e.g., VS-PEC based on a curve fit of many, >10, worm cycles rather than playing back a single cycle of corrections), and some that need to be disabled for PHD2.
Your reply implies the Hand Controller is connected to the mount and is used to select Sidereal + PEC tracking mode (based on PEC correction recorded and stored in the Hand Controller) before the Hand Controller is placed in PC Direct mode for ASCOM auto-guiding. I am not sure this is the case for all ASCOM mount drivers, but it is true for EQASCOM.
While EQASCOM can be operated in this way, they have a disclaimer about usage in this mode as they do not have design access for PC Direct mode, and it cannot be included in their "design center". Hence, they strongly recommend EQASCOM usage with Hand Controller replaced with "EQDir" cable (EQ Direct), and they point out this is the only way to achieve the ideal 16ms RS232 latency whereas the Hand Controller in PC Direct mode doubles latency to 32ms.
EQASCOM also claims that their VS-PEC is not an additional set of pulse guide commands run on top of the Sidereal tracking (as are the auto-guiding commands), but rather the derived PEC curve is incorporated into the Sidereal tracking rate, and this enables superior guiding by not introducing corrections to spurious excursions that occurred during the PEC training cycle which can "fight" with the auto-guiding corrections.
I know that PHD2 recommends guide rate 0.5x - 1x, and you have recommended 1x as starting point. I also know that PHD2 reads the guide rate from the "mount" which is programmed by the hand controller. I do not know whether this guide rate is stored in the hand controller or the motor controllers in the mount, but I know the hand controller is only capable of programming a single guide rate which is used for both RA and Dec. EQASCOM allows separated RA and Dec guide rates of 0.1x, 0.2x, 0.3x, 0.4x, 0.5x, 0.6x, 0.7x, 0.8x, and 0.9x. I assume this would be the guide rate PHD2 would read from the "mount", if the Hand Controller is replaced by EQDir cable (unless guide rate is stored in non-volatile memory on motor controller boards from when they were previously programmed by Hand Controller?). I am even less certain what guide rate PHD2 would read, if the Hand Controller is connected to the mount and placed in PC Direct mode.
Such an interesting puzzle. I suspect you will counsel not to get so anal about how this all works...
Thanks,
Fritz
staffor...@gmail.com
staffor...@gmail.com
I just noted that you are the coauthor of the PHD2 Best Practices Power Point. I feel honored to be getting the attention of the experts.
Thanks,
Fritz
On Tuesday, January 9, 2018 at 2:55:10 PM UTC-7, Andy Galasso wrote:
bw_msgboard
Hi Fritz. Wow, I can’t imagine what I said that would generate all this. J Let me reiterate what I thought I’ve said in the past.
- We recommend using an ASCOM connection for any mount that supports it rather than using ST-4 guiding. Different mounts have different ASCOM drivers and different ways of connecting the PC to the mount controller.
- I really don’t know beans about any of the EQ series mounts. My impression is that using ASCOM pulse guiding with them requires use of the EQASCOM software. If that is correct, there are certain settings that need to be correct in the EQASCOM user interface – those are what we’ve documented. I have no idea what role a hand-controller has in any of this, and I’m not recommending anything specific beyond what it takes to use ASCOM pulse-guiding.
- You should quit fretting about what guide speed values might be read from the mount. These have no effect on how PHD guides, they are used only as a way to sanity check certain things. If the sanity checks look funny, you’ll see an alert message in PHD2 which you are free to ignore. Guiding will proceed in any case.
If you are bogged down in how to get ASCOM working with your mount, you should probably ask questions on one of the EQ forums. There are probably hundreds of PHD2 users who are doing it, it can’t be all that complicated. There’s only so much we can do on this forum, we can’t know all the details for the dozens of different mounts out there.
staffor...@gmail.com
I have EQASCOM working with my mount, sort of. I have successfully been able to get Cartes du Ciel to point the mount and use the EQASCOM driver to slew the mount at speeds ranging from 1x to 800x sidereal. I have also been able to get PHD2 to connect to the mount, but since weather has not cooperated, I have not been able to do any Calibration, GA or auto-guiding. All of this has been with SynScan Hand Controller in PC Direct mode.
I have EQDir cable from ShoestringAstronomy arriving in next day or two, so I hope to test this weekend.
There is also a SkyWatcher ASCOM driver on the ASCOM web site, and I have been able to connect to my mount with this via Hand Controller in PC Direct mode. I have not explored this driver any further, as the EQASCOM driver has many more capabilities (e.g., superior VS-PEC), including the possibility to achieve ideal RS232 latency. Remember, one of my goals is to eliminate all possible causes of the "wrong-way" guide star displacements seen in GA backlash measurements AND Calibration. Of course, my main goal is to achieve sanity check between GA backlash measurement and what I observe via other means, and this will give confidence that Calibrations are correct AND that there is no undue thrashing occurring during auto-guiding.
I am member of EQASCOM Yahoo forum, I have read their horrible 178 page manual several times, I have been able to confirm that EQ8 mount is supported via firmware update log.
I have asked you questions, as your are so responsive.
Thanks,
Fritz
staffor...@gmail.com
I am very pleased that I am achieving good guiding performance with PHD2, 0.6" - 0.7" RMS on both RA and (unidirectional) Dec with occasional 1.5" peak excursions and worst case 2.0" peaks. See attached Orion image processed from eight 10 minute subs obtained on 1/14/2018 during ~2 hour window of OK evening visibility with light haze before the fog coalesced.
However, I do have the concern that PHD2 in concert with the Mallincam AGm camera and its' ST4 interface / firmware is generating anomalous behavior. As previously reported, this anomalous behavior manifests as large backlash measurement by Guiding Assistant. The key unexplained observation is that when GA reverses the direction of the DEC guide pulses during backlash measurement, there are three subsequent "wrong-way" guide star displacements. This is clearly visible in the GA backlash plot and log file (too large to attach, so here is Google drive link,
https://drive.google.com/file/d/1_zGJimpf5FltqZ92jYEPEcdAvmiMeJee/view?usp=sharing , accessible with email address, open-phd...@googlegroups.com ).
As I have become more familiar with PHD2, I also observe these three "wrong-way" guide star displacements during Calibration upon direction reversal of BOTH Dec (as previously reported) AND RA (new report!!!). The good news is that there are no wrong-way guide star displacements upon RA direction reversal during normal auto-guiding (New report!!!).
I have received guidance from multiple PHD2 experts not to be concerned with this anomalous behavior, as long as good guiding performance is being achieved. However, I have 30 years of experience with software / firmware as Printing and Imaging Hardware Scientist, and I have had numerous experiences where (ignored / tolerated) anomalous behavior has come back to bite you, resulting in new product delays.
Thanks,
Fritz
bw_msgboard
Hi Fritz. As far as I can tell, you’re using ASCOM pulse-guiding to move the mount, which is a good thing. So the Mallincam camera and the ST-4 interface are not being used. If you have an ST-4 cable connected between the camera and the mount, you need to get that out of there. That cable can transmit unintended signals that are interpreted as guide commands.
Beyond that, I can tell you I’ve seen this sort of “retrograde” movement on a few other inexpensive mounts but I have no idea what causes it. I’m highly confident it isn’t PHD2. But if you really want to get to the bottom of all this, you’ll need to develop your own ability to examine logs to see what is actually being transmitted to the mount. If you open the PHD2 debug log file, you can do a text-search on “calibration move”. Those entries (and neighboring ones) show the direction of the commands and the length of the guide pulse. The directions are 0=north, 1=south, 2=east, 3=west. If you do that with your log, you’ll see the directions are being switched correctly, without delay, when appropriate. Be careful to not get confused when you stop the calibration prematurely, which you did several times.
When you are satisfied with this, you can move on to what the ASCOM driver is doing. Hopefully, it produces its own log and you can parse that. If it doesn’t do logging, you’ll have to put a serial line monitor on the COM port being used for guiding. To understand what those commands look like on the wire, you’ll also need to know the low-level command protocol used by the mount and exactly how it supports pulse-guiding. I anticipate this will all be a waste of time but you might enjoy the learning process. I suspect the problem is either in the mount controller or the mount mechanics and I don’t know who could help you with that.
Good luck,
Bruce
From:
open-phd...@googlegroups.com [mailto:open-phd...@googlegroups.com] On Behalf Of staffor...@gmail.com
Sent: Saturday, January 20, 2018
10:11 AM
To: Open PHD Guiding
Subject: Re: [open-phd-guiding]
PHD2 Backlash Much Too Large
Howdy Bruce, Andy and All;
I am very pleased that I am achieving good guiding performance with PHD2,
0.6" - 0.7" RMS on both RA and (unidirectional) Dec with occasional
1.5" peak excursions and worst case 2.0" peaks. See attached Orion
image processed from eight 10 minute subs obtained on 1/14/2018 during ~2 hour
window of OK evening visibility with light haze before the fog coalesced.
However, I do have the concern that PHD2 in concert with the Mallincam AGm
camera and its' ST4 interface / firmware is generating anomalous behavior. As
previously reported, this anomalous behavior manifests as large backlash
measurement by Guiding Assistant. The key unexplained observation is that when
GA reverses the direction of the DEC guide pulses during backlash measurement,
there are three subsequent "wrong-way" guide star displacements. This
is clearly visible in the GA backlash plot and log file (too large to attach,
so here is Google drive link,
https://drive.google.com/file/d/1_zGJimpf5FltqZ92jYEPEcdAvmiMeJee/view?usp=sharing
, accessible with email address, open-phd...@googlegroups.com ).
As I have become more familiar with PHD2, I also observe these three
"wrong-way" guide star displacements during Calibration upon
direction reversal of BOTH Dec (as previously reported) AND RA (new report!!!).
The good news is that there are no wrong-way guide star displacements upon RA
direction reversal during normal auto-guiding (New report!!!).
I have received guidance from multiple PHD2 experts not to be concerned with
this anomalous behavior, as long as good guiding performance is being achieved.
However, I have 30 years of experience with software / firmware as Printing and
Imaging Hardware Scientist, and I have had numerous experiences where (ignored
/ tolerated) anomalous behavior has come back to bite you, resulting in new
product delays.
Thanks,
Fritz
On Tuesday, January 9, 2018 at 4:55:58 PM UTC-7, staffor...@gmail.com wrote:
Howdy
Bruce;
I have EQASCOM working with my mount, sort of. I have successfully been able to
get Cartes du Ciel to point the mount and use the EQASCOM driver to slew the
mount at speeds ranging from 1x to 800x sidereal. I have also been able to get
PHD2 to connect to the mount, but since weather has not cooperated, I have not
been able to do any Calibration, GA or auto-guiding. All of this has been with
SynScan Hand Controller in PC Direct mode.
I have EQDir cable from ShoestringAstronomy arriving in next day or two, so I
hope to test this weekend.
There is also a SkyWatcher ASCOM driver on the ASCOM web site, and I have been
able to connect to my mount with this via Hand Controller in PC Direct mode. I
have not explored this driver any further, as the EQASCOM driver has many more
capabilities (e.g., superior VS-PEC), including the possibility to achieve
ideal RS232 latency. Remember, one of my goals is to eliminate all possible
causes of the "wrong-way" guide star displacements seen in GA
backlash measurements AND Calibration. Of course, my main goal is to achieve
sanity check between GA backlash measurement and what I observe via other
means, and this will give confidence that Calibrations are correct AND that
there is no undue thrashing occurring during auto-guiding.
I am member of EQASCOM Yahoo forum, I have read their horrible 178 page manual
several times, I have been able to confirm that EQ8 mount is supported via
firmware update log.
I have asked you questions, as your are so responsive.
Thanks,
Fritz
On Tuesday, January 9, 2018 at 4:07:51 PM UTC-7, Bruce Waddington wrote:
Hi Fritz. Wow, I can’t imagine what I said that would generate all this. J Let me reiterate what I thought I’ve said in the past.
1. We recommend using an ASCOM connection for any mount that supports it rather than using ST-4 guiding. Different mounts have different ASCOM drivers and different ways of connecting the PC to the mount controller.
2. I really don’t know beans about any of the EQ series mounts. My impression is that using ASCOM pulse guiding with them requires use of the EQASCOM software. If that is correct, there are certain settings that need to be correct in the EQASCOM user interface – those are what we’ve documented. I have no idea what role a hand-controller has in any of this, and I’m not recommending anything specific beyond what it takes to use ASCOM pulse-guiding.
3. You should quit fretting about what guide speed values might be read from the mount. These have no effect on how PHD guides, they are used only as a way to sanity check certain things. If the sanity checks look funny, you’ll see an alert message in PHD2 which you are free to ignore. Guiding will proceed in any case.
staffor...@gmail.com
It appears that a backlog of three images builds up while GA and Calibration routines drive the guide star in W / N directions before reversing direction, and then PHD2 continues analyzing the backlog images on FIFO bases which results in the apparent "wrong-way" guide star displacements.
Thanks,
Fritz
On Saturday, January 20, 2018 at 11:11:26 AM UTC-7, staffor...@gmail.com wrote:
Howdy Bruce, Andy and All;
I am very pleased that I am achieving good guiding performance with PHD2, 0.6" - 0.7" RMS on both RA and (unidirectional) Dec with occasional 1.5" peak excursions and worst case 2.0" peaks. See attached Orion image processed from eight 10 minute subs obtained on 1/14/2018 during ~2 hour window of OK evening visibility with light haze before the fog coalesced.
However, I do have the concern that PHD2 in concert with the Mallincam AGm camera and its' ST4 interface / firmware is generating anomalous behavior. As previously reported, this anomalous behavior manifests as large backlash measurement by Guiding Assistant. The key unexplained observation is that when GA reverses the direction of the DEC guide pulses during backlash measurement, there are three subsequent "wrong-way" guide star displacements. This is clearly visible in the GA backlash plot and log file (too large to attach, so here is Google drive link,
https://drive.google.com/file/d/1_zGJimpf5FltqZ92jYEPEcdAvmiMeJee/view?usp=sharing , accessible with email address, open-phd-guiding@googlegroups.com ).
bw_msgboard
I don’t think I can tell you anything new – we have a profound difference of opinion on this. Image capture and execution of mount commands are done on the same thread, they are serialized. Enqueuing of commands to the worker thread is done asynchronously, so debug log entries may get interleaved. If you just pay attention to the log entries generated by the worker thread, you’ll see everything is serialized. But at this point, I imagine you won’t believe me. So your next best reference is here:
https://github.com/OpenPHDGuiding/phd2
I think I’m done on this topic because I don’t think there’s anything else I can do for you.
Good luck,
Bruce
From:
open-phd...@googlegroups.com [mailto:open-phd...@googlegroups.com] On Behalf Of staffor...@gmail.com
Sent: Saturday, January 20, 2018
12:09 PM
To: Open PHD Guiding
Subject: Re: [open-phd-guiding]
PHD2 Backlash Much Too Large
Howdy Bruce, Andy and All;
1. We recommend using an ASCOM connection for any mount that supports it rather than using ST-4 guiding. Different mounts have different ASCOM drivers and different ways of connecting the PC to the mount controller.
2. I really don’t know beans about any of the EQ series mounts. My impression is that using ASCOM pulse guiding with them requires use of the EQASCOM software. If that is correct, there are certain settings that need to be correct in the EQASCOM user interface – those are what we’ve documented. I have no idea what role a hand-controller has in any of this, and I’m not recommending anything specific beyond what it takes to use ASCOM pulse-guiding.
3. You should quit fretting about what guide speed values might be read from the mount. These have no effect on how PHD guides, they are used only as a way to sanity check certain things. If the sanity checks look funny, you’ll see an alert message in PHD2 which you are free to ignore. Guiding will proceed in any case.
Andy Galasso
It appears that a backlog of three images builds up while GA and Calibration routines drive the guide star in W / N directions before reversing direction, and then PHD2 continues analyzing the backlog images on FIFO bases which results in the apparent "wrong-way" guide star displacements.
Andy Galasso
We did have a similar problem a long time ago with a camera driver that buffered images internally before delivering them to PHD2. The result was that PHD2 would be looking at stale images and this would wreak havoc with guiding. The resolution was an update to the code controlling the camera ensuring that PHD2 never received buffered stale camera frames. It is plausible that something similar could be happening here with your camera. I would definitely recommend contacting the provider of the camera driver to make sure that the camera driver does not buffer images.
staffor...@gmail.com
I did not see your Post until I made my second post today speculating on timing / coordination problem, but I still believe this is distinct possibility.
So far, I have not been able to get PHD2 / EQASCOM to Calibrate with ASCOM pulse guiding through SynScan hand controller in PC Direct mode, so am I using Mallincam ST4 interface for guiding with "On-camera" Mount and SkyWatcher ASCOM driver for Aux Mount. When you observed premature Calibration termination, that was PHD2 / EQASCOM losing the guide star after not receiving any guide camera images after issuing ~6 subsequent guide pulses. Then, I switched back to "On-camera" ST4 interface guide mode.
I now have EQDir cable from Shoestring Astronomy that will enable elimination of SynScan hand controller AND elimination of ST4 cable between Mallincam and HDX110 mount. I hope the weather will allow enough clarity tonight to attempt Calibration with this "EQ Direct" setup (i.e., optimal RS232 16ms latency).
THanks,
Fritz
staffor...@gmail.com
This seems plausible, as it does appear that PHD2 GA and Calibration routines are utilizing stale images. Also, Mallincam's product focus is video astronomy, primarily planetary and lunar. Another point is that Rock Mallin recommended usage of the Windows WDM-style webcam camera driver rather than their ASCOM Mallincam Camera driver, but I was not able to get PHD2 to Calibrate with the WDM-style driver (same lost guide star issue due to no return guide camera images after issuing ~6 guide pulses).
I will contact Rock Mallin and ask whether the AGm buffers images and whether this can be disabled for guiding.
BTW, what might be a better auto-guider camera choice? I see Orion has their StarShoot AutoGuider Pro Mono (200 fps) on sale.
Thanks,
Fritz
staffor...@gmail.com
On Saturday, January 20, 2018 at 1:24:20 PM UTC-7, Bruce Waddington wrote:
I don’t think I can tell you anything new – we have a profound difference of opinion on this. Image capture and execution of mount commands are done on the same thread, they are serialized. Enqueuing of commands to the worker thread is done asynchronously, so debug log entries may get interleaved. If you just pay attention to the log entries generated by the worker thread, you’ll see everything is serialized. But at this point, I imagine you won’t believe me. So your next best reference is here:
https://github.com/OpenPHDGuiding/phd2
I think I’m done on this topic because I don’t think there’s anything else I can do for you.
Good luck,
Bruce
From: open-phd...@googlegroups.com [mailto:open-phd...@googlegroups.com] On Behalf Of staffor...@gmail.com
Sent: Saturday, January 20, 2018 12:09 PM
To: Open PHD Guiding
Subject: Re: [open-phd-guiding] PHD2 Backlash Much Too Large
Howdy Bruce, Andy and All;
Based on the anomalous behavior I have observed, it appears there is timing / coordination problem in GA and Calibration routines between when PHD2 issues guide pulse followed by camera exposure command and then waiting long enough to receive camera image, analyzing and displaying guide star displacement result before issuing the next guide pulse.
It appears that a backlog of three images builds up while GA and Calibration routines drive the guide star in W / N directions before reversing direction, and then PHD2 continues analyzing the backlog images on FIFO bases which results in the apparent "wrong-way" guide star displacements.
Thanks,
Fritz
On Saturday, January 20, 2018 at 11:11:26 AM UTC-7, staffor...@gmail.com wrote:
Howdy Bruce, Andy and All;
I am very pleased that I am achieving good guiding performance with PHD2, 0.6" - 0.7" RMS on both RA and (unidirectional) Dec with occasional 1.5" peak excursions and worst case 2.0" peaks. See attached Orion image processed from eight 10 minute subs obtained on 1/14/2018 during ~2 hour window of OK evening visibility with light haze before the fog coalesced.
However, I do have the concern that PHD2 in concert with the Mallincam AGm camera and its' ST4 interface / firmware is generating anomalous behavior. As previously reported, this anomalous behavior manifests as large backlash measurement by Guiding Assistant. The key unexplained observation is that when GA reverses the direction of the DEC guide pulses during backlash measurement, there are three subsequent "wrong-way" guide star displacements. This is clearly visible in the GA backlash plot and log file (too large to attach, so here is Google drive link,
https://drive.google.com/file/d/1_zGJimpf5FltqZ92jYEPEcdAvmiMeJee/view?usp=sharing , accessible with email address, open-phd...@googlegroups.com ).
bw_msgboard
Hi Fritz. If you’ve gotten things straightened out and working, that’s all that matters. If you’re happy, I’m happy. <lol>
The next PHD2 dev release will include a different approach to measuring backlash. It might be good if you tried that to see if it gives you a better estimate. If the backlash is below a second, you might be able to do bi-directional Dec guiding with the PHD2 backlash compensation feature enabled.
Regards,
staffor...@gmail.com
<p class=MsoNorma
