EM 5.7 SX Controller Retrofit

Disclaimer

The information provided here reflects my understating at the time of writing.  However, I am constantly learning about siliXcon's methodology, and motor control in general.  This page may contain misinterpretations, explanations that could be improved and outright errors.  Consider the content mostly as a notebook for the author's reference that will likely change over time.

To eliminate redundant information, much of the preliminary setup work (and additional explanations) can be found on the page describing my initial (bench) experiments with the SX controller.  See: https://www.electricmotiontech.com/home/em-5-7/sx-controller-experiments

This page will be updated as I learn.  Currently, it contains the minimum needed to convey a sense of the project.

Motor Parameter Identification

The temporary connection is sufficient for LaunchPad to automatically identify the motor's parameters.  You must specify the sensor type (Hall in this case) and the number of pole pairs (the 5.7's motor has 4) beforehand.

/driver/motor/Ld : 2.51546e-5 (25 microhenries, inductance in the direct axis)

/driver/motor/Lq : 3.07219e-5 (31 microhenries, inductance in the quadrature axis)

/driver/motor/Rt : 0.004393 (4.2 milliohms, phase resistance)

/driver/motor/psi: 0.014897 (15 milliwebers, this is the main motor constant) 

Motor Hall Sensors and Thermistor 

The original Golden Motor Hall-effect sensors and thermistor are wired via an AMP Superseal 1.5 female connector. 

Position Feedback Connector Pinout for Golden Motor

• Pin 1, red, +5V power from controller

• Pin 2, white, Thermistor 

• Pin 3, black, Return (common) 

• Pin 4, yellow, Hall Phase A (aka Phase U)

• Pin 5, blue, Hall Phase B (aka Phase V)

• Pin 6, green (x2), Hall Phase C (aka Phase W)

I believe the thermistor is a KTY84/130 which has a nominal resistance of 603 ohms at 25° C and 1000 ohms at 100° C.

Quoting siliXcon, “Thermistor value and limiter setting are specified in ohms instead of in temperature units to maximize the compatibility with various sensors.  Thermistor resistance reading can be found in /driver/motor/RThermistor.”

/driver/limiter/mtemplo: [ohms] The thermistor resistance at which the limitation starts.

/driver/limiter/mtemphi: [ohms] The thermistor resistance at which the power is 100% limited.

Implementing Controller Precharge

The original 5.7 battery does not perform any controller capacitor precharge whatsoever.  I consider this a pretty significant design flaw and vowed to correct it.  To understand why this is important, see my write-up on the topic: https://www.electricmotiontech.com/home/ev-tech-101/dc-link-capacitor-precharge

My initial idea was to use a resistor and a momentary push button that could be manually operated for a few seconds prior to switching on the battery.  Unfortunately, there's no room for such a push button in any accessible location on the 5.7's battery enclosure.  (This being especially true since I retrofitted a DB-9 connector to communicate with the BMS.) 

My next idea was to replace the original SPST power switch with a DPST switch.  Then, one half of the switch could be wired for a precharge circuit.  This would have been possible because there is a substantial delay (about 2 seconds) from the moment the switch is active until the contactor engages.  During that delay, power would flow from the battery through a Dale 400-ohm RH-10 power resistor to the controller (thereby precharging the controller's capacitors).

But as it turned out, replacing the original SPST switch was unnecessary.  I simply routed power from that switch through the resistor to the downstream side of the contactor.  During the 2 seconds it takes for the contactor to engage, precharge is accomplished.  The resistor remains in the circuit, but is then in parallel with the “zero resistance” path provided by the contactor. 

The controller's total capacitance is approximately 2000 uF.   Thus, the R-C time constant with a 400-ohm resistor is about 800 milliseconds.  The 400-ohm resistance may not be perfect, but it's what I had on hand and is completely satisfactory, as evidenced by the oscilloscope capture below.

I'm very pleased with this implementation.  It operates automatically and was quite safe to install.  I first discharged the battery to about 30% (making it marginally safer to perform the surgery).  I also unplugged the connector for the contactor's coil so it could not accidentally engage.  Only two small holes were drilled in the enclosure to mount the resistor.  Tape on the inside caught any metal shavings while drilling.  I tapped holes in the power resistor, so no nuts would be needed.  The resistor connects to the downstream (controller) side of the contactor, so again, this is pretty safe to wire.  The riskiest part of the operation is making the connection to the battery's power switch.  (But when the power switch is off, there's no voltage present.)  As can be seen in the photo below, the red wire with yellow stripe was soldered to the terminal that provides battery voltage to the LED display and BMS.  As a final safety precaution, I taped the power switch in the off position while performing the work.

