I would like help using an Arduino based project on the propeller

turbosupra

http://www.instructables.com/id/Arduino-OBD2-Simulator/?ALLSTEPS

Looking at ChrisGadds obd2 object http://obex.parallax.com/object/690, I'd like to build a simulator for this to test with it. The protocol I am most interested in is ISO, which (from research) uses pins 7 and 15 on the obd2 connector. I do not know much about the Arduino or what on board capability it has hardware wise, so I may need to use some hardware with the prop, I don't know. How similar are the Arduino's and the propellers and how difficult is it to translate code from one to the other?

My end goal is to be able to simulate all of the standardized/universal obd2 PIDs to Chris Gadds object using the ISO protocol. Thanks



ISO


Pin Signal Description
2 J1850 Bus+
4 CGND Chassis ground
5 SGND Signal ground
6 CAN High J-2284
7 K-LINE (ISO 9141-2 and ISO/DIS 14230-4)
10 J1850 Bus-
13 TC Timing check - ignition advance angle adjustment or ABS slow codes out
14 CAN Low J-2284
15 ISO 9141-2 L-LINE (ISO 9141-2 and ISO/DIS 14230-4)
16 +12v Battery power

http://www.obdtester.com/obd2_protocols

OBD-II Protocols
An OBD2 compliant vehicle can use any of the five communication protocols: SAE J1850 PWM, SAE J1850 VPW, ISO9141-2, ISO14230-4 (KWP2000), and since 2003 also ISO 15765-4/SAE J2480. ELM-USB and OBDTester support all of them.

Some websites say they support 9 or even more protocols. This is because they mistakenly count protocol variants as separate communication protocols. If you add 4 variants of CAN-BUS to our list, you are on 9.

Please note that some models are equipped with SAE J1962 connector, but these cars are NOT OBD2 compliant. Typical examples of such cars are some early VW/Skoda/Seat models (European versions only), Ford cars with EEC-IV using Ford DCL protocol (e.g. Ford Escort), Nissan EU/Asian models (using Nissan DDL protocol), or some European Hyundai models.
ISO15765-4 (CAN-BUS)
The most modern protocol, mandatory for all 2008+ vehicles sold in the US. Uses pins 6 and 14, communication is differential.

Four variants of ISO15765 exist. They differ only in identifier length and bus speed:

ISO 15765-4 CAN (11 bit ID,500 Kbaud)
ISO 15765-4 CAN (29 bit ID,500 Kbaud)
ISO 15765-4 CAN (11 bit ID,250 Kbaud)
ISO 15765-4 CAN (29 bit ID,250 Kbaud)

ISO14230-4 (KWP2000)
Very common protocol for 2003+ vehicles using ISO9141 K-Line. Uses pin 7.

Two variants of ISO14230-4 exist. They differ only in method of communication initialization. All use 10400 bits per second.

ISO 14230-4 KWP (5 baud init,10.4 Kbaud)
ISO 14230-4 KWP (fast init,10.4 Kbaud)

ISO9141-2
Older protocol used mostly on European vehicles between 2000 and 2004. Uses pins 7 and optionally 15.
SAE J1850 VPW
Diagnostic bus used mostly on GM vehicles. Uses pin 1, communication speed is 10.4 kB/sec.
SAE J1850 PWM
Diagnostic bus/protocol used mostly on Ford. Uses pins 1 and 2, communication signal is differential and it's rate is 41.6kB/sec.

JonnyMac

I built a CAN buss shield for the Propeller Platform for my column in N&V magazine some time ago. In fact, I think I gave you the design files. In the time = money world, you might consider getting that Arduino CAN shield and dropping it onto a Propeller ASC+. You'd instantly have the hardware you need and could focus on software.

ChrisGadd

From what I can tell, ISO9141-2 K-Line uses simple RS232-based signalling - 8bit; 1 start, 1 stop, no parity, non-inverted, at 10.4Kbaud. The OBD-II messaging is the same regardless of which protocol you use, so the main part of my OBD object, the one that translates received messages into understandable text might still be of some use, but the CAN reader and writer need to be replaced with a serial object. It's possible that even FullDuplexSerial would might do the job, otherwise ELM makes the ELM323 OBD to RS232 intepreter, which is built on a PIC16F and which they'll be glad to sell you for just $15.50 - what a bargain. Personally, I'd stick a scope probe on the K-line and see what's there.

