Can't get less than 1" total RMS


Henk Aling
 

My system is a G11S with OnStep v3.16o, CNCv3 with TMC2130 drivers set at 32 microsteps configured for mode switching and the TMC2130_VQUIET model and 17HM15-0904S steppers (0.9 degrees).  I added DIY spring loaded worms and run it with a 12" Newt with FL=1380 mm, an OAG with an ASI120MM mini guider, altogether 50+ lbs of gear.  OnStep is controlled by Ekos with its native autoguider.  Slewing / goto works great especially with the SLW that prevent the ring gear from binding up, which unfortunately, happens a lot with Losmandy when trying to minimize the backlash.

While I read that several G11 owners achieve 0.25" total RMS, I can't get below 1" - well just once I achieved 0.49" in a session where I had mostly 0.6" over all but that was just once.  I understand that the seeing matters but so do a number of configuration parameters such as exposure time.  This makes me wonder if there is something wrong with my configuration.  I have played around enough with the SLW (also simply disabled them) and guider (tried PHD2 also) that I believe I can eliminate them as the cause.  My PA is good (I use Ekos with plate solving, similar to SharpCap), and my PE is probably around +/- 5" though this depends on the mechanical conditions such as how the worm blocks were set, how much counterbalance was provided and how tight the clutches were turned.  I have not yet started using Ekos' predictive PEC.  I counterbalance with a small extra weight or I put a hoodie over the counterweight.  Doing that cut my RA RMS in less than half (this was before the 1" RMS mentioned).  Guiding at 1" RMS makes images look pretty bad.  I believe that 0.25" RMS should be the norm.

1)  Is 32 microsteps accurate enough?  It leads to 0.28" per microstep.
2)  What is the best autoguider exposure time?  Losmandy users recommend several seconds and say that it matters.  I usually do 1 s, tried 3 s last night but it did not make a big difference (but I will try again).  A larger exposure time reduces the effect of poor seeing but can add errors due to guiding (the guider subs show clearly visible streaks in RA when RA is restless so it's a moving target and can cause unpredictable feedback).
3)  What is the best guide rate?  Cloudy Night users recommend not using 1x, which is the default AFAICT, this is how it shows up in Ekos.  It means that the motor comes to a full step or twice the speed.  Is that ideal, and if not, how can I change it?  I see no GUI in the Android client but there is code in Initialize.cpp that sets it to GuideRate1x that I could change.
4)  Any idea if the ASI120MM is too cheap a guider?  It provides noisy images, shaky too but that may be for the right reason.
5)  Should I switch to PHD2 instead of Ekos autoguiding?  I switched once and did not see improvement.

Only questions (1) and (3) pertain to OnStep, the other ones are uncertain factors that also affect the guiding performance.  Thanks in advance for your response.


"Guilherme Vênere
 

Just a few takes at it but im not an expert.

Phd2 offers multi star guiding which can visibly improve the guiding accuracy. I use it since it was implemented and following some suggestions from friends also using it, I decreased the exposure times to 1s only and I could see a big improvement in my GM8 with OnStep. The reason for it to work in PHd2 is the multi star guiding which can compensate for seeing errors. Right now with my G811G and Gemini I can get around 0.6" to 1" RMS without much tweaking which is more than enough for me. 

Guide rates may depend on the type of issue your mount shows. In general 0.5x is the recommended rate. You can change that from OnStep web interface but the default at least in 4.xx should be that already.

.28" step already tells you you won't be able to achieve .25" accuracy. Maybe you need to change your gear ratios or microstep to get a better step ratio. I have the same motors in my GM8 and i use 64 microsteps with it without any problem.  

just my .02c

Guilherme

On Wed, Jul 21, 2021 at 9:38 AM Henk Aling <haling@...> wrote:
My system is a G11S with OnStep v3.16o, CNCv3 with TMC2130 drivers set at 32 microsteps configured for mode switching and the TMC2130_VQUIET model and 17HM15-0904S steppers (0.9 degrees).  I added DIY spring loaded worms and run it with a 12" Newt with FL=1380 mm, an OAG with an ASI120MM mini guider, altogether 50+ lbs of gear.  OnStep is controlled by Ekos with its native autoguider.  Slewing / goto works great especially with the SLW that prevent the ring gear from binding up, which unfortunately, happens a lot with Losmandy when trying to minimize the backlash.

