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.
Infineon "K" Series Many of the 'generic chinese' Infineon controllers fall into this category..
JPods BaseBoard Notes for the "BaseBoard" PC board developed by JPods as a master control board for bogies.
VESC Controllers This section documents the ESC controllers developed by Benjamin Vedder ("V"+ESC) of Sweden and open-sourced.
Controller Resources Links to a variety of aids to better understanding motor controllers.







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

Return to Top of Page


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.

Return to Top of Page

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.


Return to Top of Page






Infineon - "K" Series

This covers the somewhat generic version of the chinese made "K" series Infineon controllers. These will mate with the K* LED displays that provide the functionality of a bike computer in addition to the electrical info such as battery levels. The main distinction between all of these generic infineon controllers is that the ones rated for higher power levels will have more MOSFETs (e.g., 12 vs 6), and those for higher voltages (e.g. 48V vs 36V) will use electrolytic smoothing capacitors with correspondingly higher ratings. Knowing this, if you end up with a controller without proper labeling, you can make some reasonable assumptions about its design specifactions. The higher quality controllers will use MOSFETs that are more reliable and efficient.

The photos here are courtesy of the russian website . Just search the site for "Ќонтроллер Infineon" -- where the cyrillic (russian) sript is translated as "Controller". [ Ќонтроллер] If, in the unlikely event you aren't fluent in Russian, you can resort to the google translate feature and experience the current state of AI skills.


The part of the controller's main board seen above shows the ports where the five programming cables (red, green, black, yellow, and blue) are attached.

The schematic below shows the proper wire connections in the USB cable end connected to the computer when programming the "K" and other Infineon controllers. As is common with serial communications between a device and a computer, the blue transmit (TXD/TX) and yellow receive (RXD/RD) signals are crossed, while the red 5VDC+ power and black ground wires go straight through.

Note that the yellow RX/receive and the green SDA signals are jumpered on the controller side in the programming cable. By convention we have used JST-SM-5(M/F) connectors to allow the removal of the programming cable when not required. The on/off switch in the power line of the programming cable is optional. The programming software used is the "XPD" app.

This shows the JST-SM-5 male plug as it would be attached to the controller. These wires simply correspond to those shown above attached to the controller's PCB.

This shows the mating JST-SM-5 female connector used to connect the programming cable to the controller. Both the crossing of the TX/RX lines and the SDA jumpering occur here. The USB plug going into the computer also shows a USB-TTL (Serial) UART converter attached inline. This is also a generic part and usually works fine as long as the computer's OS has the right driver installed. If the computer 'recognizes' the programming cable when plugged in and matches it to an available "COM" port, you're usually good-to-go.

Return to Top of Page






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

Return to Top of Page

