Topics

Astro Physics 1200 - OnStep Conversion & Encoder Question


Rockmover
 

Just an update on my AP1200 project and an encoder question for the group.

I finally had a chance over the holiday weekend to tear into the AP-1200 mount.  It was really stiff, so I pulled the worm gears, cleaned out all the old thick green grease they use, cleaned the worm and main gears (both RA & DEC), and re-lubed everything.  Happy to say it was smooth as silk once it was back together!

On the telescope side I installed one of the massive PKP268MD28A2 on the RA axis. For now I am using a smaller PKP246MD15A2 motor on the DEC axis.  I have two of these on my G-11 and I like them quite well. However, my gut feeling is that it will be too small for this mount, especially in -20C Minnesota winters.  The viscosity of the AP mounting grease is quite large under -10C, so even with a perfectly balanced 75 lbs load there is a lot of hysteresis.

Mounting the motors was very straight forward and I just needed to machine a simple motor mount for the RA motor.  I made a mount for the DEC axis as well, but for now the motor bracket fit almost dead on so I just used that as is.

One trick was the 100 tooth gear on the RA axis.  I didn’t like the stock coupling, plus an extension shaft, plus the gear. I felt there was too much runout, and that it may affect my PEC.  So instead I machined a single piece coupling and shaft out of aluminum. I used a Y pattern for the set screws which let me tighten them to minimize the runout with a dial indicator (image below).

The 100/20 tooth gives me a 5:1 stepdown ratio, and thus with the 225 main gear lets me use only a 32 microstep size.  On the DEC axis I have 60/20 and thus am using 64 steps.

I have a board with the TCM2130’s, but also another one with 5160 (I cut the clk pin and wired a ground wire as per the posts elsewhere regarding the big tree controllers).  Not sure which one I am going to use…suggestions?

 

Now to the main question….

 

The mount is NOT a goto mount (one of the reasons I was able to pick it up relatively dirt cheap).  However, it has encoders (which have never been used) built into it.  Turns out they are 4000 PPR encoders. I made up a little test Ardunio board and they both seem to be working fine with some simple test code (A,B, ground, and 5 volt pins).

 

My question is what advantage would these even give me?  How does OnStep use encoders in the algorithm?  I am always using an off axis guider, and I 100% of the time do a plate solve to get my targets dead on before imaging.  So, even though I have free encoders, and I have a MaxPCB v2 board that I have encoder support on (3 of these boards actually), I don’t know if it will do anything for me?  Also, is it better to have encoders on the motor/worm drive to detect slip (or motor stall), or is it better to have them on the axis and thus have the real position (once you have star aligned)?

 

I am putting on a PEC index switch (I have both a HAL and mechanical one I have mounted…just not sure which I like better right now).  So I don’t know how/if that effects the encoders?

 

And finally, I know absolute encoders are not supported in OnStep, but I am really thinking about adding them to this scope. I am also happy to write my own code and have a separate controller for them. Basically, all I want is an approximate position so I can plate solve and get the exact location.  That way if I loosen the mount, power goes out, the PC locks up, or any of the other 100 things that happen on occasion, I will never need to realign the scope again (this is in a permanent observatory BTW).  Has anyone already done this?  Why or why not?  Am I missing something?  Seems you can get reasonable absolute encoders for about $150 each, so add $50 for a good Arduino board and some parts and for <$300 a guy would have a mount that never needed to be re-aligned. After plate solving I would update the absolute encoder info, but that’s simple. …and with all that being said, if there are a couple free pins, why couldn’t this just be added in OnStep? It would literally only need to get the encode info on startup, and then save it once plate solving is done???  There would be no extra overhead during normal operation.





Rockmover
 

Seems my last message would post, so here are the other pictures:

   

  





Rockmover
 


And the motor mounts:


  


Howard Dutton
 

On Tue, Sep 8, 2020 at 12:48 PM, Rockmover wrote:

My question is what advantage would these even give me?  How does OnStep use encoders in the algorithm?  I am always using an off axis guider, and I 100% of the time do a plate solve to get my targets dead on before imaging.  So, even though I have free encoders, and I have a MaxPCB v2 board that I have encoder support on (3 of these boards actually), I don’t know if it will do anything for me?  Also, is it better to have encoders on the motor/worm drive to detect slip (or motor stall), or is it better to have them on the axis and thus have the real position (once you have star aligned)?

 

Encoder support is really just for pointing.  Whenever a slew isn't happening and an OnStep axis coordinate relative to an Encoder coordinate > some threshold, the Axis coordinate (index offset) is updated.

 

I am putting on a PEC index switch (I have both a HAL and mechanical one I have mounted…just not sure which I like better right now).  So I don’t know how/if that effects the encoders?

 

Encoders and PEC don't interact.  Encoders update the index offsets in OnStep, PEC is lower level using motor coordinates.

And finally, I know absolute encoders are not supported in OnStep, but I am really thinking about adding them to this scope. I am also happy to write my own code and have a separate controller for them.

