Topics

Would this BOM work?


Henk Aling
 
Edited

I want to build a simple OnStep controller for my Losmandy G11S.  I looked at the "solderless breadboard" OnStep prototype, and some similar looking OnStep controllers on Cloudy Nights: https://www.cloudynights.com/topic/594453-onstep-on-a-cg-11/ .  Based on that I came up with this bill of materials:

Would this work?  The assumptions that I am not quite sure about are:

  • The TMC2130 can run on 12 V and can power my 10 V steppers.
  • The 1.8 degree steppers are OK for my G11S (360 teeth).
  • I will use the 12 to 5 V regulator to get the 5V power for the Arduino.
  • I do not need a surge protector for the TMC2130 (if I do, how?)

Thanks in advance for looking!


Khalid Baheyeldin
 

If your goal is not to solder stuff, then this is the wrong approach.
The Teensy Arduino Shield comes unsoldered and you have to put it together, which requires soldering.

If you still want less soldering, then look at the R32 + CNC V3 shields.

If you accept that you will solder, then order a Teensy 3.2 kit or STM32 Blue Pill kit from George Cushing.

Regarding the motors, everyone uses 400 step motors (0.9 degree), not the ones you listed. specially for the G11 direct coupling.


Henk Aling
 

Thanks Khalid

The soldering looks doable.  I will order a soldering station.

I will consider moving to 400 step motors but let me try the 200 first since I have them, from my current ill-fated kit.  I read that the TMC2130 is very good at micro stepping so who knows, it may work.  I can always upgrade the motors later on.

One thing I forgot that I am uncertain about is the need for an RTC.  I suspect that EKOS initializes the OnStep controller with the proper time and location.  I don't know if that is based on an RTC but the Teensy 4.0 has one so I will go with that.

I looked at the STM32 but like the simplicity of the Cloudy Night designs (which are similar to the OnStep "solderless breadboard design").  For instance, I (think I) don't need BlueTooth, ST4, WiFi, extra USB UART, buzzer, RTC, fuse (hopefully) - just trying to keep everything minimal.  EKOS will support some of this.  I am comfortable with Arduinos so the Teensy appeals to me.  Let me try it and see where it ends.


Howard Dutton
 

On Fri, Aug 14, 2020 at 09:48 PM, Henk Aling wrote:
One thing I forgot that I am uncertain about is the need for an RTC.  I suspect that EKOS initializes the OnStep controller with the proper time and location.  I don't know if that is based on an RTC but the Teensy 4.0 has one so I will go with that.
OnStep doesn't need an RTC.


Khalid Baheyeldin
 

On Sat, Aug 15, 2020 at 12:48 AM, Henk Aling wrote:
I suspect that EKOS initializes the OnStep controller with the proper time and location. 
Yes. Ekos has an option to set the location and time every time INDI connects to OnStep.
So an RTC is not needed, provided the Ekos is the only client for OnStep.

I looked at the STM32 but like the simplicity of the Cloudy Night designs (which are similar to the OnStep "solderless breadboard design").  For instance, I (think I) don't need BlueTooth, ST4, WiFi, extra USB UART, buzzer, RTC, fuse (hopefully) - just trying to keep everything minimal.  EKOS will support some of this.  I am comfortable with Arduinos so the Teensy appeals to me.  Let me try it and see where it ends.
Note that the CloudyNights thread you linked to is quite old, and OnStep has moved rapidly beyond what is there.
What you plan to do should work, but order the MiniPCB kit, the CNC V3, rather than the Arduino Shield approach.
That way you get a more modern board that will have longevity and is used by more people on this mailing list, rather than being stuck with an ancient design that has very few users.


Henk Aling
 

That makes a lot of sense Khalid, I will go with the Wemos R32 / CNC V3 combo / A4988 drivers.  It should save me some soldering and offers more features. 

I will keep the other components nevertheless, I may have other use for them.

Thanks for your advice.


George Cushing
 

First 10V is too high a voltage for you motors. If these were from your "failed kit" it may be one problem with it.

These are selling for $10 on AliExpress and maybe available from the U.S. 



Take a look at MiniPCB2 Assembly

The MiniPCB is a proven product, easy and quick to assemble and has a minimum of parts. The Kit is $45 plus shipping ($5 in the U.S.). I'll assemble and test it for $30. The Teensy has a built in RTC, just add the crystal and coin battery. The Wemos R32 / CNC V3 is experimental. Search messages on it, it is not straight forward.

