New ME1616 Motor

 New Motenergy ME1616 Motor installed

After a lot of consideration, the old ME1306 has been upgraded to a ME1616 LINK.  This new water-cooled motor with Sin/Cos encoding brings a smoother, quieter drive, more power, and with water cooling, an elimination of over-heating concerns.  It was directly compatible with the existing Sevcon Gen 4 Size 4 80v controller.

Top modifications required:

- Small cut-out in the frame with subsequent reinforcement for 2-inch larger motor

- Adding a glycol/water cooling system for the motor and controller.  this included a radiator, fan, and coolant reservoir.  All straightforward, but required a range of brass fittings to adapt the different hose sizes to shoehorn the components into the constrained engine compartment.

- New Sevcon Configuration DCF settings - This has required extensive trial-and-error to dial-in the settings.  The system is working about 95% now.   Still needs more tuning for high-torque situations.  DCF file available here  LINK

Top teachings:

1) The inductance setting is important and the spec for this motor is very broad.

2) Gains require precise adjustments to avoid current errors under heavy acceleration.

3) Field weakening is important and produces a noticeable improvement in mid-RPM range torque.

4) Without a Dynamometer, tuning is a slow process.

New BMS Configuration and Testing

More Data

The new BMS setup is working very well and is a great simplification from the previous setup.  The new chargers (2 x 600w 48v chargers in series) deliver about 12A of charging which equates to approximately 7.5 miles of charge per hour.  Additionally, the Bluetooth connection from the BMS monitoring Arduino UNO is reliable and fast.

Currently, there are three levels of protection for the battery:

1. Chargers - The chargers should terminate if the pack voltage exceeds about 115 (32 x 3.6v), but they do not monitor individual cells, so if there is a cell imbalance, it possible that some cells could be overcharged while others are low.
2. BMS - The chargers are routed through the BMS which is set to 3.5 volts for the High Voltage Cutoff.  If a cell exceeds this threshold, the BMS will turn off the Charging FETS, disconnecting the chargers from the pack.
3. BMS Monitor Arduino Uno - This Arduino communicates with the BMS over Bluetooth (HC-05), requesting every 2 seconds, a voltage level for all 32 cells.  If any cell reports greater than 3.495V, this Arduino will turn-off a contactor that physically disconnects the chargers.   Only a power cycle will permit the charger contactor to be reenergized.  The Arduino also has an 8-second watch-dog timer running along with a 30 second timeout timer for communications with the BMS.  If the BMS stops responding for 30 seconds, the Arduino will shut-down charging and turn on a buzzer.

Currently, the 220v charging power is on a wall-timer that is manually set based on the SOC of the pack (1-4 hours). 

The BMS Arduino is monitoring the cells for low-voltage events.  If any cell drops below 2.5v, the buzzer will sound and the IGN red indicator on the Dash will light, alerting the driver.  The digital dashboard display can also show the status of the back - High and Low cell number, and max delta voltage across the cells, total pack voltage, temperature of the BMS.  The BMS is set to not permit charging below 5℃ as an added protection measure.

The BMS enters into a balancing routine after the charging is complete, attempting to bring the cells to within 10mV of each other.  A series of LEDs on the BMS flash during the balancing phase.   So far, the pack reports below 10mV following charging, so the balancing appears to be working as expected.

Test Drive

With the system fully operational, I headed out around town to test the pack.  Running now in second gear, Jane accelerates great up to over 40MPH.  After 21 miles, it took right at 3 hours to charge at 1200W, equating to 3600Wh for 21 miles or about 170 Wh/mile efficiency.  The pack is now 26 x 60 AH cells & 6 72AH cells at 3.2v each --> 6.1 KWH (total), so using an 80% safe usable capacity, the theoretical range is 29 miles.  Another longer drive will be needed to confirm this.

The other benefit of being able to stay in 2nd gear for most roads around town, is the motor current draw is only high (>200A) for a few seconds during acceleration, resulting in a cooler running motor.  So far the motor has not risen about 70℃ and stays below the 5,000 RPM spec when driving around town.  Regenerative breaking is always very strong in 2nd.

 More Batteries

With the new Sevcon controller's ability to handle up to 120v, it was time to expand the battery pack to 32 cells.  The CALB 60Ah were discontinued and no longer available.  I was able to locate 6 CALB CAM72 (72AH) cells.  This new enhancement ended up motivating a complete rewire of the battery system.  The boot(trunk) is now much cleaner but still could use a few more minutes of straightening up.  

New BMS

