Topics

Problem with absolute encoder AS37


Thomas Westerhoff
 

Hello, Howard,
I had already written at other places that I can't get my AS37 encoder to run and I had the assumption that it is because of the low supply voltage. But now I took a look into the code and found out that the ESP8266 is actively sending a clock on the MA line. But it does not do that for me. I just measured this with the oscilloscope.  Here is my Config.h, which is very similar to the original Config.h. Otherwise the ESP8266 runs without any problems. The web server works as well as the output of debung info via the USB port. What could be the reason for this behaviour?


--
Thomas Westerhoff
Kirchheim Observatory /Germany
http://sternwarte-kirchheim.de/
https://www.facebook.com/VolkssternwarteKirchheim/


Thomas Westerhoff
 
Edited

I don't really know why, but I get some values displayed in the webserver, although I don't measure any usable signal on the lines. But the values, which are shown to me are complete nonsense. Either there are utopian high values or "***Fault***".


--
Thomas Westerhoff
Kirchheim Observatory /Germany
http://sternwarte-kirchheim.de/
https://www.facebook.com/VolkssternwarteKirchheim/


Howard Dutton
 

Same software + same hardware = same result: something isn't the same over there.

Not that I think this is the cause of the problem, but this is a 23bit encoder so (2^23)/360 ticks per degree not 22.222:

#define AXIS1_ENC_TICKS_DEG     23301.688


Howard Dutton
 

You really have it wired correctly right?

(A/CW/MA) & (B/CCW/SLO.)


Thomas Westerhoff
 

Hello Howard,
I get data from the encoders. The wrong parameter AXIS1_ENC_TICKS_DEG was my fault because I thought that an absolute encoder gives the position in a numerical value that doesn't need to be converted by that parameter.
But I still often get a ***Fault*** message in the Web interface.

Another Question:
Ths encoder is very precise. So would it be possible to user this encoder to eliminate the periodic error instead of using a PEC?
--
Thomas Westerhoff
Kirchheim Observatory /Germany
http://sternwarte-kirchheim.de/
https://www.facebook.com/VolkssternwarteKirchheim/


Howard Dutton
 
Edited

On Wed, Dec 2, 2020 at 07:17 AM, Thomas Westerhoff wrote:

But I still often get a ***Fault*** message in the Web interface.

I've never seen a fault indication with the current software here... except when I unplug the encoder.

Another Question:
Ths encoder is very precise. So would it be possible to user this encoder to eliminate the periodic error instead of using a PEC?

1. It's probably not accurate enough and 2. there is no facility in the software to do that.


Howard Dutton
 

On Wed, Dec 2, 2020 at 07:37 AM, Howard Dutton wrote:
On Wed, Dec 2, 2020 at 07:17 AM, Thomas Westerhoff wrote:

But I still often get a ***Fault*** message in the Web interface.

I've never seen a fault indication with the current software here... except when I unplug the encoder.
I could add to the software a re-try count, say up to three successive reading attempts are ignored before giving up and flagging the failure.


Thomas Westerhoff
 

On Wed, Dec 2, 2020 at 07:37 AM, Howard Dutton wrote:
1. It's probably not accurate enough
Well the encoder has a 23bit resolution so there are theoretical 23301.688 ticks per deg.
11650.844 is the correct value that works for me. 23301.688 results in 6h (RA) value difference  when turning the encoder 180 deg.

Ok. 11650.844 ticks per degree gives a resolution of  0.3089 arcsecs per tick and this is extremely precise.
What would happen if I set the "Max angular distance (Encoders vs. OnStep)" to 1 arcsec with this encoder directly mounted on the RA axis? With a periodic error this difference would be achieved if the tehoretical position (from motor coordinates) is different from PE induced encoder values of 1 arcsec. Will the sync simply overwrite the internal coordinates with the encoder coordinates or will the motor move faster or slower to compensate the difference?
--
Thomas Westerhoff
Kirchheim Observatory /Germany
http://sternwarte-kirchheim.de/
https://www.facebook.com/VolkssternwarteKirchheim/


Howard Dutton
 
Edited

On Thu, Dec 3, 2020 at 04:24 AM, Thomas Westerhoff wrote:
Well the encoder has a 23bit resolution so there are theoretical 23301.688 ticks per deg.
11650.844 is the correct value that works for me. 23301.688 results in 6h (RA) value difference  when turning the encoder 180 deg.
Accuracy = +/- 80 arc-seconds according to the datasheet.


Howard Dutton
 

