to7motor@SZ
🔋 Established
Over the last couple of years, we’ve spent a lot of time following the DM motor threads across forums and community groups. Beyond the positive feedback, we’ve paid close attention to the troubleshooting threads, firmware questions, installation challenges, and long-term reliability concerns.
Instead of publishing another static spec sheet, we want to give the users an honest look at how the DM platform has evolved. Integrating a mid-drive involves a complex chain: hardware durability, controller firmware, setup parameters, and clear documentation. Some issues were clear mechanical or software fixes on our end, while others stemmed from confusing configuration options or gaps in our manuals.
We haven't solved everything overnight, but real-world riding is the ultimate test of any propulsion system. Here is what we’ve learned, what we’ve updated, and what we’re still working to refine.
The concept of torque sensing is simple: pedal harder, and the motor provides more assist. However, real-world feedback on earlier DM units highlighted specific areas that needed work.
Riders reported resting values drifting, torque readings that looked off, and sensor behavior changing as the motor warmed up.
When investigating these reports, we addressed the issue across the whole chain:
A modern motor isn't really "done" when the mechanical assembly is done. Firmware changes torque response, assist curves, RPM limits, error handling, display communication, basically everything that makes the motor feel the way it does.
We've made a lot of firmware tweaks based on field feedback. Some fixed specific issues. Others made the system less unexpected and more predictable.
One thing that has helped our engineering team tremendously, and something we actively encourage when riders reach out with technical issues, is providing as much context as possible.
Because a motor system involves battery voltage, gearing, firmware versions, display settings, specific details (like your motor model, voltage, firmware version and so on) make a massive difference. It allows us to pinpoint root causes quickly and push out effective solutions much faster.
Here's something we learned the uncomfortable way.
There's a difference between "the electronics can technically handle this voltage" and "this is a voltage we're comfortable recommending for normal use." Those are not the same thing.
With DM01, we've pulled back on how we communicate battery compatibility. Our current guidance centers around 48V and 52V. We don't treat 60V as a normal supported configuration anymore.
We wanted to set realistic expectations for long-term reliability rather than pushing the system to its absolute engineering limit.
Recommending a setup just because it tolerates it under ideal conditions isn't responsible engineering. We’d rather provide rating guidelines we know will hold up over years of real-world use.
Real-world riding exposes hardware to sustained loads, chatter, and environmental conditions that bench tests simply miss.
Field reports regarding noise, gear wear, and bearing issues helped us refine our testing protocols significantly, ensuring our evaluation standards reflect actual long-term riding rather than ideal factory conditions.
DM02 was always meant to be lighter and more compact than DM01, with a different balance between weight, power, and efficiency.
But riders taught us something obvious in hindsight: there's no single "best" motor behavior for every bike. A commuter wants different response than a cargo rider. A mountain biker wants different response than someone on a recumbent trike. A recumbent rider especially cares about cadence and RPM behavior in a way that upright riders don't always think about.
That changed how we think about firmware and assist curves. The motor shouldn't just make power — it should make the right kind of power for the application.
We know this isn't the exciting part, but it matters.
A technically good motor can still be a nightmare to own if the manual doesn't clearly explain configuration settings, display compatibility, torque calibration, or error codes.
When our parameters or setup guides are confusing, it creates unnecessary setup friction and makes systems seem broken when they just weren't configured correctly for the build.
We've been rewriting our manuals and troubleshooting guides to make sure the documentation is as solid as the hardware. Not exciting, but it actually helps people.
We posted recently about what happens before a motor ships. Every production unit gets functionally tested.
Someone pointed out that final testing isn't the same as quality control.
Final testing catches problems, but it doesn't prevent variation in the first place. So we've been putting more effort into the process itself, component checks, assembly controls, calibration, and traceability, making final testing the last layer of quality, not the only layer.
I don't want this post to sound like "we had problems, fixed everything, now it's perfect." That's not true.
We're still working on firmware improvements.
Still working on documentation. Still learning about long-term durability, that only comes with more miles in the field. Support and spare parts availability are areas we need to get better at too.
We'd rather say that openly than pretend otherwise.
Our goal has always been to build the best mid-drive system on the market.
Achieving that level of reliability across thousands of unique frame, battery, display, and gearing configurations requires continuous, obsessive refinement.
For us, that means constantly pushing forward: better hardware where durability matters, better firmware for smoother delivery, clearer default settings, more comprehensive documentation, and direct, responsive support. Every iteration should bring us closer to that standard.
The DM platform today reflects a substantial evolution from our early production runs. Those refinements run through everything, from physical hardware and internal controller updates to refined firmware and clearer documentation.
Community feedback, diagnostic details, and critical field reports drive our development priorities.
The DM platform is an active, continuously evolving project, and we're committed to making every build better than the last.
If you've been riding a DM motor—whether you have feedback on a recent update or a challenge that needs solving—let us know.
Real-world insights are what allow us to keep refining and perfecting this hardware.
Instead of publishing another static spec sheet, we want to give the users an honest look at how the DM platform has evolved. Integrating a mid-drive involves a complex chain: hardware durability, controller firmware, setup parameters, and clear documentation. Some issues were clear mechanical or software fixes on our end, while others stemmed from confusing configuration options or gaps in our manuals.
We haven't solved everything overnight, but real-world riding is the ultimate test of any propulsion system. Here is what we’ve learned, what we’ve updated, and what we’re still working to refine.
Torque Sensing — Refining the Pedal Assist Response
The concept of torque sensing is simple: pedal harder, and the motor provides more assist. However, real-world feedback on earlier DM units highlighted specific areas that needed work.
Riders reported resting values drifting, torque readings that looked off, and sensor behavior changing as the motor warmed up.
When investigating these reports, we addressed the issue across the whole chain:
- Updated factory calibration procedures
- Refined controller configuration settings
- Resolved signal-processing issues on earlier controller boards
Firmware Matters More Than We Expected
A modern motor isn't really "done" when the mechanical assembly is done. Firmware changes torque response, assist curves, RPM limits, error handling, display communication, basically everything that makes the motor feel the way it does.
We've made a lot of firmware tweaks based on field feedback. Some fixed specific issues. Others made the system less unexpected and more predictable.
One thing that has helped our engineering team tremendously, and something we actively encourage when riders reach out with technical issues, is providing as much context as possible.
Because a motor system involves battery voltage, gearing, firmware versions, display settings, specific details (like your motor model, voltage, firmware version and so on) make a massive difference. It allows us to pinpoint root causes quickly and push out effective solutions much faster.
Voltage Range — Setting Realistic Limits
Here's something we learned the uncomfortable way.
There's a difference between "the electronics can technically handle this voltage" and "this is a voltage we're comfortable recommending for normal use." Those are not the same thing.
With DM01, we've pulled back on how we communicate battery compatibility. Our current guidance centers around 48V and 52V. We don't treat 60V as a normal supported configuration anymore.
We wanted to set realistic expectations for long-term reliability rather than pushing the system to its absolute engineering limit.
Recommending a setup just because it tolerates it under ideal conditions isn't responsible engineering. We’d rather provide rating guidelines we know will hold up over years of real-world use.
Mechanical Feedback — Real-World Stress Testing
Real-world riding exposes hardware to sustained loads, chatter, and environmental conditions that bench tests simply miss.
Field reports regarding noise, gear wear, and bearing issues helped us refine our testing protocols significantly, ensuring our evaluation standards reflect actual long-term riding rather than ideal factory conditions.
DM02 — Different Use Case, Different Tradeoffs
DM02 was always meant to be lighter and more compact than DM01, with a different balance between weight, power, and efficiency.
But riders taught us something obvious in hindsight: there's no single "best" motor behavior for every bike. A commuter wants different response than a cargo rider. A mountain biker wants different response than someone on a recumbent trike. A recumbent rider especially cares about cadence and RPM behavior in a way that upright riders don't always think about.
That changed how we think about firmware and assist curves. The motor shouldn't just make power — it should make the right kind of power for the application.
Documentation — Boring But Important
We know this isn't the exciting part, but it matters.
A technically good motor can still be a nightmare to own if the manual doesn't clearly explain configuration settings, display compatibility, torque calibration, or error codes.
When our parameters or setup guides are confusing, it creates unnecessary setup friction and makes systems seem broken when they just weren't configured correctly for the build.
We've been rewriting our manuals and troubleshooting guides to make sure the documentation is as solid as the hardware. Not exciting, but it actually helps people.
Factory Testing — We Heard You
We posted recently about what happens before a motor ships. Every production unit gets functionally tested.
Someone pointed out that final testing isn't the same as quality control.
Final testing catches problems, but it doesn't prevent variation in the first place. So we've been putting more effort into the process itself, component checks, assembly controls, calibration, and traceability, making final testing the last layer of quality, not the only layer.
What We Haven't Figured Out Yet
I don't want this post to sound like "we had problems, fixed everything, now it's perfect." That's not true.
We're still working on firmware improvements.
Still working on documentation. Still learning about long-term durability, that only comes with more miles in the field. Support and spare parts availability are areas we need to get better at too.
We'd rather say that openly than pretend otherwise.
Our goal has always been to build the best mid-drive system on the market.
Achieving that level of reliability across thousands of unique frame, battery, display, and gearing configurations requires continuous, obsessive refinement.
For us, that means constantly pushing forward: better hardware where durability matters, better firmware for smoother delivery, clearer default settings, more comprehensive documentation, and direct, responsive support. Every iteration should bring us closer to that standard.
Where We Are Now
The DM platform today reflects a substantial evolution from our early production runs. Those refinements run through everything, from physical hardware and internal controller updates to refined firmware and clearer documentation.
Community feedback, diagnostic details, and critical field reports drive our development priorities.
The DM platform is an active, continuously evolving project, and we're committed to making every build better than the last.
If you've been riding a DM motor—whether you have feedback on a recent update or a challenge that needs solving—let us know.
Real-world insights are what allow us to keep refining and perfecting this hardware.
