Return to Main Menu

Documentation for motor Controllers

Brushless 3 Phase DC (BLDC) & ESC types
Phaserunner This section documents the Grin Technologies Phaserunner BLDC FOC controllers.
Grinfineon This section documents the Grin Technologies Grinfineon BLDC FOC controllers.
Infineon by Lyen This section documents the Infineon controllers modified by Ed Lyen to allow more power to be used.
VESC Controllers This section documents the ESC controllers developed by Benjamin Vedder ("V"+ESC) of Sweden and open-sourced.

 

 

 

 

 

 

Phaserunnerunner

Typical Specs: FOC, DC 90 volts, 3,600 watts, 40 amps

Justin: "There is a lot of talk about sinusoidal and field oriented controllers ("FOC") on this board which is a good thing to finally see happen. Both sinusoidal and FOC controllers run brushless motors silently with no hum or buzz, but a FOC by definition also automates the phase advance process so that the motor is driven at optimal timing even at very high RPMs. This makes them work well over a broad range of motor types and as a result this has been our go-to controller source for all our interesting EV projects."

Bill James acquired the first two units of these Phaserunners for our joint projects in Aug 2016. We intend to primarily pair these controllers with Alexey's RV-100 and RV-120 BLDC motors.

Inventor/developer/manufacturer: Justin Lemire-Elmore of ebikes.ca in Vancouver, BC; info@ebikes.ca (he prefers email over PM's on endlessphere.com;)

We're using the post-beta, BAC 8000 potted units from Grin. Catalog page for PhaseRunner on Grin Tech site

Main thread on Endless Sphere (ES) forum: includes links to Firmware and Programming (Setup utility, FTDI drivers, etc.) PhaseRunner on ES

Software/Programming

The PhaseRunner is based on the ASI (Toronto) manufactured BAC8000 controller, which used the "Bacdoor" software to program the controller's operating parameters and run the "Autotune" procedure to match the controller to a particular motor -- the actual motor, not just it's model or type. Justin at Grin redesigned the circuit board to fit into a smaller form factor, added better wiring and switches, heatsinks, and potted the entire controller.

Using the PhaseRunner software, on ES
Justin's updated GUI controller software can be downloaded at the following links:
Windows
Linux
(MacOS version just going through some adjustments)

Phaserunner & Crystalyte 3525

First test run 16 Sep 2016; I made an adapter for the Hall sensor mini 5 pin plug on the 3525 to mate with the 'standard' Grin JST-SM-5 Hall connector, where pin 1 is GROUND and pin 5 is +5VDC. The Phaserunner phase wires didn't match the Crystalyte's wire colors, so I swapped the YEL and BLU outside wires on the Phaserunner side (GRN remained the middle phase wire on both sides). This did NOT work. The static spin test just had the wheel do a violent "shudder" (no rotations). I got an erroneous result screen with a "Kv" value of 1.54 RPM/V, and "Warning: Invalid hall sensors! Running sensorless. Hall Offset 0 degrees". I did forget to set the parameters to use the Hall sensors, but that didn't really seem to make a difference when I corrected that and re-ran the Autotune.

I then switched the BLU and YEL phase wires back to their original positions on the Phaserunner and re-ran the Autotune, selected "Hall sensors" (on start and run -- Grin recommends Start with sensors, but RUN sensorless, will try that next). This time the Autotune finished without any errors, and everything seemed to work fine. The speed in the dashboard display seemed too low with WOT, but the Sigma indicated a ground speed of 22.8MPH, which is right where it should be. This is using the default "Torque" throttle with my pill bottle throttle control, so the "loaded" speed may differ.

Note that when using the Lyen Infineon controller, we also switch the BLU and YEL wires, so maybe it's important to connect the phase wires "Infineon" style, even on the Phaserunner. I thought it auto-detected all of the wire connections.... will need to confirm that. To begin with, I've left all other settings at their defaults.

Infineon by Lyen

This is the very first controller we got to build the erowbike1 prototype, using the Crystalyte rear hub motor. We're currently using this controller on the BogieDyno to test generic Infineon controller compatibility. Ed Lyen starts out with a standard Infineon controller and replaces/adds MOSFETs and makes other board modifications that make these controllers to handle much larger currents.

 

 

 

 

 

Grinfineon: DC 48 volt, 1500watt, 45 amp

This is an Infineon type controller designed and built by Grin with enhanced capabilities that are fully configurable via a programming app.

Throttle/Regen

On all Grinfineon controllers, the 0.0 to 0.8V throttle range is mapped into a proportional regen mode, so the lower your throttle voltage goes below 0.8V the more regen you get. This should allow you to "reverse" the throttle, assuming that the throttle if left untouched outputs between 0.9 and 1.1 (approx?) volts.

Alternatively, you can also activate the ebrake, and while ebrake is "ON", increasing the throttle will increase the amount of regen.
Grinfineon controller regen chart




(courtesy of BJ: via email 05/08/2015 12:37 PM)
Infineon controller output wiring photo

Circuit Board

Photos of Infineon circuit board (via MrBill's website)

Reverse

Enabling reverse on most Infineon style controllers is simply accomplished by ...

Throttle

Testing the throttle

1) Use the "Throttle test" feature of the controller/motor tester.
2) Confirm +5VDC on the power input (Red wire) and open it up to WOT. You should get ~4.2VDV+ on the sense/signal/output (Green, etc.) wire.