While I read that several G11 owners achieve 0.25" total RMS, I can't get below 1" - well just once I achieved 0.49" in a session where I had mostly 0.6" over all but that was just once.  I understand that the seeing matters but so do a number of configuration parameters such as exposure time.  This makes me wonder if there is something wrong with my configuration.  I have played around enough with the SLW (also simply disabled them) and guider (tried PHD2 also) that I believe I can eliminate them as the cause.  My PA is good (I use Ekos with plate solving, similar to SharpCap), and my PE is probably around +/- 5" though this depends on the mechanical conditions such as how the worm blocks were set, how much counterbalance was provided and how tight the clutches were turned.  I have not yet started using Ekos' predictive PEC.  I counterbalance with a small extra weight or I put a hoodie over the counterweight.  Doing that cut my RA RMS in less than half (this was before the 1" RMS mentioned).  Guiding at 1" RMS makes images look pretty bad.  I believe that 0.25" RMS should be the norm.

1)  Is 32 microsteps accurate enough?  It leads to 0.28" per microstep.
2)  What is the best autoguider exposure time?  Losmandy users recommend several seconds and say that it matters.  I usually do 1 s, tried 3 s last night but it did not make a big difference (but I will try again).  A larger exposure time reduces the effect of poor seeing but can add errors due to guiding (the guider subs show clearly visible streaks in RA when RA is restless so it's a moving target and can cause unpredictable feedback).
3)  What is the best guide rate?  Cloudy Night users recommend not using 1x, which is the default AFAICT, this is how it shows up in Ekos.  It means that the motor comes to a full step or twice the speed.  Is that ideal, and if not, how can I change it?  I see no GUI in the Android client but there is code in Initialize.cpp that sets it to GuideRate1x that I could change.
4)  Any idea if the ASI120MM is too cheap a guider?  It provides noisy images, shaky too but that may be for the right reason.
5)  Should I switch to PHD2 instead of Ekos autoguiding?  I switched once and did not see improvement.

Only questions (1) and (3) pertain to OnStep, the other ones are uncertain factors that also affect the guiding performance.  Thanks in advance for your response.


Henk Aling
 

On Wed, Jul 21, 2021 at 12:52 PM, "Guilherme Vênere wrote:
Phd2 offers multi star guiding which can visibly improve the guiding accuracy. I use it since it was implemented and following some suggestions from friends also using it, I decreased the exposure times to 1s only and I could see a big improvement in my GM8 with OnStep. The reason for it to work in PHd2 is the multi star guiding which can compensate for seeing errors.
Ekos also has multi-star guiding, this is what I use.

Right now with my G811G and Gemini I can get around 0.6" to 1" RMS without much tweaking which is more than enough for me. 
It depends on the FOV, with an ASI2600MC (an APS-C sized sensor) and 1380 mm FL.

Guide rates may depend on the type of issue your mount shows. In general 0.5x is the recommended rate. You can change that from OnStep web interface but the default at least in 4.xx should be that already.
Ah OK.  I am still using the old stable v3.16o but I now see on the Wiki that the stable version is v4.24.  That is great, let me switch to it.  I hope the guide rate is now configurable through Config.h.

.28" step already tells you you won't be able to achieve .25" accuracy. Maybe you need to change your gear ratios or microstep to get a better step ratio. I have the same motors in my GM8 and i use 64 microsteps with it without any problem.  
Will do.  Thanks!


Khalid Baheyeldin
 

Henk,

You can still set the guiding speed to 0.5X on 3.16.
From the Android app, press Guide/Focus.
From there, press the 3 dot menu, then select that speed.
Note that whenever you (or any software) change the speed to 1X, that will stick and replace 0.5X.

I recommend that you use PHD2, because it will log guiding details for you, and you can use the phdlogview tool to see what is going on after the fact.

Finally, where do you live? Seeing is worse in some places than others (e.g. Great Lake area vs. Hawaii or New Mexico).


