Ebike Isolated Serial Bus discussion (focus on CANbus)

Alan B

100 GW
Joined
Sep 11, 2010
Messages
7,809
Location
San Francisco Bay Area, USA
A simple isolated interconnect for communications between modules is useful for many ebike projects. Isolation must be able to handle the voltage range of the ebike battery pack plus noise so that modules can be connected into the battery stack and still communicated with.

Requirements

* simple, low cost and parts count
* standard, commonly available parts
* work with small inexpensive microprocessors, low pin count (1-2 I/O pins)
* isolated to at least 200VDC
* multi master to facilitate more than one master, but most nodes are slave-only
* nodes: one per cell plus 8 so 32 to 48 nodes
* speed requirement?
* data transfer validation (CRC or equivalent)

Candidates, in no particular order

* CANbus
* LINbus
* I2C
* Serial
* ModBus
* One-Wire (MicroLAN)
* EnergyBus (a CANbus variant)

CANBus seems to be a bit complicated for simple stuff, and not inherently isolated. There are isolation chips for CANBus, though it stretches the requirement of commonly available parts. TI ISO1050 is one example of a chip for isolated CANBus, cost about $4, available in SMT only. It has the advantage that it is smaller than a pair of standard optical isolators and requires less power. It uses capacitive coupling for isolation. The software complexity of CANBus is rather high for the smaller chips. One thought might be to use the CANBus driver or isolation hardware but use a simpler software approach. CANBus requires fairly precise clock so is not a good fit for RC timed processors such as the Tiny45/85. update - the CANbus hardware (either in CPU or an external chip) handles the complexity rather nicely and present a simple register or SPI interface to the CPU (see MPC2515). They do require a crystal for timing precision, but that means the CPU doesn't have to be crystal controlled (unless it has internal CAN hardware).

LINbus is a one wire serial automotive bus that requires only a UART (though some processors have LIN hardware). It is a single master synchronous polled bus so there is no need for arbitration. Up to 16 nodes are supported. It is lower cost than CANbus. Optical isolators can be used for isolation. It looks like a good candidate here, though I don't see other projects using it. CANbus has become cheap enough, perhaps.

Isolated I2C presents special difficulties due to the bidirectional nature of the signals, but there exist isolation chips for it as well. One example is the ADuM1250 which requires six passive external components. I2C is generally not multi-master. Chip cost about $6. Clock and data remove precise timing requirement. Clock and data pins required.

Isolated Serial requires a fairly small parts count. One design uses a pair of standard optical couplers, an FET and a couple of resistors. I have not come across any neat chips for this, though they may be out there. Variations on this theme abound such as differential RS422/485, single ended "TTL" levels, and of course higher voltages like RS232. RS232 is not desirable due to the bipolar voltages required.

RS485 is multi-drop and differential, designed for 32 nodes (some implementations go higher) which is adequate. Example chip is ADM2483. May require more than 2 pins on CPU, or may be able to do a direction pin and an I/O pin, or 3 pins with direction, in and out. Another chip IL3185 may be a good choice. The il3285 has lower loading so more nodes are allowed.

ModBus is really a specific protocol to use over serial. Simple and popular. Might be a good choice if Isolated Serial hardware is used. Could this protocol be used over the CANBus isolation chips? There are AVR libraries for ModBus, it might be good to check the memory size of this code.

Isolated One Wire bus may be a bit slow, what are the speed requirements here? Designs for isolation use quite a few parts. Is there an isolation chip out there? Isolation can of course be constructed from optical isolators, the question is how much circuitry does it take?

USB and Ethernet are obvious serial interfaces but their complexity is too high for this application so they are omitted.

Sample Applications

One example application for this bus at the low end of the scale is battery management. A small microprocessor such as an ATTiny45/85 across each cell group reads the voltage and temperature and controls the balancing resistor load. Two pins are available for communications with other parts of the ebike system. Code space and hardware is limited. CANBus protocol stacks may be too large and hardware support not available in these chips. The clock stability is also an issue. These small chips have a Universal Serial Interface module that can do half duplex serial modes including I2C.