I have just started with the Wemos R32 / CNC V3 to see what it is about, but I see it's going to takes some study get it to do anything. For that I'm finishing a MaxESP3.

George


Henk Aling
 

Hi George,

Thanks for your generous offer, who knows I may take you up on that!  But let me face doom first and try to put the Wemos32/CNCv3 kit together.  Yesterday a new implementation arrived in te showcase, no problems were mentioned.  I have indeed noticed many not so successful Wemos messages that I can learn from.  Let's see.

I have had mixed success with my current kit but I am partly to blame for that.  The G11S, EQMod, Ekos and the kit are all fairly new to me. 

For starters, let me embarrass myself by admitting that I failed at something as simple as balancing the mount.  I used to balance DEC in the home position by rotating the OTA in a horizontal position to check the balance (I am at 34 degrees latitude).  As it turns out, the G11S has way too much friction to make that a reliable method.  After noticing asymmetric stuttering behavior when running the motors, I changed my method to first rotating the counterweight bar to horizontal position then put the OTA in horizontal position - it is much more sensitive that way due to reduced friction.  Just doing that made a world of difference.  Even for my little 14 lbs. Mak-Newt.  I had no idea that the goto kit with my G11S could struggle that much with a bit of imbalance.

Secondly, the G11S crown wheel has different friction in different positions.  I am not saying it has bumps because I can't tell that for sure but I suspect it does - just not perfectly round, which Scott told me is possible.  That forces me to leave some play when tightening the clutches.  The amount of play is indeed temperature dependent, as I experienced myself and as was pointed out to me by other Losmandy users.  My worms are not the spring loaded ones so getting the right tightness is not easy - I now use shims and leave enough play to not get in trouble.  Which is disappointing because I was hoping for a solid mount where everything is nice and tight with no problems.  Think again!  From messages on the Losmandy user board I see that many users struggle with the same problem and the consensus is to indeed to leave some play.

The combination of a slight imbalance and play in both axes can wreak havoc on goto behavior.  It provides crazy resonances that stop the motion dead in its tracks, the mount turns into a coffee grinder and the steppers lose almost all steps.  Fixing the balance greatly reduced the problems (duh) so last night everything actually went smooth.  However the system is way more sensitive to this than I like.  I see that OnStep gradually increases the motor speed and gradually slows down.  That should make for much better behavior because it takes it through various potential resonances instead of staying at one that happens to be bad.  My current kit just provides a single (adjustable) speed.  Sometimes it is a coffee grinder at 800 but smooth at 600.  Running both motors at once is a resonance hazard.

Last night though after a successful initial alignment, during the Ekos autoguiding calibration my goto kit started beeping at unexpected moments, indicating a reset.  This is rather painful because I have to re-sync on a target, etcetera.  I thought it was a fluke the first time it happened but it kept repeating itself.  I ended up packing it up with no results, as usual.  The only explanation I can think of is that the goto kit got overheated.  Last night and the time before that was during the heat wave, maybe the night time temperature was biased on the high side.  Should I take the cover off for ventilation and try again?  I could also try to run the motors at less power, which my goto kit lets me do through a GUI.  I believe I run at 100% but the default is 70%, which probably generates less heat.  It's not encouraging me to continue on this route.

Another problem I ran into is that both with Ekos (on the Pi) and EQMOD (on the laptop) the home position of the mount ends up somewhere West at or below the horizon, instead of at the NCP.  I tried various settings but have not been successful.  To start up I therefore use the Telrad to manually move the mount to Deneb, disconnect the motors then goto Deneb.  I have not discovered the setting that causes this start position.  I played around with the park position but have not been able to get it right.  There were a few times when it started at the NCP so possibly it's something that I did.  But resetting whatever I could reset does not seem to have any effect.  Meanwhile I learned that I can simply sync on Deneb without disconnecting the motors and doing a goto, which greatly reduces the pain.

Another confusing element is that I declared my goto kit as an EQMod mount in Ekos.  The confusion is about the model.  Ekos now has its own model besides plate solving, while EQMod has one, too.  It was not clear to me which one works as I use the virtual Ekos keypad, or use the right-click EQMod->Sync/goto in KStars.  Meanwhile I found that Ekos has a setting that you can use to determine this.  But it's just another bit of confusion.  When I joined OnStep I erratically thought that the Ekos model was doing my alignment so I took the approach to get something very basic and leverage Ekos as much as possible, also for the client GUI. 