Henk Aling
 

On Wed, Jul 21, 2021 at 06:12 PM, Khalid Baheyeldin wrote:
Henk,

You can still set the guiding speed to 0.5X on 3.16.
From the Android app, press Guide/Focus.
From there, press the 3 dot menu, then select that speed.
Ahh.  I always use Guide/Focus for manual control by setting the rate to the maximum.  I must have jumped to conclusions as to what it is meant for.  The code actually maxes it to GuideRate1x so I guess that's why it all works.

Meanwhile I hard-coded it in my v4.24 Git branch, and it shows up as 0.5x so I'm good.  But thanks for noting that, next time it will be easier.

Note that whenever you (or any software) change the speed to 1X, that will stick and replace 0.5X.

I recommend that you use PHD2, because it will log guiding details for you, and you can use the phdlogview tool to see what is going on after the fact.
PHD2 is a pain to use with Ekos.  I have two imagers and one time it picked the wrong one, it took me a while to figure it out.  It does not know the Ekos device configurations.

Ekos also provides a log, it is simply an Excel spreadsheet which is just as easy for me at least.

I want to try PHD2 a bit more though but not on a regular basis unless I have to.

Finally, where do you live? Seeing is worse in some places than others (e.g. Great Lake area vs. Hawaii or New Mexico).
Just outside Santa Barbara, Bortle 5 or 6, and yes it had been a warm day. 


Alexander Varakin
 

I also have G11 with AT10RC which is about #40 in total.
My RMS is between 0.6" and 1.2", depending on conditions. I am fairly happy with my images.
Here is my astrobin page, showing my images: https://www.astrobin.com/users/avarakin/
What is the problem with your images exactly - elongated stars?
Are you using OAG? With your FL, I would strongly advise switching to OAG.
Your issues may be caused by flexure in different components between the main camera and the guide camera.
You will have to upgrade your camera to 174 chip in case if you go to OAG: 120 chip is tiny for OAG.
PHD2 works great with Kstars for me. 
I try guider of Kstars once in a while and still revert back to PHD2: PHD2 is much more robust.
Did you try collecting unguided logs from PHD2 and analyzing them using PHDLogViewer?
Once you do, you will see your periodic error and the components of it. This will help you to troubleshoot the culprits.
I doubt you need to increase micro-stepping - 2130 chip has interpolation to 256 micro-steps.
Your motor might be the reason for your problems too - it has pretty low torque. 
Look for threads here, there is some very good motor from Oriental motors. It is costly but has much higher torque.


Henk Aling
 

On Wed, Jul 21, 2021 at 08:19 PM, Alexander Varakin wrote:
I also have G11 with AT10RC which is about #40 in total.
My RMS is between 0.6" and 1.2", depending on conditions. I am fairly happy with my images.
Here is my astrobin page, showing my images: https://www.astrobin.com/users/avarakin/
Very nice images indeed!  I noticed that your integration times are about 10 to 15 times mine.  And that you use PI, which has star minimization features.  If that explains the difference then I may be doing OK with 1" RMS?

What is the problem with your images exactly - elongated stars?
No the stars are round but larger than I like.  Blurry, not razor sharp.

Are you using OAG? With your FL, I would strongly advise switching to OAG.
Your issues may be caused by flexure in different components between the main camera and the guide camera.
Yes I have a QHY medium size OAG with an ASI120MM mini.

You will have to upgrade your camera to 174 chip in case if you go to OAG: 120 chip is tiny for OAG.
It works for me but just barely, sometimes I have to look for stars.

PHD2 works great with Kstars for me. 
I try guider of Kstars once in a while and still revert back to PHD2: PHD2 is much more robust.
Did you try the multi star guiding?  It works pretty well.  I switched to PHD2 and it gave me larger errors (this was with single star though).

Did you try collecting unguided logs from PHD2 and analyzing them using PHDLogViewer?
Once you do, you will see your periodic error and the components of it. This will help you to troubleshoot the culprits.
Yes I have used the PHD logviewer.  I use Ekos' log, it is an easy to use spreadsheet, you can plot graphs in Excel.
I wrote a Scilab optimization script to find the main frequencies in the time domain.