The new ANT 32s 300A Bluetooth BMS from eBay is a nice upgrade from the previous serial port version.  This meant the Arduino Uno that monitors the pack needed a HC-05 serial Bluetooth board which is a better answer since it isolates the Arduino from the high-voltage pack.  The protocol (Github and Github) to monitor the Ant BMS over Bluetooth was straight forward and worked pretty much out of the box.  The Uno drives a buzzer, red (IGN) warning indicator on the dashboard, and will disconnect the charger from the battery pack if an alarm occurs or the BMS is not communicating with the Uno over Bluetooth.

The battery pack is now divided into two 16 cell modules, which are easier to manage, than the previous 27 cell single module.

The Pack is 3.3v x 32 = 105v when charged, with a charge limit about 3.45 x 32 = 110v.

The new BMS is wired between the charger and the pack and is providing charge termination along with individual cell voltage monitoring.

The BMS also attempts to balance the cells after charging completes, which seems to be working since the cells are withing 5mv of each other after charging.  While balancing, the BMS puts on a nice LED lightshow.

The ANT BMS Software is decent on an Android device and allows excellent customization.  Here are the settings in the BMS:

New Charger

The original charger would only go to 99V even though its label indicated it could drive up to 110V.   Attaching two 16s 58.4v LiFePO4 chargers in series worked out to be an easy solution and the lowest cost option for a 15A 115v charger.  About $160 each versus a single 115v-15a charger which was closer to $500.    The chargers are powered directly from the 220VAC power connection.

The chargers are self-terminating, shutting off the charge before any cell reaches 3.5V, which is where the BMS and Arduino are set to terminate the charge.  This means there are three different systems monitoring the pack to assure cells are not over-charged.  The Uno also monitors and provides an alarm if a cell drops too low, below 2.5V.

Bluetooth Configuration

The HC-05 need to be setup as a Master Serial device and binded to the Ant BMS.  Here are the commands that setup the module.  Once setup, it quickly connects to the ANT BMS when power is applied.

The required AT commands to set the configuration:  Instructables

1. AT+RMAAD (To clear any paired devices)
2. AT+ROLE=1 (To set it as master)
3. AT+CMODE=0 (To connect the module to the specified Bluetooth address and this Bluetooth address can be specified by the binding command)
4. AT+BIND=32E3,2E,012345 (Note the commas instead of colons given by the slave module.  This is the BT address of the BMS, discovered using a BT scanning app.
5. AT+UART=38400,0,0 (To fix the baud rate at 38400)

The HC-05 is put into AT comms mode by holding the button at power-on and running at serial comms passthrough program on the Uno.

Results

The first few drives with the new pack indicate it is working as expected.  The controller is driving higher RPMs without field-weakening (FW).  In second gear, the acceleration is excellent and 3rd gear easily achieved 58MPH while the motor stayed fairly cool.  More testing is still needed to see if the higher voltages results in better watt-hours/mile efficiency measurement.  The added cells should add about 5 miles of range but that is still to be tested.

Moving from Kelly to Sevcon controller

 Time for an Upgrade

The Kelly KLS72601 controller burned up while pulling out of my driveway, something done successfully hundreds of times previously.  It was about several years old with a few thousand miles on it.

This was the trigger to move to a new controller, which has cascaded a series of changes.

New Controller:  Sevcon Gen 4 Size 4 80v unit Part #634A83207  (420A RMS motor current (10s), 350A (2 min), 140A (continuous))

The installation of the new controller required a rewire of most of the motor controls since Sevcon is not an isolated controller and handles pre-charge/startup and sensors differently.    This meant adding another contactor to control the battery voltage from the normal key switch.  Also, the reverse and forward switches are independent, so a relay was needed to support the SPST reverse switch on the dash.

Driving in 3rd gear is reasonable and very similar to the performance of the Kelly controller, though quieter, the Canbus is reliable and does not drop out, and the regenerative braking is super smooth.  However, 2nd gear performs much better with quicker acceleration.  With field-weakening, the motor easily his 4,000 RPM (or about 40 MPH) under load, something the Kelly controller could not do.  The Kelly would top out at around 35 MPH.

With the help of several versions of wiring diagrams and a lot of trial and error, this is the current setup.

1) UVW wiring (5V UVW encoder and phase connections):   See Schematic

A few Sevcon settings to tweak the operations. 

2) Disable sequence (startup) checking of the forward switch, since the default mode is forward for the reverse-relay.  The controller will set an error if the powered-on with the reverse switch on and it will not energize the motor, until the reverse switch is put into forward.

3) Throttle and Brake sensor settings - 5V power & response curves.  Braking torque turned up to 70% and will generate in excess of 5KW when braking.  This is considerably higher than the Kelly and smooth already down to a full stop.

DCF Configuration