Other applications include the motor controller talking to the battery management subsystems, the cycle analyst (user console display/interface) equivalent talking to everything, and perhaps the throttle talking to the motor controller (or talking to two motor controllers, solving the usual throttle isolation issue). The front and rear lights could be on this bus, as could the ebrakes if we trusted it enough.

Another application area is in the charging system. The charger can use this bus to talk to the BMS. The Data Logger can talk to everyone with this bus. The ignition switch might just be a member of this network as well. It would be nice to have the tail-lights, headlights, etc on this one bus and get rid of all the other signal wiring. A node on the forks could pick up everything there and put it on the bus, and another node at the tail-light.

Power

If this bus can provide power to devices that need small amounts of it that would be good. Perhaps +5 and +12 would be available. That would make it a four pin bus. If there were 5 amps or so available it would be sufficient for LED lighting. Another approach is to run the bus at +12 and just have that one voltage available. Plus 12, signal(s) and ground would be 3-4 wire cabling.

Other thoughts and suggestions?
 
Here is a sample serial design with optical isolators and low parts count:

isolatedSerialComm00.jpg


Two optical isolators, one FET and three resistors.

The fuses would only be present only on the one module providing power to the Bus.

Two connectors wired in parallel would be available for daisy-chaining of the bus.
 
Noise is a huge problem to contend with. I would therefore recommend:
RS 485/422 then CAN. RS485/422 is a lot simpler to implement. Use commercial isolation chips. They are great and about $5 and you are done, and have full bandwidth.
 
bigmoose said:
Noise is a huge problem to contend with. I would therefore recommend:
RS 485/422 then CAN. RS485/422 is a lot simpler to implement. Use commercial isolation chips. They are great and about $5 and you are done, and have full bandwidth.

Thanks for the suggestion. I will look further into RS485 isolated driver/receiver chips. Do you have any favorites?

Regards,
 
ADM2587E
http://www.digikey.com/scripts/DkSearch/dksus.dll?lang=en&vendor=0&WT.z_cid=ref_findchips0311_dkc_buynow&mpart=ADM2587EBRWZ&cur=USD
 
For my controller IC I decided for CAN bus based on one simple requirement: for throttle information
you can absolutely not tolerate any data errors. CAN bus has inherent error checking and protocols to
deal with re-transmission, bus sharing etc etc. I did not find it that difficult to use and was hugely impressed
by all the possibilities that CAN bus offers.

But I agree about the disadvantage, the CAN peripheral is not available on low-end u-processors. I haven't
really studied it but because of this requirement the automotive industry went to LIN bus, which uses
the rs232 peripherals. Many PIC16F processors for instance have LIN support build into their RS232 modules.
 
I like the CANBus hardware. I am wondering about using the CANBus driver/receiver with other protocols to reduce the hardware requirements in the micro. Some micros have the CANBus serial hardware in them but many do not.

I have not looked at Linbus hardware. Should add that to the discussion. Took a quick look at it, definitely another candidate to look at.

The ATMega32M1 chip I was looking at for motor control has both Lin and CAN bus supporting serial hardware. But the ATMega32U4 has USB instead, not CAN. LIN might be possible with the serial hardware it has though.

Some folks really like the I2C and that works on most chips. There are isolated versions, and the time independence is nice. I wonder how noise immune it is to have a clock line in the bus which creates sensitivity to edges.

Most protocols have data integrity management so throttle type data would be protected. One question is what data rate is needed for throttle. Too low would be significantly annoying. But what is really required. 20 hz? 100 hz?
 
Even if you do RS422/485 I would roll a CRC on every transmission and only take action with the data if the sent CRC matches the received CRC.

When I rolled my own CAN bus stuff about 8 to 10 years ago, I don't remember all the redundancy and error checking being in hardware. I think I had to roll my own there also.
 
bigmoose said:
Even if you do RS422/485 I would roll a CRC on every transmission and only take action with the data if the sent CRC matches the received CRC.