I doubt you need to increase micro-stepping - 2130 chip has interpolation to 256 micro-steps.
I changed it from 32x to 64x.

Your motor might be the reason for your problems too - it has pretty low torque. 
Look for threads here, there is some very good motor from Oriental motors. It is costly but has much higher torque.
Thanks that's good to know, I was wondering about that.

The trouble about building your own gear is that you can't tell the vendor that their product doesn't work because you are not using it according to spec with the vendor's tools.  I was wondering if the Gemini motors are simply stronger and work better.


Henk Aling
 

Here's a nice explanation of how the holding torque plummets with increasing microstepping that are probably not noticeable, https://www.ti.com/lit/pdf/sloa293 .  I would not be surprised if those $12 steppers of mine cause my problem.


Alexander Varakin
 

Given that the stars are round, I think the mount is not the culprit. 

I hope you realize that you are imaging at 0.56'' per pixel and that is not easy.

Possible culprits most likely are
1. Poor seeing
2. Poor focus. How do you focus ?
3. Poor optics


Yes, I use a lot of sharpening methods in PI - deconvolution and others.

Can you install demo version of PI and do DynamicPSF on your stars and share results?

Then I can compare with my results. 


Henk Aling
 

On Wed, Jul 21, 2021 at 11:35 PM, Alexander Varakin wrote:

Given that the stars are round, I think the mount is not the culprit. 

I hope you realize that you are imaging at 0.56'' per pixel and that is not easy.

Possible culprits most likely are
1. Poor seeing
2. Poor focus. How do you focus ?
3. Poor optics


Yes, I use a lot of sharpening methods in PI - deconvolution and others.

Can you install demo version of PI and do DynamicPSF on your stars and share results?

Then I can compare with my results. 

The seeing may have been poor with the very warm days we had here.  I took an image tonight, about 40x60s subs with recycled biases and flats.  Guiding was ddone mostly with Ekos, several with PHD2, both multi-star.  Ekos seemed to guide better so I went back to that.  I did not counterbalance enough in RA because I wanted to play with loose clutches.  As a result the stars are oblong in RA but not too bad.  The total RMS was pretty bad, 1.5" RMS.  You can tell that the stars are blurry.  Here is a link:  Losmandy_users@groups.io | Photo .  This is on another IO board so just in case you can't see it, here it is included (at poor resolution, I don't know how to preserve it).  I will get a PI teaser subscription later but not now because in a week I will go on vacation so I won't get enough time out of it.  I focus with an autofocuser in Ekos, this works quite well.  I collimated the OTA before I started.  The Newt has a Paracorr II CC.  The optics are fine.



Mark Christensen
 

Henk,

There are two variables you didn't consider: Your skies and the sheer weight (not to mention the moment of inertia) of your rig.

I used my G11 for several years with a 12" f/5 and it was hit or miss for imaging - sometimes I couldn't shoot longer than 120seconds, while other times I could go for 300sec. And of course it made a great sail in any breeze.

When I pulled in my horns and went back to my 8" f/5.5 everything was much more reliable, even if I stick a Barlow on it.

As to guide rate, 0.5X is the max I'd go. The only time I guide at 1X is when I am doing something like chasing a comet head.

Personally I shot 1 to 2 second guiding exposures. If I have done decent job of polar alignment and the skies are stable I get between 0.25 and 0.33". The reason why polar alignment is important is because the fewer corrections the mount makes in either axis the less chance there is that it will impact the other axis. But I don't do a perfect job of polar alignment since that way all corrections (aside from chasing seeing) will be in one direction on DEC. So backlash isn't a player there, and of course it isn't a player in RA either, if you bias the RA balance slightly eastward - that way the gear faces always stay in contact.

Stock G-11, high precision worms, old fashioned worm blocks carefully adjusted. And I don't try to get backlash out! That is overdone by most people and even the factories.

Mark Christensen


Henk Aling
 

Thanks Mark.  The numbers you mentioned are helpful.

I am very aware of the large weight especially now that I am getting more experience with it.  I will try imaging with my 6" Mak-Newt and see if it works better than the 12".