I now know that EQMod was doing the alignment with my configuration, and I am not too crazy about that.  This is because EQMOD is rather primitive in that regard.  It either triangulates the sky and picks the fitting triangle for the target, or, when the target is outside any triangle, it picks the nearest neighbor - which is rather prone to extrapolation errors.  It still works OK if you have an alignment star near the target but one should not have to.  Also, a single star leaves ambiguity due to cone error if there is one.  Looking at the OnStep alignment code I see a much better implementation accounting for all standard things but also cone error and even mount flexibility.

Altogether major bonus points for OnStep, at least in theory for now.  First I looked at InStein to order a ready made kit, which looked fine, but did not like the idea of a closed source solution (not sure if it was), I want something where I am in full control of firmware updates, etcetera.  That made me decide to build my own OnStep.  Looking at the various implementations I got the impression that the solutions were strongly inspired by the 3D printing and CNC world, so why not go with that and accept that solutions change over time.  Meanwhile Khalid swayed my mind and I decided on Wemos32/CNCv3.  The custom OnStep PCBs like the BluePill looked OK but somewhat dated and with a large BOM of cheap parts that made me feel less comfortable than with a Teensy based solution.  Also because some parts may no longer be available.  Going with something more current seemed better.  I could be wrong of course.

I'm still working with my current goto kit, its behavior improves as I am learning all this.  It has WiFi, ST4, a hand controller, not bad but altogether this learning experience feels like an unusual punishment.  So I am looking forward to having my OnStep kit.


You mentioned,

       First 10V is too high a voltage for you motors.

Why is that?  The link that I provided says 10V.

The OnStep parts will start arriving next week.  If I can't get it running (which I doubt, maybe with some help from this board) I may take you up on your offer so, thanks again!


Khalid Baheyeldin
 

On Mon, Aug 17, 2020 at 12:30 PM, Henk Aling wrote:
I have indeed noticed many not so successful Wemos messages that I can learn from. 
Don't confuse the WeMos D1 Mini with the WeMos ESP32 W32.
The former is used as a WiFi connector for any OnStep board. Recent message are about that functionality, and only some users see problems. For the vast majority of other users, it just works.
The latter is an OnStep controller itself, and that is what Rafael and others used as a controller.


Khalid Baheyeldin
 

On Mon, Aug 17, 2020 at 12:30 PM, Henk Aling wrote:

You mentioned,

       First 10V is too high a voltage for you motors.

Why is that?  The link that I provided says 10V.
The general rule for OnStep motors (or other similar applications like CNC, ...etc.) is to use low voltage
high current motors.

These are the two popular motors that people use.

https://www.omc-stepperonline.com/nema-17-stepper-motor/nema-17-bipolar-0-9deg-36ncm-51oz-in-0-9a-5-4v-42x42x40mm-4-wires.html?

https://www.omc-stepperonline.com/nema-17-stepper-motor/Dual-Shaft-Nema-17-Bipolar-09deg-44Ncm-6248ozin-168A-28V-42x42x48mm-4-Wires.html?

Note their voltage ...


Henk Aling
 


Khalid Baheyeldin
 

That is the correct one.

My mistake: I wrote W32. It should be R32.

Others who actually use it will correct me if I am wrong.


Howard Dutton
 
Edited

On Mon, Aug 17, 2020 at 09:30 AM, Henk Aling wrote:
For starters, let me embarrass myself by admitting that I failed at something as simple as balancing the mount.  I used to balance DEC in the home position by rotating the OTA in a horizontal position to check the balance (I am at 34 degrees latitude).  As it turns out, the G11S has way too much friction to make that a reliable method.  After noticing asymmetric stuttering behavior when running the motors, I changed my method to first rotating the counterweight bar to horizontal position then put the OTA in horizontal position - it is much more sensitive that way due to reduced friction.  Just doing that made a world of difference.  Even for my little 14 lbs. Mak-Newt.  I had no idea that the goto kit with my G11S could struggle that much with a bit of imbalance.
Friction on both axes of my G11 is rather low.  Have to really watch it when releasing the clutches in-fact.