Pushing the Bike as a Means of Precharge

Having noticed the lanyard LED illuminates while pushing my EM Race around, I was curious how much precharge could be accomplished that way.  This seems like a good place to leave the results of that experiment. 

I was surprised to learn that the DC-link capacitors will only charge to about 9 volts, even when pushing at a jogging pace.  I then unplugged the 34-pin connector, so nothing would be drawing current, but the result was the same.  

With the bike on a stand, you can even spin the rear wheel fast enough by hand to get to 9 volts.  Interestingly, when the battery is switched off, the residual charge on the capacitors drops to 9 volts immediately.

Handlebar Switchgear

I used the following handlebar controls: 

• Magura throttle, stock from EM 5.7, connects via AMP Superseal 1.5, female, 3 position

• Tether kill switch, stock from EM 5.7, connects via AMP, Superseal 1.5, female, 2 position

• E-clutch, from a Sur Ron accelerator (throttle) plus a bicycle lever, connects via Molex (not OE), 3-position

• Smart LED + Map button + TC/FRB button, from a 2022 EM Race (P/N TL02R-60407-00-00) connects via multiple JST JWPF-style

Smart LED (3 position, male pins):

 JST 1 (green) Communications ground

JST 2 (white) UART Tx

JST 3 (red)  +5 Volts

Note, the Smart LED receives a data packet every 10 ms.  The bit time is about 500 ns.

Map Button (2 position, male pins): 

JST 1 (blue) map change input to controller

JST 2 (black) ground

TC/FRB Button: (3 position, female pins):  

JST 1 (white / black stripe) enable input to controller

JST 2 no connection

JST 3 (yellow) battery voltage from controller

Controller Enable

Instead of having a manual controller enable/disable function as used by EM and Mecatecno, I wanted this to happen automatically whenever the battery was switched on/off.  I achieved this by tying controller pin 17 to pin 25.

Then I used the lanyard as a “seat switch” to inhibit the controller's power stage from operating and thus stop the motor.  I felt this was important because I planned to implement flux weakening.  See this section for more information: https://www.electricmotiontech.com/home/em-5-7/sx-controller-experiments#h.ltqlc9pdm2cw

However, once I implemented capacitor precharge, the controller would no longer “self enable.”  Apparently, the controller did like the slow rise-time of the resulting signal.  As a workaround, I installed a SPDT on/off switch near the controller (SX pins 17, 25, and 9).  This worked fine, but I did not care for it as a permanent solution. 

My next bright idea was to use something akin to a microcontroller R-C reset circuit to enable the controller.  But, here again, I think the rise time was too slow, and it did not work.  I think something along the lines of a one-shot timer would have worked, but the component count gets fairly high given that battery voltage is involved.

It seems the simplest (and most familiar) solution would be to use the Leonelli TC/FRB button for enable, and turn the battery off for disable.

Unfortunately, I made the wiring harness from a 10-conductor cable I had on hand.  Ten wires provided for exactly the functionality I had anticipated, but nothing was leftover for expansion.  So I ran an additional 2-conductor cable for the controller enable button.

In the future, it may be possible to reclaim two of the wires in my original harness.  The Smart LED uses its own dedicated power and ground signals.  I wired the LED that way because EM and Mecatecno had done it that way.  Although this may have been for safety or electrical noise mitigation, having dedicated wires may just have made for easier connections.

Maps

A vast array of mapping options is possible.  The firmware allows up to 9 maps, plus a safety map and reverse.  It's possible to have any map be selected when the controller is enabled using the parameter initmap.  The first three maps are represented by three LED colors (Green, Blue and Red).  Any and all other maps are represented by White.

I wanted to stick with the familiar and made the map switch behave similarly to that found on the EMs and Dragonfly.   

Map0 is called the safety map.  It's only available immediate after enabling the controller.  Once you toggle past Map0, it can't be selected again until the controller is disabled and re-enabled.  

Several performance parameters are programmable on a map-by-map basis:

/maps/map1/asc_max: (throttle range)

/maps/map1/comlvl: (regen level)

/maps/map1/kph: (vehicle speed limit)

/maps/map1/trqlvl: (torque limit as a fraction of maximum available)

I've described the effects of those parameters in the section on the Dragonfly's U-Mapp facility.  See: https://www.electricmotiontech.com/home/mecatecno-dragonfly/controller/u-mapp

Note that the Dragonfly utilizes custom firmware and not all of its functionality is available in the siliXcon GENERIC_VECTOR firmware that I have.  For example, the tickover/idle function does not exist.  Similarly, the throttle exponent /acc/csc/exp only has one setting that affects all maps. 