Hall Sensors

Testing hall sensors

The smaller Green/Yellow/Blue wires are INPUTS to the controller, from the motor's (typically three) Hall Effect sensors.
1) Use the "Hall sensor test" feature of the controller/motor tester. Rotating the motor by hand, with the test leads clipped on, makes the LED's blink in seuquence.
2) Testing the Hall sensors in the MOTOR:
When Hall sensors are fed +5VDC on the power input (Red wire), the signal/output wires (green, yellow, blue) should alternately go HIGH (+5V) and LOW (0V) when connected to ground (thin Black wire) as the motor is slowly rotated backwards by hand.
3) or, Tutorial on youtube

Programming

 

 

 

 

 

 

 

VESC Controllers (Vedder+ESC)

FlipSky (manufacturer) VESC6.6 Dual (model) controller for driving two BLDC/DC/skateboard motors. This board was damaged in shipment. I removed the clear protective shrinkwrap to allow closer inspection of the board. After doing that, it became obvious that one phase wire filter (electrolytic) capacitor had separated from its solder pad connections and was simply rolling around on the board.
vesc_controller_6-6_dual_flipsky_humpty-dumpty_photo

The presence of two plastic connector sockets right next to the positive terminal of the capacitor prevented me from getting heat to the pad for resoldering it. After consulting with an EE, it was determined that using short wires to reattach the cap was likely to work well enough. I used 26AWG silicone wire to make the repair:
vesc_controller_6-6_dual_flipsky_repair_photo

vesc_controller_6-6_dual_flipsky_photo

