Is there a way to implement with discrete components the 70V CAN bus fault protection found in some transceivers, such as TCAN1051H-Q1?

enter image description here


We are using the CAN transceiver TCAN1051H-Q1, with its integrated 70V bus fault protection, on an ebike, with a battery voltage as high as 67V when fully charged.

Apparently this transceiver can survive an indefinite short between the bus and battery voltage, e.g. from a wiring error or a damaged cable.

However, we would for other reasons prefer using 3.3V transceivers such as TCAN33x, but those do not offer 70V bus protection, hence the question.

  • \$\begingroup\$ Not really an answer to the question, but it is likely easier and cheaper to interface a 5V transceiver to 3.3 V, than adding the 70 Vbus protection to the 3.3 V transceiver. \$\endgroup\$
    – Klas-Kenny
    Commented May 3, 2022 at 12:04
  • 1
    \$\begingroup\$ Thanks for the suggestion, but we want a 3.3V transceiver in order to be able to turn the 5V rail off for power savings because of other constraints inherent to our board \$\endgroup\$
    – lmlmlmlm
    Commented May 3, 2022 at 12:29

3 Answers 3


First of all, please note that the +/- 70V rating on the parts you list are absolute maximum ratings. That means that they can survive a temporary short with your 67V, but not a continuous/permanent one. So your specification needs to address why surviving temporary shorts is important - for example this bus fault rating may protect against the bike builder being clumsy when wiring, but it will not protect against "water everywhere".

Regarding info posted in comments: it would seem that your technical problem could simply be solved by adding a separate voltage regulator for the 5V transceiver, creating two different 5V rails. Also some transceivers come with a logic level voltage option on pin 5, but I don't know of one which also got the +/-70V requirement (which is a bit extreme as CAN transceivers go, they used to be some +/-16V or so until fairly recently).

Other than that, you could add galvanic isolation to the CAN bus and supply the secondary with whatever is convenient. For example by using digital isolators (example).

  • \$\begingroup\$ I don't see any remarks in the datasheet that suggest the fault rating is not indefinite; if nothing else, thermal limiting should kick in, protecting it during current limiting. Not all "high voltage" transceivers share this; the more common case, I think, is internal TVS diodes with an assumed line resistance protecting the device from incoming surge voltage. The TCAN1051 seems to be the exception. But TI datasheets are notoriously mediocre, and it would be nice to see a more explicit statement on this. \$\endgroup\$ Commented Dec 6, 2023 at 18:04
  • \$\begingroup\$ @TimWilliams The very meaning of the well-established term "absolute maximum ratings" is that they are temporary stress values that the device may survive for a brief period of time, not something you should design normal use of the product after. \$\endgroup\$
    – Lundin
    Commented Dec 7, 2023 at 7:32

I would go with this device, MAX13041. Is available on DigiKey, but pricey.

I would architect my system as follows:


simulate this circuit – Schematic created using CircuitLab

IMHO it is much simpler to switch ON/OFF your 5V rail for the Transreceiver, than to implement the bus-protection your self.


Not really. Or the solution is worse than the alternative.

Consider this solution:


simulate this circuit – Schematic created using CircuitLab

We start with a standard transceiver with 16V abs. max. ratings. It has internal TVS diodes, but they are small (2kV ESD, 15µs 50~100mA square pulse surge), so we augment with slightly lower rated (12V nominal, ~15V breakdown, ~20V peak) TVS diodes outside.

We already identify one problem: the TVS diodes will have peak voltage such that excessive current could still flow into the device. It's not practical to reduce their voltage, because we'll quickly compromise input common-mode range in the process.

We've also done nothing to deal with surge or fault voltage. So, we add a current limiter.

Current limiting could be as simple as a resistor, but any reasonable resistor value (10s Ω max) will already cause significant transmission losses (compare to typ. 60Ω double-terminated bus impedance), and this is maybe just acceptable in the given application, because the bus is likely not very long on a bike (a few m max?). Meanwhile, such resistance does nothing to limit the power at such high fault voltages: 70V/30Ω is still 2.3A and 160W in the resistor alone, and adding in the TVS voltage drop doesn't do much to reduce that further. The TVSs would probably cook off in about the same time the resistor fuses.