On Thu, Dec 3, 2020 at 05:35 AM, Howard Dutton wrote:
On Thu, Dec 3, 2020 at 04:24 AM, Thomas Westerhoff wrote:
Well the encoder has a 23bit resolution so there are theoretical 23301.688 ticks per deg.
11650.844 is the correct value that works for me. 23301.688 results in 6h (RA) value difference  when turning the encoder 180 deg.
Accuracy = +/- 80 arc-seconds according to the datasheet
My encoder works properly with the 23301.688 value.


Howard Dutton
 

On Thu, Dec 3, 2020 at 05:37 AM, Howard Dutton wrote:
On Thu, Dec 3, 2020 at 05:35 AM, Howard Dutton wrote:
On Thu, Dec 3, 2020 at 04:24 AM, Thomas Westerhoff wrote:
Well the encoder has a 23bit resolution so there are theoretical 23301.688 ticks per deg.
11650.844 is the correct value that works for me. 23301.688 results in 6h (RA) value difference  when turning the encoder 180 deg.
Accuracy = +/- 80 arc-seconds according to the datasheet
My encoder works properly with the 23301.688 value.
I wonder if yours is slightly different, what is the exact model#?


Thomas Westerhoff
 

Hello Howard,
it's an AS37-H39B-B12S
The fact that the encoder has an accuracy of +-80 arc seconds is something I didn't realize. But I wonder why then a resolution of 23bit is used. That is completely unnecessary. Or are there still encoders in the series that are more precise than the AS37?
--
Thomas Westerhoff
Kirchheim Observatory /Germany
http://sternwarte-kirchheim.de/
https://www.facebook.com/VolkssternwarteKirchheim/


Howard Dutton
 

On Thu, Dec 3, 2020 at 07:55 AM, Thomas Westerhoff wrote:
The fact that the encoder has an accuracy of +-80 arc seconds is something I didn't realize. But I wonder why then a resolution of 23bit is used. That is completely unnecessary.
Still useful in some applications I'm sure since it can register a very small movement.  I'm just not so sure it'd be useful for tracking correction.  And the 80 arc-seconds is "with electrical correction" (whatever the heck that is) and at 25°C.  To play the devils advocate there might be enough underlying accuracy to do something with but I'm really not sure.  It's tricky to tell what's going on when you don't have an uber accurate device to conveniently compare it against.

Or are there still encoders in the series that are more precise than the AS37?
Not that I see in the datasheet.


Howard Dutton
 

For the cost and what it does it's still pretty darn impressive.

Just wondering do you have the battery backup attached and if so does your encoder forget its position when powered off?


Howard Dutton
 

On Thu, Dec 3, 2020 at 08:26 AM, Howard Dutton wrote:
Just wondering do you have the battery backup attached and if so does your encoder forget its position when powered off?
Note the encoder doesn't forget its angular position 0 to 360 degrees (0 to 8388608 counts or half of that in your case) I'm talking about the multi-turn position.  So if the angle is 720 degrees and you power off it ends up near zero or 360, that sort of thing.


Thomas Westerhoff
 

On Thu, Dec 3, 2020 at 08:26 AM, Howard Dutton wrote:
Just wondering do you have the battery backup attached and if so does your encoder forget its position when powered off

I made a video this demonstrate what happens if battery is attached.
Sorry for my not so perfect english.

https://www.youtube.com/watch?v=-ejKVuuav1I

Multi-turn postioning I will investigate now.
--
Thomas Westerhoff
Kirchheim Observatory /Germany
http://sternwarte-kirchheim.de/
https://www.facebook.com/VolkssternwarteKirchheim/


Thomas Westerhoff
 

So here is my second video with multi-turn. Multi-turn may be a problem but I think this is unimportant to me because I do no multiturn on our large mount. That would wind up the cables :-)

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

--
Thomas Westerhoff
Kirchheim Observatory /Germany
http://sternwarte-kirchheim.de/
https://www.facebook.com/VolkssternwarteKirchheim/


Howard Dutton
 

On Fri, Dec 4, 2020 at 04:09 AM, Thomas Westerhoff wrote:
Multi-turn may be a problem but I think this is unimportant to me because I do no multiturn on our large mount.
OnStep doesn't, or shouldn't, allow Axes to exceed +/- 360 degrees.

That still allows situations where certain users would need that battery on the encoder to work... though the vast majority wouldn't require it AFAIK just make sure the encoder is positioned properly during installation so the code disk doesn't cross zero (home for each axis is at 180 degrees for the encoders.)


Thomas Westerhoff
 