From velocidadmaxima
9141-2

Classification: A

Commonly Used On: European, Asian, and some Chrysler

Description:

The ISO 9141-2 protocol is essentially a serial interface, similar to the RS232 interface found in personal computers. The ISO 9141-2 data bus can be implemented as either a single-wire or two-wire interface (DLC pins 7 and 15) with a data transfer speed of up to 10.4 Kb/s. The “K” line (pin 7) is a bidirectional line. During initialization, this line carries address information or (in the case of fast initialization), the “wake up” pattern from the Code Reader or Scan Tool to the vehicle’s computer. After initialization, bidirectional data flow between the Code Reader or Scan Tool and the vehicle’s computer takes place over the “K” line. The “L” line (pin 15) is a unidirectional line (from the Code Reader or Scan Tool to the vehicle’s computer). It is used only during initialization to carry address information or (in the case of fast initialization), the “wake up” pattern from the Code Reader or Scan Tool to the vehicle’s computer simultaneously with the “K” line. After initialization, the “L” line is held in a “high” (logic “1”) state.

The ISO 9141-2 data signal is a square wave of uniform frequency, with a varying voltage level (either +12VDC or 0VDC), as illustrated.

I've never touched the Arduino, so can't help ya there.

StefanL38

some minutes before I was searching in the obex for "sound" and came across an OBD-II-Object for the propeller.
http://obex.parallax.com/object/690

best regards

Stefan

turbosupra

So to simulate the factory ECU output to pin 7, the fullduplexserial protocol might be used for transmission?

Since there is no clk signal and data transmission is 2 way, it must sample the line (after the start bit, which I assume is always a logic 1) every 0.00009615 seconds or ~96uS to read whether it is a 1 or a 0? Are there no issues with collisions where the reader and the ecu try transmit at the same time?

Before I can test the receiver, I've got to build a transmitter that can work with my code scanner. If it can communicate with my obd2 code scanner, than I can go from there.

I guess with fullduplexserial, I could do this? Do you think the mode need to be changed?

iso9141 : "fullduplexserial"
iso9141.start(RX1, TX1, %0000, 10_400)

I will scope that pin as soon as I can.

ChrisGadd wrote: »

From what I can tell, ISO9141-2 K-Line uses simple RS232-based signalling - 8bit; 1 start, 1 stop, no parity, non-inverted, at 10.4Kbaud. The OBD-II messaging is the same regardless of which protocol you use, so the main part of my OBD object, the one that translates received messages into understandable text might still be of some use, but the CAN reader and writer need to be replaced with a serial object. It's possible that even FullDuplexSerial would might do the job, otherwise ELM makes the ELM323 OBD to RS232 intepreter, which is built on a PIC16F and which they'll be glad to sell you for just $15.50 - what a bargain. Personally, I'd stick a scope probe on the K-line and see what's there.


I've never touched the Arduino, so can't help ya there.

StefanL38

I have never done anything with OBD2 but I guess

maybe this product and the links mentioned at the bottom of the page are helpful
https://www.sparkfun.com/products/9555
best regards
Stefan

turbosupra

That looks good Stefan, it looks like a lot of projects are using the ELM327, this one also http://theksmith.com/technology/hack-vehicle-bus-cheap-easy-part-1/

but I'd like to be able to send the commands to them to simulate the in car portion of it from the ECU to my odb2 scanner first.

StefanL38

Hi Brad,

I'm not sure if understand right.
Do you want to simulate the cars ECU for testing your ODB2-Scanner?

Is the ODB2-Scanner the thing you want to build with a propeller-chip?

or do you have a ready to use ODB2-Scanner and you want to use this scanner to test creating OBD2-messages with the prop?

best regards
Stefan

turbosupra

Hi Stefan,

I have an obd2 scanner that I bought at the store already.

Step1 - build a device to simulate the car ecu and send messages to the scanner that I bought from the store
Step2 - build my own reader that will work with the ecu simulation device that I've built
Step3 - test my built reader in a car

My biggest hurdle I think will be figuring out how to simulate what the automotive ecu does.

Does that make sense?


Like this device

https://www.ozenelektronik.com/iso-9141-obd-ecu-simulator-p.html

which uses this

