4

What problems are the chips ELM327 and STN1110 solving?

If I connect the necessary interface ICs (I mean dumb ICs, like level shifters, inverters, etc., not pre-programmed devices like ELM327) between the OBD pins and a suitable micro-controller, can I not read OBD data? I suspect these devices help in simplifying the software. Is that right? If so, what is the big problem they solve?

And if I don't want to use these chips, what do I need to know to start reading data from the port using just the dumb interface ICs and a microcontroller? I really don't wan't to depend on a closed-source product.

Peter Mortensen
  • 1,676
  • 3
  • 17
  • 23
Dojo
  • 919
  • 10
  • 19
  • 2
    Do you have knowledge of the low-level protocols they translate? If you do then don't use them. – Andy aka Feb 18 '14 at 18:01
  • The ELM327 is exactly that: a microcontroller programmed to "talk" OBD protocols. Of course, you are free to implement your own solution. If you want to talk OBD, you should probably learn the protocol. Or use the chip. It's a trade-off - spend time doing the coding yourself or buy the closed-source chip. Depends what is important to you and/or your project goals. – dext0rb Feb 18 '14 at 18:23
  • @Andy aka If you are talking about documented protocols like CAN, I can learn them. After I learn them what would I need to know to pull data like RPM, MAF etc? Would I need build a large number of custom routines to handle manufacturer specific differences in protocol implementation? Would I need access to NDA covered or hard to get documents from the manufacturer? Or can I get by just knowing generic OBD codes? This could become a commercial product so I don't want to have third party dependency. – Dojo Feb 18 '14 at 19:35
  • @dextorb Please see my other comment addressed to Andy aka. What do you think? – Dojo Feb 18 '14 at 19:39
  • @Dojo I haven't got a clue - I looked it up on google, saw what it did and made my comment. If I knew I'd have made it an answer but i cheated LOL! – Andy aka Feb 18 '14 at 20:14
  • @Dojo You will have to check the spec for sure, but I think there are some "standard" codes that all vehicle manufacturers must support, like RPM and MAF. There are definitely manufacturer specific OBD codes and routines that might even use their some protocol on top of OBD or something. If you want to support them, you must talk to the vehicle manufacturer. – dext0rb Feb 18 '14 at 22:22

1 Answers1

8

PIC Microcontrollers (and others) contain hardware serial blocks for speaking OBD/CAN protocols. You can buy a PIC yourself and implement the protocol engines, which amounts to programming the register space, clock dividers, handling interrupts etc. If you are then sending the data to a PC/mobile you also need a UART and transmission buffer.

This becomes quite a lot of work if you are making an adapter cable - hence the popularity of off-the-shelf OBD-to-UART adapters such as ELM327/STN1110. They are both PIC chips (ELM327 is implemented on the PIC18F2480, STN1110 on the PIC24HJ128GP502) loaded with software that does rx/tx buffering, filtering, power management etc.

Microchip has reference designs if you want to design your own:

AN738 - PIC18C CAN Routines in 'C'                                     05 Nov 2001
AN853 - PIC18XXX8 CAN Driver with Prioritized Transmit Buffer          09 Sep 2002
AN816 - A CAN System Using Multiple MCP25050 I/O Expanders             04 Nov 2002
AN873 - Using the MCP2515 CAN Developer?s Kit                          02 Sep 2003
AN877 - DeviceNet™ Group 2 Slave Firmware for PIC18 with CAN           06 Oct 2003
AN916 - Comparing CAN and ECAN Modules                                 05 Mar 2004
TB078 - PLL Jitter and Its Effects in the CAN Protocol                 15 Jun 2004
AN930 - J1939 C Library for CAN-Enabled PICmicro® Microcontrollers     16 Jun 2004
AN733 - Using the MCP2510 CAN Developer's Kit                          27 Jul 2004
AN878 - PIC18C ECAN C Routines                                         28 Feb 2005
AN228 - A CAN Physical Layer Discussion                                16 Sep 2005
AN713 - An introduction to the CAN protocol key features.              16 Sep 2005
AN754 - Understanding Microchip's CAN Module Bit Timing                16 Sep 2005
AN945 - A CANopen Stack for PIC18 ECAN Microcontrollers                12 Oct 2005
AN247 - A CAN Bootloader for PIC18F CAN Microcontrollers               15 Dec 2008
AN1249 - ECAN Operation with DMA on dsPIC33F and PIC24H Devices        13 Feb 2009
TB3017 - dsPIC30F CAN Interrupt Management                             27 Feb 2009
AN212 - Smart Sensor CAN Node using the MCP2510 and PIC16F876          04 Nov 2010
AN215 - A Simple CAN Node using the MCP2510 and PIC12C67X              08 Nov 2010
shuckc
  • 3,012
  • 14
  • 19
  • 1
    Thanks shuckc. I am trying to understand why there are only two vendors offering ELM327 like functionality. The hardware seems pretty simple. Had it been just a hardware + simple software job, I would expect many more vendors or open source projects. I have a hunch that there is some proprietary sauce in the firmware of these chips that abstracts out minor differences in OBD implementations of different car manufacturers. Now that is something that requres extensive testing with different vehicle models and not a plain protocol implementation job. What do you think? – Dojo Feb 18 '14 at 19:23
  • 1
    Simply there's a *very* limited appeal/volume for these translator chips. Anyone making cables in sufficient volume will design their own to slash costs. Anyone building a handheld diagnostics device will have the skills in house to bring in the protocol to the main mcu. This leaves these chips for the hobbyist/small volume market that are not price sensitive. – shuckc Feb 19 '14 at 09:07