0
\$\begingroup\$

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?

\$\endgroup\$
  • \$\begingroup\$ No, it is more common to use a 2.5 V difference, 3.75 V and 1.25 V. \$\endgroup\$ – Peter Mortensen Oct 14 '17 at 12:37
1
\$\begingroup\$

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.

| improve this answer | |
\$\endgroup\$
2
\$\begingroup\$

To emulate the CAN bus and verify the operation of devices that will attach to it, you need to emulate a portion at least of the protocol.

There are plenty of OBD II emulators out in the market ....you could just buy one.

If you want to create your own, then I'd suggest you start here.

This guy did a great job of both assessing current product and defining what was required to make one. He finally didn't achieve his goal, but he got close (high marks for that).

You could also read this ....a bit more hit-and-miss, but it may give you leads.
It's based on an Arduino, so you may find both emulator code and reader/recorder code that will help you.

| improve this answer | |
\$\endgroup\$
  • \$\begingroup\$ Thanks for the input. The issue with an OBD II simulator is cost. Average price seems to be in the $150 range and if we want 20 (or more as time goes on - the idea is to be able to rapidly do a batch of these with minimal human interaction) of these, the cost adds up... It's not the end of the world, but I was hoping for something a bit better if we try to scale it up. After doing more searching, this appears to be closer to what I want to be using: sparkfun.com/products/13262 \$\endgroup\$ – bgp Mar 10 '17 at 3:20
  • \$\begingroup\$ A good collection of info, but the Sparkfun board is not a simulator, they send you out to here: scantool.net/development-tools/obd-simulators/ecusim-2000 ....this simulator costs $100's and needs a PC to go with it. \$\endgroup\$ – Jack Creasey Mar 10 '17 at 3:36
  • \$\begingroup\$ Gotcha. My intention was to use the CAN bus board to essentially just "answer the questions" that the device I'm trying to initialize asks. I do realize there is probably a lot that goes into making an actual simulator, but I don't need all that functionality, I just need the bare minimum required to make my device happy. I'm hoping it just a few things like overall engine state and odometer reading or something. But I won't know until I'm able to interface with it and see what codes it's sending. \$\endgroup\$ – bgp Mar 10 '17 at 7:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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