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.

One thing leads to another

Lots of grease

During a recent commute, a thumping sound was audible between about 10 mph and 20 mph.  The sounds was speed dependent and seem to be correlated to wheel rotation.

Looking underneath, two things were seen - A torn outer CV boot (driver side) and a torn steering rack boot (driver side).  Also, the oil drip from the main shaft seal seemed to be getting worse, so it was time for a major enhancement session (3 weeks on the jack-stands).  Here is a summary of the latest updates.

• New Rear Main Seal (LUF10005).  Previously, the bolt holding the primary gear to the shaft adapter for the motor would not easily slide through the seal and onto the motor shaft.  Some light grinding and thinning of the bolt head resulted in it not tearing the seal when attaching it to the shaft.  The old seal had an obvious gash.

• Idler gear float - confirmed the idler gear float is 0.004 inches (right in spec).  Verified the torque on the bolts holding the flywheel housing/transfer gear cover.  The gears all turn very easily by hand when in neutral.  This was part of an effort to reduce gear noise.
• New gasket for gear-box cover.  Removed the RTV "make-a-gasket" material and installed a custom gasket, making it easier to service in the future.
• CV Boot replacement (GDG0233) - This required disassembling the driver side wheel hub - 2 ball joints.  Then the drive shaft could be removed, repacked both CV joints and reassembled.  Replaced ball-joint dust covers (BTA0377) since they were destroyed in the disassembly process.  Needed to apply some crowbar pressure to get the stud to seat into the knuckle so that the nut could be tightened.  The old boot had a plastic zip-tie on the large end, sitting inside the wheel hub, and it may have snagged on the hug causing the boot to tear.    Used the metal band that came with the new boot.   It has a much smaller head.
• Steering Boot replacement (BHM7113) - Removed the tie-rod end ball joint.  The ball-joint seal was not installed with the upper clip so the joint was frozen.  This is a non-greaseable joint.  After some freeze-all and lots of wiggling of the stud, the joint freed up. Then a good application of silicon grease and standard grease had the joint twisting very smoothly.  The cap was installed with zip-ties on both the top and bottom to prevent water incursion.    Greased up the steering rack as best possible and installed the new boot.  It is hard to tell whether the steering is easier now but this certainly did not hurt.
• Brake cylinder rebuild (BHM7068) - one of the brake cylinders had a significant leak so a quick replacement of the inner and outer seals resolved it.  Also, replaced the broken water ring for the inner front hub seal (GHS0173).

Electrical Updates

As an experiment, I inserted a spare CA60FI LiFePO4 battery in series with the existing 26 cells.  This raised the resting pack voltage to approximately 87V.  The Kelly controller shuts off at 90V, so there is not much margin but the pack should never exceed this during driving.  Charging voltage goes higher, but the Kelly controller is not operating during charging.  Regenerative braking does not produce enough boost to raise the pack voltage above about 88V.

This resolved:

• The DC-DC converter would shut down if the Pack voltage dropped below about 72V.  During heavy acceleration (300A-400A), the pack could drop to this level, especially, if it was below 50% charge, resulting in the 12V system dropping down and relying on the small starter battery.  Lights would dim but nothing else noticeable, just annoying.  The extra 3.2 volts made the difference and now the DC-DC converter never drops out.

Now however, the 27 cells means two things - a new BMS since the current (Green Bike Kit GBK) unit is customized to 26 cells, and a new mechanical arrangement.  The 13 x 2 rack will have to be redone to a 9 x 3 setup, if that will fit in the boot.  This is a good reason to re-engineer the battery setup anyway.  Just need to order a new BMS.

Second benefit - About a 4% increase in battery capacity - not a lot, but every bit helps.

New Digital Dashboard

New Dashboard

It was time to upgrade the Digital Dashboard.  Here is a quick summary and a few fixes

1) New DUE Arduino controller

2) New Serial CANBUS from Longan Labs  http://docs.longan-labs.cc/can_bus/ 

3) Sainsmart 7 inch TFT LCD with CTE Shield (uses SSD1963 controller)

4) Using the UTFT and URTouch library for the display

Setup

1) UTFT myGLCD(20, 25, 26, 27, 28);  //Setup for display  This is CTE70=20

2) URTouch  myTouch( 6, 5, 32, 3, 2);  // the 32 was a change from the default 4

     - Touch Calibration worked with #define TOUCH_ORIENTATION  LANDSCAPE

3) Serial CANBUS connected to Serial 3 on the DUE  (tx-rx rx-tx)

4) 12V DC supply to the DUE (see below for 3.3v fix)

Fixes

• TFT display would not consistently initialize after being powered off for longer than a few seconds

