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.







Phaserunner by Grin Technologies

Typical Specs: FOC, up to DC 90 volts, 3,600 watts, 40 amps continuous/90A peak; up to 60,000 eRPM (actual motor RPM x pole pair count

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 in Vancouver, BC; (he prefers email over PM's on;)

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


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:
(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.

In the following photo from November, 2013, you can see the Lyen controller mounted on a board on the rear rack, above the eZee Flatpack 13A/48V traction battery.






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.


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)


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


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









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.

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:


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 IDC (0.1") connector. This allows the direct connection of an ebike type throttle when the VESC is properly configured ("ADC" vs "PPM", see below).

VESC (Dual) Controller Testbenches

To make it easier to test and program the VESC series of controllers, I made two versions of small testbenches that included a jig to hold the controller, mounts for two separate motors, an onboard soft-start ON/OFF switch, and a 6S battery pack to provide portable power.

The following photo shows the testbench setup for programming and testing the VESC dual controller, with two generic black BLDC skateboard motors. Note the two blue "power" LEDs, and the two green activity LEDs (the left one only partially visible under the black USB 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 and determining their electrical characteristics, including whether or not they use positional sensors, and any temperature sensors.

The next photo shows the testbench setup for programming and testing the VESC dual controllers, with two generic direct drive (in-wheel) BLDC skateboard motors. Note that these motors are using Hall sensors, but no temperature sensors. This required adapting the factory-supplied 5 pin connector to properly mate with the JST-PH-6M connector on the controller.

VESC (Dual) 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:

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 the VESC controllers we're using this "ADC" function is handled by the controller hardware itself, and is simply 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.

Also, the "dual" controllers which we are using are capable of controlling two motors via a single throttle. These VESCŪ 6.6 controllers have two identical connectors (#5 & #6) located at the edge of the circuit board. They are 8 pin JST-PH-8M, and each have three analog-to-digital ("ADC1-3") pins on them. Connecting a standard three-wire ebike throttle to 3.3V, GND, and ADC1 on one connector will control both motors, as long as the second motor/VESC is "slaved" to the first VESC via the CANBUS connection built into the dual controller(s). The controller's firmware settings must of course be properly configured using the VESC-TOOL to properly utilize the ADC throttle hardware. These settings include both selecting the correct options as well as calibrating the throttle's minimum and maximum voltages on the signal wire.


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

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 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 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. 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.

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:










Return to Top of Page
Return to Main Menu