Not specifically supported but they were on my mind when coding the encoder support and one is free to use those four A/B inputs (or 1/2 of them even) as a pair of serial interfaces instead.  In-fact I will be working on exactly that in the coming weeks and testing an (biss-c) Broadcom AS38-H39E series encoder I have in my possession curiosity of JTW Astronomy who asked about support for it.


Khalid Baheyeldin
 

On Tue, Sep 8, 2020 at 03:48 PM, Rockmover wrote:

However, my gut feeling is that it will be too small for this mount, especially in -20C Minnesota winters.  The viscosity of the AP mounting grease is quite large under -10C, so even with a perfectly balanced 75 lbs load there is a lot of hysteresis.

Snowmobile grease may help here, since it is designed for such harsh winters, similar to what we have in Ontario, Canada.

I have a board with the TCM2130’s, but also another one with 5160 (I cut the clk pin and wired a ground wire as per the posts elsewhere regarding the big tree controllers).  Not sure which one I am going to use…suggestions?

The TMC5160 is better, because it does not heat at all like the the TMC2130.
It also has the current setting in the firmware, via Config.h, so adjusting the current is just a matter of editing, compiling, and flashing.

Note that my answers below on the encoders are to be considered "preliminary", and should be taken with a grain of salt.
The reason being I don't use encoders myself, and the info below is from past discussions about them.

My question is what advantage would these even give me?  

Not much. 4000 PPR is too coarse (5.4 arc minutes) for correcting the tracking ratio.

How does OnStep use encoders in the algorithm? 

It is an experimental feature, and only a few people have used it. It is done by connecting the encoders to the WeMos, not to the main microcontroller. It is mainly used to help the scope know where it is pointing. For example, you can combine push to and goto, and the scope would still know where it is, unlike with pure steppers without encoders, where OnStep would lose its bearings if you did it.

Refining the tracking is not possible with your encoders, even if this was a well tested feature (see above: too coarse).

I am always using an off axis guider, and I 100% of the time do a plate solve to get my targets dead on before imaging.  

If it was me, I would just continue to use autoguiding, and forget about the encoders completely.
Others who used the encoders should pitch in here.

I am putting on a PEC index switch (I have both a HAL and mechanical one I have mounted…just not sure which I like better right now).  

I have a Hall Effect sensor on my mount for PEC. But since I started autoguiding, I found that PEC is not needed at all.
The above statement should be qualified with: my PE is very low at -/+ 2" (or was it 4"? Either way it is way lower than regular EQ5 mounts and such).
The AP1200 must have a low PE, better than my Vixen SXD.
Since you are planning to autoguide, I would say: don't bother with the PEC until you have tested the mount under the stars, with autoguiding.

And finally, I know absolute encoders are not supported in OnStep, but I am really thinking about adding them to this scope. I am also happy to write my own code and have a separate controller for them. Basically, all I want is an approximate position so I can plate solve and get the exact location.  That way if I loosen the mount, power goes out, the PC locks up, or any of the other 100 things that happen on occasion, I will never need to realign the scope again (this is in a permanent observatory BTW).  Has anyone already done this?  

The current encoder functionality allows for this: OnStep knowing where the scope is pointing.
You don't need absolute encoders. Probably the 4000 PPR that you have suffice for this.

Read the Encoder Support section here

https://onstep.groups.io/g/main/wiki/5650


Rockmover
 

I am really liking the specs on that AS38-H39E (16 bit), and it only $207 on mouser.

I was just going to order a 14 bit abs encoder to play with, but for that price I might just get that one too...


Howard Dutton
 

On Tue, Sep 8, 2020 at 12:48 PM, Rockmover wrote:
 That way if I loosen the mount, power goes out, the PC locks up, or any of the other 100 things that happen on occasion, I will never need to realign the scope again (this is in a permanent observatory BTW).
Never is a long time.  Even the most substantial concrete piers move.  You will probably end up changing OTA's and collimating from time to time too.  These things affect alignment.  Not loosing orientation information is nice though.  Platesolving can get it back too if things go horribly wrong as can having home switches.


Rockmover
 

Howard, my thought is that every time I plate solved I would automatically just update the absolute encoder offset.  So by "never", I mean I would never have to go out and manually have to look at where the scope is actually pointed.

Even with a 12 bit encoder and say a 12" scope, there would be more than enough resolution to be in the ballpark to plate solve on startup, or on a power failure.

My thinking is you simply mount the encoder and its it doesn't matter what position it is in. Then you just need to store the encoder offset, which would get updated and saved when you plate solve. That offset can get checked and updated as you like.

If power goes out, the mount turns back on and it knows its absolute encoder position. It gets the last offset vale (saved on the PC or wherever), and you are again well within the require resolution to plate solve (and have the exact scope position again).  The absolute encoders would only be used on start up, and not for the exact position, but just for the "approximate" position to plate solve. 

After that, the system would work as it does right now. 


Howard Dutton
 

Pretty close to my thoughts on it.

I'd perhaps lean toward two offsets in the encoder system.  One to set the base encoder angle that's in Config.h only, then another that's stored in NV which is adjustable but only within limited range.  Make it impossible to set too far from true in-case something goes wrong further up the chain.


Howard Dutton
 