https://www.ozenelektronik.com/downs/pdf/oe91c1010.pdf

StefanL38

Hi Brad,

now I understand.

So I googled with "opensource simulate obd2 data of an ecu" and found this
http://icculus.org/obdgpslogger/obdsim.html
as this guy has written a OBD2-simulator he should know a lot about how it works

Did you take a look inside the code of the OBEX-OBD2-Code?
from a quick view I guess there is a good chance to understand how it works.

If you combine it with displaying the raw datastream on the OBD2-connector while your OBD2-Scanners talks with the ECU
you should be able to analyse it. For displaying the raw datastream I suggest using a Y-cable

ECU

---

X

---

OBD2-Scanner

at "X" there is the branch which will be connected to a serial-terminal-software.
Maybe some kind of low-level-translation (like the EML327) is needed.

As I mentioned above. I have never done anything with OBD2. These are just quick guessings from crossreading
OBD2-Infos

best regards
Stefan

turbosupra

Hi Chris,

It looks like after 2008, it was CAN only, no ISO or any other protocol, with 1 frame equaling 4 bytes.

Can you tell me how you would request pids through mode 1?

Mode 01 appears that you set a mode first (eg: current data or free frame data, dtcs, etc)

Then you request pid 0 or 32, or 64, or 96 (etc) and that pid will tell you if the ECU supports the next 31 PIDS or not.

It then reports the value of the supported PIDs to the diagnostic reader and I believe automatically moves onto the next set of 31? I assume it loops until it reaches an increment of 32 that does not respond?

Mode 02 looks about the same with only 1 difference with Pid01.

Mode 03 doesn't need a PID and looks (I still don't know how the diagnostic reader sets the mode?) for any response and will give all corresponding DTC's that have been set

Mode 05 accepts a pid and then returns a value

Mode 06 accepts a pid and then returns a value

Mode 07 works the same as mode 3

Mode 09 will accept a pid and then returns a value


Which parts of this does your object do for 2009+ CAN?

ChrisGadd wrote: »

From what I can tell, ISO9141-2 K-Line uses simple RS232-based signalling - 8bit; 1 start, 1 stop, no parity, non-inverted, at 10.4Kbaud. The OBD-II messaging is the same regardless of which protocol you use, so the main part of my OBD object, the one that translates received messages into understandable text might still be of some use, but the CAN reader and writer need to be replaced with a serial object. It's possible that even FullDuplexSerial would might do the job, otherwise ELM makes the ELM323 OBD to RS232 intepreter, which is built on a PIC16F and which they'll be glad to sell you for just $15.50 - what a bargain. Personally, I'd stick a scope probe on the K-line and see what's there.

ChrisGadd

The OBD-II main object has methods for mode 1 current data, and mode 2 freeze-frame data. The query method accepts a mode and PID as parameters, passes them to the writer object, which constructs a message using ID $7DF. The reader object sees the outgoing message and captures the mode and PID. The reader receives and parses every message from ID $7E8, but only stores a message if the received mode is $40 greater than the outgoing mode, and the received PID is the same as the outgoing PID.

This works fine for modes 1 and 2; I'm uncertain if it'll work for the other modes. Mode 3 doesn't use the PID field so no idea what it'll return there. Mode 4 doesn't return any data, but I have used it to clear trouble codes. I haven't even looked at 5 through 9.

The query_s method uses the same query method, but uses the returned bytes to construct a string based on the PID, so obviously only good for modes 1 and 2.

So to request PIDs through mode 1: query(1,PID). The query method returns true if a response is detected, and the response is stored in the 8-byte Receive_buffer. Otherwise it times-out and returns false after 1 second.

Here's a snippet that will display the data bytes of the received message. The first byte will be the number of meaningful bytes in the message, second is the mode + $40, third is the PID, fourth through eighth contain the requested data.

  if OBD.query(Mode,PID)
    repeat i from 0 to 7
      fds.hex(byte[rx_buffer + i],2)    ' The start method in main returns the address of the 8-byte rx_buffer
      fds.tx(" ")
    fds.tx($0D)

I relied heavily on Wikipedia for determining how to parse the returned data. The same Wiki article mentions how modes 3, 5, and 9 are structured.

turbosupra

Thank you. I will come back to this, I think I need to take a baby step with the BEAN protocol first, before tackling this.