1.  Added a 9K resistor as shown in http://www.dimdim.gr/2016/03/fixing-startup-issues-with-arduino-dues/
2.  Used the latest UTFT library and un-commented out all of the unused configs in the memorysaver.h - 
3. Removed the 3.3v supply from the DUE to the TFT Shield by bending header pin outward.  This solved the cold-start startup problem.  It seems like the 3.3v suppliers (one on the TFT shield and the one on the DUE may have been fighting each-other.

Now the system consistently boots in less than 1 second.

•  Serial Can Bus Library - Since Serial Can Arduino Master relied on SoftSerial, a global replace of "canSerial"-> to "Serial3."

•  Add some buffer clearing since 1939 CAN Data is on the bus starting at power-up.  This floods the serial3 port on the DUE making it difficult to perform the setup.  Sending "+++" to the Serial CANBUS board, sets it to Command Mode, but if the a baud rate is unknown, then the "+++" must be sent at each of the 5 possible baud rates.   After sending the +++; flush the receive buffer then return to Data mode.

• Change the Serial Can Bus factorySetting() routine to set the serial baud rate to 115200 and to start searching for the current baud rate at 115200 since that is most likely where the board is set to at power up.  The Serial CanBus board stores all settings in nonvolatile memory.   Also set all 6 filters to EXT 0 and the two masks to EXT 0.  EXT is for extended frames used in J1939 CAN Bus 2.0b broadcast protocol.  The 0x00 filter and masks allow all frames to pass through.  When set right the Receive LED on the Serial Can Bus board will flicker dimly with traffic.  If set wrong, it will either be bright or off.  Also, the Green power LED flickers with serial traffic to the DUE.

Tuning the Kelly KLS-72701-8080i

Understanding the Settings

After about a year of using the Kelly KLS72701-8080I BLDC sinusoidal controller (Hall Input) with the Motenergy ME1306, I spent time experimenting with different settings available in the Kelly PC app.  Here is a summary of the settings did to the performance of the car.  The goal was to optimize acceleration from a stand-still on level road.  One indicator of performance is how the battery amps changed (not phase amps).

1. Increasing IQ-Kp and ID-Kp to 6000 from the previous setting of 4500 resulted in a hum from the motor at about 300 rpm.  Increasing these to 9000 increased the hum.  No performance difference.
2. Increasing IQ-Ki and ID-Ki to 5000 from previous setting of 500 resulted in low hum from the motor.  No performance change.   Reverted both back to 1000 to resolve the hum.  No performance.
3. Decreasing IQ-Ki and ID Ki to 0 and 10, resulted in the motor not starting to turn from a stop.
4. Increasing Torque Kp & Ki from 4500 to 10000 resulted in noticeable improvement in acceleration from a stop.  The battery amps appeared to increase faster when accelerating.
5. Decreased Speed Error to 50 from 200 and the acceleration was very sluggish.     
6. Increase Speed Error to 4000 and observed improved performance.
7. Lowered PWM frequence from 20k to 6k. High hum with no real motor spin.
8. Lowered Maximum Output Frequency from 1000 to 100.  No change to acceleration but in 2nd gear, the controller shutdown with no error message.  Resumed once RPMs returned to 0.
9. Increased acceleration time from 1 to 100 (0.1ms to 10 second) - Noticeable reduction in acceleration rate.

Overall, with the Torque Kp & Ki changes and the Speed Error increases, the acceleration is improved with no other observable issues or problems.

Bottom Balancing

Started the annual bottom balancing the drive pack.  Using a custom discharger which is set to connect each cell to a 1/4-ohm resistor network, pulling about 10A (3v/0.25 ohm).  A voltage meter is set to connect the network when the cell's voltage is above 2.8v.  As the pack SOC moves down the shoulder of the voltage curve, the voltage with oscillate around 2.8v until the pack is finally discharged to a stable 2.79v and no longer recovers to above 2.8v.

Summary of Changes over the last year

1. Rear Subframe - This resolved the concerns from the heavily rusted, 40 year rear frame.
2. Dampers - GAZ shocks for lowered models from MiniSport.  Noticeable improvement in the ride.
3. Walnut Dashboard with round digital dashboard to match center console speedo.  This also involved replacing the CAN-BUS transceiver from the Serial Can-Bus device.  With the new transceiver, the system is using the built-in CAN-BUS feature of the DUE.  Still having intermittent CANBUS dropouts/loss of communications.
4. Interior Door Trim - the plastic window roll-down handles broke, so this led to replacing all of the handles with bright alloy versions.  7ENT.COM
5. Diagonal Tie Rods Link - The old ones were bent and in need of replacement.
6. Speedometer Cable - The probably 40 year-old one broke due to tight routing. The new one resulted in a much smoother speedometer needle.  Before breaking, the needle always bounced at low-speeds, and now it just moves smoothly.
7. Cooling fans for the Controller - The controller was overheating and self-limiting motor current once it got above about 60C.  Two 12v 5" box fans under the controller keep it in the 50C range over long runs with heavy braking.
8. GreenBikeKit Battery Monitor - This was the end of the CellLog monitors which served Jane well.  The GreenBikeKit 26S BMS is a integrated and programmable system.  A new Arduino communicates over the serial port to the BMS to monitor cell voltages, terminate charge, and drive an audible & visual alarm for over & under voltage conditions.  The BMS also provides charge termination based on two different mechanisms, providing additional protections.  This brings the Arduino count up to 3 for the car.  

KLS72701-8080i Controller Serial USB Communication

Ran into a problem that the controller stopped communicating with the PC Configuration program over the Serial-RS232-USB connection.  The Kelly PC App Reported, no connector or power.

Saw this post on Endless Sphere

In summary - I ran a separate 12v supply to the SM-4P 12v line and cut the 12v coming from the controller (red wire) to the SM-4P connector.

This resolved the issue. The PC still only connects about 30% of the time but once it is connected, I can power cycle the controller without exiting the PC app and the App reconnects (on the Monitor Screen) reliably.

Finally, did some adjusting for Ki Kp SpeedTorque settings to try to squeeze out a bit more performance.