• ASI Mount

  • Getting the best performance from my AM5

raawe Just wondering what was your sidereal rate when you took that screenshot (0.5?)

Yes, 0.5x sidereal guide reate (and at 2 FPS).

That was before it dawned on me that reducing the guide rate could help a bit more. Although, with those guiding error numbers, just like @StarzLite 's case, I think the limiting factor is something else already -- ptobably the centroid mean estimation in ASIAIR.

My RST-135 has pretty large peak-to-peak PE (somewhere around 50 arc sec peak-to-peak) but has low harmonic distorrtion. If you recall some posts back, the slope if directly related by a factor of N to the N-th harmonic. So, if if you have a large fifth harmonic distortion, it will make the mount harder to guide. If you notice, @StarzLite 's very first post on this thread also shows very reasonable harmonic distortion.

Anyhow, all these problems (even with high harmonic distortion) will go eventually away, even if you just apply a two-pulse-per-exposure algorithm (i.e., just an extra line or two of code). What today looks like a a large sawtooth would be reduced to two sawtooths whose peak-peak amlitude that is halved. Using four-pulses per exposure wil reduce the influence of the slope of the PE curve (where all the harmonic distortion is creating havoc) by 4 etc.

Again, if the 2-pulse-per exposure method is not clea (or to any others)r, I can draw more blue lines to the existing sawtooth to show how it works. Once you see it, the "Aha!" lightbulb will come on and you will wonder why no one in the past has thought of such a trivial solution.