I am using DIY spring loaded worms that work great for goto.  For tracking I have turned them off sometimes and did not notice much difference.

I think my PA is very good as I do it using Ekos.  No drift unguided.  I am counterweighting in RA, not quite ready to misalign in DEC.


Alexander Varakin
 

Henk,
Can you share your guide graph for this session?
Are you getting most of error on RA or on DEC?
Can you share your unprocessed stack? I can measure the PSF for you.



Henk Aling
 

On Thu, Jul 22, 2021 at 07:10 PM, Alexander Varakin wrote:
Henk,
Can you share your guide graph for this session?
Not for this session but I will get a PHD2 log tonight.

Are you getting most of error on RA or on DEC?
This time about 50% more on RA but that was also because I did not counterweight much.  During my best run at 0.6" total RMS they were about equal.

Can you share your unprocessed stack? I can measure the PSF for you.
I will put an Autosave.tif on my cloud space and let you know.

One more question, I can't find good references for the TMC2130's Vref.  There was a calculator online that returned 1.27 V for my 0.9 Amps/phase (== Irms I think).  Howard said to turn it down to half that, which I did.  I would like to understand the effect on tracking accuracy.  I will experiment tonight.


Mike Ahner
 

On Thu, Jul 22, 2021 at 07:13 PM, Henk Aling wrote:
I would like to understand the effect on tracking accuracy.
Maybe start here:
main@onstep.groups.io | Wiki


Henk Aling
 

On Thu, Jul 22, 2021 at 09:06 PM, Mike Ahner wrote:
On Thu, Jul 22, 2021 at 07:13 PM, Henk Aling wrote:
I would like to understand the effect on tracking accuracy.
Maybe start here:
main@onstep.groups.io | Wiki
I know that link well, it doesn't say anything about Vref for the TMC2130.


George Cushing
 

Ah, Losmandy rates the G11 at a 60 pound payload. Your average 12" f/4.5 Newt weighs about 45 pounds. CF may knock off a 2-3 pounds, but you are still pushing the mount's limits.

Additionally, as we say at the yacht club that boat has a a lot of windage. The 50"+ length and 14"+ height of the optical tube has to be considered when evaluating the capacity of a mount. 


Henk Aling
 

I am wondering if I configured my system poorly for the given load and stepper characteristics.

My stepper is 0.9 degrees configured with 64 microsteps.  My gear reduction is 360.  When I am autoguiding at the magical 0.25" RMS it is reasonable to assume that the guider tries to squash errors of around 0.25".  The step size for this after gear reduction is 360*0.25"=90".  The step angle is 0.9*3600/64"=50.625".  The number of steps the stepper needs to take is therefore 90/50.625=1.8 steps.
 
For a well defined pulse clearly we need more than 1.8 steps.  If I guided at 256 microsteps this would be 4x that, 7.2 steps.  Not perfect but a lot better.  So maybe I should use 256 microsteps?  
 
Will the torque then still be good enough depending on the acceleration associated with the pulse ramp-up time?  If it is not we will miss steps, which leads to more error and control action.  
 
The incremental microstepping torque is Tmicro = Thold*sin((pi/2)/nMicro) where nMicro=256 in this case.
 
I found this torque calculation reference at Oriental motors:
 
https://www.orientalmotor.com/products/pdfs/2018-2019/technical-reference/Technical_Reference_Overview.pdf?hsCtaTracking=72ff05cd-3657-4344-9f9a-2e6973a004d1%7C65a4e02f-5779-4945-953a-1e14fe96003b
 
I ran the math for my system:
 
- An OTA of 48 lbs placed at 1 ft from the RA axis
- Counterweights for simplicity placed at 1 ft
- A stepper with a holding torque of 0.36 Nm
- A guide ratio of 0.25
- 256x microstepping
- A static load of 2 lbs at 2 feet (like Howard used in the static stepper analysis)
- An equal amount of friction added (ditto)
- A rotor inertia of 54 g cm^2
- A ramp-up/down time that is 0.1 times the total pulse time
- A safe factor of 2
- I have not accounted for reducing Vref of the TMC2130 to half
 
