Jason73
New here
FarDriver “Inverse Logic” Experiment — Reverse Timing Map in Forward Motion?
Been doing some testing on a Fardriver 72260, my1020 setup and found something interesting enough that I think it deserves proper discussion instead of random Facebook comments.
This is NOT a “free power hack” claim.
What I’m seeing appears to be a control-loop / timing-map behavior difference between FarDriver’s forward vs reverse logic paths.
Theory
FarDriver controllers appear to use asymmetric timing overlays for forward vs reverse operation.
By electrically configuring:
- mechanical rotation = forward
- controller logic = reverse
…the controller may apply the reverse timing/torque compensation table while still producing forward motion.
The method is simple:
1. Swap any 2 phase wires
2. Swap the same 2 hall wires
3. Run Auto-Learn in that configuration
Result:
- wheel spins forward
- controller still shows reverse logic (反 icon)
- reverse timing path appears active
What I observed
On my setup:
- noticeably faster ERPM rise
- smoother phase behavior
- lower idle watts
- stronger launch feel
- different response from InverseTime tuning
Most interestingly:
InverseTime behaves COMPLETELY differently on my setup compared to what most people report.
Default values (~36) felt relatively damped.
Higher values dramatically changed torque response and motor behavior under load.
However:
- multiple other riders tried the wiring method
- they gained unloaded stand RPM
- but reported little/no additional road torque
Which leads me to believe this effect only appears when the controller is configured in a specific control topology.
What seems to matter
On my controller:
- PEnable = 0
- very fast CurveTime
- high InverseTime value
- aggressive torque-oriented response shaping
My suspicion is:
If the speed/proportional loop is active, the controller simply corrects away the timing advantage under load.
So:
- unloaded RPM changes still appear
- but road torque gains disappear
Important
I am NOT claiming:
- hidden horsepower
- bypassed current limits
- broken protections
- fake “double power”
All protections remain active.
This appears to be:
- a timing-bandwidth / lead-angle behavior difference
- possibly related to how FarDriver reconstructs hall offset tables for reverse operation during Auto-Learn
What I’m looking for
I’d really like input from people who:
- understand FOC timing reconstruction
- have logged phase current + ERPM
- have experimented with InverseTime
- know how FarDriver handles reverse direction internally
Especially interested in:
- whether reverse uses different lead-angle compensation
- whether Auto-Learn stores separate forward/reverse hall offsets
- whether P-loop dominance masks timing-map effects under load
I’m not trying to sell anything or claim magic.
Just trying to understand why:
- some setups only gain unloaded RPM
while
- my setup genuinely changes loaded torque behavior.
Curious what the more experienced motor-control guys think.
Been doing some testing on a Fardriver 72260, my1020 setup and found something interesting enough that I think it deserves proper discussion instead of random Facebook comments.
This is NOT a “free power hack” claim.
What I’m seeing appears to be a control-loop / timing-map behavior difference between FarDriver’s forward vs reverse logic paths.
Theory
FarDriver controllers appear to use asymmetric timing overlays for forward vs reverse operation.
By electrically configuring:
- mechanical rotation = forward
- controller logic = reverse
…the controller may apply the reverse timing/torque compensation table while still producing forward motion.
The method is simple:
1. Swap any 2 phase wires
2. Swap the same 2 hall wires
3. Run Auto-Learn in that configuration
Result:
- wheel spins forward
- controller still shows reverse logic (反 icon)
- reverse timing path appears active
What I observed
On my setup:
- noticeably faster ERPM rise
- smoother phase behavior
- lower idle watts
- stronger launch feel
- different response from InverseTime tuning
Most interestingly:
InverseTime behaves COMPLETELY differently on my setup compared to what most people report.
Default values (~36) felt relatively damped.
Higher values dramatically changed torque response and motor behavior under load.
However:
- multiple other riders tried the wiring method
- they gained unloaded stand RPM
- but reported little/no additional road torque
Which leads me to believe this effect only appears when the controller is configured in a specific control topology.
What seems to matter
On my controller:
- PEnable = 0
- very fast CurveTime
- high InverseTime value
- aggressive torque-oriented response shaping
My suspicion is:
If the speed/proportional loop is active, the controller simply corrects away the timing advantage under load.
So:
- unloaded RPM changes still appear
- but road torque gains disappear
Important
I am NOT claiming:
- hidden horsepower
- bypassed current limits
- broken protections
- fake “double power”
All protections remain active.
This appears to be:
- a timing-bandwidth / lead-angle behavior difference
- possibly related to how FarDriver reconstructs hall offset tables for reverse operation during Auto-Learn
What I’m looking for
I’d really like input from people who:
- understand FOC timing reconstruction
- have logged phase current + ERPM
- have experimented with InverseTime
- know how FarDriver handles reverse direction internally
Especially interested in:
- whether reverse uses different lead-angle compensation
- whether Auto-Learn stores separate forward/reverse hall offsets
- whether P-loop dominance masks timing-map effects under load
I’m not trying to sell anything or claim magic.
Just trying to understand why:
- some setups only gain unloaded RPM
while
- my setup genuinely changes loaded torque behavior.
Curious what the more experienced motor-control guys think.