By the way, if I recall (too long a thread to scroll back to look, and my memory isn't what it used to be :-), you are already getting quite decent numbers the last time you posted about it, right? Once you get below 0.35" total RMS error or so, the errors from the harmonic distortion of the mount is pretty much no longer the tallest tent pole.

Again, if the two-pulse solution is not clear to everyone, I can draw it. Just takes 5 or 10 minutes to post an explaination (based on the fact that the second derivative of the PE curve is small :-).

Chen

      Byrdsfan1948 I must admit there is a lot here for my aging brain to absorb.

      Aw, come on now, that school of yours probably taught Fourier Series even in the Freshman year!!! (I did have Fourier Series in high school Physics, but nowhere near the rigorous treatment in college).

      By the way, there is a nice lecture series on Fourier Transforms (EE261) from Stanford (nowhere like what the lectures from MIT are like, I am sure :-) here:

      https://www.youtube.com/watch?v=gZNm7L96pfY

      Osgood started out explaining periodic functions and how they can be represented as Fourier Series, and then in a later lecture in that series, took the limit and arrived at the Fourier Transform. (Yes, I watch all of it, like a good movie.)

      So, if you really are rusty, just watch that YouTube (no, he didn't shill any product from ZWO :-).

      I had taken the same EE261 when I arrived at grad school even though I have had Fourier Transforms in undergrad. Since it was given by Ron Bracewell (RIP) himself, who initiate that class when he arrived at Stanford in the 1960s, so I thought it would be entertaining at the least. Ron ran the Radio Astronomy group (I was in the Radar Astronomy group) and had written a book called "The Fourier Transform and Its Applications."

      I don't know if Osgood was born yet back then :-).

      Chen

        w7ay Again, if the 2-pulse-per exposure method is not clea (or to any others)r, I can draw more blue lines to the existing sawtooth to show how it works. Once you see it, the "Aha!" lightbulb will come on and you will wonder why no one in the past has thought of such a trivial solution.

        That discussion needs to happen where Phd2 coders hang out and I doubt it is on this forum, unfortunately. AM5 users read it and now understand the logic and principles behind it. Unfortunately, we are for the most part, hobbyist and wouldn't know how to make that happen.

        • w7ay replied to this.

            Byrdsfan1948 First like someone else here perhaps in another post mentioned I was having trouble understanding what you exactly mean when you say Slope of the PE... I mean obviously from the supplied graphs of the PE that slope, dy/dx changes over time.

            Ah, notice that the absicca of the plots are simply a time axis even though they are shown as some units of rotation. And the ordinate is the PE in arcsec. So, you can derive dPE/dt by taking the slope of that graph and do the appropriate scaling.

            I simply used some graphical tools in EazyDraw (a macOS application) to measure the distances, but you can see many other innovative ways of measuring it in this thread (gives me hope that astrophotography has not yet be taken over by the Easy as 1,2,3 snapshooters).

            appears you are essentially graphing a tangent line to that point in the PE curve that appears to have the largest dy/dx.

            Yes. Similar triangles. The x-axis is time, the y axis is arcsec deviation. The tangent is precisly the slope (i.e., remember how you were first taught that the derivative of a curve is the limiting case of (x1-x2)/dh as h approaches 0? And if both numerator and denominator converges to zero (does not happen in the PE curves, mercifully), to apply l'Hopital's rule?)

            Please if you don't mind confirm or correct my conclusion here.

            Yes, the worse case of the slope comes into play in that sawtooth graph. I.e., the larger the slope of the PE (not directly the amplitude of the PE), the larger is the amplitude of that sawtooth. But, also no larger. So, what you do is to limit the max pulse duration to that, and that will result in not causing the gear to change when not needed.

            you will see that the slope is not precisely the guide rate, but the guide rate minus the slope of the periodic error

            The slope of the PE curve acts all the way from the begiing of the exposure to the end of the guide exposure. There is no way to stop it -- it is part of the gears. At the leading edge, we are appling a "correction" with an opposing sign. The "correction" has a slope of 7.5 arcsec/sec if you are using 0.5x sidereal rate guiding. However, since the PE is always running (so to speak), the leading edge of that sawtooth is not 7.5 arcsec/sec but it is 7.5 arcec/sec minus the slope of the PE curve.

            Once you take the foot off of the correction pulse, the guide star resumes tracking at the rate of the slope of the PE.

            Chen

              tempus Unfortunately, we are for the most part, hobbyist and wouldn't know how to make that happen.

              I will be doing it for myself in INDIGO.

              I have already added a layer of interface to INDIGO to make the API look like Cocoa API (i.e., the BLOBs have been turned in NSImage, the C callbacks, have beenn turned into delegate calls, etc). So, i should be able to do my guide experiments there, to refine the algorithms. I have been using Cocoa (and grown accustomed to it) even before it was released to the public (I was at Apple between 1988 and 2005, when I finally retired doing algorithms research in the areas of imaging and graphics).

              But my interest is in how smooth I can make the algorithm work, not how much someone else can make his or her mount work.

              I will be releasing the white paper, and anyone can use it however they wish.

              There are three ways to protect intellectual property -- one is to keep it a trade secret, and hope that no one else discovers the same idea and patent it, so you yourself can no longer use it freely. The second method is to patent the idea, so that the idea is shared openly, but you can still derive monetary payments until the patent expires (that is the Harmonic Drive patent case). The third way to make sure no one can prevent you from using your own ideas, is to publish it. Bell Labs used BSTJ -- Bell Systems Technical Journal -- to do that in the past. IBM had the IBM Journal, HP had HP Journal, etc. Once published rapidly without any going through IEEE or ACM, it becomes public knowlege right away ("prior art," in patent-speak) and again, no one else can stop you from using your own ideas. My plan is to use this third route; with a white paper published to my web site. So no one can go claim later that it is GPL or something.

              Chen

                  By the way, you can skip the EE261 YouTube to 16:30 of the video. Where he starts right with Fourier Series (and by 17:50, you will see why I use it for Periodic Error :-).

                  Chen

                    Hey Chen Thanks, BTW I saw here someplace you would be willing to send to those of us interested in this matter a copy of your white paper via e-mail. If so please sign me up!! If you don't still have my e-mail address just let me know.

                    To be honest while all this is fine and dandy, for me it's mostly just an exercise in better understanding certain aspects of our hobby. It's interesting how obsessed people can be with their guiding numbers. I suppose because there is some satisfaction from the instant feedback. As opposed to the very slow and tedious work needed in assembling the images and doing all the post processing.
                    For me given the level of my current skills everywhere else, guiding is probably my least problematic area that needs work. It's much like going to the music store to pick out a new guitar. No matter how good or expensive it is, It's not going to allow me play better. That comes from another source !! :-))

                    There is a LOT in this thread that relates to some of the very complex Dynamic issues we faced when designing our high speed assembly machines. Balancing all the rotational forces harmonic and other wise, generated at the operational speeds was a huge challenge, in particular in that those forces were coming from all sorts of different mechanical inputs. Not only Harmonic gear drives, but many others such as Geneva drives, as well as many simple power arm drives.
                    All adding their own balance problems as they accelerated and de accelerated the various masses they were moving and very accurately placing along the assembly beam. Cam design became beyond critical.
                    Bottom line far too complex for me. Thankfully by then I had become the SVP of engineering and I had a team of brilliant young engineers from the finest schools in the world including yours that knew what they were doing and made me look good..... I guess for me in that position it was far more important that I understood the problem, and they understood how to solve it :-)). Al

                    • w7ay replied to this.

                      Byrdsfan1948 BTW I saw here someplace you would be willing to send to those of us interested in this matter a copy of your white paper via e-mail. If so please sign me up!! If you don't still have my e-mail address just let me know.

                      Will do. Yes, I do have your email address, Al. Right now, I am just up to describing the existing guide paradigm. Let be get a bit further, and I will publish it to my Hostgator server and send you a link.

                      Chen

                        Byrdsfan1948 There is a LOT in this thread that relates to some of the very complex Dynamic issues we faced when designing our high speed assembly machines. Balancing all the rotational forces harmonic and other wise, generated at the operational speeds was a huge challenge, in particular in that those forces were coming from all sorts of different mechanical inputs.

                        Yeah, the only reason I bought my first RainbowAstro mount sight unseen (received serial number 13 from the first production run -- I don't usually volunteer to be a guinea pig) is only because

                        1) RainbowAstro is a "hobby" spin off from RainbowRobotics, and RainbowRobotics have been using (and understand the dynamics) of the strain wave gears,

                        2) RainbowAstro uses the gears from Harmonic Drive LLC (I suspect they get it from Harmonic Drive Systems in Japan, which is a partner company of Harmonic Drive LLC (in Massachusetts)),

                        3) The RST135 is not the first strain wave geared mount they built, they had earlier sold the rather expensive RST-150h. I fact, I was deciding between the RST-150h and the small Avalon fork when RainbowAstro announced the RST135, and it was a no brainer decision at that point,

                        4) The RST150h is not even the first mount RainbowAstro built; they built many large German mounts for schools and research facilities in Korea,

                        5) RainbowAstro (and RainbowRobotics) CEO had collaborated with Hobym to build the even earlier strain wave geared mounts back in 2008,

                        6) they have a facility in the US (that they share with UNLV's Robotics Group in Las Vegas; a lot of UNLV's robotics faculty are apparently RainbowRobotics employees) where they can fix the mounts,

                        7) their command protocol is exquisite. Commands are simple and to the point. Like Einstein said, things should be as simple as possible, but no simpler.

                        So, I bought it sight unseen mainly because the RST-135 was not their first rodeo. And they are even experts on robotic arms. I bought the second RST-135 a few months after being happy with the first one (just to have a spare mount in case one goes south; after the RST-135, I couldn;t go back to using the Takahashi EM-11 anymore).

                        I am still on the fence with buying the Pegasus Nyx-101, since they are another new comer to this area, even though their build quality and ergonomics (none of the cables move during the night) seem really good -- like they were designed by someone who actually uses mounts.

                        Not only Harmonic gear drives, but many others such as Geneva drives, as well as many simple power arm drives.

                        Yeah, the Flex Spline part of the strain wave gear is very scary. But so far, after the abuse I gave to my mount, the ones manufactured by Harmonic Drives appear to be holding out OK. The Harmonic Drive LLC gears are used on multiple NASA robots now to drive the wheels, and I dont think any rover wheels have fallen off yet.

                        By the way, check these out and you would be proud:

                        https://harmonicdrive.de/en/company/walton-musser
                        https://www.machinedesign.com/archive/article/21826153/c-walton-musser

                        (Check the universities he went to.)

                        Chen

                          w7ay Could you please draw/explain how would you approach two-pulse-per-exposure? Currently, there is exposure time, then centroid calculation and correction while new exposure is being taken. I can't understand how would you apply that second correction. Correct me if I'm wrong, but you can't have overlapping exposures (first 0.5sec exposure starts, then new one starts when first exposure is half way done)

                          • w7ay replied to this.

                              raawe Could you please draw/explain how would you approach two-pulse-per-exposure?

                              OK. First recall from above that I had described the leading edge of the sawtooth as (an unavoidable) self-inflicted wound?

                              I.e., the sawtooth's negative (leading edge) excursion is caused by the autoguider itself, by applying that correction pulse of length N. But it is neccessary since it has to compensate for the perioid error slope that makes up the trailing edge of the sawtooth.

                              That being said, here is the two-pulse method (this figure should invoke a lot of lightbubs over you nerds' heads, even before I describe what is happening :-)

                              What you do is you take that N-millisecond correction pulse and divide it by two.

                              The "self-inflicted" wound (the first dashed cyan leading edge on the bottom graph) is only half the amplitude now. The periodic error slope will then start to drive the trailing edge of the sawtooth up. And if you don't stop it, will create a large error.

                              But... we add another correction pulse (also N/2 in duration) right at that halfway mark, to again push the sawtooth down (the second leading edge of the dashed sawtooth).

                              Notice that the trailing eddges are always the slope of the periodic error curve. Nothing we can do about that; it is the "given" part of the problem.

                              Now stand back and look at the picture. See that the dashed cyan sawtooth is now half the amplitude of the original green sawtooth?

                              We are in total still applying N milliseconds worth of correction (to correct for the slope of the PE over that exposure time). But we are distributing the error.

                              As long as the change of the slope of the PE (i.e., the second derivative of the PE) is small, you can simply break that N into two N/2 pieces. And you will see (from the white paper) that the "small second derivative" assumption holds (as long as the period is much longer than the exposure time (i.e., 400 seconds vs 1 second).

                              Notice that we really don't even have to do anything different from today's legacy guiding. We simply take the N that today's guide equation gives us, and drive the mount not with a single N-millisocond pulse, but as a distrtibuted pulses.

                              Those of you who have worked on PWM will recognise this similar to the way to get better filtered "DC" (use smaller capacitors) from PWM by raising the PWM frequency. Same here. The percentage of the pulse modulation is the same, e.g., N/2 + N/2 remains = N for the exposure duration.

                              I leave it as "an exercise for the student" to extend the above to a 4-pulse solution, an 8-pulse solution, etc.

                              Chen

                              P.S.: slopes, slopes, slopes... sawtooths, sawtooths, sawtooths... see the pattern? :-)

                                  w7ay oh, light bulb moment indeed. Was reading it and thinking why stop at N/2 but you saw that coming. Interesting approach

                                    Notice that for today, the only way to reduce that sawtooth amplitude (without writing any extra code) is to use shorter guide exposure times.

                                    For folks with large PE slopes, definitely give short guide exposure (high framerates) a try.

                                    If your PE slope is of the order of 0.2 arcsec/second, you are probably not limited by the sawtooth amplitude, so shorter exposure time won't help (much)/

                                    Unfortunately, shorter exposures probably won't work with an OAG with a small prism since you are photon-starved, and cannot get enough stars to give accurate centroid readings.

                                    (BTW, as you shrink the sawtooth -- recall that the guide star is moving along the sawtooth, and is not static -- you will also gather more photons per pixel. So that is another place 2-pulse helps.)

                                    The limiting factor is both the sensitivity of the guide scope/camera, and how many frames per second the guide system can provide (until relatively recently ASIAIR used to be limited to 1 FPS even when you use 0.5 second exposures with tiny sensors).

                                    2-pulse-per-exposure allows you to use 1 second guide exposures, and even 4-pulse-per-exposure with two second exposures.

                                    Chen

                                    w7ay I will be doing it for myself in INDIGO.

                                    Just hit me, might be easier to fork PHD2 repository and update it for two pulses. Not sure if you are familiar with C++.

                                    • w7ay replied to this.

                                        raawe Not sure if you are familiar with C++

                                        Sure, waaay back when. (If you want to see my history with the C language, take a look at http://www.fortran-2000.com/ArnaudRecipes/CompMuseum.html and search for "kcc"; yeah, when you are at my age, you get dumped into web pages that has the title "museum" and "history" in it :-).

                                        But ever since 1999 or so, I have moved to Objective-C (same language Tim Berners-Lee wrote the original world wide web).

                                        INDIGO compiles under Xcode/Objective-C, but I have also added a layer (for myself) to make the API completely Cocoa (the GUI layer in macOS and iOS nowadays).

                                        So, the image BLOBs in INDIGO have been turned into Cocoa's NSImage objects, for example. To display a captured image, I can simply create an NSWindow with an NSImageView, and simply send the NSImage to NSImageView. All the C callbacks have also been turned in Cocoa's NSDelegate callbacks.

                                        INDIGO has turned into the plaform of choice to test new ideas for me, because it is so simple to do it now with alll the foundation stones laid out.

                                        If you recall, when the slope of the PE is large, the amplitude of the sawtooth is large. The ordinate of the sawtooth describes the path of a guide star in the hour angle dimension (the time axis is the abscicca). The normal understanding is that a gude star sits there for you to compute a centroid -- that is not true. The guide star always move (thus, the target in the main camera will also always move) even if guiding is perfect (except fr that "guide by guide rate "Pulse Amplitude Modulation" scheme that I will be introducing in the white paper).

                                        The movement of the guide star is small (probably of the order of 0.1") for a traditional mount for guide exposures that are short (under 2 seconds in time, say). But that is not true when the slope of the periodic error of out mounts is of the order of 0.3"/sec to 1"/sec.

                                        So, not only do you have to revamp the guide equations to match a moving guide star (again, that will be revealed in the white paper), but we probably have to revisit how to more precisely obtain guide star centroids. Recall that graphics folks resort to correlation matrices to motion-deblur an image, and those techniques might be what is good for autoguiding also. We pretty much have a motion blur problem, but we have it easy, we know that the blur is in the direction of the RA axis or the declination axis (so a fulll cross correlation is probably not neccessary).

                                        Because of that, I will be starting from first prinicples to do the INDIGO experiments. Both for caturing guide images and also for how to turn them into guide pulses.

                                        Anyhow, my interest is in instrumentation and not snapping pictures, so I don't mind spending the next few years refining autoguiding. Even my first NSF Undergrad Fellowship at the NRAO had involved instrumentation -- https://www.gb.nrao.edu/electronics/edir/edir79.pdf ; bad old days, the manuscipt was typed on a IBM Selectric by my boss Sandy Weinreb's secretary. For those who are not familiar with Sandy (Sander), he was the first to observe interstellar OH radicals using instrumentation (the autocorrectaion receiver) that he built for his Ph.D at @Byrdsfan1948 's alma-mater :-)

                                        But, if you want to do quick changes to PHD2 to potentially improve autoguiding by a lot, the two-pulse per exposure is probably easy to do; using existing star centroid and pulse duration computations. My instrumentation mentality is really more academic, and towards satisfying my engineering curiousity of how far one can take the problem -- heck, I can already guide well enough with the RST-135, I really don't have to work on it anymore if I just want to snap decent pictures.

                                        Chen

                                          Pretty please can someone just give the final PHD2 guidance settings?!?! Would so appreciate that! Thank you all you brilliantly people here who are freely giving this guidance.

                                          Background: I've had the AM5 a few months now, I loved it, but then again have had some BIG problems that I now realize were due to the mount and the ASCOM driver, has caused me endless troubles (again I didn't realize that was the mounts fault originally). Like every time I 3-point polar align in NINA (causing 3 overall slews), the :-) mount decides to STOP tracking and won't allow you to turn tracking back on!!!!!!!!!!!! (I learned this through Cuiv the Lazy Geek video). I find literally 3 thousand plus times in the mount's logs:

                                          01:08:42.357Tracking It might hit the tripod legs after meridian flip so tracking has been stopped
                                          (sample log file name:                                          ASCOM.ASIMount.0057.381900.txt`

                                          I tried to install beta version (zwo-ascom-setup-v65150323) but that maybe only made it worse, this is getting very upsetting and edging towards begrudgingly returning. I've also noticed these weird problems where yes, it seems to have periodic significant fluctuations in tracking, like the guy above originally explained. Then other times runs perfect (best thus far .44", never seen ones as good as oens listed above).

                                            copernicus365 Pretty please can someone just give the final PHD2 guidance settings?!?! Would so appreciate that!

                                            No one can do that since it depends on your mount. There is a huge variance between one ZWO mount and another ZWO mount, even from the same manufacturing run. What works well for someone else might give you disastrous guiding.

                                            The general way to derive your own mount's settings are:

                                            (1) First measure the slope (first time derivative) of the mount's Periodic Error. The periodic error itself has units of arc-seconds. So the slope will have units of arc-seconds per second (of time).

                                            If you read through this thread, you will find at least 4 (so many that I stopped counting) different ways (some quite ingenious) to do that.

                                            (2) if the magnitude of the slope is greater that 0.25 arc-sec/second, you might consider using guide exposure times of less than 1 second to try to achieve a guide frame rate (FPS) that is 2 FPS. The key is the FPS, not the exposure time, but FPS is a function of both exposure time and your guide software.

                                            This often precludes being able to use an OAG, since the size of the OAG prism keeps you from getting enough stars to obtain aa reasonably error free centroid. It will also preclude you from using the small toy guide scopes, and you may need to use guide scopes that have apertures of 50mm to 60mm, together with a large guide sensor. You will need more than 6 to 8 guide stars (using multi-star guiding) to get a decent centroid when the seeing is poor (6 guide stars at 1 second exposure is equivalent to 1 guide star at 6 seconds exposure, when all the guide stars have the same brightness).

                                            There is already a known algorithm on how to achieve the same performance as large FPS while using longer exposure time, (also discussed ad nauseum above) as long as you are capable of writing your own guide code.

                                            (3) Knowing the max PE slope (from (1) above), set the Max RA duration to be compatible. I.e., if your guide rate is 0.5x sidereal (i.e., 7.5 arc-sec/sec), then set the max RA duration to perhaps only 2 times the PE slope divided by the guide rate. This number will usually fall into the range of 100 milliseconds to 200 milliseconds. Your max RA duration is set to 2500 ms, which is way out of whack. But you can only know how low you can set it by measuring the slope in step (1). Guiding will also go out of whack sometime during the night when the max RA duration is set too low. There is a sweet spot, that depends on your mount. And the easiest way to determine that sweet spot is to go through step (1) above.

                                            Set the Declination max pulse duration to something about 0.5x to 0.9x of the max RA duration if you have good polar alignment. The declination error should be small enough when you just do that.

                                            (4) set the "aggressiveness percentage" of both RA and declination loops to below 0.5. Your 0.7 (RA) and 0.6 (declination) values can cause guide instability somewhere through the night. Experiment with values starting at 0.25 and only increase it if you find the guiding not keeping up (the guide graph keeps drifting off slowly to +infinity or -infinity), or if dither recovery is too slow.

                                            Be sure to read this entire thread to understand what is happening when the slope of the periodic error of a mount is large (common with strain wave geared mounts). Don't just go poke at some parameter if you don't know what it does.

                                            Chen

                                                copernicus365
                                                Regarding the TPPA there are 2 possible reasons.

                                                1. By default, TPPA sets tracking to off after completion. You can check in the plugin settings. The setting "Stop Tracking when done" should be OFF. In this case, if it does stop because the setting is set on ON, you can restart tracking through the ASCOM driver.

                                                2. You might have set the starting position and parameters so that the 3rd point is across the meridien. In that case, AM5 will stop at the meridien and turn off tracking.

                                                  Thanks so much for the responses. A couple quick notes:

                                                  1) my setup: AM5, Askar FRA 400, ZWO 533mm cam, 60mm guide scope w/ZWO 290mm mini.

                                                  2) PE periodic error from ZWO sheet: it seems a pretty sad 25.9/13.8 arc-secs. Is this bad? 😔

                                                  3) on the PHD2 settings I screenshoted, sorry, those were just the defaults, my purpose was to show a simple screen that normal users can recognize to know what we’re talking about. Regardless I had only lowered aggressiveness on Cuiv’s suggestion. The night after I left the above note I took out in the field and tried some much lower settings like some have done above (eg durations of 300 instead of 2500), and it went terrible. After dither, guiding would just slowly track off the page (being off 1’, and growing to 2’, 3’ etc) . Even after being less extreme in lowering many of these parameters (durations and aggressiveness) things were not good so I just went back to some high values (but not as high as those defaults). I’m not happy with what a dither does, it seems way too long and hard to recover. I still get plenty of good tracking, some at .5” rms, but then those big fluctuations, and bad dither recovery. I really don’t want to waste the precious time and limited attention of you guys, I know sir you encouraged above not to just randomly change values hoping for the best, but that’s all I have at the moment. I will definitely be trying to follow along and learn more above but wanted to leave this update for the moment. But PLEASE ZWO condense the needed information from this page into some much needed condensed and practically focused guidance.

                                                  4) on the TPPA (3 point polar alignment) thank you sir for the response, the failure (that tracking gets killed) is not because it’s passing the meridian, the other night and many times I’ve had it start fairly low. It seems to fail on the third try usually fyi. But it’s definitely not just stopping tracking after completing, rather TRACKING itself is killed completely before the third picture solve is complete, in fact the third picture will have star trails, so TPPA completely fails because tracking got shut down and subsequent attempts are just trails. As again happened to me after leaving the note above, I had to multiple times manually kill the ASCOM AM5 mount GUI app, it will not allow you to turn tracking back on, it’s HORRIBLE. I ask ZWO do you guys have a beta update ASCOM driver I can use? I think I’m on a beta (6.5.15.0323) but it’s unclear if I’m using the newest, the one Cuiv said fixes the problem. The problem most certainly is not fixed


                                                  5 days later

                                                  w7ay
                                                  Just a quick question regarding your figures in (#3). You state that if I use my “worst case slope of ( 5.07*6.17/198 ) = 0.16 arc-seconds per second.” and apply the figures to (3) in your post to calculate durations… I do not get between 100-200ms or close. Maybe I am calculating this wrong or reading this incorrectly? Am I going crazy n old? Haha

                                                  • w7ay replied to this.