Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[togo]

CANBUS is a digital protocol used between automotive systems

It is used between the Sevcon and the MBB on a Zero, for example, and CrashCash reports success reading it with Raspberry Pi and CopperHill to read e.g. estimated range.[1]  (BEWARE of writing to this bus, it could be harmful to the your vehicle or your life.)

Canbus is also used in charging systems to tell the charger to enable or disable, to tell the charger max amps and max voltage.  I believe the onboard and the diginow and the evtricity and remmie/wijnand71[2] rapid-chargers setup all do this.  The onboard mbb talks to the onboard charger with canbus and the (diginow and r/w and maybe evtricity) use a separate microcontroller module to control the charging.  I think the chargers require a heartbeat signal, and turn off automatically if the microcontroller stops.

Canbus is also used in the signalling between vehicles and stations for Chademo and Tesla Supercharer high voltage DC charging.  (CCS Combo uses ethernet-over-power.)  Tesla is authenticated, you need a Tesla VIN to activate it, but Chademo is potentially decodable.  (flow and diagrams at https://code.google.com/archive/p/open-chademo/ )

Canbus generally requires a 120 ohm resistor at each end of the communication.  I have a seeedstudio canbus shield, which has 120 ohm built in, and also a linksprite one, which has a 60 ohm resistor.  I found that odd, googled around, and found a good discussion of canbus variants and termination:

http://www.keil.com/forum/21024/can-bus-one-60-ohm-instead-of-two-120-ohm-resistors/

There exist a lot of OBD-II products called ELM327 that decode bits of the Canbus traffic, and produce output that can be read by computers and apps.   Those are handy for *car* decoding, resetting trouble codes, which are pretty standard, but not so much for the Zeros or the chargers.  They are even a bit spotty on the electric and hybrid cars.

[1] http://electricmotorcycleforum.com/boards/index.php?topic=6809.0
[2] http://electricmotorcycleforum.com/boards/index.php?topic=6405.msg58759#msg58759
[3] http://electricmotorcycleforum.com/boards/index.php?topic=4690.msg31304#msg31304

So that's about what I know about Canbus so far.  Let's try to get the facts down about canbus in this thread.

And let's be careful out there.

[Shadow]

Couple of observations:

Throttle Disable seems to signal via CANbus and that message can be lost if the bus is saturated. Correct me if my guess is wrong here but I did experience a situation where throttle disable did not have any effect.

Downloading MBB logs via Bluetooth and the Android Zero Motorcycles app will saturate the bus and make a motor controller commissioning procedure fail.

[togo]

Thanks, Shadow, for that observation, based on your own personal experience, I assume.

I imagine saturating the canbus with by downloading mbb logs can cause lost messages
of all kinds and should probably not be done concurrently with other operations.

[DonTom]

IMO, it's an extremely dangerous design to require any type of data to kill a motor on an electric  motorcycle.

Shadow learned this the hard way. I was the one to get the tow truck for him (using my Spot Messenger Tow service) when he broke down near here, with a motor  that would not stop or slow down, no clutch, no neutral, no working kill switch. At least the  key did not require data to shut the bike down. I would hate to think what would have happened if he could not get to the key to shut the bike down.

IMO, on a motorcycle, in many cases, canbus has more disadvantages than advantages. All the advantages are in cheaper design, running a lot less wires. Then come all the limitations  of CANBUS to the buyer.

-Don-  Reno, NV

[togo]

What?  You are claiming downloading the logs killed the motor?

That seems a bit of a stretch.

[anton]

CANBUS is neither advantage nor disadvantage. If the underlying software chokes on amount of data it receives through CANBUS and cannot prioritize events such as kill switch then it's a problem with how that software is written, not CAN itself.

Then come all the limitations  of CANBUS to the buyer.

And what are these limitations exactly?

[Shadow]

What?  You are claiming downloading the logs killed the motor?...

I think Don is commenting on the scary situation of not being able to safetly reduce acceleration from a runaway acceleration condition during a motor encoder or power controller malfunction. Had the contactor somehow fused closed at the same time as the runaway acceleration inccidents I would have most likely had to (best case scenario) have mashed the service brakes to reduce speed and then lay the bike down.

Anyway the bike relies on CANbus so a deeper discussion about whether that is appropriate is wandering a bit off topic.

[DonTom]

What?  You are claiming downloading the logs killed the motor?

That seems a bit of a stretch.

I wasn't clear--sorry-- Shaddow's kill switch did not work. The motor keep running at near full speed after  the kill switch was switched on.  Quite dangerous.

-Don-  Reno, NV

[DonTom]

CANBUS is neither advantage nor disadvantage. If the underlying software chokes on amount of data it receives through CANBUS and cannot prioritize events such as kill switch then it's a problem with how that software is written, not CAN itself.

It seems to me that anything controlled by data has countless ways to go wrong. And  with most software, problems continue to be found, under various conditions that are not apparent at first.

Then come all the limitations  of CANBUS to the buyer. what are these limitations exactly?

Low current limits, speed to get some functions completed, etc.   Canbus is like sharing the time on  a couple of wires for many different functions. And problems can be a lot more difficult to troubleshoot--especially intermittent problems.

The old fashioned way of separate wires for everything doesn't have such limitations. And a lot easier to deal with when something does go wrong.

-Don-  Reno, NV

[togo]

Corbin had an electric motorcycle land speed record back in the day with such a system.

He introduces Richard Hatfield as the guy who took his record away.

https://newatlas.com/mike-corbin-quicksilver-land-speed-electric-motorcycle/46696/

[togo]

I can't believe they stole his knife switch.

[gyrocyclist]

CANBUS is a digital protocol used between automotive systems

 ...

Canbus generally requires a 120 ohm resistor at each end of the communication. 

Good info; thanks!
OK, that said, speaking as a computer scientist I find this a bit confusing. "digital protocol" sounds like: I say ABC to you, you reply BBC to me, I say XYZ, you reply "WTF." On the other hand, a 120 ohm resistor is hardware, which is a specific implementation of a protocol. Could you clarify?  Thanks in advance!

[Doug S]

gyrocyclist, think of it like a TCP/IP stack. There's a PHY layer (the hardware), a low-level driver layer, an "Ethernet" layer, and on up to the application layer, from the most concrete to the most virtual.

If you're an old-timer like me, you'll remember how much trouble "plain ole serial" communication used to cause, with no standardization at all. There were two different flavors (DTE and DCE IIRC), dozens of different connectors, some used flow control and some didn't. And that's just the PHY layer! Then we have to agree if we're going to use N81E or some other settings , Kermit or XMODEM....give me an over-specified protocol any day of the week.

[togo]

Yes, there's a bus, with a physical reality and a digital protocol on top of that.

On the bus, resistors terminate, and there seems to be some variance as to whether and which interfaces do it right.  Lots of canbus adapters are sold on ebay shipped from china that apparently work for talking amongst themselves but don't work in a proper automotive situation.  See the forum discussion linked previously.  This is the side of canbus you see when you are wiring it up.  There's a CAN plus or CAN High wire, and a CAN minus or CAN Low wire, and you may need to add resistors to keep signal from bouncing.

The digital protocol on top of it would be what you work with when you program.  You receive a packet into a buffer and read bytes decode it.  You write bytes into a buffer and send a packet.

So, yeah, both.

[togo]

More about the digital side of the protocol here:

https://hackaday.com/2013/10/22/can-hacking-the-in-vehicle-network/

There's an identifier, indicating what type of message, 11 or 29 bits, followed by a data length, followed by up to 8 bytes of identifier-specific data.