CAN bus - Applications in eSk8

Topic for CAN bus discussion.

Purpose of thread is to capture our collective knowledge of CAN bus usage and implementation in eSk8 applications.

The CAN standard was born in the automotive industry to reduce the complex wiring in vehicles and is part of the OBD2 standard.

I’ll maintain this post and update it as information is shared as to create a community resource.

Beginner’s Primer
Sparkfun YouTube CAN bus explainer

eSk8 implementations
All VESC’s - non standard use case for slave/master ESC syncing


I’ll start by asking… What specification of CAN is being used in most applications?

High speed (v2) or Low speed fault tolerant (v3)?

Also what’s the potential for a bus to be used to turn on and off things like head and tail lights etc?

Can telemetry be broadcast from the BMS and VESC in messages and collected by raspberry pi with its own CAN interface…


My question is this. If can bus is a network, how do you connect more than 2 things together? I get connecting 2 vescs using one pair of wires but what about more devices?

As I send this I know I should just look it up on google, and I probably will, but that could a be a rabbit hole

1 Like

VESC runs CAN bus…

Edit: DieBMS too


As far as I understand devices with a CAN interface just connect to a twisted pair ‘bus’… The protocol handles the communication on that bus of which I’m only just learning about and works on a message based system…

Question is what version is the one being used in esk8? High speed? Or Low speed?

Because this difference changes the bus configuration from a straight bus with end node resistors to more of a ad hoc system where devices are end nodes…

I’ve seen posts about L (low) and H (High) which alludes to the high speed implementation

CAN requires a very well structured design that follows strict standards to operate properly, from transient protection, ensuring proper termination resistances at the ends of a network, and the handling of EMI.

CAN has no place in esk8 except in the most thoroughly designed prefab boards.
Its flexibility arises in that it can be adapted to any well structured design, not from being whacked in any which way in the comparative hodgepodges that are diy or small production run boards.
Maybe fault-tolerant CAN could work but that is honestly pushing the specification.

I2C has significantly less strict standards and is better suited for esk8, ebikes, escooters.

You could make CAN work for esk8, but that’s placing a significant burden on the user to set up the network properly, and is made even harder by the fact that the VESC, the most popular ESC for esk8, fails to implement CAN properly.

1 Like

oh snap!

Hallo, mr. mishrasubhransu hath invited me to this conversation and I believe I can answer some questions. I can also start a parallel topic here (the website in general) in regards to the reverse engineering effort on esk8 builders.

So, CAN bus is extremely versatile provided you follow the required physical structure which consists of a twisted pair wire line with your nodes branching off of it (I can get into more detail on the limitations if asked) and a 120 ohm terminating resistor on each end, this can also tell you if you have problems if your bus resistance is anything other than 60 ohms (when the system is powered off).

From what I understand in terms of the history of using CAN in esk8 applications is vedder brought it onto the scene with the vesc, not immediately for direct control, but for controlling multiple vescs with the master designated vesc handling the signal communication to the operator.

I’ll say this right now, using I2C for vital controls is a problem if it’s done anywhere outside a circuit board. I2C stands for Inter-Circuit Communication, it consists of a clock and data line, that data line at long distances (more than a few inches) is very vulnerable to interference with practically no physical layer protection unless you intentionally shield it. As everyone’s familiar, the nunchuck is I2C, I hope I’m the only one familiar with the frequent communication dropouts of the Nyko Kama that would cause the vesc to go full throttle for a second.

As for the bus speed and hardware, the vesc uses hardware compliant with the CAN V2.0B standard, meaning it is the higher speed, overall better version. My testing has been done at 500k and if I set it to anything else, I wouldn’t read it so lets assume that’s the default operating speed. I would also assume that other peripherals made for esk8 CAN also likely use that speed, however modern automotive sensors and components use 250k outside of the engine, so just keep in mind what you’re connecting to what.

To the lighting question, if you want to control a shit ton of lights but don’t have enough IO through the vesc, you can make a dedicated lighting controller that’s connected via CAN bus and command it through that or use that as the receiver node and pass along the vesc commands via CAN. It’s probably not doing on a skateboard scale, but the automotive world puts controllers in individual modules like lights n shit so you don’t have a massive wiring harness, thing with lights on a skateboard is the lights typically don’t get big enough to warrant a dedicated controller on them. There’s another protocol called LIN bus, but I’m not touching that unless it becomes more relevant.

As for the setup question, the main issue is if someone mapped out the entire message structure, it hasn’t been shared which is why I’ve started trying to reverse engineer it myself. There’s a lot of freedom with what messages you can send in the CAN bus, but at this scale, any control you want over CAN bus has to be done with controllers you made, this was a common problem back in the day when I was using CAN on drones for research, any module we wanted off-the-shelf was made for a car or construction vehicle, meaning it was massive and heavy. There’s also the issue of the freedom, you need to have a bit of knowledge with how CAN is packed and unpacked and reading datasheets of other devices for pretty much any application that is completely custom (ie anything outside of pairing vescs together), unless you make a system that’s plug and play and sell enough that it becomes the standard everyone builds too.

Any other questions please feel free to ask!


