1
\$\begingroup\$

I need to review some physical layers used in OBDII, a very common interface communication of vehicles and used as interface in a automotive scanners. I don't need exactly to know how the protocol works, more precisely speaking, I need to know the ICs and actual panorama of these protocols, for example, actually, I use a SN65HVD251D as a transceiver for CAN physical interface, however, I read that in 2015 was published the standard ISO 11898-1:2015 that specifies what is called CAN-FD and allow data rates greather than 1Mbps and payload wider than the allowed in previous CAN standard. So I would like to know if there is newer updates to other protocols and and to the ICs that I use. I will put here a panorama of what I know about this at the moment:

CAN Physical Layer : In 2015 was published the standard ISO 11898-1:2015 that specifies what is called CAN-FD and allow data rates greather than 1Mbps and allow payloads wider than the allowed in previous CAN standard. I found ICs that allow up to 12MBps like the ADM3050E .

J1850 Physical Layer: J1850 allows for the use of a single or dual wire bus, two data rates (10.4 kbps or 41.7 kbps), two bit encoding techniques PWM (pulse-width modulation ) or VPW (variable pulse-width modulation). Actually, I use comparators together with a microcontroller tom implement PWM alternative, so a simple comparator is sufficiently. As a solution to VPW alternative I use the MC33390 IC, this IC is hard to find and I didn't found an alternative to it.

ISO 9141 Physical Layer: Actually I use a L9637, I know another IC, the L9613, but as I culd see, they are similar and the difference is about Voltage tolerance of power supplly.

About CAN, was relativeley easy to find out that my approach using SN65HVD251D to CAN physical layer can become outdated soon. But I really don't know how to know it, in a similar way, about the others protocols.

Does someone has these informations or know a manner to get these informations about these protocols, like updated versions or something similar ?

\$\endgroup\$

1 Answer 1

2
\$\begingroup\$

CAN-FD is a different hardware layer. It is not compatible with "classic CAN" even though they are specified inside the same standard. So CAN-FD is not an "update" to CAN, it is an entirely new hardware standard.

It isn't meaningful to upgrade existing CAN networks to CAN-FD. You would need to change everything from scratch, both hardware and software. It only makes sense to use CAN-FD for new projects.

J1850 is something else entirely, it's yet another standard. I have never used it so I don't know much about it, except that it was fashionable around 20 years ago and Motorola released some special MCUs with hardware support for it back then.

I don't need exactly to know how the protocol works

Well, you do need to know this in order to understand why CAN-FD doesn't make sense as "drop-in replacement". It's not just faster baudrate, it is the data part of the frame getting clocked faster to allow higher payload than 8 bytes, up to 64 bytes. But all the higher layer protocols are designed and specified to use up to 8 byte payload, so they won't be able to do anything meaningful even if given more bandwidth.

\$\endgroup\$
2
  • \$\begingroup\$ Yes, you're right. As I need to verify and, maybe, re-desgin the physical layer of an automotive scanner, when I read about CAN-FD for the first time, I started to see if my system is compatible, not only the transceiver but the controller too. And they are not, so I will nedd to investigate a bit more as you said. But, is CAN-FD being used by automotive industry? I found the ISO standard of CAN-FD, but I didn't know any usage in vehicles until today. \$\endgroup\$
    – Daniel
    Commented Mar 5, 2020 at 17:02
  • 1
    \$\begingroup\$ @Daniel I not yet done any CAN-FD project. All I know is that silicon vendors invest heavily in CAN-FD chip support, so it seems like it may become successful. Time will tell. \$\endgroup\$
    – Lundin
    Commented Mar 6, 2020 at 8:05

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.