TL;DR: If I connect one of these https://www.scantool.net/scantool/downloads/97/stn1110-ds.pdf directly (i.e. the CAN RX and CAN TX pins, plus overall 12 V power) to a device intended for a car (in order to make the device think it is plugged into a vehicle and thus initialize itself) is that going to work or is the circuit more complicated than that and where should I look for more information?
I notice the datasheet on page 10 has a 100 kohm pull-up to 3.3 V on both CAN wires. Maybe that's what the bus needs to operate correctly.
I'm trying to create a system, driven by either a Raspberry Pi or Parallax Propeller board that can be used to initialize an OBD-II connected device – one that is intended to be connected to your car.
To do this, I need to emulate the minimum functionality needed to get the device to be aware that is plugged into a car. The point is to test that the device is working with basic functionality without having to physically run out to the parking lot and plug it into a car. The goal is to be able to do this with a lot of devices – possibly batches of 20 or so at a time.
After puzzling out the various types of signaling used for OBD-II (the two that look most promising seem to be SAE J1850 PWM and ISO 15765 CAN, but neither is straightforward) and the issues involved with voltage level conversion, I'm looking at using an IC like this: https://www.scantool.net/scantool/downloads/97/stn1110-ds.pdf. These are relatively inexpensive and would appear to handle the underlying CAN or other signaling and give me something I can just treat as a serial interface. This sounds great and like a good approach.
However, what is not entirely clear to me is if a chip like this is intended and able to be used to emulate the "car side" of the bus. Almost everything I read about OBD-II assumes you are trying to hack or otherwise get data out of your car. In my case I want to "be the car". I've read through what I can find for free on ISO 15765 and the concept of a CAN Bus, there should be no problem – each node is a peer and broadcasts messages to everyone on the bus and the interested device(s) listen and do what they want, with collision detection, etc. This all sounds good and fine, but I wanted to see if anyone with more experience than me has any ideas about what I might run into with such an approach.
For example, and this is probably a stupid question, but bear with me – the CAN bus is described has having a "recessive voltage" around 2.5 volts and a high wire and low wire which are respectively driven up to around 4.5 and down to around 0.5 volts. Where does that recessive 2.5 V come from? If I am going to emulate the "car side" do I need to provide that?
Best Answer
I've done this recently, without needing an ODB-II "simulator" device.
Grab yourself an Arduino CANbus shield and the associated DB-9 to ODB-II cable, and hook it into a car. Write up some code to read CAN messages and transmit them out via serial. Dump this data from serial to a file on your computer. You can then invert the process and transmit the CAN messages over serial back to the device, in a loop, to simulate the vehicle idling.
If the device under test just passively listens into CAN messages, you may need two CAN shields: one to loop the transmission, and the other to actively receive the messages on the other end, while your device under test hooks into the CAN lines in the middle. I'm not sure why this is necessary, but it was for me; the transmitting CAN shield would not initialise the transmit buffer unless I had something explicitly "accepting" the messages at the other end.