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
Getting the best performance from my AM5
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
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
- Edited
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)
- Edited
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? :-)
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
- Edited
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
- Edited
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.357
Tracking It might hit the tripod legs after meridian flip so tracking has been stoppedASCOM.ASIMount.0057.381900.txt`
(sample log file name:
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).
- Edited
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
- Edited
copernicus365
Regarding the TPPA there are 2 possible reasons.
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.
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.
- Edited
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
Hi Kevin,
Incidentally, I had yesterday gone through most of the numbers posted here, and the ZWO mounts appear to come in between 0.15 arcsec/sec and 0.3 arcsec/sec. Now, this is just 6 or 7 of them, so there are bound to be outliers. But, yours appear to come in one the "good" end.
That being said, a correction pulse at 0.5x sidereal rate will run a whopping 7.5 arcsec/sec. And you only need to move 0.15 arcsec/sec worth, or 0.15/7.5 seconds = 20 ms. When it is that small, you might as well give it about 100 ms, since that will help bring speed up dither recovery, while still keeping any non-periodic error "small enough."
We are only depending on a small part of the periodc error curve to get the slope of the PE, since ZWO does not publish the more important slop, and instead publishes the PE itself. So, unless you measure carefully yourself (actually not hard to do by aligning the camera angle and stopping tracking) over a longer time span, you might as well also assume that the slope could be larger than what that sheet of paper shows.
100ms at 0.5x sidereal rate basically just says "ignore (or at least clip) errors that are greater than 0.75 arc seconds" to keep the autoguider from correcting errors that we know not to originate from the periodic error (and end up doing a couple of cycles of oscillations on the guide graph).
You can probably use 1 second guide exposures instead of 0.5 second exposures, since the error in a 1 second exposure is of the order of only 0.15 arc sec. Not so with folks that have the 0.3 arcsec/sec type (or worse) mounts, since even under perfect guiding, the guide star centroid for the 0.3"/second case would already produce 0.3 arcsec of movement. That makes 0.5" type RA corrections questionable. And we have not even added declination yet.
So, you might try 1 FPS instead of 2 FPS guiding since that may be better when seeing is poor.
2 second type exposures, though, will also bring you into the "not so good" zone (i.e., 0.3" centroid movement in the guide plate). So I probably wouldn't go longer than 1 second exposures.
I usually would also encourage people to use a smaller guide rate, if dither recovery is not a problem. But, in your case, you should already be able to guide to better than 0.5" total RMS (assuming good declination guiding), so changing it to 0.25x sidereal guide rate will probably not help, given the other errors.
Again, just pool everything you know about guiding (that sawtooth is the biggest help) and just logically figure out stuff. And you already have one of the better ZWO mounts.
Chen
- Edited
Thanks Chen, my duration number came in at 22ms so I was just questioning my sanity! Thanks again for your input. I am using 1s exposures and not planning on 0.5 or 2s and I am getting an average of 0.5rms in turbulent skies using 300-350ms and will try out 100ms as soon as I get clear skies.
I have been following this thread with great interest and would like to express my gratitude to all of you for sharing your instruments and knowledge with us common folks. Thank you! I attempted to apply the workflow to my AM5 and obtained a suggested RA pulse of roughly 78 ms, but I am not entirely confident that I did the homework right... @w7ay does it make sense?
This is the PE of my unit (max/min 24.1/12.0 arcsec):
I also used WebPlotDigitizer to extract the data points from the graph and fed them to the Octave script wrote by fbitto to confirm the 78 ms figure I got on paper.
erossi suggested RA pulse of roughly 78 ms
Horizontal red line corresponds to primary period (430.82 seconds or time).
So 7.2-1.57 = 5.63 screen units corresponds to 430 seconds.
The red sloped line havs these screen parameters.
The horizontal extent is 3.08-1.7 units = 1.38 units, so, using the abscissa scale above, the horizontal extent of this line is 1.38*430/5.63 = 105 seconds.
Accoring to the scale on your piece of paper, the height of that sloped red line is about 10+14 arc seconds. Call it 24 arcseconds.
So, your slope is therefore 24/105 = 0.23 arc sec/sec.
An upper bound for the pulse will depend on your guide rate and exposure time. With one second exposure, the amplitude of the trailing edge of the sawtooth that is caused by this slope is 0.23 arc sec.
If you guide at 0.5x sideral (== 7.5 arc sec/sec), the leading edge of the sawtooth would need to be at least 31 milli seconds, assuming you are not concerned with dither recovery time. 78 ms is a little long at 0.5x sidereal, since it will allow other errors (star centroid estimation, etc) to make a whopping 0.58 arcsecond "glitch" in the guiding (followed by some undershoots and overshoots).
You have an "average" ZWO mount. SO far, the reported numbers seem to be in the range of 0.15 arcsec/sec to 0.3 arcsec/sec.
With some care nursing it, you should still be able to achieve 0.5" to 0.7" total RMS guiding as long as you can keep the declination axis to better than 0.25 arcsec RMS tracking. But it might be tough to get the 0.4" to 0.5" type tracking that some others are getting from the ZWO mount (or the RainbowAstros).
At least you are not seeing the 0.3"/second type errors that some ZWO mounts are showing, where it would probably be hard to do better than 0.7" total RMS errors over an entire gear period.
Chen
Thank you so much Chen, I truly appreciate it!
Forgot to say that I came up with the 78 ms figure by guiding at 0.5x sidereal using 0.5s exposures, which is what I've actually been doing in the past few sessions. For testing purposes both RA and DEC pulses were set to 150 ms, so far I can confirm an average 0.6" to 0.7" RMS.
As soon as the skies clear up I'll do more testing and report the results. I'm really curious to see if I could get good improvements by reducing the pulses furthermore while guiding at 0.25x sidereal.
