ElectricMotorcycleForum.com
Makes And Models => Zero Motorcycles Forum | 2013+ => Topic started by: togo on September 29, 2017, 02:12:04 AM
-
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.
-
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.
-
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.
-
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
-
What? You are claiming downloading the logs killed the motor?
That seems a bit of a stretch.
-
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?
-
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.
-
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
-
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
-
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/
-
I can't believe they stole his knife switch.
-
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!
-
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.
-
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.
-
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.
-
(I've waited a while until I had the time to go look everything up properly before replying to this thread.)
I would summarize the kill switch safety concern as a lack of fail-safe consideration in the design.
Fail-safe principle: https://en.wikipedia.org/wiki/Fail-safe (https://en.wikipedia.org/wiki/Fail-safe)
Any safety mechanism should have fail-safe considerations built in.
For example, the Sevcon Gen4 controllers have switch concepts built in like FS1, deadman, and seat switches.
- FS1 locks out the throttle, and helps implement an interlock when switching between forward and reverse modes.
- A deadman switch to lock out drive mode and engages a brake (which they recommend against for highway vehicles).
- A seat switch can also lock out drive mode / throttle operation.
- Wire-off detection for the throttle which the 2015+ Bitron throttle probably supports more directly than the older
According to https://en.wikipedia.org/wiki/CAN_bus (https://en.wikipedia.org/wiki/CAN_bus), CAN is a serial "multi-master bus", meaning that more than one node must initiate a transfer.
The choice to route the kill switch (and the kickstand switch to a lesser extent) through the MBB means that an MBB deadlock or livelock prevents activation of the interlock.
- The design flaw is in requiring an active element of forwarding a signal from the MBB to the controller.
- The cutout switch should just have been a digital signal to the controller; I can't think of a critical reason for the MBB to be directly in the loop.
- One could argue why not make it sort of a DPDT switch to send signals to both at once in case the MBB needed to react as quickly as the controller, but that does introduce another unnecessary point of failure.
- I'm guessing that Zero engineers felt that the Sevcon couldn't manage the shutdown itself for some reason (where the MBB would have been notified by the controller of the event secondhand).
- Maybe there was a decision based on information we don't have (technical or political), but no real answer is going to be satisfactory.
Now, this is relevant to anything we discuss doing on our Zero's systems!
- As is now clear, downloading logs in drive mode is a heavy batch operation and we can easily advise against this.
- However, the category of live telemetry operations by calling the MBB directly is inherently risky (and I've heard hints about that as a direct experience).
- Complicating matters, we can't test this without putting the bike on a (dyno?) stand and trying polling rates and backoff strategies while trying to operate the bike at various RPMs.
In short, live telemetry will require a careful mix of tuning polling rates against the data volume requested; so more signal values will require a lower polling rate. And it's likely that one would want to batch the requests or something and only let one telemetry app operate at a time (as in: don't run the OEM app concurrently with any other telemetry app).
It just occurred to me that perhaps the instrument cluster only gets sent messages for values it's configured to display. So, it's hypothetically testable that one could reduce the load on the MBB for another telemetry app by selecting values to display on the dash that are configured to update less often. Maybe.
It's rumored that 2017+ model years' MBBs are more robust (with faster CPUs and larger RAM capacities), but running out of buffer or I/O dispatch capacity or such on a small board could still happen. Also, I'm gathering that every year's MBBs have different physical connectors which precludes any reasonable retrofitting for older models.
I have no answers to this, but it seems responsible to spell out the implications. I've updated the MBB section a bit for this:
https://zeromanual.com/index.php/Unofficial_Service_Manual#Main_Bike_Board
-
Only way I know to saturate the bus is to pull logs. I don't know if you can do that while riding, but I would not recommend it anyway. Focus on riding while riding ;)
-
Only way I know to saturate the bus is to pull logs. I don't know if you can do that while riding, but I would not recommend it anyway. Focus on riding while riding ;)
Oh, is that what happens when I try to send BMS logs to email and then it takes forever and then fails? I've never tried to ride while pulling logs, I've only done it when parked and charging. Doing it while riding *does* sound like asking for trouble.
-
I've watched the OBD port while trying to get BMS logs. LOTS of canbus errors.
-
Pulling BMS logs (especially if you have firmware bug that results in ~1 hr download time) can definitely saturate the bus. Generally producing a lot of output over OBD port (logging for example) will result in messed up throttle response. I've experimented a lot with what works and what doesn't and MBB seems to have a concept of signal priority -- eventually it will respond to your inputs and when it does, everything seems to work fine. However if you let it "idle" (no inputs being sent to MBB), there's going to be a delay between your input and how bike reacts, sometimes as big as 1-2 seconds. Do take a note though, during normal usage this isn't something you have to worry about. Bluetooth communication isn't affected by this at all though, that doesn't seem to lock up MBB.
-
Only way I know to saturate the bus is to pull logs. I don't know if you can do that while riding, but I would not recommend it anyway. Focus on riding while riding ;)
Oh, is that what happens when I try to send BMS logs to email and then it takes forever and then fails? I've never tried to ride while pulling logs, I've only done it when parked and charging. Doing it while riding *does* sound like asking for trouble.
There's a theory that a lot of data is being transferred but not written out, especially if you've had any ride-through faults. I may be misunderstanding this it could be a simple bug. However if what I heard applies, then if you have a ride-through fault there's a lot of data that not even the dealer can access, or that is what it sounded like was being explained to me. So having many ride-through faults in this theory would mean a huge quantity of data and making the transfer take a long time.
-
> ... Bluetooth communication isn't affected by this at all though, that doesn't seem to lock up MBB.
That makes a lot of sense, since bluetooth (I think) is a slower protocol.
-
Looks like lower cost Linux-based hardware is now available.
https://copperhilltech.com/blog/lowcost-doityourself-can-bus-to-wifi-bluetooth-ble-usb-rs485-gateway-based-on-raspberry-pi-zero/
-
Looks like lower cost Linux-based hardware is now available.
https://copperhilltech.com/blog/lowcost-doityourself-can-bus-to-wifi-bluetooth-ble-usb-rs485-gateway-based-on-raspberry-pi-zero/
Indeed, now even cheaper.
I was able to successfully control charging units with this setup this past weekend:
1. rasperry pi zero wireless with headers $14, e.g. https://www.adafruit.com/product/3708
2. waveshare rs485 can hat $14, e.g. https://www.waveshare.com/rs485-can-hat.htm
3. high endurance micro-sd card, $11, e.g. https://smile.amazon.com/SanDisk-Endurance-microSDHC-Adapter-Monitoring/dp/B07P14QHB7/
items needed you may already have, no cost assigned:
And of course you need the usual Raspberry Pi
micro-sd cable (you probably have one)
5V 2A+ usb power supply
And to set up for wifi connectivity, etc:
micro-USB OTG keyboard, or OTG adapter and standard keyboard
mini-HDMI connection to a TV or monitor
-
[/quote]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!
[/quote]
https://www.ixxat.com/technologies/all4can/can-news-blog/can-news-blog/2017/09/22/rs485-vs.-can
OK, so I think I can describe more clearly now that I've read that link, that canbus uses RS485-style physical layer, and implements packetization and prioritization and error detection on top of it.