In addition to the main VESC board, vendors typically supply a M-M "servo" cable to connect the VESC to a "receiver". This Receiver receives the 2.4 GHz radio transmissions from a remote throttle and translates them into a pulse position modulated ("PPM") signal the VESC uses to control the motor(s). For skateboard use, these remote throttles are typically hand-held units. This particular VESC model also has hardwired red, black, and white cables terminated with a Female IDS (0.1") connector. This allows the direct connection of an ebike type throttle when the VESC is properly configured ("ADC" vs "PPM", see below).

The following photo shows the testbench setup for programming and testing the VESC controller, with two generic black BLDC skateboard motors. Note the blue "power" LEDs, and the green activity LEDs (left one partially visible under a black cable), showing a properly functioning "dual" VESC. This was shortly after the repairs to the board were finished. The laptop screen shows the VESC-TOOL app open, with the successful results of having "detected" both of the BLDC motors.
vesc_controller_and_bldc_skateboard_motor_testbench_photo

VESC Controller Throttle Input

Typical motor controllers for ebikes and small electric vehicles are designed to connect to either a resistance (5-10K potentiometer) or a Hall-effect throttle to vary the motor's speed and braking torque (if supported). In both of these cases the throttle signal is a simple DC voltage which ranges from about .85V for no throttle to about 4.2V for full throttle. Since this voltage change occurs with no steps or "sampling", it is described as being "analog".

Motor controllers for radio control ("RC") applications are known as "electronic speed controllers" (ESC) and are designed to connect to RC "receivers" which supply a 1ms pulse for no throttle (0 volts) and a 2ms pulse for full throttle (4.* volts). Note that a "neutral" throttle position is 1.5ms pulse, or halfway between no throttle and full throttle. If configured this way, the motor/vehicle would be "coasting"; neither braking nor accelerating. This "Pulse Position Modulation" (PPM) signal is considered to be a "digital" signal. This shouldn't be confused with the similar "Pulse Width Modulation" (PWM) protocol which can also be used for motor control. The likely reason for using a digital protocol is that in the RC world the throttle signal is sent via radio waves (hence "radio|remote control", or RC), and that can be more easily done if the signal is already digitized. See the following diagram for a pictorial representation of the difference (courtesy of the internet).

Comparison of "ADC" (analog) and "PPM" (digital) throttle signals:
ebike_throttle_vs_esc_throttle_photo

The consequence of this analog/digital difference in the throttle signals expected by the two different controller types is that using an analog throttle with a VESC requires an analog-to-digital ("ADC") conversion. For our purposes here we're assuming that on the VESC controller we're using this ADC function is handled on the controller hardware itself, and can simply be activated via a software setting. If this were not the case, a separate ADC device would need to be installed between the ebike throttle and the VESC controller.

 

VESC Controller Failures

 

Red LED flashing 3x pattern & FAULT_CODE_DRV

This condition arose while using a FlipSky VESC 6.6 controller with two generic BLDC skateboard motors. Using the VESC TOOL app (revised replacement for "BLDC-Tool") on a Win PC laptop, the app and controller successfully did an autotune ("detect") of both motors. Both sections of the VESC dual controller had steady blue and green LEDs lit, with no red LED activity. The green LED would flicker when data was being transferred to or from the controller.

VESC TOOL screen showing successful "detection" of motors
vesc_autotune_success_two_generic_bldc_skateboard_motors_photo

After attempting some more software configuration to use a 5K pot (basic ebike resistance throttle) as a throttle, both sections of the dual controller began to display flashing red LED's in a pattern of three flashes ON, followed by a slight pause (OFF state). The VESC TOOL debugging console then also showed the FAULT_CODE_DRV error code.

I started doing some research here to figure out what the red LED 3x blink pattern and FAULT_CODE_DRV error code in the Debug window of the VESC TOOL means. It's obvious that this error condition goes back to at least 2015 and affects all variants of the VESC hardware, whether they are DIY, manufactured by founder Benjamin Vedder, or manufactured by third parties such as the VESC here, made by FlipSky of China.

Unfortunately this combination of red LED flashing 3x combined with a FAULT_CODE_DRV error in the app's terminal output is not uncommon, and can be caused by a wide variety of issues. On the simple side, some have reported this error condition after just failing to enter the correct battery voltage value into the app during configuration of the VESC. Some have had the error condition occur apparently 'out of the blue', and have not gotten any answers after posting online. See this post at vesc-project.com for an example in which the poster said "The fault only happens when using the remote but then goes away." This 2018 post had not yet received any response by 2020. Frequently posters get a response that their (often brand new) VESCs are now "expensive paperweights", even though that's probably not true in many of these cases. Sometimes one respondent to a post tells the poster his VESC is "bricked", while the next poster asks one more question, and based on the original poster's reply provides a simple solution to the problem.

Even though this brand new VESC was damaged in shipment, it clearly worked *once* (after the obvious repair of the broken-off capacitor) to detect two motors while on the testbench. These motors were unloaded (no resistance on the shafts), not hot, and run on 6S/24 volts, which is in the middle of the voltage range acceptable to the VESC's components. There was no magic smoke or visible signs of component damage, so at this stage a software glitch is still the likely suspect. Vedder, the projects founder, does say that the DRV8302 MOSFET driver chip used in this design is not very robust, so a failed chip remains a possibility. I don't think this is so, however, because for a brief time the #2 side of the dual VESC board booted without the blinking red LED, after I did a number of 'resets' to default conditions and reloaded the firmware using the VESC Tools app.

Debugging VESC Failures

One method for spotting a VESC failure is observing the three LEDs on each single VESC. If a red LED flashes after the VESC finishes booting, an error condition is likely. Another method involves querying the firmware loaded onto each VESC's main logic chip, an STM 32 microprocessor. It will answer queries sent to it by the VESC Tool app. In the Terminal window, sending the command "fault" or "faults" will return the text versions of the error code(s). If for some reason it's no longer possible to boot the VESC, it may be necessary to intall a new bootloader using the STM32 ST-LINK utility and programming tool.

See also this post at vesc-project.com for another example of the same issues we're having here. The pattern is that everything was working fine during bench testing, but then the dreaded red LED 3x flashing appears, along with the FAULT_CODE_DRV error code in the terminal window of the app. In this example the poster's problem also mirrors ours in that the detection process measures the motors' milliHenry induction (L) ok, but fails to measure the resistance (R). Problems typically appear in FOC (field oriented control) mode, and some users have said that they could get it to work in BLDC mode while it was continuing to fail in FOC.
The posted "solution" to this problem was the common suggestion to replace the MOSFET driver chip:

The more time one spends looking for answers to this VESC error issue, the more obvious it becomes that "it's a thing". The following link points to another example of the same type of error, this time with the same model VESC as we are testing here.
forum.esk8.news/t/flipsky-fsesc-6-6-dual-plus-issues/11119 October 2019
As a test I'd suggest you lower the battery amps to 30 and see if there errors still occur. Lots of these errors are phantoms using earlier VESC further revisions on FlipSky & Maytech VESCs.
If the errors still occur try loading the Ackmaniac firmware and see if it still happens.
...
In my experience with the FlipSky 4.20s anything over 50a is gonna cause problems. I haven't used the 6s so cannot do other than theorize.

Possible FAULT_CODE_* error messages generated by VESC-TOOL: [vesc_tool/datatypes.h]

 

 

 

VESCŪ Tool 2.02

This is the revised open source replacement for the "BLDC-Tool" app designed to program the VESC hardware controllers developed by Swedish Benjamin Vedder. It will read and write the configurable parameters of the VESC's onboard 32 bit microcontroller/logic/CPU chip, as well as allowing the uploading of new firmware to the VESC hardware. It also is a GUI tool to manage all of the parameters, and allow configurations to be backed up to external files using the standard XML format for storing the settings. The logic chip on the VESC board has an internal bootloader which allows the VESC Tool to connect to it via a USB cable. Without a functioning bootloader, the VESC logic chip must be programmed using a separate external tool designed for the purpose, such as the STM32 ST-LINK utility and programming tool.

Tringa is using this path to store backup configuration files:
"T:\ebike\controllers\vesc", where drive letter "T:" is mapped to "wanda2:/data".

Photo of the app's main screen, running on a Windows 10 OS. The small popup window suggests updating the firmware on the VESC hardware. Since the app will probably be updated more often than the VESC, this popup is likely to be seen every time a new version of the app is installed and used to program a VESC.
vesc_tool_app_main_screen_photo

The following is a sample from an XML formatted data file used by the VESC TOOL app to store configuration data for backup and restore purposes.

 

 

Online resources for VESC programming tips:

 

 

 

References


 

 

 

 

 

Return to Top of Page
Return to Main Menu