|
Lukeyson |
|
|||
|
I've just had a bit of a windfall.
I managed to locate copies of the SAE J2178 and J2190 documents to help me learn the SAE PIDS, and I also managed to get a few Ford Enhanced PIDS from a CAN forum. At least, I got a list of Ford Enhanced PIDS from a 2002 Focus, and many of them match up with the PIDS I pulled out of the BA Workshop manual - but there's still a heap to go. I now have to verify that those PIDS return useable values - we're getting there bit by bit. I'll be sure to do a write up at some stage to share my findings. The somewhat lofty ambition is custom-write my own BA Falcon/SX Territory Scantool software in VB to help put in to practice what I'm learning - and see if I can get that working with Microsoft Media Centre. Lukeyson |
|||
Top | |
bowsaw |
|
|||
|
Very interesting, but its all goobly dook to me, lol. What will be the end result? being able to reprogram PCM? or something else?
|
|||
Top | |
eagleaus |
|
||
|
I was told by the guy i got my scantool off, that the Ford Focus was the basis used for the BA on etc.,
|
||
Top | |
Lukeyson |
|
|||
|
OK - Goals?
(1) To be able to read the custom values from the PCM, BEM, ICC and IC for diagnostics and trouble shooting. (2) To be able to read specific values and put them up on display. Many people are now putting CarPC's in their cars. By making the display accessible using Media Player, I could theoretically drive th display from the remote. The basic stuff is already visible - RPM, Speed, Mainfold Pressure etc - at 'low' resolution. With access to higher resolution I can potentially run a rolling-dyno and do electronic 0-100km/h times. Some of this stuff is already available in software such as Digimoto, but as it uses J1797 low-res stuff I don't think it's that accurate. (3) Extend my understanding of how these things work. I started by just trying to understand how to do a MCC to ACC upgrade, but I can't control my curiosity. I'm like this with every bloody car I buy.... CAN bus communication is based on the OSI 7-layer model of communications, and I'm currently a Network Engineer, so there's a natural segue for me. Lukeyson |
|||
Top | |
bowsaw |
|
|||
|
Uuumm okely dokely, understood the first bit, lol, good stuff.
|
|||
Top | |
Nicko |
|
|||
|
My scan tool arrived today that i had purchased off ebay - However it cant comunicate with car - once again i believe due to different pin wiring to the obd2 standard wiring on the scan tool
Ill have a look at the manual tonight and see if i can nut it out. I have to try and find out which way the scan tool is wired and correct it!
_________________ Nicko |
|||
Top | |
Lukeyson |
|
|||
|
What scantool did you end up getting?
I'm at the point now where while my ELM327 based unit does a whole lot for me (including managing headers transparently and doing CRC's for me for each message) it's just not fast enough at the Serial side to support a full bitrate 'packet capture' of all messages on my CAN Bus. I can certainly filter and capture specific broadcast messages - like BEM to IC for instance - but at the expense of not being able to see the other messages. I don't have much choice in the short term, but longer term to do the full capturing from another tool I'd have no choice but to user a higher speed tool, such as a Drewtech Mongoose (which is J2534 Passthrough compliant - which is a big deal since that will be the new standard that non OEM ECU Programmers will have to use.) Lukeyson |
|||
Top | |
Lukeyson |
|
|||
|
OK, a few beers in me, especially some nice 8.5% abv Belgian stuff (Gouden Carolus Classic - absolutely AWESOME beer), and I'm going to start waffling.
If I waffle while half munted, then later on we can pull all this together and make a tech article out of it. But for now, just let me ramble. (As more beers go in, more 'speel' checking will be needed ...) OBDII OBDII is a 'generic term used to describe a standards-based method for accessing a vehicle's self diagnostic and reporting capability'. This is being nice. Think of OBDII as a standard definition of a 'Portal' for accessing all of the 'Networks' in your car. And by 'Network' I mean just that - a strand of 1 or more wires that links modules in your car over which information can be transmitted back and forth. The OBDII standard includes a number of onboard 'network protocols' used to connect different computerised modules, or 'ECU's, on a car. I am going to bias this discussion heavily on the BA Falcon and newer, inclusive of BF Falcon and SX/SY Territory, but will include maybe a little but of relevance for other vendors (but not much). In Australia, it was mandatory that all carssold from the start of 2006 and onwards support OBDII. the BA Falcon, however, was compliant when it was first introduced back in 2002 - which I think is neat. The Commodore V6 was not compliant until the Australian built HFV6 was introduced in the VZ (None of the Buick V6 Commodores supported OBDII in Australia, even though they had OBDII support in the US from 1995), although the LS1 V8 Commodores have been OBDII compliant for quite some time (I don't have a year yet). The 'Port' used to access the 'Networks' on any OBDII Compliant Vehicle, including the BA Falcon, is described by Standard SAE J1962. This standard defines the size, shape, pins, voltages - all sorts of stuff. But essentially it's the port in the Fuse Box on every BA Falcon (or above). www.obd2cables.com sell lots of different types of cable for this port. Any scantool that is OBDII compliant must have a connector that can insert into a port of this nature. The J1962 standard describes which particular 'Networks' are accessible and on which particular pins you'll find them. The 'Networks' are described by even more standards themselves, and describe speeds and messaging protocols so that you can read - or write - data to or from devices - or 'ECU's' - on each Network. The 'Networks', the standards that describe them, and some basic usage information for each type of 'Network' are as follows; * SAEJ1850 PWM - 41.6kbps, used a lot by Ford * SAEJ1850 VPW - 10.4/41.6 kbps, used alot by GM * ISO9141 - 10.4kbps, used by Chrysler, European and Asian Cars - and by the BA/BF Falcon and SX/SY Territory for ABS/Traction Control Module (for Diagnostics Only - (ABS/TCS)), ABS/EVAC FILL Module, Parking Aid Module (PAM) and Restraints Control Module (RCM) * ISO 14230 KWP - Keyword Protocol 2000 (1.2 to 10.4kbps) * ISO 15756 CAN - 250kbps or 500kbps - By 2008, all vehicles sold in the US will be required to implement CAN. The BA/BF Falcon and SX/SY Territory has a 500kbps 11-bit CAN Bus, which connects the ABS/Traction Control Module, Audio Control Module (ACM - in the ICC), HVAC INtegrated Module (HIM), Instrument Cluster (IC), Body Electronics Module (BEM) and Powertrain Control Module (PCM). Last edited by Lukeyson on Fri Jun 27, 2008 11:50 pm, edited 6 times in total. |
|||
Top | |
Lukeyson |
|
|||
|
SAE J1979
The next stop in our description of how to access data on a BA Falcon network is this standard - J1979. J1979 was created by the EPA for accessing certain parameters from the onboard ECU. J1979 describes the first 9 'Modes' for retrieving information from an ECU, and the 'PIDS' used for Mode 01 access to Data. The Modes (from http://en.wikipedia.org/wiki/OBD-II_PIDs) are as follows: $01 Show current data $02 Show freeze frame data $03 Show stored trouble codes $04 Clear trouble codes and stored values $05 Test results, oxygen sensors $06 Test results, non-continuously monitored $07 Show pending trouble codes $08 Special control mode $09 Request vehicle information When it comes to Mode $01, there are up to 254 values that can be extracted from an ECU, but J1979 only describes the first 30. PID $00 shows which PIDS from $01 to $1F are supported in a 'bitwise' fashion. In addition, PID $20 does the same for PIDs $21 to $3F, and $40 for $41 to $5F. PIDs from $20 to $5F are described, however, by SAE J1920 - and are not supported by the BA Falcon. The mode $01 PIDS supported by the BA Falcon (and above) are: 00 Supported PIDS 01 # of DTCs and supported/completed Mode06 Tests 03 Fuel System Status 04 Engine Load 05 Engine Coolant Temp 06 Short Term Fuel Trim Bank 1 07 Long Term Fuel Trim % Bank 1 08 Short Term Fuel Trim Bank 2 09 Long Term Fuel Trim % Bank 2 0a Fuel Pressure 0b Intake Manifold Pressure 0c Engine RPM 0d Vehicle Speed 0e Timing Advance 0f Intake Air Temp 10 MAF Airflow 11 Throttle Position 12 Sec. Air Status 13 Oxygen Sensors Present 14 Bank 1 Sensor 1 Ox Sensor Voltage Short Term Trim 15 Bank 1 Sensor 2 Ox Sensor Voltage Short Term Trim 18 Bank 2 Sensor 1 Ox Sensor Voltage Short Term Trim 19 Bank 2 Sensor 2 Ox Sensor Voltage Short Term Trim 1c OBD standards this vehicle conforms to 1d Oxygen sensors present When you download a free 'Scantool' utility that is said to support J1979, you can expect that these are the values you will see extracted by that utility from a BA Falcon (Or above). I have not included some values as you may notice - excluded values are not supported by the BA ECU. No matter what OBDII Compliant Scantool you buy, these Mode $01 J1979 PIDS will be available. All of the 'freeware' scantool utilities support these PID values. If you buy some software then you may find a little bit more supported - such as the EPA Mandated Mode $06 values - but not much more. Some software is able to provide calculations based on the values extracted using J1979 - such as 0-60Mph (or 0-100kph) times, and rolling-dyno based on accleration times combined with endered values for Vehicle Weight, Tyre Width and Tyre Diameter. Everything else, however, requires a tool custom developed for Ford, or custom developed tool for Flash Tuning (Such as the CAPA / Herrod flash tuner tools, or thge CAPA XCalibrator 2). Of note here is if you have the 'Engine Warning' Light on your car flashing at you. If this is the case, then a 'DTC' value (Diagnostic Trouble Code) will be written to the PCM (Powertrain Control Module) which can be read by a J1979 compliant Scantool using Mode $03. A list of 'DTC's are available which describe what type of problem triggered the error code. You can also use a Mode $04 command to clear these trouble codes - although this is only recommended if you have fixed the proble that caused the DTC in the first place. Otherwise another DTC will simply be written to the ECU to flag that the problem still exists. I have extracted the error codes from different references that I've managed to find on the Internet and will post them shortly. Lukeyson Last edited by Lukeyson on Sun Apr 08, 2007 9:32 pm, edited 3 times in total. |
|||
Top | |
Lukeyson |
|
|||||
|
OK, here's the file that lists the DTC's for the BA Falcon (and above).
Note that I have constructed this DTC list myself. This may also be available elsewhere on the 'net, I haven't checked. Lukeyson
|
|||||
Top | |
Lukeyson |
|
|||
|
OK, enough for today.
I need to explain the standard for how the DTC messages are constructed, but have run out of steam for now. I plan to discuss SAE J1978 next - OBDII Diagnostic Tools - with an obvious emphasis on the ELM327 based tool I am using - it's capabilites, advantages and drawbacks. This will be followed by more of a discussion on CAN - sending/receiving messages, 11 bit CAN address formats and broadcast messages. This, my friends, is the interesting stuff, and may well need to wait until I have reverse engineered my own cars first. I will, however, also include a tutorial on how to use an ELM327 based Scantool to extract information yourself. Oh boy am I munted. I'll be suprised if I wake up in the morning and any of this makes sense..... Lukeyson |
|||
Top | |
michbound |
|
||
|
{USERNAME} wrote: I just placed and order for an ELM327 based OBD2 to RS232 Scantool from here: http://www.obdallinone.com. It was about the cheapest version of the ELM327 scanners I could find.
Lukeyson Just wanted to plug my ELM327 compatible scantool, that is probably the cheapest version USD $ 84.99. Check out http://www.obdpros.com Plus it has a couple of features such as higher speeds upto 128KBPS Thanks Paul www.obdpros.com |
||
Top | |
Lukeyson |
|
|||
|
Hey there dude, you must be linking across from mp3cars.com. If your tool had been around (or perhaps if I'd known about it) when I was in the market for one, I would have gotten yours.
I've noticed that the Digitmoto 4.03 version that supports the ELM327 command set only supports 9.6kbps. And all my captures are done at 38.4kbps, so I have to keep cracking the case open on my unit to change the baud rate. The ability to change the bitrate on yours without having to open the case is nice. I do appreciate that the speed is much faster, and for that reason alone it's better than the unit I have. I recommend yours over the one I have yes. I just wish there was some way to capture at the full 500kbps rate from the CAN bus at your price point. My guess is that this would not be too far off. Tell me, do you reckon you'll ever have J2534 support for your unit? As I understand it that's just a matter of implementing an API that accepts J2534 calls and converts them to ELM commands right? (To everyone else, I'll describe what J2534 is later.) Lukeyson Last edited by Lukeyson on Sun Apr 01, 2007 2:43 pm, edited 1 time in total. |
|||
Top | |
Nicko |
|
|||
|
Hi Luke,
http://cgi.ebay.com.au/Electronic-vehic ... dZViewItem thats the one i bought - except mine was cheaper. My reason for going for this was more so for Clearing dtcs after my flash tune - it also has the dtc stored in the unit so no reading a manual to find the dtc code - However it doesnt appear to work on my BA - i believe wiring will be llightly different - Maybe its proprietry wiring for ford?
_________________ Nicko |
|||
Top | |
michbound |
|
||
|
{USERNAME} wrote: I just wish there was some way to capture at the full 500kbps rate from the CAN bus at your price point.
My guess is that this would not be too far off. Tell me, do you reckon you'll ever have J2534 support for your unit? As I understand it that's just a matter of implementing an API that accepts J2534 calls and converts them to ELM commands right? Lukeyson Hi Luke, Yeah I would like to get the scantool to be capable of keeping up with all the can messages at 500 KB, I am working on it. The J2534 API is the way most of the car manufacturers prefer to work with, unfortunately most of the hobbyist targeted software is written for the ELM327 based ASCII protocol, that means before I support J2534 I need to also ensure I have a client software that can do things like the Digimoto gauges etc... As far as getting the J2534 layer working it's pretty much a matter of writing a client side DLL that supports the J2534 API. So currently the plan is to have a version that can do both J2534 and an ASCII version. I will keep you posted on the progress. Thanks Paul www.obdpros.com |
||
Top | |
Who is online |
---|
Users browsing this forum: No registered users and 29 guests |