Throttle, Quick versus Slow

The asc_max parameter is what gives the throttle its range (slow-turn versus quick-turn, and anything in between).  Electrically, the throttle produces ~5000 mV when the throttle twisted to the mechanical stop.  But if you specify that as the range, there is way too much dead zone at the bottom.  A setting of around 3500 to 4000 produces more familiar behavior.  Of course, nothing more happens as you keep turning the throttle past the asc_max value.  This feels a little weird when running flat out on easy ground between sections.  Honestly, it all seems backwards to me, but that's how siliXcon implemented it.

The smaller the value, the “quicker” the throttle.

/maps/map1/asc_max: 4500  (slower throttle)
/maps/map2/asc_max: 4000 (default)
/maps/map3/asc_max: 3400 (quicker throttle)

Initial Testing / Observations

I began with the very conservative current settings of 100 motor phase amps.  (This was the value I used when bench-testing the unloaded Motenergy motor.)  As the old joke goes, that's not enough power to pull the skin off a pudding.

Eventually, I got the bike working fairly well in the driveway at about 300A.  I then took it to our normal riding spot, where its performance exceeded my expectations! 

Configured with 3 maps, I made one specifically for Cindy.  Basically, it was a lot of educated guesswork.  Of course, nothing exists that can't be improved, but the bike was completely rideable for both Cindy and me.  I did not even bother to take my EM Race off the trailer.  Cindy and I swapped back and forth between the 5.7 and the Dragonfly.  (I finally got to ride the Dragonfly enough to appreciate its anti-rollback feature.)

Motor noise is greatly reduced with the SX controller.  The Kelly is a primitive square wave controller, and this creates a large harmonic content.  With the siliXcon, the motor is now quiet enough that you notice the chain noise.  But because the overall sound is reduced, the “resonance noise” in a narrow RPM band around, say, 1500 that is present with both controllers becomes more objectionable.  I'm not really sure what causes this, but think it may be a structural resonance in the motor and/or chassis.

What follows are the features I implemented for the second field test.  It all worked very well, but ongoing refinement to the parameter values will make it even better.

Anti-Rollback

Having sampled anti-rollback on the Dragonfly, I wanted to implement it on the 5.7 immediately.  This feature is not well documented, but setting the drive options (drvopts) parameter to 34 causes anti-rollback to function.  

Drive options is a bitmask.  

/drvopts:  bit 5 (Enable auto brake) must be set.  This seems strange to me, as bit 4 (Enable auto hold) sounds more like the correct bit to set, but it is not.

Note: a drvopts value of 34 (32 + 2) also sets bit 1, which is needed for regenerative braking on closed throttle.

The feature works great!  But there is a complication because I have the controller always enabled, and use the “seat switch” as a kill button with the lanyard.  Thus, there's no way to roll the bike backwards for maneuvering other than by powering-down the battery.  This was quite annoying in the garage.  Of course, having a real mechanical clutch would negate that problem.  

I eventually solved this by making the Green map behave as a neutral.  Now, the Blue map is for Cindy and the Red map is for me.  It's possible to cycle back to the Green/neutral map at any time.  I would prefer the neutral map was White, but that is somewhat more complicated.

As an aside, I thought anti-rollback might not work well with Hall sensors, but it's just fine.  I'm beginning to think there is no performance advantage to EM's use of a sine-cosine encoder.  Sin-cos encoders provide excellent position resolution and have a low computational cost, but are more expensive than simple Hall-effect sensors.

Electronic Clutch

My preferred embodiment for the E-clutch is to use a rotary Hall-effect throttle from a Sur Ron motorcycle and a cable-operated bicycle lever.  The problem is that with the clutch lever released, the voltage is small and when the lever is pulled to the bar, the voltage is large.  Mathematically, what's needed is a transfer function such that: OUTPUT = absolute value (5000mV - INPUT).

However, an even simpler solution is to make the max value numerically smaller than the min value for /acc/ascclt.  This inverts the logic.

/io/IN_clutch: 9,0 (assigns the clutch functionality to SX pin 21) 

/common/ioconf1: 0 (allows the input pin to float and accept analog signals)

/acc/ascclt/max: 800 (millivolts with lever fully released)

/acc/ascclt/min: 4300 (millivolts with lever pulled to the bar)

Regen Braking on Closed Throttle

The siliXcon name for regeneration is braking.  I suppose this makes sense, as it is the end result.  (They also prefer accelerator to the term throttle.  Although certainly correct, it will be harder for me to embrace that one.)

