Propeller and OBD-II interfaces

awesomeduck

Does anyone have experience interfacing a Prop (or BS2 for that matter) to the OBD-II interface on their car? I am specifically interested in the CAN flavor.

From another post there is the Microchip MCP2551 CAN Transceiver which seems to be an OBDII to RS232 converter. But I have found the ELM323 from http://www.elmelectronics.com/ which is an OBD-II interpreter. It looks like this should require less code on the Prop, but I am not certain.

I didn't see any objects in the object exchange, so I was looking for any insight from people that may have already looked into doing something with OBD-II. My main concern is that the protocol to run the OBD-II will require a lot more memory than can fit in the Prop RAM.

Any insights on interpreter versus dumb conversion would be...well...insightful.

Bob Lawrence (VE1RLL)

A few have looked into it (for the Prop) but I haven't seen any updates on their progress. Maybe they have an update by now.Try the post below:

http://forums.parallax.com/showthread.php?p=750908

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Aka: CosmicBob

Erik Friesen

It sounds like you are somewhat informed already. I was interested in this very thing some time back but realized that there would be a serious time commitment to see this happen. For one thing the obdII protocol is not free to download.(I don't believe) It kind of goes against the grain to use the elm chip I know. I think the prop is well capable as the elm interpreter is only on a 8 bit platform. It is just that the odbII protocol is probably as complex as usb.

parts-man73

I did my experiement as shown in that other thread. I created a custom circuit board based on the ELM datasheet and connected it to the Propeller with 2 1k resistors, as the ELM chip is a 5 volt device.

You simply RX and TX to and fro with FullDuplexSerial or the like. I connected a keyboard and a composite screen and I could type queries to the ELM chip, and it replied with the vehicle data. It worked quite nicely. I never really had time to take it much further than that. I planned to create a program with an infinite loop that continuously checked a set of parameters and feed to another cog to display that data.

The stumbling block I ran into is that I seemed to get responses in a different format depending on what type of vehicle I was connected to. It made it difficult to parse the data and extract the needed variables.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Brian

uController.com - home of SpinStudio - the modular Development system for the Propeller

PropNIC - Add ethernet ability to your Propeller! PropJoy - Plug in a joystick and play some games!

SD card Adapter - mass storage for the masses Audio/Video adapter add composite video and sound to your Proto Board

awesomeduck

parts-man, thanks for the update. I understand the problem with getting different results from different cars, but it looks like new cars are converging on the CAN J1979 protocol. (Correct me if I am wrong.) I am really only interested in newer cars, so this might not be a problem. I have a nice Innova 3130 scan tool...and what scares me about these protocol differences is that with that 3130 scanner I can actually force the engine to run tests where the RPMs vary and it does who knows what to check for compression or spark or whatever. The last thing I need is a code error throwing some random signal on the CAN bus that causes the engine to do something crazy.

I'd really just like to monitor things like RPM and speed, and then compare that to the speed I am getting off the GPS module.

There is a sourceforge project called freediag I have been looking at...I just started, but it might be possible to reverse engineer the protocol from that code. If only someone would write a J1979 for Dummies book.

DynamoBen

I've used the ELM ICs for a couple of different projects. The nice thing about them is you can focus on functionality instead of the protocol. The ELM chipsets will work well with both the basic stamp and prop the selection will depend on what you are hoping to accomplish. Let me know if you want more details about the ELM chips.

awesomeduck

Please do post anything you like. The web is filled with incomplete info on the topic. As it turns out it looks like the cheapest way to figure OBD II out is going to cost $300 to buy a copy of the HS-3000 book from SAE. Their are parts and pieces all over the web, but I don't really feel comfortable screwing around with my cars computer without knowing all the details...or at least having a good feeling for what I don't know. At this point all I know is there is that I don't know what I don't know.

Project5k

I used to work on honda ecm's and bmw ecm's, and we would sniff the can bus(using the 1979 protocol) with a simple little board, a couple chips and a serial connection to the computer, then just set up something like hyperterminal and you could read the msgs as they went by.. It was a simple little board in that we bought it from somewhere(i wasnt allowed to know from where) for around $100 if memory serves. thats been a couple years ago now tho..

Hugh

I have a ELM327 to RS232 module which connects to the OBD port in my car. I have connected the RS232 output of the module to the Prop chip, (swapping over the RX/Tx lines en-route, using a common ground but no loop-back signals). I am using the ELM327 manual as a guide to the control signals / responses.

The following code successfully resets the ELM327/RS232 module every few seconds (I see the LEDs cycling and the reset command is echoed back to the Prop). However, I know that the module is supposed to send an identification on startup / reset, which I don't appear to see. The code seems to 'garble' the first message received (as if some bits aren't aligned) - have I missed something with the intialisation / use of FullDuplexSerial?