The outcome of this is that, during the ramp-up, a total torque of Tm=0.0079841 is achieved, with a Tmicro=0.0088348.  Apparently, with this configuration, we are right at the limit of what the stepper can achieve.  With 0.5x guiding I would not be able to step safely.  With 64x microstepping I would not be close enough in terms of accuracy.
 
If you want to check the math or just keep me honest, here's the Scilab script.  The variable names are similar to what is used in the above link, the math was taken from the horizontal rotating table example with 10 weights.
 
// Conversion constants
kg2oz = 35.2739619;
m2in = 39.3700787;
lb2oz = 16;
kg2lb = 2.20462262;
ft2in = 12;
m2ft = 3.2808399;
Nm2ozin = 141.61193227806;
rad2deg = 180/%pi;
rad2as = rad2deg*3600;
 
J0 = (54/1000)/100^2;               // Rotor inertia in kg/m^2
Tl = (2/kg2lb)*(2/m2ft);            // Load torque for 2 lbs at 2 feet
Tl = 2*Tl;                          // Add an equal amount for friction
gearRatio = 360;                    // Gear ratio
guideRatio = 0.25 ;                  // Guide rate
dTheta = 0.25/rad2as;               // Minimum step for control
r = 1/m2ft;                         // Masses (OTA, counterweights) are at 1 ft from RA axis
m = 2*48/kg2lb;                     // 48 lbs plus counterweights
Jw = m*r^2;                         // Moment of inertia in kg-m^2
omEarth = (15/rad2deg)/3600;        // Nominal angular velocity OTA at equator
dOmega = guideRatio*omEarth;        // Change in angular velocity
t0 = (dTheta/dOmega)/1.25;          // Total pulse time
t1 = 0.1*t0;                        // Time to ramp-up or ramp-down linearly, say 0.1*t0
                                    // (t0 + t1)*dOmega = dTheta, t1 = 0.25*t0
 
// After the gearing
Tl1 = Tl/gearRatio;
dPhi1 = dTheta*gearRatio;
Jw1 = Jw/gearRatio;
dOmega1 = dOmega/gearRatio;
 
micro = 64;
thetaStep = (0.9/micro)/rad2deg;    // Step angle
Sf = 2;                             // Safety factor
A = dPhi1/thetaStep;                // Number of pulses
f2 = A/(t0-t1);                     // Pulse speed
Nm = (thetaStep/(2*%pi))*A*60;      // Revolutions per minute
 
// Microstepping torque vs holding torque
Thold = 0.36;                       // Holding torque
Tmicro = Thold*sin((%pi/2)/micro);
 
Ta = ((J0 + Jw1)/9.55)*Nm/t1;       // Acceleration torque
Tm = (Tl1 + Ta)*Sf;                 // Required torque
 


Henk Aling
 

On Thu, Jul 22, 2021 at 07:10 PM, Alexander Varakin wrote:
Henk,
Can you share your guide graph for this session?
Are you getting most of error on RA or on DEC?
Can you share your unprocessed stack? I can measure the PSF for you.
I have the guide log, debug log and Autosave.tif are at

https://1drv.ms/t/s!At7g23ZLfniEogZzcmiOJVv7REFN
https://1drv.ms/t/s!At7g23ZLfniEogdzcmiOJVv7REFN
https://1drv.ms/u/s!At7g23ZLfniEogVzcmiOJVv7REFN

I tried to attach the logs but they show a cross so I think they failed.
The image of 14x60 subs is at Losmandy_users@groups.io | Photo and is at low res included below. 



There is a gradient, the neighbors still have the Christmas lights on outside.  
When you study the log, several things went wrong in the beginning.  DEC started to drift.  I loosened the clutches, still drift.  Later I found that a screw that had to be loose for the SLW was stuck.  After loosening it the SLW could work again and the rest was smooth.  Lots of bumps while I was doing that.  Eventually the clouds moved in.


Henk Aling
 

As an aside, I tried setting the microstepping first to 256x and 128x.  For some reason the goto becomes excruciatingly slow.  I went back to 64x and goto worked normal again.  I suppose the TMC2130 or Wemos does not like those values.  They work for others.