The site won't let me post the ebay link - its too long.
All i did was search on "L6470 Stepper Driver Breakout 3A 8-45V" on the Uk ebay site, and loads of them popped up.
Chinese imports for arrounf £7


Wow, that dSPIN unit is a whole load of features for £8!

Take your point of energised non-moving motors being the issue, I would have assumed that the speeds of side-real tracking would present very similar heating problems - but I defer to your experience :)


answering to a number of points above:
That 0.9 deg motor looks to me be be a good contender.

There's bags of force with that motor, but my mind has now jumped to heating issues. Under normal conditions, the RA motor will constantly be moving (and Alt-z mounts will have both going 100%), and if you run these motors at full wack, then i expect will get very warm fairly quickly. So do you maths and check the torque requirements for your set-up.

Mitigations to this effect:
1. Most decent controller boards (phigets included) do reduce current to c50% the motors when in idle for a period (second or so), but as explained above, this won't help if the motor is on a long imaging run and side-real tracking!
2. You could run the whole system at lower power - BUT NOTE - by "lower power" means managing current limits to these motors (just lowering power supplies voltages won't have the desired effect!), if you need further explanation on this then I'll provide a reference and more details separately.
3. There are motor controllers that have RS232 interfaces that allow the controller to be programmed dynamically, (rather than the DIP switches). Now - I haven't investigated this so you will need to research - but it occurred to me that programming the current limits and micro-stepping values dynamically via software will open up a very useful way of maximising high speed slews on full step, whilst reprogramming to track objects using micro-stepping. By also cleverly adjusting the current limits (high of accelarations and lower power for simple tracking), you will also help reduce the temperatures of these motors.

Final point: don't under estimate the heating effects and hitting a temperature problem. These motors at full power typically consume 12v * 3amp = 36W or more. 1kg of steel warms up at the rate of 500J/C, so every minute at full power will raise the temperature by about 4Degs! (assuming no heating losses to air). Motors typically have an operating limit of around 80Degs before contact between internal parts might begin (the stator teeth start to rub and begin to make iron filings!), and bearing grease starts to leave by the nearest exit! - well ok, i'm being a little dramatic, but take heed, it will be an issue to manager you power settings on (not so) long imaging runs.


Wbirk: Yep, agree with all you comments. I rather hoped that using standard raspian/python i might avoid loosing steps by monitoring stepper drive pulses with a input interrupt routine which was connected to the drive pulse pin and i assumed the OS would schedule efficiently. It did work ok to a point, but i was surprised at how low my max slew worked out to be!

I amrelatively new to python, (and indeed a very rusty old coder), so managing Cores is a bit beyond me at the moment - Im at the stage of knowing what i don't know!


Happy to help constructively.

I've already ordered mine! Paid by paypal late afternoon today, and the delivery is 9am tomorrow! WOW, beats Amazon prime!
I'll be giving it a work out with: Canon D7, ATIK filter wheel, ZWO AIS 1600MM Cool, Celestron CGE mount, & CPC800 both nextstar.

Love the mobile app - look forward to using it.


WBIRK: i have used many Rpis variants, my comments were intended as general remarks.
I have used Zeros, and found that (being only 1 core) they get quickly overloaded if multi-tasking, so a dedicated machine is really needed for realtime tasks (obvious really -LOL).
Rpis-B are fine, as too are 3's although they do have limits that can all be reached. Pushing the 3 to its limits, and found that with routines written in python and not complied are quite slow - especially using any computations inside the code loop.
Running 128 microsteps and ruining max slews was an issue if I was also tracking the stepper counts within the software. The fastest method/approach was to use the PWM output from a pi (with the frequency set from python) to drive the step input on the motor driver, and then read the PWM signal as an input on an interrupt basis, and count the pulses with an interrupt routine. This gave the best performance (and could get very high motor speeds), but i found that the interrupt routine often dropped pulses and therefore count accuracy suffered.

I haven't yet attempted complied C code,but I am guessing that the limits would not pose problems, as the its a lot faster at execution. I also never exploited the use of CORES in python, which I might expect would help to dedicate tasks to processors. I' also new to python, and very rusty with C, so its all been a re-learning curve for me!


Back lash is typically proportional the quality and number of the physical gears use in the gear train, so avoid adding in gears that you might be able to avoid; so spend more on a increased number of teeth on your worm gear wheel, and avoid using the planetary gear on the motor that drives the worm screw.
Design stuff: My celestron scope has spring tensioners that force the gears to one side of the gear groove, and with a well balanced (slightly biased in one direction) helps enormously with the backlash. Also note that software is usually used to correct of the backlash; normally scopes include a routine at the end of a GOTO command that runs the motors in a consistent direction, thus ensuring (no matter which way the gear slewed to the target), then will end up with a +ve RA & DEC direction, which applies force on a consistent side of the gear grove. This all helps for GE mounts - but standard non-GE mounts - then backlash corrections are more problematic due to tracking DEC/RA forcign the use of both sides of the gear grooves.



This is a great idea. I'm the target market for this device - short on time and a little challenged on coding!
I've reviewed your FAQ, but still have a few questions you might like to consider and add into the list.

1. Support: what is the approach used to update these packages - is there built in version updater package, or a simple script someone can follow, there are many updates to these systems I would not want to mis-out on.
2. I am in the process of designing my own devices, ( Flip/flap, weather, focuser, etc), it is not clear to me how one might attach these devices to this setup? Can i assume that if a device (and device) meets INDI drivers standards, then they will be plug and play?
3. I've loads of raspberry Pi's and power supplies for my local plugs! Would you sell the SD card with preloaded software?


Lynxsky: I like the equipment in the link, and would love a setup like that. Further thoughts for your consideration.

If space/portability isn't an issue, i would tend to go with the bigger motor; not only does it take away the 'will/it won't it worry, but if you can wear the increase costs of power supplies etc, then the motors are better driven well within their working envelope, than on the ragged edges and run the risk of a missed step.
Also, further to a point made earlier in the thread, these motors will get warm if in use at full power to periods of time. An over sized motor would allow you to run them at lower power, but it still has a greater thermal mass to help reduce the effect of any temperature issues.

I would tend to stay-off motor gearing if possible, since using them will increase the backlash of the system. Motors direct onto the worm drives are probably best.

Also, although the majority of stepper motors are 1.8degs step, that are others. On ebay you can source 0.9degs for similar prices. This will double your resolution without degrading backlash.

Final thoughts on motor drivers: Using micro stepping will improve your resolution, but it is associated with a few issues:
1. The stepper motors are designed to step forward one complete step (say 1.8 degs). Using microstepping progressively energises the coils in graduated sequence to 'fight one another' to hold the angle of movement between the designed steps that motor has. As soon as you de-energise the motor, the motor will snap back to a 1.8deg integral angle.
2. you loose torque using micro stepping - so re-enforces the case for over-sizing.
3. Obvious really, but gives a much smoother angular rotation with less stepper vibrations, which (unless using a geared system) might be material issue in the system you design.
4. Higher the micro-steps means your microprocessor needs to work harder. I played around with Raspberry Pi systems, with driver code written in Python (being interpreted) will struggle to operate high slewing rates - i've tried 128 microsteps, and rotational limits were imposed by software (900MHz processors!). Ardinuo systems (8MHz) quite evidently would struggle. So: use multi-core-RPi-3 (not Zeros) and consider compiling your code!


I'll add my tuppence worth:

Assuming standard bi-polar motors: NEMA stepper motors have two important descriptions you will need to review for your application. 1. The physical size of the mounting face (NEMA 8, 11,17,23,34) all refer to the dimension of the front face. 2. The Force/current rating, which will in part determine the number of coil stacks used in the windings and so defines the height of the motor. (lower the impedance, higher the force, higher current requirement, more windings = bigger motor). Most of the standard motors are designed to 1.8 deg full step, but driven by a micro-stepping unit you can improve the resolution further.

I have chosen NEMA-8 for a focuser, with 0.14Nm - which is tiny, and is perfect for the job, but well over powered/engineered. A stepper motor from a CD player would have just about been enough.

I would expect that NEMA 17 would be a bit on the large size for your application, but you might need a higher force depending on your mount loads you are planning.

My 3d printer uses NEMA 17, but others work well on NEMA11.

I'm running NEMA 23, 4Nm for a CNC machine, it has over 300kg of force on the spindle to drive the axes.

You might also consider motors with build in position decoders - they do exist - but a bit pricey, and interfacing them to a raspberry pi might prove interesting. This would be the approach I would investigate if I were considering this project.

One final point. I would strongly recommend using a proper stepper motor micro-controller units which is able to drive higher voltages (recommend using 24v will do - all motors will tolerate this). These controllers avoid burning the steppers out by regulating the current flow allowed into the motor, and so get far more force/power for the motor size. These controllers also lower the power consumption with idling, which keeps them cool.