Btw thanks for the TeleViz software,  it's handy for debugging/simulation purposes.

I noticed the graphic goes "a bit funny" around the NCP... this is likely due to Topocentric coordinates and refraction.  You could refract the coordinates back to instrument (but it will never be perfect since it depends on temperature/pressure) or use these commands instead, intended for encoder support, it all comes full circle!  They give the instrument angles in degrees.  Dec can be > 90 or < -90 when in the alternate orientation (meridian flip.)  Read that ASCOM write-up on it.  To get these through the ASCOM driver you must use CommandString().  Not standard but a special mode/detection of OnStep could get it done.

// Get formatted axis angles.  RA,Dec.  In degrees.
:GX40#
:GX41#

// Get decimal axis angles.  RA,Dec.  In degrees.
:GX42#
:GX43#


Rockmover
 

No problem and I have wanted to post an updated version of TeleViz as I have a few new additions as well. 

One item I am struggling with however is I wanted to be able to advance the time, eg "fast forward" the mount to the end of the night and see where it would be at when a given image session ends.  I have a huge 65 mm filter wheel, and I am always afraid of it getting to close so it would be nice to quickly visualize the position.  However, this has turn out to be a bit more than the 20 minute job I thought it would be.....

Also, this AP1200 mount, and a SHC got me a bit side tracked on working on my Arduino dome control (main original purpose for TeleViz), but I hope to jump back on it next week.  
 
On a side note I just booted my SCH for the first time tonight. I am still waiting for my middle 5 way button to arrive (seems you can only get this on ebay from china?). I am 3D printing my case now. I have say to say thanks and hats off to everyone who has put in development on that, it seems very impressive and will be a nice perk from using my crappy little G11 hand controller (not that I really even use it that much, but the new displace is very cool).  I am continuously so impressed at the work that has gone into this project!! 

Although I have to admit, the first thing I did once I got it to boot was to find the splash screen data and customize it.  :)  



Howard Dutton
 

There is now preliminary support for the Broadcom AS37-H39B-B, and probably the AS38-H39E-B absolute encoders, in the master branch WiFi Addon.

The AS37 device uses the BiSS-C protocol and a differential interface that can't tie directly into the ESP8266 so I used this to wire it in:
https://easyeda.com/hdutton/diffenc

The WiFi Addon has two new control features for use with absolute encoders:
1. A "Set Zero" button in the web-interface that sets an offset and stores it in NV memory, so on next power up the true angle is restored.
2. A new setting in Config.h to specify the maximum allowed sync angular distance.


Rockmover
 

On Sat, Oct 10, 2020 at 08:35 AM, Howard Dutton wrote:
Broadcom AS37-H39B-B
That's great news Howard.  Where can these be bought at?  Digikey has a 6 month lead time.  At a couple hundred bucks each I am definitely getting them for the AP1200.


Howard Dutton
 

Mouser says they'll have 20 in stock in about 2 weeks.

Digikey has 3 in stock now, same shaft bore as the one provided to me by JTW Astronomy:
https://www.digikey.com/en/products/detail/broadcom-limited/AS37-H39B-B12S/6166410


Rockmover
 

Excellent, this is exciting!

I'll grab two DF13-10S-1.25C cables for the encoder. And then looking at the new board you posted its clear the connections to the encoder side, but then how/where does the other side connect to the MAXPCB?


Howard Dutton
 

On Mon, Oct 12, 2020 at 12:50 PM, Rockmover wrote:
but then how/where does the other side connect to the MAXPCB?
The encoder pins are labeled A and B on the MaxPCB.  A = MA and B = SLO.

MA is the clock which the Addon provides and SLO data from the encoder.


Thomas Westerhoff
 

I am currently considering whether to equip our old Zeiss VIII mount with a good precise absolute encoder. Instead of the graduated scale, I would install the following encoder.

HDmag flex MQR 3000F

This provides depending on encoder type the data in Binary SSC format or in Gray SSC format. If I have understood it correctly, then the Broadcom AS37-H39B-B used here also use the Binary SSC.
As this Broadcom AS37-H39B-B works well on my other mount equiped with OnStep the MQR 3000F should also work. Is that correct?

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


Howard Dutton
 

On Thu, Jan 14, 2021 at 03:05 AM, Thomas Westerhoff wrote:
As this Broadcom AS37-H39B-B works well on my other mount equiped with OnStep the MQR 3000F should also work. Is that correct?
Data format is completely different, no way.


Howard Dutton
 

On Thu, Jan 14, 2021 at 04:14 AM, Howard Dutton wrote:
As this Broadcom AS37-H39B-B works well
That's a nice bit of information to see, wasn't really sure that was the case.


Marco Lorenzi
 

On Thu, Jan 14, 2021 at 03:05 AM, Thomas Westerhoff wrote:
As this Broadcom AS37-H39B-B works well on my other mount equiped with OnStep the MQR 3000F should also work. Is that correct?
Hi Tomas, could you provide some more details and feedbacks on the successful installation on the AS37-H39B-B on your other mount ? I am interested too and I really would like to hear some more of your direct experience :)
Thanks!
Marco