When I rolled my own CAN bus stuff about 8 to 10 years ago, I don't remember all the redundancy and error checking being in hardware. I think I had to roll my own there also.

Agreed. Message level CRC is a requirement for any of these.
 
Added EnergyBus. Thanks! I'll have to research that one.

Looks like it is CANBus plus power connections with special connectors. May have to be a member to use it.

Wonder if the power connectors are rated for 150V 100A?

Looks like they don't have specs on the web, doesn't sound very useful to us. Nice idea for commercial products though.
 
For throttle I use a rate of 100 Hz in my controller IC. Also, when it's in CAN receive mode for
throttle there is a time-out defined (I think I use 50 msec), if no throttle is received before time-out
the controller IC automatically resets (watchdog timer which times out after 50msec but is reset
whenever throttle info is received)
 
Lebowski said:
For throttle I use a rate of 100 Hz in my controller IC. Also, when it's in CAN receive mode for
throttle there is a time-out defined (I think I use 50 msec), if no throttle is received before time-out
the controller IC automatically resets (watchdog timer which times out after 50msec but is reset
whenever throttle info is received)

Sounds like a good technique. Anything critical should have a watchdog shutdown if things don't happen on schedule.

I like the CAN transceivers, looks to me like other serial protocols can use them as long as the rate is high enough to avoid the driver's timing out. The CAN transceivers are smaller, cheaper, and have the ability to detect collisions which the RS485 transceivers don't seem to have.

Lin transceivers are set up for smaller groups of elements and I didn't see much in the way of isolated ones.
 
I did review one of the CANBus transceivers and it has a 300 uS dominant timeout. This prevents a stuck transmitter from locking the bus. This means that a recessive bit must be sent more often than 300 uS. Of course CANBus protocol takes care of this, but if we were to use this chip for some other simpler serial protocol it would need to have a guaranteed recessive bit more often than that. Assuming that async serial was used with 8 bits no parity there are 10 bits in a byte and between the start and stop the length is 10 bits. The stop is recessive and guaranteed, so 30 uS per bit is as slow as one can go, or 33 kilobits per second.

Another feature of the CANBus transceivers is the ability to detect collisions. If two nodes are colliding and one is sending dominant and the other recessive the dominant wins and the receiver detects this.

The CANBus chips that I found are physically smaller and lower in cost than the RS422/485 chips. RS422/485 has a bit more long distance capability but for our purposes CANBus drive is adequate (40 meters at 1 megabit).

So it appears quite practical to use the CANBus transceivers for some other simpler serial protocol for those applications where processor hardware and memory don't support CANBus protocol.
 
Hi Folks. I've been looking at this further for a design that I'm working on. The microprocessor chip in this design is an ATmega32M1 which is similar to microprocessor chips used in Arduino, but this particular model is designed for the automotive market and has CANbus and other useful modules designed in the hardware.

So I've been reviewing CANbus and considering it more seriously for this design, and evolving a set of compatible boards around it later on. The CANbus hardware in the ATmega32M1 does most all the heavy lifting needed, so there is very little the software needs to do to send and receive messages. An external driver chip is required, but these are inexpensive and small, and are available in isolated and non-isolated types. Isolated units are not required except for the BMS modules that may be sitting at elevated voltages in the battery stack.

For microprocessors that don't have CANbus hardware, there are chips and small PC boards that handle it and provide an SPI interface. They are under three dollars on ebae. Search for MCP2515.

CANbus Intro Videos
https://www.youtube.com/watch?v=fTWp6bFIt0s
more will pop up after this one...

Now a few choices still need to be made within the CANbus standards.

I don't plan to use extended identifiers, the standard 11 bit is sufficient for ebikes, so that's CAN 2.0A.