(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









JPods "BaseBoard"

This is the original "bucket-of-electronics" version of the JPods BaseBoard bogie controller. Probably should have used genuine TupperWare for greater reliability.

Moving towards a real PCB: the breadboard version of the JPods BaseBoard bogie controller.





BaseBoard Rev 1.0

This is the populated version 1 (2019/2020) of the JPods "BaseBoard" designed by Bill James and Denny Fox. This PC board replaces the breadboard plus Arduino combination (seen above) used for early bogie prototypes. This board was designed to improve the reliability of the various input connections, to prevent misconnections, and to reduce the cluttered look of point-to-point wiring. The edge connectors used are 2,3, and 4 pin Molex type male headers using 2.00mm spacing (compare to the JST-PH connector family). The board could optionally be assembled with any other 2.00mm pin spacing connectors with a compatible footprint. The advantages of the Molex connectors are that they are both keyed and locking, and are also widely available. Additionally, there are two pads (one labeled "P2") for the Lolin D32 I2C bus that are 4 position, 2.00mm pin spacing. These pads can be populated with either JST-PH-M4 or Grove 4 pin PCB connectors to provide access to that I2C bus. Pay attention to the current requirements of any sensors placed on that 3.3V Vcc bus.

Note the unpopulated dual row of holes ("U1") to the left of the Lolin D32/ESP32 for the optional Raspberry Pi Zero mounted on its edge via a right-angle connector. There were several errors in this board's design which required some minor modifications, which were manually done on this board and would be visible from the bottom side of the PCB. Also, some resistor values might need to be modified. This original board, as well as Rev 1.4, were designed using Eagle and manufactured by Seeed Studios in China. As it turns out, Rev 1.4, the "fixed version", also needs some modification to the board. This newer board is available as of June 2020. A ready way to distinguish the boards is to look in the top left corner. If connector "P2" is found there, it is the original board, as seen here. If the connector in that position is labeled "P3", it is the newer Rev 1.4 board.

The socket for the ESP32 module consist of 4x8 IDE (0.1"/2.54mm) headers shown here. Unfortunately, joining the two 8 pin headers on each socket side, instead of using a single 16 pin header socket, leaves an excessive pin gap, requiring the header pins on the ESP32 module to be distorted in order to fit.

Detail of the D32 module on the Rev 1.0 schematic, showing the mislabeled ENABLE port.

Another view showing part of the schematic annotated with repair notes, and the bottom of the Rev 1.0 board with a blue wire reconstructing the GPIO13/UREAR net after disconnecting it from the ENABLE pad.







BaseBoard Rev 1.4

The following photo shows the TOP view of the Rev 1.4 BaseBoard, highlighting the mis-routed trace from the D32 ENABLE pin (#P14, third from the bottom) to a VIA near the center of the board. The net name for this trace is UREAR, for "ultrasonic rear sensor". This UREAR trace should instead be routed from the D32's GPIO13 pin, located fourth from the bottom, or immediately *above* the ENABLE pin. This mis-routed trace continues from the VIA in the center of the board, to a trace on the bottom of the board which then goes to the left through-hole of R3 (also highlighted, near silkscreen label "JP5"). From there it goes straight up to pin #3 of X5 (UREAR connector labeled "US Rear"), and finishes its run downwards to the right side of resistor R4. Both of these last two traces are located on the top of the board and should be left intact.

The repair for this version of the board is to cut the ENABLE trace just to the right of the square solder pad, before the trace turns northeast to the VIA.

This shows the top of the board with the ENABLE trace cut. The copper trace is actually the lighter green stripe *between* the two darker stripes. This cut could have been much smaller/shorter, and here we see some of the surrounding copper ground fill exposed unnecessarily. Use a continuity meter (part of DMM function) to verify that there is no longer any continuity between the ENABLE pad and the left side of R3. The solder blob on the pad above the ENABLE pin is part of the second repair, detailed below.

The second repair that must be made to the Rev 1.4 board is to attach that part of the circuit ("UREAR") removed from the ENABLE pin to the pad above it, the GPIO13 pin. The ideal repair would have a wire running directly from the existing VIA for that circuit to the GPIO13 pad, but I was not able to get an AWG30 solid wire into the VIA without risking a short/bridge to the surrounding ground fill. I opted to run a longer wire from the GPIO13 pin immediately above the ENABLE pin (lower right of photo) to the left side of resistor R3 (upper left of photo). Both points were easy to solder to reliably. To avoid interfering with the D32 socket header on the top side of the board, I ran this patch wire on the bottom side of the board, as seen below.



Return to Top of Page






VESC Controllers (Vedder+ESC)

FlipSky is the manufacturer of the VESC6.6 Dual controller boards that we are using for driving the BLDC skateboard hubmotors in this project. The following photo shows the actual controller as delivered from the factory, with the supplied connector pinout sheet in the background. Some users just cut openings in the shrinkwrap to allow the necessary cable connections. While this adds physical protection to the board and its components, it also restricts the necessary cooling air flow over the parts and the solid aluminum heatsink the board is fastened to. There is thermal tape directly under the heat-producing MOSFETs to help cool them. Make sure that this heatsink is not trapped in dead air space.

This is the "manual" from the Flipsky website. Follow this link for more information, including videos.

Return to Top of Page

Damaged Controller

This particular controller 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:


Return to Top of Page

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 motor's 5 pin JST-PH-5F(emale) connector to properly mate with the JST-PH-6M(ale) connector on the controller.
This shows the factory supplied adapter cable which doesn't solve our connection problem. While the 6 pin JST-PH-6F connector going to the controller board is correct, the 6 pin JST-ZH-6M connector does NOT mate with the five pin JST-PH-5F coming from the motor. Both the pin count (5 vs. 6) is incompatible, as well as the smaller "ZH" (1.5mm) pin spacing pattern, as opposed to the larger (2.0mm) spacing of the "PH" connector series. It can be made to work, however, by removing the JST-PH-6F housing from the adapter cable and swapping it out with the JST-PH-5F housing on the motor's sensor wire bundle.

Return to Top of Page

VESC (Dual) Controller Throttle Input

Typical motor controllers for ebikes and small electric vehicles are designed to connect to either a variable resistance, such as a 5-10K potentiometer ("pot"), 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 0V for max regen braking, 0.85V for no throttle ("neutral"), to about 4.2V for full throttle ("floored"). Since this voltage change occurs with no pulses or steps("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 send the controller a 1/1,000 second (microsecond, "ms") long pulse for no throttle and a 2ms pulse for full throttle. 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 with a neutral throttle setting 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.

This model FlipSky VESC6 Dual controller comes from the factory with an approximately 10 inch long three-wire (red, black, and white) "Receiver" cable. Go to the controller photo above, connector #7 labeled "PPM + UART", to see this Receiver/PPM wire and plug. The three wires are terminated with a female IDC/duPont (0.1") connector to plug the VESC into a radio "receiver". The intended type of receiver utilizes the 2.4 GHz radio band transmissions from a remote throttle transmitter and translates them into a pulse position modulated ("PPM") signal the VESC uses to control the motor(s). Note that if you use certain receivers designed for the RC "hobby" world, their male pin sockets expect the controller IDC plug to have slightly beveled corners, preventing incorrect insertion. For skateboard use, these remote throttles are typically small hand-held units working on a single channel. The firmware on the controller must be properly configured for "PPM", as opposed to "ADC", input.

Do NOT be tempted to connect any kind of potentiometer or ebike type analog throttle to this three wire PPM plug! As they say, "Don't ask me how I know this". While the smoke that comes out doesn't smell as bad a burning electrolytic capacitor, it is still smoke.

Note that these three wires are simply soldered on the underside of the board to their corresponding header socket pins (black=negative, red=5VDC positive, white=PPM signal), and are extremely prone to being broken off. It may be a better idea to utilize a custom made cable that plugs into the standard 0.1"/IDE header on the top of the board. To use an ADC (analog) throttle, we'd connect it to one of the ADC sockets on the controller via a JST-PH-8F plug, populating just those positions we'd need, such as ADC1 for the signal, 3.3V positive for Vcc, and the negative/ground/common wire.

Return to Top of Page

Below we see the controller testbench shown with a stock dual-axis "joystick", harvested from an old, non-functioning RC 'hobby' airplane transceiver. Only the "throttle" axis is being used here, connected via an inline JST-SM three conductor plug pair. Two wires are for the +3.3VDC and Ground, while the third is the throttle 'signal' wire. The source current is supplied by the controller. Note that the input voltage in this case is 3.3 volts, but in the typical ebike world this would be 5 volts, but it's really up to the controller to determine this.
To use this type of throttle, the VESC dual controller is programmed to accept a single analog ("ADC") input , since this joystick is the functional equivalent of a 5K pot configured as a voltage divider. However, if we use the *other* axis on this joystick (typically mapped to control the ailerons of an airplane), we get a voltage divider with a center detent (neutral') position. This allows us to map a single throttle control to provide both positive and negative going signals. This provides the additional functionality of having the bogie being able to go forwards and backwards, or using regenerative proportional braking, all with a single control input. This capability is made possible by the firmware built into the VESC controller.

Return to Top of Page




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]

Return to Top of Page




VESCŪ Tool 2.0*

This is the revised open source replacement for the "BLDC-Tool" app designed to program the VESC hardware controllers developed by Swedish Benjamin Vedder. A big THANK YOU to Benjamin, since he has been working on this project as a labor of love. The VESC-TOOL 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. The dual VESCs from FlipSky that we're using all come with a working bootloader (so far!).

Downloading the 'free' version of this open-source software entails going to the website and picking your way through a series of counterintuitive and obtuse steps involving the creation of an "account", filling a "shopping cart", obtaining a code, optionally printing an "invoice", and finally (at least in my case) struggling to find the actual DOWNLOAD LINK for the software. Maybe there's something lost in the translation. When a new version of the software becomes available, it's rinse and repeat (except for the new account creation). After some googling (and finding that I'm not the only one unable to find "the download link") I discovered that the secret is to CHECK YOUR EMAIL! The appropriate links for the different OS versions of the VESC-TOOL are there for you to use. One of the emails sent to your address will contain a link to a zip file, which when unzipped will yield the VESC-TOOL executable -- which is the only file in the zip container. Once that's done, things return to normal and you simply run the app and follow its prompts.

[Note: There may be another direct download option via links on github. I didn't explore that route - yet.]

If you want to watch a youtube video that covers this entire process very well, watch this one: I'd actually give it a "like" if it didn't have the obnoxiously annoying background 'music'. Even with that, the voice-over is understandable and informative.

Photo of the app's main screen, running on a Windows 10 OS. The small popup window shows that this version has been updated from the 2.02 version to 2.06 (done July 3, 2020).


This popup window, encountered when connecting a VESCŪ controller, suggests updating the firmware on the VESC hardware. Since the VESC-TOOL software will likely be updated more often than the VESC hardware connected, this popup is likely to be seen every time a new version of the app is installed and used to program a VESC. Upgrading the hardware's existing firmware is entirely optional, unless...
vesc_tool_old-firmware_popup_photo's not! Here we're using the tool's SETUP wizard to modify the settings for a dual VESC controller programmed with an earlier (2.02) version of the VESC-TOOL.

Return to Top of Page



Updating Controller Firmware

After selecting the "Firmware" option on the left-side menu (hand-drawn blue arrow), we see this screen. It shows that the currently loaded firmware is version 4.1, which was installed using a previous version of the VESC-TOOL. We will be updating both halves of the dual controller at the same time, so we'll select the "All" button (hand-drawn yellow hi-liter). Both green LEDs on the dual controller should be blinking rapidly during uploading/writing process.

After a successful write, the following popup warns you to wait 10 seconds before powering down the controller. Note that the controller has been automatically "disconnected" from the VESC-TOOL software after the firmware update process, and the upload progress bar will say "Upload Done". After this step, I would recommend leaving the controller connected to the computer via the USB cable, but powering it down for at least a few seconds, and then powering it back up -- basically "rebooting" the controller to confirm that the new firmware is working. Select the "Connection" menu item from the left side of the screen, and reconnect the controller to the VESC-TOOL app by clicking on the "Autoconnect wizard" bar located near the bottom of the screen.

Go back to the Firmware screen using that menu option and verify that the loaded firmware is now a newer (higher) version number. The following screen snippet shows that the same generation of controller hardware ("Hw: 60") has now been upgraded from version 4.1 to version 5.1. Apparently the "hardware" (referring to the controller itself) version of "60" correlates to the "6.6" version of the VESC.

This screen portion shows a fairly recently purchased VESC 6.6, using hardware version "60", that was shipped with firmware version "3.62". When first connected to the VESC-TOOL app, it causes the app to display a popup screen (see above) that says that the firmware is old but largely compatible with the current feature set. It's considered to be good practice to update the controller's firmware to the most recent version available in the updated VESC-TOOL app that you are using. This controller was also upgraded to version 5.1, after this screenshot was taken.




Motor Detection

[todo: Add motor detection screens!] Note: remember to write motor configuration updates to controller -- icon menu, right side of screen

To make sure that the detection process doesn't overpower the motor, select the proper size of the motor being detected. Most 'skateboard' motors will fall into the "Medium Outrunner - 750 gram" category.

Return to Top of Page




Input Setup

After getting a new controller or completing any new firmware upload to an existing controller, its input parameters need to (re)matched to the input hardware -- typically a "throttle" -- being used with that controller. To do this, the controller must be connected to the VESC-TOOL app, as well as whatever input device will be used. The motors (assuming a dual controller) to be controlled should also be attached in order to fully test the new configuration.

To enter the Input Setup screen, select the "Welcome & Wizards" menu item located in the top left of the main screen. From the Wizards screen, select the "Input Setup" wizard button, and follow the intermediate 'help' screens. These intermediate screens include the app scanning the controller to find what it thinks is attached, and how they are configured. When you are configuring a VESCŪ dual controller, one (the 'master') will typically be found to be connected via the USB port while the other is connected via the CANBUS. It doesn't typically matter which is which, as long both are recognized. For our dual-drive skateboard setups, both controllers should be responding to the same input device.


Eventually you will get to this following critical screen, which allows you to select which type of input you will be using to control the motors. During the initial testing and configuration that I did with these controllers and motors, I used a basic 5K potentiometer to simulate a simple analog throttle, similar to those used in the ebike world. For a more complex application, I also used a salvaged joystick control from an old hobby radio controller. This dual axis control employed self-centering pots, each of which allowed a single throttle to control both acceleration and ebraking if so configured in this Input Setup part of the VESC-TOOL. Selecting the "ADC" option from this popup menu screen enables the use of virtually any device which is capable of accepting an either 3.3 or 5 volt source provided by the controller, and 'dividing' that voltage into a value proportional to the amount of 'throttle' applied by the user.


Input using ADC

As soon as the user selects the "ADC input ..." option, the following screen pops up. It is the first "live" screen which shows, in realtime, whether an input device is detected, and where it currently is set. Moving your input device's controls at this screen should be immediately reflected by changed values appearing in the CH1 or CH2 (or both) status bars. Assuming your analog input device is connected on the controller's ADC1 pin, the variable output will appear on CH1, as on the following screen. In this example, I've connected a 5K joystick device which shows a "center" (resting) value of 1.6728 volts (rounded to 1.63 volts). Since this value should be 1/2 of the 3.3 nominal input volts, its being half of 3.3456 volts is actually pretty close to perfect. If the input voltage were exactly 3.3 volts, half of it would be 1.65 volts, which we could arbitrarily select as the "ADC1 Center Voltage", and proceed with testing that value. Once you feel confident that your input device is being properly read by the VESC-TOOL, you "map" your input device values with the values the controller uses to control the motors. If your input device is producting reasonable values, select a throttle control method from the dropdown box labeled "Off" by default and then click the "Apply" button to save your choices in the app. Click the Next button to proceed to the next step in the ADC input configuration process.


The ADC Configuration screen allows the controller to be configured to behave in a manner desired by the user. Remember to write the settings to the controller when all selections have been made. In version 2.06, at least, the only confirmation you get when writing these settings to the controller are very brief blinks of the green 'data' LEDs.

Continuing with this same example, here are some of the configuration choices made:

Current Reverse Center Current control. The output is off when the input is centered. Input less than center brakes until the motor stops, at which point it it starts in the reverse direction.




... and it works. Push lever forward to make bogie go forward; pull back to make it go backwards; let go to make it stop. It's a good idea to power everything down, and then back up, and safely test all features after rebooting -- making sure the wheels are spinning freely in the air during this entire process. You have been warned.


Input using PPM

If you plan on using a 2.4GHz radio system such as those used in hobby "RC" (think model airplanes, etc.) applications, the same INPUT SETUP Wizard can be used to configure your VESC controller. By simply selecting the PPM choice when running the wizard, you'll be presented with the choices relevant to this method of throttle control. For this example I used a Spektrum DX6i transmitter coupled with an AR6200 6 channel receiver, also made by Spektrum. The receiver is connected to, and conveniently powered (5VDC) by the VESC controller via a standard three-wire servo cable. Note that the typical servo cable plugs, while mostly the same as the common 2.54" header ("duPont") plugs, have two of their corners slightly chamfered to fit into the receiver's sockets.

Using this 6-channel combination is largely overkill, since driving the bogies via the VESC controllers really only requires the single throttle "channel". However, such features as e-braking, reverse motion, as well as other functions may be desired for the skateboard bogies, and these multi-channel radio tools could enable those features. Ultimately, of course, all control methods and the associated channels used for the skateboard bogies operating in the network will be based on dedicated microcontrollers running custom firmware. The radios used could utilize any number of frequencies and protocols, including wi-fi, bluetooth, nRF, or - as in the following example - 2.4GHz.

The following screen shows the default values in the basic PPM properties that can be configured. Again, the throttle lever on the radio transmitter must be "mapped" to the controller's expectations. Even though the screen talks about mapping the throttle to the *receiver* (which the part of the radio system mounted to the bogie), the throttle is really on the *transmitter*, which is NOT on the bogie. The receiver simply collects the signal, decodes it, and passes it on the PPM input on the VESC controller board.

Note that in the following screen that the "Current No Reverse with Brake" option has been selected from the PPM Pulselength Mapping dropdown box, and that the green colored bars reflect the "live" movements of the throttle control on the transmitter. Read the very useful built-in help screens in the VESC-TOOL app to find out more about the available options.



Return to Top of Page

Android Phone app Tool

This free software app by FlipSky, is available only for Android OS devices for now (in the middle of 2020). It can be used both to program certain firmware parameters on the VESCŪ controllers, as well as to display certain realtime data sent from the controller.

In addition to the freely downloadable phone app, it requires a Bluetooth module sold by Flipsky for around $10 US. The Bluetooth module is powered by the controller and plugs into the onboard JST-PH-8M "Comm" port, which is also used for connecting analog (ADC) throttles and sensors.

The following shows a functional diagram of how to connect both the Bluetooth module and an ebike type ADC analog throttle to a VESC controller. Apparently all of the Ground connections on these controllers are common, since this official FlipSky diagram shows that either the 3.3 or the 5 volt rails can share the same Ground. Refer to the VESCŪ manual above for the exact pin assignments on the dual Comm ports (connectors #5 and #6 in the manual). On the Dual controllers we use that are constantly connected via an onboard CANBUS link, either COMM port may be used.


Return to Top of Page




Controller Resources

VESC programming tips

Return to Top of Page






Return to Top of Page
Return to Main Menu