Were you using a wireless nunchuck? I used a wired nunchuck on one of my builds for a while back and never had an issue, wireless, not so much. I see i2c used for industrial controls and remote sensors and the only problem they had there was parasitic wire capacitance. I’m guessing they were using shielded cables. A proper CAN setup requires shielded twisted pair, anyways.

If any sort of CAN is going to be used, it needs to be fault-tolerant CAN. The specification has more lenient requirements, including supporting a range of termination resistances and network configurations. It may be lower speed, but better than excessive bit-errors.

I’m guessing the reason why you are having ao much trouble finding information on the VESC CAN message structure is because there is none; the VESC uses CAN as if it were UART. The blog posts on the UART message structure should prove helpful.

This is why I don’t think CAN should be used in esk8, unless a controller with a proper implementation of CAN exists, but even then properly setting up the network, even between intentionally compatible devices, places significant burden on the user.

CAN is not a plug and play communication bus; fault-tolerant CAN gets somewhat close.
I2C is more plug and play, I used it in robotics as well and the issue was never with the I2C.
Yes, I know CAN is used in FRC, but they place very strict reatrictions on the hardware you can use.

Thanks @ZFreaky for that write up… Good to get that background and @Gamer43 I appreciate your concern in questioning if CAN is fit for purpose or if at all.

It seems clear that Vedders use of CAN is to support high speed pinging of the slave from the master ESC to sync their operation. This is in itself fine but means that we can’t share that bus for general use. A) writing a message that interferes with the ESC messages is probably not good but B) messages that are written by other devices will be overwritten by the Master ESC on that bus. This is a bit of an assumption but seems logical from what I understand about the standard.

Basically in other words we need another bus to support interdevice comms and like @Gamer43 suggests probably should be the low speed fault tolerant version… I think they do dual buses in vehicles anyways… One for the engine and another for entertainment or accessories… So this would make alot of sense, albeit overkill, in a skateboard.

Dual CAN shields exist for arduino and raspberry… So in practice using one bus to receive messages from the master ESC and the other for connecting to the ‘accesories’ fault tolerant bus could be a solution. And this setup allows for a skateboard wide monitoring via a arduino/raspberry pi…

Thinking about renaming this thread either to:

Communications - The CAN bus


Communication protocols in eSk8

This thought is around having other threads dedicated to other protocols following a similar naming theme like:

Communications - the UART

Or just turn this thread into a general comms research thread. Personally I’m for the former.

Thing is, industrial environments are relatively sterile compared to automotive applications, ultimately CAN wins out in that field, skateboards are more akin to mobile machines than a factory machine, and it doesn’t really need a shield unless you start pushing faster than 1 megabit per second, which I’ve never seen my applications hit more than 30% utilization at that speed, the vesc runs at 500k by default. To what degree of “plug and play” are you looking for? Most esk8 builders aren’t making controller networks in general. I2C would lower hardware requirements, but you’re still talking address and message management for every single controller in a given network, that’s already a massive burden to any given user not well-versed in embedded systems. In my context I was saying you could potentially make a system that worked well and was popular enough to the point that other people started building toward it as a standard. Also, correct me if I’m wrong, I believe I2C addresses are static on certain devices, meaning if you want more than one of said device operating, you’d need to employ more hardware for chip selection, or sacrifice a byte in your payload for additional indexing. Pretty much all CAN devices (primarily J1939) have provisions for changing the source address.

Yes, CAN does have a bigger integration hurdle at this device size, however the prevalence in the automotive as J1939 and even aerospace as ARINC Spec 825 should show how well adopted it is as the preferred communication protocol, which also hints to a very large, very experienced support base if the interest blossoms.

@Gamer43 as it appears you have quite a bit if knowledge in this area maybe you can answer my question-

If I have a dual vesc connected via can-bus internally is there any issue with leaving it connected while running a uart remote using a split connection(flipsky vx1 see pic below)

What about the length of the bus cable? Any best practices? I read twisted? Should I twist them in my 4wd setup?

1 Like

Afaik, a canbus can be more than 100 m long. But @klaus79856 can tell you more than I could ever do.

Sorry for lateness. Yes, the physical layer needs a twisted pair connection, each end gets a 120ohm terminating resistor which is built into the vescs by default. Ideally the two others in a awd setup need to be drops in between the terminations, with their resistors removed so the sum of the bus resistance when powered off is 60ohms.

1 Like

hmm, I’ll check this in detail, a quick measure gave me 60 Ohms on the free port of the Dual MakerX mini. CAN is working but the termination stuff might make it rock solid :slight_smile:

I think that CAN bus is designed to handle the vast majority of tasks that we have been hacking UART ports to handle. It fixes issues with forwarding VESC command because it’s already sitting on the CAN bus, it allows easy communications with an arbitrarily large number of additional devices. No more UART splitter shenanigans. Want to add a smart BMS? Can bus. Lighting controller? Can bus. Onboard LCD display? Can bus.

It’s already on our ESCs, it already does everything we need. We just need to start utilizing it.


Before using it, we need to write standard up.
VESCs use their own way to speak, so as the DieBieMS.
With @janpom and @SimosMCmuffin we talked about this and I started to write something up (here).
I’d be great if someone could jump into this work as I’m not this-stuff engineer.

Once this protocol will be well defined, we’ll see more and more engineers designing accessories that can hook up each others.