The bus speed can be reduced for longer range, but I plan to use the 1 megabit which is adequate for 25 meters, more than enough for my ebikes. It might make sense to lower the rate to conserve power or make the communications more reliable. I see 500 kbits/s is recommended, so perhaps I will start there. This will be revisited later, as it is fairly easy to change, though it might require reprogramming of several nodes. One commercial battery BMS I see uses 500 kbits/s. Another uses 250 kbits/s, so they are not consistent and many are not configurable.

The physical interconnect I'm looking into uses RJ45 connectors and standard twisted pair ethernet cabling. This cable is readily available and easy to terminate, or one can buy premade cables. The pin usage is:
pin 1 is the CANbus High line
pin 2 is the CANbus Low line
pin 3 is the CANbus ground
pin 4 is reserved
pin 5 is reserved
pin 6 is the CANbus shield
pin 7 is another CANbus ground
pin 8 is the CANbus V+

The cable is paired: 1,2; 3,6; 4,5; 7,8.

I'm planning to put 5V on the Pin 8 CANbus V+ line to power the isolated side of the CANbus transceivers, for those using isolated interfaces. It could also be used for powering low power modules (up to a couple hundred mA total).

I'm also considering putting some 12V on the CANbus to power low power modules that need more than 5V (up to a few hundred mA total). I would use:
pin 4 +12V
pin 5 Ground

Each CANbus item would have a dual RJ45 jack for CANbus in and out. They are parallel jacks so it doesn't matter what plugs in where.

The CANbus needs terminations on both ends, for this I would use RJ45's with 120 ohm resistors installed between pins 1 and 2. One of these would go in each of the jacks on the end of the string.
 
Looking at CANbus address allocation schemes and philosophy.

11 bit addressing is used in this setup.

Lower values have hardware priority on bus transactions (leading zeroes win).

To take advantage of this we could use an address scheme where the address was made up of 3 fields:

<priority class:2><signal:4><node id:5>

This would support four priority classes, for example:
00 urgent control
01 urgent status
10 regular control
11 regular status

Each node could have 16 signals or messages or message types within each of the four priority classes, or up to 64 different message codes per node. The data field is up to 8 bytes, as always

There could be up to 32 nodes in a system.

This is arbitrary, and could be adjusted. More message types, fewer nodes. Or the opposite. More priority classes, less of something else.

Other schemes are possible as well, or a mixture of schemes could be employed. For example some signals are fairly "universal" and are independent of their source. Things like primary throttle, system voltage and current, ambient temperature, etc should perhaps not be node centric. Perhaps reserve node #00000 for these fixed system globals.

A typical ebike system would have:

1 motor controller
1 display / user interface with throttle, ebrake, horn, lights, 3speed switch inputs (used as needed)
1 charger
2-4 BMS nodes

An advanced sytem might add
1 GPS/accelerometer/compass/altimeter node
1 RFID node
2 Light control nodes
2-4 additional BMS nodes on secondary battery
1 battery control node (controls selection of battery banks)
1 data logger
1 second motor control node
1 second display node with secondary throttle input
1 wifi/BT interface node

Total 7 + 13 or about 20 nodes.
 
Hehe... Hello all. This ES thread stumbled across searching ES for any mentions re "Serial bus system Controller Area Network (CAN)". Was just curious `cause folks like Go Swissdrive and Bosch have been implementing this in their Ebike systems.

Anywhooo.....

CAN in Automation (CiA) is the international users’ and manufacturers’ group for the CAN network (Controller Area Network), internationally standardized in the ISO 11898 series. The nonprofit association was established in 1992. The aim is to provide an unbiased platform for future developments of the CAN protocol and to promote the image of the CAN bus technology.

https://www.can-cia.org/

CANdictionary

For many years, CiA has been publishing the CANdictionary. It contains brief explanations of CAN-related terms and vocabulary including CAN FD. It is regularly reviewed and updated. Nevertheless, feedback is always welcome.

All CANdictionaries can be downloaded free of charge. Only the English one is available in printed version additionally.

https://www.can-cia.org/fileadmin/resources/documents/publications/can_dictionary_v9.pdf

Just thought could add this info and links here `case anyone interested. Hope may be of use!

Regards
 
Back
Top