Houston - We Have a Problem...
As mentioned in an earlier post, I smoked the front controller a while back. This happened while puttering along a bike path on the front motor (rear clutch was acting up). Ilia at Ebikes SF
wasn't concerned since these old Crystalyte controllers are known to give up the ghost unexpectedly for no apparent reason. However, a month or so later, the front controller shorted a FET again - this time when both motors were engaged. This was genuinely suspicious and also very odd, since the front motor spends most of the time disabled and the front and rear are wired identically with the exception of the length of the phase/hall wiring. After replacing the controller again (Thanks Ilia!) I decided to be careful to crank the throttle closed before switching on/off a controller/motor.
Yesterday, the front controller shorted a FET again when walking the bike up a step with both motors engaged (Big Sigh).
Needless to say this is very puzzling since the failures are not occurring under stress, but seem to occur during light use and are occurring on the controller that is seldom in service. If the rear controller was failing as well, then some fundamental electrical design flaw in the build would appear more likely, but as it is, the only material difference between the two controllers (other than the phase wire length) is use-oriented: the front controller logic is powered up and down while underway and the rear controller logic always remains on.
Bench voltage measurements of the harness/controller wiring have not been not illuminating and instrumentation of the internals of the controller for active monitoring during use is problematic - particularly for such intermittent (although catastrophic) failures.
At this point my operative theory is that the controller logic is failing because the current build design uses the 'logic enable'
control line as a means to enable/disable the motors on the fly instead of simply as a onetime pre-ride power-up feature as intended by Crystalyte. Presumably, some component stress/damage occurs and sets the stage for a later failure under seemingly innocuous circumstances. Although an analytical resolution would be comforting, the current plan is to revise the build design to eliminate this potential operational trouble spot by leaving both controllers powered up regardless of the enable/disable state of the motors. Although there is no hard evidence that this will be The Remedy, it is easy to implement and will eliminate a noteworthy problem variable if failures continue. Ilia is on board with the plan and is going to try some bench power cycling to try to induce a similar failure.
The diagram below shows a modification that uses the motor control switches to manipulate the controller 'Throttle Override'
inputs (used by the CA) to disable motors by replacing the normal CA override signal with Gnd to suppress the operator throttle voltage. This requires a rebuild of the tiny electronics board
, but other dashboard and handlebar wiring is unaffected. All existing switch functionality is preserved. (Original design here
Since tax preparation is eating available time this week (too much bike riding = procrastination
), my plan is to swap in a new controller and temporarily run the bike with both motors always engaged until I can tack together a new board. If nothing else, it will be peppy!
News to follow... EDIT: A new circuit design was implemented and installed at the same time as the CA v3 upgrade. See this post.