|
Admittedly, the J2534 devices tend to cost more, but they also tend to have some advantages: They tend to provide better throughput for high data-rate networks (e.g. CAN), and they also allow for multiple filters (important on high-datarate networks) and multiple scheduled messages.
I think another value of the J2534 interface is that code written to it is portable among connection devices (some providing advantages over others in various ways), though I can understand how that might not be desirable to a device mfr. If code is portable, it increases incentive to develop applications using the J2534 API because the same code works across multiple devices.
The ELM-class devices do present a nice low-cost option, are certainly good enough for purely OBD (i.e. request/response) data, and they're simpler to use manually. In fact, such devices are perfectly good for getting any request/response data (whether OBD or OEM-defined). But I think they tend to be a bit more clumsy to program against (at least for clumsy programmers like me) and don't seem to have the advantages enumerated above. I guess it all depends on what one is using the device for, but there are some data that I don't think can be got at all through an ELM-class device (i.e. high-speed broadcast messages).
I guess this might not be the best thread on which to have this discussion. Sorry for drifting a bit ...
|