Topics

Tracking Accuracy


Howard Dutton
 
Edited

On Tue, Oct 30, 2018 at 11:56 AM, Khalid Baheyeldin wrote:
Last night, I tried Full Compensation, Dual Axis. I was using the latest OnStep version and Android app available at the time (that is, the version prior to today's releases with the DF fix).

I did a 6 star align, and was given 192" and 192" as polar alignment error (suspicious that both values are identical).
The coefficient search is "granular" ending at 64 (arc-seconds) for "mid-level" performance MCU's... 3 x 64 = 192, so this result isn't all that unlikely. 
For a Teensy3.5/3.6 or ESP32 the search ends at 16.
On a Mega2560 the search ends at 128 (about 2 arc-minutes, and the # of coefficients searched for is fewer too.)
On a PC, using Sky Planetarium to solve, the search ends at 1 arc-second (you can then upload the model.)

Trade-offs due to performance limitations are necessary.

The sequence of the 6 stars were kind of odd, with 2 west of the meridian, two east of it, then one west, then one east. The confusion was because I kept adjusting the list of stars as I was waiting for the clouds to clear out, and forgot to sort them by proximity. Not sure if that makes a difference.
Sequence meridian side etc. should be no issue for GTA.  It doesn't care.

The results are inconclusive when I took 480 second exposures. I did not see much difference between with and without Full Comp Dual.
Other sources of error may be overwhelming the small (but important) potential improvements.  The large polar alignment error in my initial test was deliberate so I could easily see the correction work.

There was also some breeze.

Other factors that I can think of are:

1. PEC:
There is no PEC. I did not start using this feature yet. There is no sensor in the mount (yet). I can use the Park feature, but want to first get a hand controller so recording PEC is easier (will be awkward with a touch screen).
Setup autoguiding.  Use android app to press "Record".  Wait for it to complete.

Lack of PEC will produce a short streak while the star oscillates(*) in place because of the PE of the worm gear.
Yes.

2. Backlash:
I did adjust backlash values somewhat, but not sure if these are the optimal values. The mount can do precision slews with 30" arc second margin of accuracy.

If the backlash values are inaccurate, they can cause imprecise compensated tracking.
In that this can mess up the alignment.  Otherwise no.

On the next available clear sky window, I plan on trying the newer version of OnStep with the DF fix.
Good plan, thanks for testing! 

Sorry the DF thing ... testing this stuff takes serious effort so thanks for looking at it.

Here's what last night's OnStep model (LXD75) looked like before the fix...



And after (this was uploaded, solved in OnStep, then downloaded again)...


And SP's internal GTA solution...


Here's a graphic display of the model at work (the corrected model.)  Just a fraction of the points so you can see the results clearly.  The Bulls eye circle in a circle shows the model working.  The short line in each is where the instrument pointing would have been vs. where it is now (small circle.)


Khalid Baheyeldin
 
Edited

On Tue, Oct 30, 2018 at 05:02 PM, Howard Dutton wrote:
The coefficient search is "granular" ending at 64 (arc-seconds) for "mid-level" performance MCU's... 3 x 64 = 192, so this result isn't all that unlikely. 
For a Teensy3.5/3.6 or ESP32 the search ends at 16.
On a Mega2560 the search ends at 128 (about 2 arc-minutes, and the # of coefficients searched for is fewer too.)
On a PC, using Sky Planetarium to solve, the search ends at 1 arc-second (you can then upload the model.)

Trade-offs due to performance limitations are necessary.

Good to know.

I added a section comparing all MCUs (ignoring the lesser used Tiva), and included what you said, plus the MaxRate

See it at the end of this page, and please revise it for accuracy.

https://groups.io/g/onstep/wiki/8-Advanced-Topics

Perhaps a dedicated page under 'Construction' called 'Comparison' is a better place. I leave that up to you.


Howard Dutton
 
Edited

On Tue, Oct 30, 2018 at 11:56 AM, Khalid Baheyeldin wrote:
1. PEC:
There is no PEC. I did not start using this feature yet. There is no sensor in the mount (yet). I can use the Park feature, but want to first get a hand controller so recording PEC is easier (will be awkward with a touch screen).
My LXD75 has no PEC sensor either.

Lack of PEC will produce a short streak while the star oscillates(*) in place because of the PE of the worm gear.
I have streaks, as expected, in my LXD75 unguided images too (even with compensated tracking.)  Even PEC will not fix "all things mechanical" (NPE) anyway - it just improves what you have.  I like having the option though for the ease of use since it extends what's possible (in exposure length/image scale) with acceptable results while not having to mess around with guiding.  However, for a portable mount I find parking a pain in the neck so I don't bother with PEC unless I have the sensor...

On the other hand my LXD75 test mount has a fancy Gruley 8235S 200k encoder on the RA axis and I've been toying around with that for a few days.  I'm cautiously optimistic about the prospects of this working now but until it's out under the stars I really don't know.

There's a wide range of options for the Gruley 8235S but this one has a 10,000 line optical disc (near the max available) and 20x interpolation to reach 200k resolution.  My tests so far are encouraging in that they seem to show the worm's PE.

The software for this runs on the ESP8266 or Teensy3.2, etc. (Wifi/Network add-ons.)  The system is configurable and adaptable to different encoders but presently only supports CW/CCW units (I'd need to customize the quadrature encoder library to pick up the pulse timing for A/B type.)  Since this measures the frequency of encoder pulses in addition to the counts there is overhead involved and during a fast manual move or slew it might miss pulses - I'm really not sure.  Worse case I could add controls where the user selects what function they want and if imaging or slewing swap the ISR's.  There's controls that adjust the rolling averages (Blue short term) Green (long term) and for interpolation correction (a cosine correction term with adjustable period (20 samples in this case) and phase to match the encoders interpolation window.  Then a "Magnitude" term is adjusted to cancel out the cyclic interpolation error.  It works very well for my encoder and really knocks the noise down.

There are blue and green traces on the chart, I setup so that the Blue trace is responsive at time-scales of about 20 seconds so should be able correct for errors that matter during imaging.  The Green trace is slow moving but still fast enough to show large scale errors, like worm PE.

The graph at the bottom is 600 seconds wide (the worm period) and vertical scales of +/- 0.2 x sidereal Blue and +/- 0.02 x sidereal Green. 

The Green trace then, if fully displaced to the top of the chart would represent 0.02 * 15 =0.3 arcsec per second faster than the rate OnStep is shooting for.  So for example one minute width of Green trace at the top would be 0.3*60 = +18 arc-seconds of motion.  Keeping this in mind you can see that my data is very much inline with what one would expect from a LXD75 (they generally run around +/-15 or 20 arcsec PE.)  The chart uses transparency so if you look closely can see the darker green and blue dots from the prior pass.  The pattern repeats hour after hour, and yes it looks like the overall (average) rate is just a hair fast but it seems consistent and there's an adjustment to compensate for that too (Encoder rate comp.)




So is that worm PE or just some encoder error that just happens to match the worms 10 minute period?  And assumed magnitude too, from recent images I estimate this LXD75 to be +/- 14.5" the above chart shows the rate holding at (I estimate) +/-0.003 or 0.004 for about 40% of the period, lets say 0.0035 for 4 minutes, that's (0.0035*15*240) 12.6 arcsec.  Still... I won't be convinced until I see the evidence on an image.

And as above except the OnStep rate control is enabled (kind of like guiding but with a new command that sends a rate correction directly.)


Khalid Baheyeldin
 

On Fri, Nov 2, 2018 at 12:49 PM, Howard Dutton wrote:
However, for a portable mount I find parking a pain in the neck so I don't bother with PEC unless I have the sensor...
My previous GPDX with the Sky Sensor 2000 PC did not require any parking to keep track of the PEC curve. It was always there. Very convenient, and I miss this feature.

There are blue and green traces on the chart
Those before and after charts are immensely impressive! Well done.

Too bad they require yet another piece of hardware to be somehow mounted (the main challenge with OnStep in general).


Howard Dutton
 
Edited

On Fri, Nov 2, 2018 at 12:56 PM, Khalid Baheyeldin wrote:
Too bad they require yet another piece of hardware to be somehow mounted (the main challenge with OnStep in general).
Some mounts are easier than others.  The LXD75 is not one of the easier ones and without the 3D printer there would have been NO WAY I would gone to the effort and expense.  The encoder cost me only about $100 on eBay and I had the printer already.

And again, not even sure this will work, looks and reality can be two different things.  And there's plenty of room between barely works and amazing performance too.


Howard Dutton
 
Edited

On Fri, Nov 2, 2018 at 01:06 PM, Howard Dutton wrote:
And there's plenty of room between barely works and amazing performance too.
I was thinking last night about how to get more performance from the encoder.  Currently I time the arrival of each pulse (one to the next,) average them (rolling average) and apply the cosine correction factor.

Instead, I'm thinking about timing all 20 pulses separately (20x interpolation.)  So I'd have 20 rolling averages and then take those and do a traditional average on the array to arrive at a final rate.  No need for cosine correction.

I'll implement this, if it's an improvement I'll keep the existing system and allow the user to choose.  Lots of encoder designs out there.


Howard Dutton
 

Here's the indoor test results of the new routine I described.  It does appear to significantly improve the performance.  Note the chart height is 300 px instead of 200 px and also the scale is 0.1 and 0.01x sidereal instead of 0.2 and 0.02x so the chart vertical is 3x the resolution.  Is this capable of working?  I don't know... but I feel the concept is good and even if my encoder setup isn't up to the task I'll leave the code in the add-ons for other adventurous individuals.  I will test under the stars soon and report.

First, the before data (no guiding:)




And the after data with guiding:



Howard Dutton
 
Edited

Since the subject of encoders came up again recently I setup the LXD75 mount and did some testing outdoors.  Note that the prior results in this topic were done on a MaxESP and that controller was decommissioned in favor of a MaxESP2.

This was my first time taking the whole setup out in a while and getting everything going took away from my available time to get the data so more work is needed but I believe this confirms that the rate control works.  The mount polar alignment was poor which was both a good thing and a bad thing for this testing. The camera image scale is 2.47 arc-seconds/pixel and Dec lines up very closely with the vertical and so RA with the horizontal.

Here's a full worm period (10 minutes) on single star.  This is an unregistered stack of 10x 1 minute exposures unguided (dual axis refraction compensation enabled,) no PEC, no Encoder:



Same star and conditions as above except the Gurley 8235S Encoder is controlling the tracking rate.  A close examination of these images reveals that not only is the long-term rate closer to optimal but the FWHM (star width) of the following image seems to be better than the above (more flux in fewer pixels):



Here's the center crop of the registered stack of 10x 1 minute exposures (near M101) with the encoder controlling the rate.  You can see the stars are slightly oblong vertically (Dec axis) which a better polar alignment would have fixed.  The better polar alignment and better tuned encoder rate control can probably still tighten up the RA axis too.  PEC could be enabled alongside the Encoder control so there is less rate variation to fight against which you'd think would help too.  In short a good start and I still see plenty of room for improvement.


Howard Dutton
 
Edited

Here's some test data from last weekend (indoors) before I took the images in the last post.

First, before any of this I used the encoder tracking rate control to record a few rounds of PEC.  The encoder guides OnStep using the pulse-guide command so you can record PEC from it...




Then I turned all rate correction off (PEC and Encoder) and just logged the mount's detected tracking rate.  I had the averaging set fairly deep for this so the data is nice and smooth but the latency would be a bit more than I like, though it still serves to demonstrate that things are working.  The chart sensitivity was so high the LTA was knocked out of scale so isn't present, again, that doesn't really matter.  You can see the darker shaded traces from the prior cycles and how nicely PE repeats:




Now here's what things looked like with the just PEC running:




And with just the Encoder guiding:




Finally with both PEC and Encoder guiding:


Jay Murphy
 

That's awesome, Howard.


Howard Dutton
 

On Tue, Jul 9, 2019 at 11:06 AM, Aisling Lightworks wrote:
That's awesome, Howard.
Thank you, it's a relief to see it really work for the first time, I put a few hours into this.


bjaffa Jaffa
 

Howard,

I want to try to duplicate your indoor testing but I am not sure if I have the right hardware & software revisions.
Here is my current configuration: OnStep v3.16o  (MaxPCBv2)
                                                     SkyPlanetarium 4.46        Ascom OnStep Driver: On-Cue-On-Step2.0.4  connected via USB/COM  POTH connection
                                                     Ethernet Addon  OnEth 1.11f   (note: this not the latest with OnStep v3.16o)
                                                     I have high res. encoders on the RA & DEC axis but do not have encoder rate control enabled
Question: 1. Does the webserver of the Ethernet Addon support the graphical display of the PEC graph or do I need to update the Ethernet addon version?
                     Also the Config.h has the the motion control   #define  STEP_WAVE_FORM       SQUARE     Do I need to change this to PULSE?
                     I do not see any wave form in ether the webserver (actually not graphical display at all)  or the PEC graph on SkyPlanetarium
 If I turn on Full Dual Axis Compensation either through SkyP or the webserver I do not see any waveform only the vertical lines advancing either through recording or playback

Thanks,

Brent


 


Howard Dutton
 

On Sun, Aug 2, 2020 at 10:30 AM, bjaffa Jaffa wrote:
I want to try to duplicate your indoor testing but I am not sure if I have the right hardware & software revisions.
Good luck, my final results were "inconclusive."

Question: 1. Does the webserver of the Ethernet Addon support the graphical display of the PEC graph or do I need to update the Ethernet addon version?
That graphic depicted below is in the Ethernet addon.  You simply have to enable it.

                     Also the Config.h has the the motion control   #define  STEP_WAVE_FORM       SQUARE     Do I need to change this to PULSE?
No, that doesn't matter for this.


bjaffa Jaffa
 

Thanks Howard  but how is the graphical display enabled? I don't see the TAB/Button to turn it on?

Thanks


Howard Dutton
 

On Sun, Aug 2, 2020 at 10:59 AM, bjaffa Jaffa wrote:
Thanks Howard  but how is the graphical display enabled? I don't see the TAB/Button to turn it on?
In the Addon's Config.h file.


bjaffa Jaffa
 


Howard,

Below is the addon ethernet config.h file.  Are these the parameters that must be set to ON to get the graphical display in the webserver?

// DISPLAY -------------------------------------------------------------------------------------------------------------------------
#define DISPLAY_HIGH_PRECISION_COORDS OFF //    OFF, ON for pull high precision coordinates from OnStep.                      Option
#define DISPLAY_HIGH_PRECISION_COORDS OFF //    OFF, ON for high precision coordinate display on status page.                 Infreq
 
Also if I wanted to experiment with encoder rate control is there any description on how/what the rate control parameters control?

// ENCODER RATE CONTROL
#define AXIS1_ENC_RATE_CONTROL        OFF //    OFF, ON Rate control for RA high resolution encoder. EQ mounts only.          Infreq
#define AXIS1_ENC_INTPOL_COS          OFF //    OFF, ON enables cosine compensation feature.                                  Infreq
#define AXIS1_ENC_RATE_AUTO           OFF //    OFF, n, (Worm period in seconds.) Adjusts avg encoder pulse rate to account   Option
                                          //         for skew in the average guide rate over the last worm period.            Option
#define AXIS1_ENC_BIN_AVG             OFF //    OFF, n, (Number of bins.)  Enables binned rolling average feature.            Option
 

Thanks,


// ---------------------------------------------------------------------------------------------------------------------------------
// Configuration for OnStep Ethernet Add-on
 
/*
 *          For more information on setting OnStep up see http://www.stellarjourney.com/index.php?r=site/equipment_onstep 
 *                      and join the OnStep Groups.io at https://groups.io/g/onstep
 * 
 *           *** Read the compiler warnings and errors, they are there to help guard against invalid configurations ***
*/
 
// ---------------------------------------------------------------------------------------------------------------------------------
// ADJUST THE FOLLOWING TO CONFIGURE YOUR ADD-ON'S FEATURES ------------------------------------------------------------------------
// <-Req'd = always must set, <-Often = usually must set, Option = optional, Adjust = adjust as req'd, Infreq = infrequently changed
 
//      Parameter Name              Value   Default  Notes                                                                      Hint
// ETHERNET HARDWARE ---------------------------------------------------------------------------------------------------------------
//#define W5500                         OFF //    OFF, ON If using W5500 Ethernet Adapter: RST ctrl Pin9, SPI default pins,     Option
#define W5500                         ON //    OFF, ON If using W5500 Ethernet Adapter: RST ctrl Pin9, SPI default pins,     Option
                                          //         CS on Pin10. OFF for W5100 adapter. Uses standard Arduino libraries.
 
// SERIAL PORTS --------------------------------------------------------------------------------------------------------------------
#define SERIAL_BAUD_DEFAULT          9600 //   9600, Common baud rates for these parameters are 9600,19200,57600,115200.      Infreq
#define SERIAL_BAUD                 57600 //  57600, Use 19200 if talking to a Mega2560 OnStep                               <-Req'd
                                          //         At startup this firmware will attempt to switch OnStep's baud rate to this
                                          //         faster speed (vs. SERIAL_BAUD_DEFAULT) and AFTER success, start WiFi, etc.
 
// DISPLAY -------------------------------------------------------------------------------------------------------------------------
#define DISPLAY_WEATHER               OFF //    OFF, ON Shows weather/ambient conditions (from OnStep) on status page.        Option
#define DISPLAY_INTERNAL_TEMPERATURE  OFF //    OFF, ON for internal MCU temperature display.                                 Option
#define DISPLAY_HIGH_PRECISION_COORDS OFF //    OFF, ON for pull high precision coordinates from OnStep.                      Option
#define DISPLAY_SPECIAL_CHARS          ON //     ON, For standard ASCII special symbols (compatibility.)                      Infreq
#define DISPLAY_ADVANCED_CHARS         ON //     ON, For standard "RA/Dec" instead of symbols.                                Infreq
#define DISPLAY_HIGH_PRECISION_COORDS OFF //    OFF, ON for high precision coordinate display on status page.                 Infreq
 
// COMMAND CHANNELS ----------------------------------------------------------------------------------------------------------------
#define MONITOR_GUIDE_COMMANDS        OFF //    OFF, Allow error reporting to also monitor guide commands.                    Infreq
 
// ENCODER SUPPORT -----------------------------------------------------------------------------------------------------------------
//#define AXIS1_ENC                     OFF //    OFF, CWCCW, AB. RA/Azm Axis on Pin 5 (A or CW) and Pin 6 (B or CCW,)          Option
#define AXIS1_ENC                     AB //    OFF, CWCCW, AB. RA/Azm Axis on Pin 5 (A or CW) and Pin 6 (B or CCW,)          Option
#define AXIS1_ENC_REVERSE             ON //    OFF, ON to reverse the count direction.                                       Adjust
#define AXIS1_ENC_TICKS_DEG     864.71111 // 555.55, n, (ticks/degree.) Encoder ticks per degree.                             Adjust
#define AXIS1_ENC_DIFF_LIMIT          900 //    900, n, (arcsec.) Maximum difference between encoder and OnStep before sync.  Adjust
 
//#define AXIS2_ENC                     OFF //    OFF, CWCCW, AB. Dec/Alt Axis on Pin 7 (A or CW) and Pin 8 (B or CCW)          Option
#define AXIS2_ENC                     AB //    OFF, CWCCW, AB. Dec/Alt Axis on Pin 7 (A or CW) and Pin 8 (B or CCW)          Option
#define AXIS2_ENC_REVERSE             ON //    OFF, ON to reverse the count direction.                                       Option
#define AXIS2_ENC_TICKS_DEG      864.71111 // 13.333, n, (ticks/degree.) Encoder ticks per degree.                             Adjust
#define AXIS2_ENC_DIFF_LIMIT          900 //    900, n, (arcsec.) Maximum difference between encoder and OnStep before sync.  Adjust
                                                     
#define ENCODERS_AUTO_SYNC            OFF //    OFF, ON, Enable support for auto sync of OnStep to encoder values.            Adjust
 
// ENCODER RATE CONTROL
#define AXIS1_ENC_RATE_CONTROL        OFF //    OFF, ON Rate control for RA high resolution encoder. EQ mounts only.          Infreq
#define AXIS1_ENC_INTPOL_COS          OFF //    OFF, ON enables cosine compensation feature.                                  Infreq
#define AXIS1_ENC_RATE_AUTO           OFF //    OFF, n, (Worm period in seconds.) Adjusts avg encoder pulse rate to account   Option
                                          //         for skew in the average guide rate over the last worm period.            Option
#define AXIS1_ENC_BIN_AVG             OFF //    OFF, n, (Number of bins.)  Enables binned rolling average feature.            Option
 
// AUXILLARY SWITCH/FEATURE CONTROL ------------------------------------------------------------------------------------------------
// *** Warning: only OnStep Aux pins that are unused for other purposes should be assigned! ***
#define SW0_OFF                           //   _OFF, "Name" for Aux0 feature on Control webpage, provides On/Off control.     Adjust
#define SW1_OFF                           //   _OFF, "Name" for Aux1 feature on Control webpage, provides On/Off control.     Adjust
#define SW2_OFF                           //   _OFF, "Name" for Aux2 feature on Control webpage, provides On/Off control.     Adjust
#define SW3_OFF                           //   _OFF, "Name" for Aux3 feature on Control webpage, provides On/Off control.     Adjust
#define SW4_OFF                           //   _OFF, "Name" for Aux4 feature on Control webpage, provides On/Off control.     Adjust
#define SW5_OFF                           //   _OFF, "Name" for Aux5 feature on Control webpage, provides On/Off control.     Adjust
#define SW6_OFF                           //   _OFF, "Name" for Aux6 feature on Control webpage, provides On/Off control.     Adjust
#define SW7_OFF                           //   _OFF, "Name" for Aux7 feature on Control webpage, provides On/Off control.     Adjust
#define SW8_OFF                           //   _OFF, "Name" for Aux8 feature on Control webpage, provides On/Off control.     Adjust
 
// AUXILLARY ANALOG/FEATURE CONTROL ------------------------------------------------------------------------------------------------
// *** Warning: only OnStep Aux pins that are unused for other purposes should be assigned! ***
#define AN3_OFF                           //   _OFF, "Name" for Aux3 feature on Control webpage, provides 0..100% PWM.        Adjust
#define AN4_OFF                           //   _OFF, "Name" for Aux4 feature on Control webpage, provides 0..100% PWM.        Adjust
#define AN5_OFF                           //   _OFF, "Name" for Aux5 feature on Control webpage, provides 0..100% PWM.        Adjust
#define AN6_OFF                           //   _OFF, "Name" for Aux6 feature on Control webpage, provides 0..100% PWM.        Adjust
#define AN7_OFF                           //   _OFF, "Name" for Aux7 feature on Control webpage, provides 0..100% PWM.        Adjust
#define AN8_OFF                           //   _OFF, "Name" for Aux8 feature on Control webpage, provides 0..100% PWM.        Adjust
 
// ETHERNET SETTINGS ---------------------------------------------------------------------------------------------------------------
// Enter a unique MAC address for your controller if you like:
byte mac[] = { 0xDE, 0xAD, 0xBE, 0xEF, 0xFE, 0xED };
// The IP addresses below will be dependent on your local network:
//IPAddress ip(192, 168, 1, 55);
//IPAddress myDns(192,168, 1, 1);
//IPAddress gateway(192, 168, 1, 1);
//IPAddress subnet(255, 255, 255, 0);
IPAddress ip(192, 168, 2, 10);
IPAddress myDns(192,168, 2, 1);
IPAddress gateway(192, 168, 2, 1);
IPAddress subnet(255, 255, 255, 0);
 
// THAT'S IT FOR USER CONFIGURATION!
 
// -------------------------------------------------------------------------------------------------------------------------
 
#define Ser Serial1 // Default=Serial1, This is the hardware serial port where OnStep is attached
 
// ---------------------------------------------------------------------------------------------------------------------------------
 


Howard Dutton
 

On Sun, Aug 2, 2020 at 04:50 PM, bjaffa Jaffa wrote:
Also if I wanted to experiment with encoder rate control is there any description on how/what the rate control parameters control?

// ENCODER RATE CONTROL
#define AXIS1_ENC_RATE_CONTROL        OFF //    OFF, ON Rate control for RA high resolution encoder. EQ mounts only.          Infreq
Turns the feature on.

#define AXIS1_ENC_INTPOL_COS          OFF //    OFF, ON enables cosine compensation feature.                                  Infreq
Provides a manually adjustable correction based on the cosine of some period (in ticks.)  If the encoder design is such that it suffers from a behavior like this and this is a good fit for the inaccuracy you can create an opposite error to apply to correct that.

#define AXIS1_ENC_RATE_AUTO           OFF //    OFF, n, (Worm period in seconds.) Adjusts avg encoder pulse rate to account   Option
                                          //         for skew in the average guide rate over the last worm period.            Option
For worm/wheel mounts.  Corrects for gross (large scale) inaccuracy in the encoder by assuming the angular distance traveled by one worm rotation is more accurate than the encoder.  It measures this and applies a correction.

#define AXIS1_ENC_BIN_AVG             OFF //    OFF, n, (Number of bins.)  Enables binned rolling average feature.            Option
Some encoders have a cyclic pattern where they interpolate between the lines of an optical disc with significantly fewer ticks than the encoder has.  In the case of my encoder it's 20x more ticks then lines.  There is a repetitive pattern, a consistency, with each frame of 20 readings.  One can leverage that precision to extract more accuracy from the encoder by not looking for the equal time between ticks (vs. some average or calculated time) but for the time between each 20th tick.

I used the last two of these in my tests.

Then in the UI you will see the ability to tailor each of these.  How many bins, how deeply to average, etc.

To help visualize what's going on there's settings for STA, LTA:
STA stands for short term average.
LTA stands for long term average.

When running this looks at the rate the ticks arrive and applies the STA then decides if too fast or slow and applies guide pulses to OnStep.


bjaffa Jaffa
 

Howard can you tell me the specific config.h parameter which will turn on the graphical interface in the EthernetAddOn module?
I have gone through the config.h and do not see the function?

Also there are two similar define statements (DISPLAY_HIGH_PRECISION_COORDS)  in the config.h disply section  are they just a duplicate?

// DISPLAY -------------------------------------------------------------------------------------------------------------------------
#define DISPLAY_WEATHER               OFF //    OFF, ON Shows weather/ambient conditions (from OnStep) on status page.        Option
#define DISPLAY_INTERNAL_TEMPERATURE  OFF //    OFF, ON for internal MCU temperature display.                                 Option
#define DISPLAY_HIGH_PRECISION_COORDS OFF //    OFF, ON for pull high precision coordinates from OnStep.                      Option
#define DISPLAY_SPECIAL_CHARS          ON //     ON, For standard ASCII special symbols (compatibility.)                      Infreq
#define DISPLAY_ADVANCED_CHARS         ON //     ON, For standard "RA/Dec" instead of symbols.                                Infreq
#define DISPLAY_HIGH_PRECISION_COORDS OFF //    OFF, ON for high precision coordinate display on status page.                 Infreq