It took several days to land on reasonable Sevcon Gen 4 settings using the DVT software from Thunderstruck  The last one that was limiting iQ Max was the temperature cutback.  Here is what I learned:

0) Sevcon firmware version:  0705_gen4_IMPM_7050013.dld - Sevcon support sent this to me.

1) Gains

2) Motor Parameters

Contactor:

Inputs

3) Cutbacks and Limits - still tuning voltage, torque, and temp curves

4) Footbrake settings based on the output from the inline brake pressure sensor.  Getting 3-4 KW of regen at low speeds with light brake pedal pressure.

Digital Dashboard and Canbus Interface

The Teensy 4.1 is speaking with the Sevcon controller very well.  The Sevcon sends 5 TPDO packets out every 20 milliseconds which is more than fast enough.  With the screen updates, the Teensy is unable to keep up but the FIFO canbus buffer just rolls over so there is no negative impact.  Did add 4 reads per update loop to make sure a reasonable number of packets are processed every cycle.  The RPM display is updating more than quick enough.  A new Canbus screen is also available with a touch of the touch-screen.

What I've learned

1) PI Controller - Sevcon is inconsistent with naming conventions.

Both Current (Q-Axis. torque) and Speed proportional gains are used in Torque/Speed mode.  Setting speed & current (Q & D) Ki integral gains to zero causes strange behavior.  D-Axis (Field Weakening, FW) Kp and Ki are important since controller driving id to zero will throw-off iq currents.  This best explanation  of the iQ & iD relationships I can draw:  

Target iq determined by target torque (throttle and limits (battery, temperature)), motor inductance, iq-max, current limits (motor) and Target id.  The gains are used to adjust the voltages being applied in an effort to get actual iQ and iD to approach the Target iQ and Target iD.

Small changes in the Kp gains can have large changes (runaway and oscillations).  Ki values seem to force convergence over time, especially the speed Ki integral gain.

2) Key equations

Max iQ - dependent on cutbacks (voltage & temperature) - when all is correct, this should match 420a (RMS), the controller's limit.  Cutback values shown on Motor Status page.

Motor Inductance LS - This changes the maximum flux current, which appears to be a limiter for iD, which may have its biggest impact on field weakening which I have not really tested.  The controller is reporting a measured LS of 54 microhenries which is less than the datasheet value of 100-200 µH (.1 or .2 mH).  More testing is needed.

Ke also impact impact Max Flux Current but changes cause problems with the PI control loop, so I could not experiment too much with changes to this value.

Digital Dashboard Do-over

 New Digital Dashboard

After several years of using an Arduino DUE (32-bit, 64Mhz) as a digital dashboard controller, it was time to modernize the system.  The Teensy 4.1 was released in 2020 and brings 600 Mhz, a floating point unit (FPU), and a lot of I/O.

Interfacing this to the existing systems required some new code development.

SAINSMART 7" SSD1963 LCD - A custom wiring interface had to be created to connect this display to the Teensy.  It is a 16-bit interface so having the extra I/O on the Teensy 4.1 was a benefit.  Also, the timing of initializing the display created additional development.  The 600 MHz processor start-up is quite fast and prior to the LCD initialization, special timing delays (100ms) needed to be introduced.  The MCUFriend_KBV LCD driver library worked great and a custom Teensy 4.1 SSD1963 interface was posted on GitHub.

The RF24 (radio, comms to the BMS and battery charge monitor), XPT2046 (touchscreen, used to switch display modes), and SD (storage of startup bitmap image) libraries worked as expected.  The Teensy version within the Teensyduino package from PRJC Version 1.54 Beta 9.

The Flexcan_T4 Canbus interface did not work on the CAN3 integrated interface in the Teensy 4.1 but worked well on CAN1 with a 3.3v Canbus transceiver from LC.

The built in Real Time Clock (RTC) of the Teensy only requires a coin-cell battery (2032), but that was simple.

A separate 12V-5V (25w) supply has been added to power a USB hub and the TFT LCD backlight.  This hub now provides a single USB connection to the dashboard, timing advance controller (Teensey 4.0), and the Kelly KLS controller serial-USB interface for configuration.  The hub also provides power to these devices.

The simplest step was the analog drivers (with FET drivers) for the original Mini gas gauge and motor temperature gauge which require 10v to operate.  A dedicated adjustable power supply is in place to provide a constant 10v supply from the car's 12v.

With the new design, new mounting brackets for the LCD to the dashboard were created and 3D printed.

The new processor is fast enough to provide are faster interface for the driver and better gradation of the graphics, improving the overall look for the dashboard.

Timing Advance finally works

 With enough power, anything is possible

