As I have advised a few before. I would not start throwing 100µF capacitors around in a random fashion. There is usually all the required input and output C built in to any equipment. “Normal” electrolytic usually have more quite a bit of inductance which will do nothing in the way of bypassing higher frequency noise. Better with 0.1µF or 0.01µF. Electrolytics are generally used to supply current in between rectification pulses or smooth out ripple up to about 100Hz.
Capacitors should NEVER be put on BOTH ends of a length of wire. This introduces a tuned circuit which can have disastrous results. In general it is good practise to only have any sort of filter ON ONE END ONLY of any wire length.
Cheers Bob
Probably nothing will happen. This is a good example where an oscilloscope in invaluable. Putting caps around to get rid of so called “noise” that you haven’t got in the first place will do nothing.
But like I said above DON’T put a cap on BOTH ends of any wire. You just might introduce trouble. ONE end only.
Cheers Bob
OK what happens if you power the Nano via a USB cable wired into the buck converter. does that cause the same issue?
If so, then what happens if you power the Nano by a USB brick like a phone charger?
I dont think that your issues have anything to do with the stepper motor, it looks like the Nano is somehow getting messed up by the buck converter power.
Havet tried a usb wired into a buck converter, would that involve cutting a usb cable and finding the 5v positive and negative and wiring it into teh buck converter?
When disconnecting the buck converter and powering by a usb power block like an iphone charger or a portable speaker charger im still having the same issue.
obviously i havent followed a scientific method but initial tests suggest powering via usb with correct timing didnt seem to fix the issue.
Fair enough.
I’m unclear how the thinking is being measured.
Gregory - what more can you tell us about the glitches ?
Can you estimate when they happened ?
Are they roughly evenly spaced, or random ?
Can you estimate the magnitude of the error ?
Add far as I can tell from your description, the overall average speed is correct - is this true, or do the errors accumulate?
I’m wondering if there is a mechanical component, like a loose fitting key on a shaft, or an elastic element that loads up and then springs back into place, like a cracked tooth on a gear.
Yes. Hack a USB cable in half, strip the outer wires, and there will be a Black and a Red and a White and a something else. Use the Black as -VE and Red as +VE.
But powering from your computer via USB works?
Just to round out the completeness of information in case I missed it, the timing that you are measuring that is not consistent, that is you logging the time BETWEEN steps in the loop on the Arduino, right?
Have you tried to break it back to first principals, ie remove everything from the circuit, everything, and run the Nano with NOTHING else connected other than it’s power and see if the timing is still out?
Oh last idea that I dont think I read anywhere, are you logging the timings to memory or looking via terminal?
This might help to isolate the problem: double the time for each timer tick, and move the motor two steps per tick. Or quadruple the time per timer tick and move four steps per tick. You have indicated that you have previously tried 1/8 and 1/4 microstepping, but found the vibration excessive. Two or four steps per tick at 1/16 microstepping might mask any speed fluctuations due to missed steps, while still giving you the smoothness of 1/16 microstepping.
Yes, i have taken the Arduino micro and placed in on a bread board and simply checking the step pin. an Arduino uno checks the steps and logs it on the computer. Further testing today found some interesting results.
A third power supply seems to not have the issue. 12v 2 amps timing looking normal which is interesting.
plug it all back up to the platform and timing was still good with this new power source.
Here is the interesting part, watching the log live I can see timing is fine, as soon as I touch the stepper motor (lay a finger on it) the counting issues appears immediately and when i let go it returns back to normal.
Thanks Jeff, code has been written and hoping for some gaps between clouds tonight to test!
I would be tying the GND from 12v supply to GND on Nano.
I’m also not exactly clear on what the wiring looked like for the test that worked, when not touching the stepper.
Was it the same as above?
If so, was it just the 12v supply that was different?
Hi Gregory
Switching frequency interfering with your stepper frequency maybe. Would be interesting to try it with an analog supply or even a 12V battery.
Cheers Bob
I was going to suggest a 12v battery too, seeing as surely that will be the end goal for astro photography anyway and you can be sure that the power is ‘clean’.
That makes no sense. I can imagine a faulty connection somewhere, particularly in the ground connection, causing the driver to miss the step pulse, but I cannot see how it could affect the Arduino providing that pulse on time. The only thing I can think of that could affect the timing would be something causing additional code to execute and delaying the checking of the timer tick. I believe you have already checked that the switch cannot be a problem, and your code does not have any interrupts enabled that could unexpectedly fire. The Arduino timer does have fairly ordinary long-term accuracy, but short-term stability is good, and it is certainly not affected by power supply issues that don’t also reset the processor.
Have you tried setting the logging console output to graphic mode - that will make it much easier to see if there is a pattern.
Interesting that the “delayed” pulses are about twice the period of the “regular” ones, it points to an occasional missed pulse, but your code is still keeping time.
With that relatively small time between steps, you could definitely use Timer 1 to generate your pulses directly as (veeery slow) PWM.
Take a look at this guide and let us know if you’d be up to it:
If your pulse counter still reports errors after this, then you can rule out code, and start looking harder at the electrical bugs we’ve been chasing so far, or your pulse counter as the error.
-James