Polymer PTC fuses are a possibility, if one is chosen with relatively high resistance so it heats up quickly, and if one can be found rated for the fault voltage and load current (at least 50mA nominal rating, over 70V max). The TVSs will probably need to be quite large (SMC package? maybe several in parallel?) to handle the let-thru, as PTC fuses take quite long to open circuit (10s, 100s of ms).

Next option, and as shown: limit the current with active circuitry. A popular and effective solution to cross-wiring faults for low-voltage inputs, is to use depletion MOSFETs to limit the current flow. At low current, these act as resistors, and we've more than used up our margin here as the DN2450 is around 10Ω RDS(on), and we need another 10Ω to set the current limit value (100-300mA). And we need two, one for each line, so the total added resistance is about 60Ω, fully halving our bus voltage from the get-go.

The large and loosely-controlled current limit is still problematic because of power dissipation. At 300mA, 21W is dissipated, above the limit of a DPAK part on PCB, and even with aggressive heatsinking, it's not likely to survive more than some seconds. (The TVSs are probably fine, in SMB or larger package size, say?) There is at least the possibility that the transistors and TVSs survive long enough for heat to spread out (100s ms to ~s), and so R1 and R2 could be PTC types, greatly amplifying their PTC-ness and providing a foldback limiting characteristic (while stressing them far less than as direct fuses, presumably/hopefully increasing their cycle life if that should be helpful). Or we could use further, more elaborate, active circuitry to thermally protect and foldback-current-limit the circuit.

But you see, we've already increased the layout area by >10x, component count by 8x, and BOM cost by who knows how much, and we still don't have good confidence in surviving this situation.

A perhaps somewhat cheaper circuit could be realized, by going down that higher-complexity route; a BJT-based circuit seems viable to me, and the layout area might not be great, the component count even less so, but the cost can be brought down by most of those components being jellybeans (resistors or R-packs, and dual NPNs and PNPs). But we come to another issue: as an engineer, I would need some tens of hours to play around with such a circuit, creating it from principles; analog engineering is not cheap, and unless you can find someone who's created this exact function, you'll be paying a lot of engineering time to solve it.

The best solution, by far, is to just not allow CAN to get cross-wired.

Apply poka-yoke design principles:

  • Don't put CAN on terminal blocks.
  • Don't use bare battery wires, for that matter.
  • Don't use bare boards.
  • Put everything in shrouded connectors, if at all possible. (Sealed connectors at that, since this is presumably an all-weather application. Likewise, boards will probably be conformal coated at least, or partially or fully potted, and placed in IP6x enclosures.)
  • Don't reuse connectors (cross-wiring possibility). Use unique, incompatible types for each cable. Perhaps even for each end of each cable (e.g. where pinout differs).
  • Reduce tool operations. Use fewer brackets, beams, clamshells, etc. (implied: anything that screws together); use more slides and snap fits; add guards around electrical terminals so that, when tools are necessary for a step, a previous step has protected critical connections from their misuse, or the tool and fastener are relatively far from such connections.
  • Clearly mark hazards. Use bright orange connectors for the battery. Add warning marks in bright red, yellow-black stripe, etc. around dangerous connections.
  • Lock out hazards. Add brackets, panels, protective elements so that connection can't even be made, at least until significant effort has been done towards the clear goal of exposing that connection. Don't make ambiguous or multipurpose actions: for example, removing a panel to expose both a control circuit AND the battery connection; add a second guard over the battery connection, or separate them.
  • If assembling in factory, provide better instruction to the assemblers. If assembled by user (kits), do all the above and provide copious, clear instructions.

The list goes on; one can imagine many possible solutions, from electrical and mechanical, to managerial and documentation. If this is a corporate setting, push back on management, clearly indicate budget and timeline overruns, and what you need from them to fix the mess they're ultimately responsible for (and if they refuse, looking for a job elsewhere is your best solution). If more of a few- or single-person shop, or personal project for that matter, that training will of course be more direct: a learning experience, perhaps a costly one (PCBAs, enclosures, etc. are scrap), but that is simply the cost of learning, sometimes. Set aside some time, alone or in meetings, to contemplate where things are going, how they might succeed, how they might fail, and what things can be improved. Come up with a plan, not just how to proceed, but how to test success of the proposal. Hopefully an expanded perspective (such as considering these and the above ideas, and more) leads to a successful project. Good luck!


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.