Secondly, the G11S crown wheel has different friction in different positions.  I am not saying it has bumps because I can't tell that for sure but I suspect it does - just not perfectly round, which Scott told me is possible.  That forces me to leave some play when tightening the clutches.  The amount of play is indeed temperature dependent, as I experienced myself and as was pointed out to me by other Losmandy users.  My worms are not the spring loaded ones so getting the right tightness is not easy - I now use shims and leave enough play to not get in trouble.  Which is disappointing because I was hoping for a solid mount where everything is nice and tight with no problems.  Think again!  From messages on the Losmandy user board I see that many users struggle with the same problem and the consensus is to indeed to leave some play.
No doubt each is slightly different.

The combination of a slight imbalance and play in both axes can wreak havoc on goto behavior.  It provides crazy resonances that stop the motion dead in its tracks, the mount turns into a coffee grinder and the steppers lose almost all steps.  Fixing the balance greatly reduced the problems (duh) so last night everything actually went smooth.  However the system is way more sensitive to this than I like.  I see that OnStep gradually increases the motor speed and gradually slows down.  That should make for much better behavior because it takes it through various potential resonances instead of staying at one that happens to be bad.  My current kit just provides a single (adjustable) speed.  Sometimes it is a coffee grinder at 800 but smooth at 600.  Running both motors at once is a resonance hazard.
Stepper motor/drive design plays a big role in taming resonances.  I'd use the higher current (1.5 or 1.7A rated) 400 step NEMA17 motors and TMC2130, TMC5160, or LV8729 drivers.

Running these motors at 24VDC is best but 12V is usually ok.  I've never had any trouble such as you describe but then as George said 10V rated? motors are seriously not what one wants for this especially running them at 12V.

[I should note too that balance has been practically irrelevant to the drives and I've accidentally run it when severely out of balance and only found out when I released the clutches (to the point of near personal injury)]

Last night though after a successful initial alignment, during the Ekos autoguiding calibration my goto kit started beeping at unexpected moments, indicating a reset.  This is rather painful because I have to re-sync on a target, etcetera.  I thought it was a fluke the first time it happened but it kept repeating itself.  I ended up packing it up with no results, as usual.  The only explanation I can think of is that the goto kit got overheated.  Last night and the time before that was during the heat wave, maybe the night time temperature was biased on the high side.  Should I take the cover off for ventilation and try again?  I could also try to run the motors at less power, which my goto kit lets me do through a GUI.  I believe I run at 100% but the default is 70%, which probably generates less heat.  It's not encouraging me to continue on this route.
I actually recommend about 40% power as a starting point.  Usually drives tend to work better around there.

Altogether major bonus points for OnStep, at least in theory for now.  First I looked at InStein to order a ready made kit, which looked fine, but did not like the idea of a closed source solution (not sure if it was), I want something where I am in full control of firmware updates, etcetera.  That made me decide to build my own OnStep.  Looking at the various implementations I got the impression that the solutions were strongly inspired by the 3D printing and CNC world, so why not go with that and accept that solutions change over time.  Meanwhile Khalid swayed my mind and I decided on Wemos32/CNCv3.  The custom OnStep PCBs like the BluePill looked OK but somewhat dated and with a large BOM of cheap parts that made me feel less comfortable than with a Teensy based solution.  Also because some parts may no longer be available.  Going with something more current seemed better.  I could be wrong of course.
Bluepill has 128KB of flash and that is a real limitation.  Also it's a hassle to flash firmware into it relative to pretty much anything else.

Teensy's are very easy to flash.  The MiniPCB2 kit Is a basic controller but refined and capable.

The S6 is great if willing to work through its quirks.  A little expensive, a bit of a hassle to flash.

The ESP32/CNC3 is not that big of a deal to get working.  In the end it's just another ESP32 OnStep.  One resistor to cut off on the CNC3 (probably wouldn't matter even if you didn't.)  Easy to flash.  Skip WiFi entirely if you like (built-in Bluetooth.)  Probably run everything from 12VDC (ESP32 and CNCV3/stepper drivers.)  Don't bother with TMC2130 drivers (too much hassle) use LV8729's... the Wiki for it covers all of this.

I'm still working with my current goto kit, its behavior improves as I am learning all this.  It has WiFi, ST4, a hand controller, not bad but altogether this learning experience feels like an unusual punishment.  So I am looking forward to having my OnStep kit.
In the end you are still designing and implementing a goto controller / drive system.  There is a learning curve. :)


Howard Dutton
 

On Mon, Aug 17, 2020 at 10:20 AM, Henk Aling wrote:
Hi Khalid,  this is the one I ordered:

https://www.ebay.com/i/164261011498?_trksid=p11401.c100711.m5036&_trkparms=aid%3D111001%26algo%3DREC.SEED%26ao%3D1%26asc%3D20170110121435%26meid%3D05cb911e48794deb915e2c6c1bbe3a63%26pid%3D100711%26rk%3D3%26rkt%3D4%26mehot%3Dnone%26b%3D1%26sd%3D280920603565%26itm%3D164261011498%26pmt%3D0%26noa%3D1%26pg%3D11401%26brand%3DUnbranded&ul_noapp=true
It is labeled ESP32 WiFi+Bluetooth+UNO WeMos D1 R32, not Mini not W32 but R32 and ESP32 so now I'm not sure anymore.  Should I order a different part?
Looks good.

For the CNCV3 shield some early adopters noted that all are not created equal... the one linked to in the Wiki seems to be of higher quality which is a good thing:

https://www.aliexpress.com/item/2044795124.html?spm=a2g0o.productlist.0.0.7b594faanPTfJh&algo_pvid=70f7f5d9-3da7-47c8-b1fc-4f8e69eed43b&algo_expid=70f7f5d9-3da7-47c8-b1fc-4f8e69eed43b-21&btsid=0ab6f81e15911856988297550e66a5&ws_ab_test=searchweb0_0,searchweb201602_,searchweb201603_

I'd buy that or something that looks like it.


Khalid Baheyeldin
 

On Mon, Aug 17, 2020 at 12:30 PM, Henk Aling wrote:
Another confusing element is that I declared my goto kit as an EQMod mount in Ekos.  The confusion is about the model.  Ekos now has its own model besides plate solving, while EQMod has one, too.  It was not clear to me which one works as I use the virtual Ekos keypad, or use the right-click EQMod->Sync/goto in KStars.  Meanwhile I found that Ekos has a setting that you can use to determine this.  But it's just another bit of confusion.  When I joined OnStep I erratically thought that the Ekos model was doing my alignment so I took the approach to get something very basic and leverage Ekos as much as possible, also for the client GUI. 
Ekos does not create, nor keep, its own alignment model.
It will help your mount create a model, using the Mount Model tool, but it does not internally keep a model.


Henk Aling
 

Ekos does not create, nor keep, its own alignment model.It will help your mount create a model, using the Mount Model tool, but it does not internally keep a model.
I think you are right, my mistake.  IIRC I saw a check box to choose between Ekos and EQMOD enabled in one the EQMOD driver tabs.  I had no camera hooked up so it would not be able to plate solve, and mis-interpreted their statements about N-point solutions (which apparently referred to calling plate solving N times).  I jumped at the wrong conclusion. 


Khalid Baheyeldin
 

On Mon, Aug 17, 2020 at 03:14 PM, Henk Aling wrote:
  I jumped at the wrong conclusion. 
That is fine.
Things are already very complicated, with many parts making up the optical and mechanical trains.
And to make things worse, the software stacks have all sorts of options and settings.
So confusion is not unusual. The lack of it is ...


Henk Aling
 

On Mon, Aug 17, 2020 at 01:28 PM, Howard Dutton wrote:
For the CNCV3 shield some early adopters noted that all are not created equal... the one linked to in the Wiki seems to be of higher quality which is a good thing:

https://www.aliexpress.com/item/2044795124.html?spm=a2g0o.productlist.0.0.7b594faanPTfJh&algo_pvid=70f7f5d9-3da7-47c8-b1fc-4f8e69eed43b&algo_expid=70f7f5d9-3da7-47c8-b1fc-4f8e69eed43b-21&btsid=0ab6f81e15911856988297550e66a5&ws_ab_test=searchweb0_0,searchweb201602_,searchweb201603_

I'd buy that or something that looks like it.
Howard you were right as usual.  I was just browsing through my old messages to find out what stepper motors were recommended when I noticed this post by you.  Indeed, I got two cheap CNCv3 boards and was unable to get SPI working with one while it worked with the other.  The connectors were soldered at angles and I had to bend them straight.  If I buy more CNCv3 shields I will go with the link you provided.


Howard Dutton
 

On Fri, Sep 11, 2020 at 09:10 AM, Henk Aling wrote:
Howard you were right as usual
Just echoing the experiences of others.


George Cushing
 

Keyestudio are the folks who designed the CVC V3 and shared it under the Arduino philosophy. So of course the design was cloned to death. Seems fair to support them.