Hello, Howard,
I tried a little bit more and found out the following. When I turn the encoder everything works fine until I reach the value 1000 (degrees?). In the code in the Command.ino the -999.9 and 999.99 is also set as limit. Then I get the message
MSG: CMD_CH_B "SX40.1004.075070", Error parameter out of range
Interestingly, it is not possible to turn back the encoder to get back into the valid range. I have to set it to zero via the web-interface. Then it counts again.
Couldn't you just set the range of values to a very high value in Command.ino, because if the encoder is not directly connected to the axis, but with a gear ratio, then it can do much more rotations than the one.     


--
Thomas Westerhoff
Kirchheim Observatory /Germany
http://sternwarte-kirchheim.de/
https://www.facebook.com/VolkssternwarteKirchheim/


Thomas Westerhoff
 

Hi,
After the AS37 encoders worked great at home in the experimental setup on the desk with an older OnStep firmware version (i think it was 4.22), I added such encoders to the large mount in the observatory. The conversion lasted a few weeks because of mechanical adaptions and in this context I have also provided the OnStep control with the latest firmware to be up to date. The cables to the encoders are now 1 meter (RA) and 2 meter (DE) long.  But now I have the problem that only occasionally valid data come from the encoders. Something seems to be wrong with the communication (see video).  It is also the case that I can only synchronize the telescope at the moment when BOTH encoders do not return an error. Otherwise, the sync is incomplete, that is, either only the RA or the DE coordinate is taken over or none at all. Could there be a problem with longer cables? What is specified in the BISS hardware specification?

During the troubleshooting I also found also some new entries in the Config.h files. Is there also a suitable documentation for them?
https://youtu.be/MZa9IgqORoE


Here is my Config.h from the WiFi directory.

// ENCODER SUPPORT -----------------------------------------------------------------------------------------------------------------
#define ENC_AUTO_SYNC_DEFAULT          ON //     ON, Automatically sync Encoders to OnStep.                                   Option
#define ENC_AUTO_SYNC_MEMORY           OFF //    OFF, ON Remember automatic sync setting across power cycles.                  Option

#define AXIS1_ENC                     BC_BISSC    //    OFF, CWCCW, AB, BC_BISSC. RA/Azm Axis (A/CW/MA) & (B/CCW/SLO.)                Option
#define AXIS1_ENC_REVERSE             OFF         //    OFF, ON to reverse the count direction.                                       Adjust
#define AXIS1_ENC_TICKS_DEG           33650.1731      // 22.222, n, (ticks/degree.) Encoder ticks per degree.                             Adjust
 
#define AXIS1_ENC_DIFF_LIMIT_TO       300         //    300, n, (arcsec.) Minimum diff. between encoder/OnStep for sync. to OnStep.   Adjust
#define AXIS1_ENC_DIFF_LIMIT_FROM     OFF         //    OFF, n, (arcsec.) Maximum diff. between encoder/OnStep for sync. from OnStep. Adjust
                                                                                    //         For absolute encoders, leave off when setting Zero, then enable.
 
#define AXIS2_ENC                     BC_BISSC //    OFF, CWCCW, AB, BC_BISSC. Dec/Alt Axis (A/CW/MA) & (B/CCW/SLO.)               Option
#define AXIS2_ENC_REVERSE             OFF //    OFF, ON to reverse the count direction.                                       Option
#define AXIS2_ENC_TICKS_DEG           49259.08495 // 22.222, n, (ticks/degree.) Encoder ticks per degree.                             Adjust
 
#define AXIS2_ENC_DIFF_LIMIT_TO       300 //    300, n, (arcsec.) Minimum diff. between encoder/OnStep for sync. to OnStep.   Adjust
#define AXIS2_ENC_DIFF_LIMIT_FROM     OFF //    OFF, n, (arcsec.) Maximum diff. between encoder/OnStep for sync. from OnStep. Adjust
                                            //         For absolute encoders, leave off when setting Zero, then enable.

// 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

Do I need  ENC_AUTO_SYNC_MEMORY if my AS37 encoders are battery buffered and stores the position in internal memory? When I switch it ON then I will get ALWAYS the same coordinates after repowering OnStep regardless of what position the telescope was in when I turned it off. Apparently a value was stored at some point and is now always retrieved.
 
ENC_AUTO_SYNC_DEFAULT ON: Does this mean that OnStep automatically gets the position data of the encoders cyclically, or that the encoders get the Onstep coordinates transmitted cyclically?

What does zeroing the absolute encoder via the web interface?

--
Thomas Westerhoff
Kirchheim Observatory /Germany
http://sternwarte-kirchheim.de/
https://www.facebook.com/VolkssternwarteKirchheim/