I decided to attempt the phase timing advance system again, to compensate for the lack of flux-weakening, timing advance in the Kelly KLS controllers.  With BLDC motors, there is real benefit to dynamic phase timing to both gain additional torque in the lower RPMs and a bit more speed at the top-end.  The trade off is more power going into the motor which can increase the motor temperature, but that is reasonable given the increase in power.  A fixed (rotate the timing sensor on the motor) would provide incremental benefit in the forward direction, but with electronic reverse, this permanent advanced angle would make reverse rotation difficult and maybe unusable. This is what contributes to the need to have dynamic timing adjustment.  The motor (Motenergy ME1306) comes from the factory set to neutral timing.

Using a Teensy 4.0, which is an impressive platform, combined with a bidirectional 5V-3.3V level shifter CYT1082 for the 6 signals (3 from the motor, 3 to the controller), the timing shifter's HW was rather easy to integrate.

A number of key teachings came from developing the phase timing shifter code.

1. Give the motor a full revolution to stabilize before starting any timing shifts.  This means a full 24 phase changes (6 phase for 4 e-revolutions).  
2. Having a floating point processor simplifies the process.  The phase times for the motor go from about 30,000 microseconds (at low RPM) to less than 500 microseconds when spinning at 5000 RPM.  Phase shift is typically referenced as a angular shift (independent of speed, so the algorithm selects a desired angle of shift and then computes the amount of shift time (timing advance... The time the next shift should occur) necessary to achieve that angular shift.  Floating point math just makes this easier to program.  Each phase is 60 e-degrees so the shift time = phase time x (shift angle / 60).
3. A 600 MHz processor means that the system can loop through the state-machine many times per e-phase, minimizing the chance of a missed or delayed signal.
4. A basic state-machine worked well with the following paths.
1. Bypass->Forward->Advance Timing-> Bypass
2. Bypass->Reverse->Bypass
3. Bypass: a pass through mode when the timing signals pass through unaltered.
4. Forward: Forward rotation is detected.
5. Advance Timing: After a number of forward cycles, timing shifting can begin.  This includes a linear slew rate for how fast the timing is changed and a timing advancement curve that sets the target degrees of advancement based on the current RPM.
6. Reverse - Reverse rotation is detected.  Currently the system just passes through the signals in reverse since no timing changes are needed.
5. Using timer-driven interrupts to drive the signal change is simple, but managing two timers simultaneously is necessary since the "next" cycle may begin either before or after the previous cycle has ended depending on if the motor is accelerating or decelerating.  Also, assuring the timers have completed their cycle before the state machine transitions to another state is key to avoid unexpected signal changes.

After all of this, there is a noticeable low-RPM torque boost from the timing advance and an increase in the top-end RPMs when in neutral.  The motor now hits around 5,000 RPM in neutral where before the timing advance, it was closer to 4,500.  This was the evidence that the timing is advancing.  I have not tested to see if this will result in higher road speed.

Just a note, when the timing shifter is not functioning properly, the motor can behave quite poorly, resulting in unexpected phase changes or changes that are not aligned with the physical coils/magnets of the motor.  This resulted in some loud thunks, sudden vibrations, or other undesirable motor actions.  There is still some empirical work to do to see what the optimum timing advancement curve should be. 

Currently the timing advance curve looks like this.

 RPMs                  25k    5k   3333   2500  1250   833   625   416   357     156  

angleOut[] =   {      35,   45,    45,    45,     35,     35,     30,     25,   25,      20}

Idler Gear Bearing

Well after a little close listening, I suspected the idler gear bearing (13H7848  I.D.(shaft diameter) .750", O.D.-1.063"., equivalent to the SCH1212) was a source of some of the whining sound generated while the motor is under load.

Pulling off the gear cover and examining the gear, the pins looked OK but all on-line guidance indicated replacing it should help.   There are two identical bearings, one in the block and one in the cover.  The gears all look OK so there are only a few things that could cause the whine.  

Removing the bearing from the block was easy but the one in the cover took heating the cover with a heat gun to 75C and then strong repeated pulls with a slide-hammer + blind bearing puller rented from my local auto supply.  The new bearings installed easily.  This did allow me to check the end-float on the idler bearing and it measured with feelers at 0.004 inches.  Right in the desired range.  Everything spins easily and upon reassembly, the whole motor sounds quieter though the whine still exists under load.

This tear-down project did permit some additional cable clean-up, a lowering of the controller and the replacement of a piece of sheet metal along the side of the engine compartment.  This now simplifies motor access.

After some additional research, I replaced the oil with 20w50w given the age of the gearbox and the fact it never operates at a temperature above ambient.