CON

  _clkmode = xtal1 + pll16x
  _xinfreq = 5_000_000

  CR = 13                                               ' ASCII <CR>
  LF = 10                                               ' ASCII <LF>
  serXmit   = 7                                      
  serRecv   = 6                                         
  
  LCD_PIN   = 2                                         'For AMC1602AR serial LCD on P14
  LCD_BAUD  = 19_200                                    'Baud rate for communication to AMC1602AR LCD is set
  LCD_LINES = 2  

OBJ
  text          :               "vga_Drive"
  uart          :               "FullDuplexSerial"
  lcd           :               "Debug_Lcd_AMC1602"
VAR

Byte gps_buff[noparse][[/noparse]80], Rx, dataIn[noparse][[/noparse]100], ct, crt



pub main   


uart.start(serRecv, serXmit, 3, 9600)                      ' Start the RS232 communications
uart.rxflush                                            ' Flush the buffer
lcd.init( LCD_PIN,LCD_BAUD,LCD_LINES)                   ' Start the LCD display
lcd.cls                                                 ' Clear the display
  
text.start(16)                                          ' Start the monitor
text.out(00)
text.str(string("TEST"))                                ' Place the text "TEST" on the monitor


repeat
    
   longfill(dataIn,100,0)                               ' Empty the dataIn variable

   repeat while Rx <>= CR                               ' Continue to collect data until the end of the data 
     
     Rx := uart.Rx                                      ' Get character from Rx Buffer
     dataIn[noparse][[/noparse]ct++] := Rx

   crt := 0
   repeat (ct - 1)  
     text.out(dataIn[noparse][[/noparse]crt])                              ' Display the data received on the VGA
     lcd.putc(dataIn[noparse][[/noparse]crt])                              ' Display the data received on the LCD
     crt++
     
  waitcnt(240_000_000 + cnt)                            'Wait a while                             
  ATZ                                                   'Send an ATZ Reset command
  
pub ATZ  
  uart.tx(65)                   'A'
  uart.tx(84)                   'T'
  uart.tx(32)                   ' '
  uart.tx(90)                   'Z'
  uart.tx(13)                   'Carriage return
  text.out(13)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Hugh - the thinking woman's Geoffrey Pyke.

CounterRotatingProps

awesomeduck said...
·I understand the problem with getting different results from different cars

Awesomeduck [noparse]:)[/noparse]

does each manufacturer have their own protocol, or 'sub protocol' ?

> As it turns out it looks like the cheapest way to figure OBD II out is going to cost $300 to buy a copy of the HS-3000 book from SAE.

Well, if you get paid say $20 an hour and it takes you 16hrs to reverse engineer the protocol... no wait,·you'll also loose maybe $30 for the needed Excedrin Extra Strength
Does that book reveal the entire protocol, including different manufacturers?

I was in a Dodge shop the other week and overheard on of the mechanics/techs talking to their SnapOn Tools rep about 'getting the latest OBD with the·whatever attachments, and ... make sure it's got the latest flash memory.'·· You could see the ($)^($) in the reps eyes.·

Guys I think there's money to be made here if we could come up with a cool, cheaper -extensible- OBD interface device... I've had that in the back of my head for at least a year or so. But the dang thing would be complicated to support all the manufacturers/models. (Not to mention the state of the Auto industry!)

cheers
- Howard
( Who learned his old truck even had a computer once it stopped working after a small, arc welding repair ~~~ zap )
·

mojorizing

What car are you connecting to?· You'll need to know the protocal if it's not following the standard.· I'm doing a scantool for the Porsche 964 as per this website:

http://www.blafusel.de/obd/obd2_kw1281.html

Click on the British flag to translate to english.

For Porsche 964·protocal , it's the ISO 1914-1 first written in1989 and is prorietary. The stream of xmitting bytes·consists of an address byte sent at 5bbs connecting the the disignated ECU, followed by a sync byte, then your connected.· I suspect there's something similar to your car, especially if the manufacture date is around the time OBD wasn't standardized.



Kevin



▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Bad spellers of the world untie!

Hugh

Cool car, mojorizing!

I'm playing with a Saab 9-3 Viggen, but haven't started with the ISO/OBD layer yet - I'm still tinkering with the RS232 portion. It doesn't help that:

* some responses have an additional '>' and carriage return after the initial response and CR
* my PC is inside, my car is outside, so I keep having to walk between the two!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Hugh - the thinking woman's Geoffrey Pyke.