It's possible to provide automatic regenerative braking on closed throttle.  For this to work, the accelerator's “center” value needs to be slightly greater than the accelerator's minimum value.  I used 500 and 450 millivolts, respectively.

The combined brake force multiplier (comlvl) then sets the strength of the regeneration.  This value can range from 0 to 1, with a larger number providing more regeneration.  Wanting to experience the full effect, I initially tried a value 0.9 which is extremely powerful and useless on a trials motorcycle.  Values of 0.2 and 0.25 were rideable, but far from optimal.  A value of 0.1 is reasonable, for now.  I think the limiter for negative battery current (which is presently set at -20 amps) would also have an effect on this, but have not experimented with it.  

/acc/asc/center: 500 

/maps/map2/comlvl: 0.1

/drvopts/: xx   bit 1, Enable accelerator brake (comlvl) must be set

Flux Weakening

When everything else is working satisfactorily, I plan to implement flux weakening.  This will allow the motor to run faster than its base speed.  Note: the concept is also called field weakening and is used with DC motors that have field windings.

Right now, the motor is limited to about 4000 rpm at full battery voltage.  This equates to a ground speed of about 36 kph.  With flux weakening, I think 5000 rpm would be mechanically safe, since Golden Motor sells a version that runs to 5000 rpm.  This would give a top speed of 45 kph.

To initiate flux weakening, a single parameter fwc (flux weakening current) is made non-zero.  

/driver/dac/fwc: 0.35

This value is represented as a fraction of Iref.  A value of zero turns flux weakening off, which is the default condition.  When experimenting with the Motenergy motor on the bench, I started with a fairly conservative setting of 0.35.  This produced the desired result, and allowed the motor to achieve a speed which is where I had an absolute kph speed-limiter set.

The .YC File

LaunchPad can generate a diagnostic report that contains approximately 640 “items” — not all of which are configurable parameters.  Many are “state variables” (dynamic values pulled from RAM at the time the report is generated).  There are also “permanents” that record extremes like the maximum currents, temperatures and so on. 

LaunchPad also creates the .yc file, which contains setup parameters used to configure a controller.  It is in a human-readable format that may be altered via any text editor.  When creating the file, you are given the choice to make it contain all 640 items, or only the non-default parameters (which can be considerably smaller).  Presently, my .yc files contained about 60 non-default parameters.  

When I get closer to a final implementation, I'll post the .yc file here after editing out my unique serial number and UUID.  I don't know if any harm could come from exposing those numbers, but it seems prudent not to allow the entire world access to them.

Intuitive Digital Control

Ultimately, I'd like to implement my Intuitive Digital Control.  That's the name I gave to a design for an electronic clutch that also allows control of regen braking.  It's described here: https://www.electricmotiontech.com/home/em-5-7/modifications/intuitive-digital-control

I mentioned this to a principal at siliXcon since it would require a change to their firmware, but have yet to get a reply. 

Closing Thoughts

Other than doing significant development work immediately after acquiring the 5.7, I really did not ride it much.  The lack of a mechanical clutch and single power setting (that I configured for Cindy) were significant hindrances to my enjoyment of the bike.  But now that the power delivery is completely programmable, that may change.  The original 5.7 battery will be a limitation.  It's only rated 1.2 kWh, as opposed to our other trials bikes that have 1.8 kWh batteries.

Two other significant differences with the 5.7 remain when compared with our other electric trials bikes:

1. Inertia.  Mecatechno commissioned custom firmware that incorporates synthetic inertia.  This makes the bike feel more familiar (much more like an ICE vehicle).  Electric Motion added physical inertia to the system, and I went to great lengths to increase it.  Frankly, I'm very impressed with Mecatecno's (siliXcon's) implementation of synthetic inertia.  It keeps vehicle weigh low while improving performance.

2. Tickover/Idle.  Again, this requires custom firmware.  It also requires a mechanical clutch to implement, and few EVs need or want one.  There are definite advantages, but the downside is increased power consumption and imperfect control if the clutch is at all draggy.  So not having it may not be a great loss.

Benefits of the SX retrofit to the EM 5.7 include:

• Completely programmable power delivery with multiple maps

• Gained anti-rollback feature

• Improved regenerative braking

• Reduced acoustic noise

• Decreased bike weight (by over a kilogram)

• Increased top speed

Overall, I feel the project has been a huge win.  It's allowed me to work with my two greatest lifelong passions, electronics, and motorcycles.  Further, it provides an ongoing opportunity to learn about state-of-the-art motor control.