My cheap treadmill has very inaccurate speed control - it slows down significantly under load (30-40% off target speed). Unlike expensive treadmills that use closed-loop feedback to maintain precise speed regardless of load, mine just applies a fixed voltage and hopes for the best.
Does this approach make sense for closed-loop treadmill speed control?
Any concerns with the digital potentiometer interfacing to the Keya controller?
Hall sensor placement - any EMI considerations being ~6 inches from the 180V DC motor?
Remote control suggestions for setting target speed, on/off, other buttons?
Any obvious wiring mistakes or safety issues I should address?
This is my first Arduino motor control project, so I'd greatly appreciate any feedback or suggestions for improvement. Thanks in advance for taking the time to review!
Components: Arduino Uno, MCP4151 digital pot, A3144 hall sensor, Mean Well IRM-05-5 isolated PSU, Keya 115/230DR10AL-02 motor controller, fuses
I can't give you any guidance with this project because I haven't done anything like this. I would just recommend that you consider whether it wouldn't be better to remove the potentiometer and control the speed using PWM and a suitable RC group to get an analog voltage from 0 to 5 volts.
Ah yes, I was wondering about that. Much simpler route for sure. As long as that direct interface will not hurt the Arduino, but the other is also a direct interface so... It will probably be fine
Is the motor a common motor found in the expensive treadmills? Is it strong enough to keep up with the load? By load do you mean speed, weight of the person on it, or all of the above? I imagine heavier folks would put more friction on the walking/running belt, thus needing more power at the motor to maintain speed.
Years ago, I did disassemble a cheap one that had a hand crank to change the speed. The motor was a single speed motor and the crank was connected to something like a CVT. It was basically a pulley that could separate each half narrower or closer, changing where the drive belt rides in the drive pulley.
But like I said, I don't know about treadmills. I am just asking.
Yes, all of the above! I have multiple treadmills, and the most expensive one (and all or most of the expensive ones) have a reed or hall sensor to adjust the speed just like I am proposing here. But with their own boards and logic of course.
The reason I know it is off is because I have filmed it and estimated the speed of the belt by using frame rate and travel distance of a marker. The expensive treadmill is dead on. One of our newer cheap ones is s bit off, but the one I am using as a "daily walker" so to speak is off by much more.
Granted, the main reason for it being off by so much has to be that it has overheated a few times and the motor magnets are probably not what they once were. I might change the motor some day too. I've already started to modify this treadmill with cooling and everything, so I just thought this would be a cool project.
I walk while I work on the computer, and I have made a tracking web app too. Just to track my sessions and send them to Garmin. But with an Arduino in place I could even control the treadmill directly from my web app.
None of this is really needed just to be active while working, but it's a really fun challenge and I want to see if I can make it happen!
Yes, it definitively goes faster. It's just that these boards are calibrated once for what voltage gives what belt speed with the motor during that production cycle at the factory. I would not be surprised if they do it with the belt unloaded and only for one of the motors in the entire cycle (since they use the same motor type for all of them).
But it’s not far fetched to think that motors vary and that they should either calibrate each treadmill separately under an average load, or have this type of sensor to adjust the speed constantly like the more expensive ones.
Added Safety Relay Circuit - I've added an optoisolated safety relay that cuts motor power if the Arduino fails in any way (crash, hang, power loss). The relay is normally-closed on the motor controller's inhibit input, so any Arduino failure immediately stops the motor. Safety independent of software.
Confirmed Controller Isolation - Supplier confirmed the Keya 115/230DR10AL-02 has proper galvanic isolation between control (S1/S2/S3) and motor power circuits. Control ground (S1) is isolated from motor negative. They also said direct PWM is not suitable for the pure positive/negative input control, and it must be an analog voltage.
I chose a digital pot over PWM - While both approaches would work electrically, I went with the MCP4151 digital pot for several reasons.
I was uncertain about PWM:
EMI concerns in a 180V brushed motor environment - PWM lines can pick up or radiate noise, though my lines will be pretty short.
Arduino's default 490Hz PWM is quite low, requiring heavy filtering to get clean analog (or at least that is my understanding, i might be wrong?)
Even at 31kHz, getting proper ripple attenuation needs multi-stage filtering or op-amp buffering (or does it, not quite clear to me but adds complexity)
Digital pot advantages:
Clean, stable analog output (no PWM ripple to filter out)
Simpler filtering requirements - no need for multi-stage RC networks or op-amp buffers
Behaves exactly like the original potentiometer (resistive divider characteristics)
Less analog design complexity compared to getting PWM filtering right
Digital pot trade-offs:
SPI wiring needs care in high-EMI environment (short runs, twisted pair)
Slightly more complex code (SPI communication vs. simple analogWrite)
But I thought that rather than trying to design proper PWM filtering for a 180V motor environment, the digital pot gives me a known-good analog signal that matches the original potentiometer behavior. Perhaps the simpler analog output is worth the slightly more complex digital control.
The extra complexity of SPI vs PWM seemed worth it for the cleaner signal and better noise immunity. Plus having hardware safety gives me much more confidence in the whole system.
Still working on component sourcing, but the design feels much more robust now.
Let me know if I've missed anything or gotten something wrong!
