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!

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

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.

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.

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

 

 

Attachments:

File comment: DTC's for BA Falcon and above. BA BF Falcon and SX SY Territory DTCs.xls [47 KiB] Downloaded 5996 times

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

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

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.

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?

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

Hi Neo_nick,

I noticed that the tool you linked to does not seem to support the CAN protocol, I think the reason it does not work with your BA is because the BA uses the CAN protocol so I doubt that you will be able to use this tool with the BA, I could be mistaken but it seems that the scantool supports everything but the CAN protocol

Thanks
Paul

The data on that product is confusing. While only listing the 4 x protocols excluding CAN, he mentions further down that it supports the CAN protocol for the BA/BF Falcon. So it either does or it does not support CAN. If it doesn't, then he's issued a false advertisement.

It DOES support the ISO9141 bus, but like I mentioned above, only ABS/TCM, PAM and RCM are on that bus.

The J1962 standard is very clear on which pins are supposed to be CAN. If it is an OBDII compliant device there's not much room for ambiguity. The only ambiguity comes with so called 'OBD1.5' devices that use OBDI onboard, but have an OBDII connector - which was the case on some GM cars from around 1995.

The CAN support is something that needs to be clarified because the DTC's you want to clear are on the PCM - which is on the CAN Bus. If it does not do CAN, and the eBay advertisement says it does, then you have very good grounds to return it and get your money back during his returns period on that item, or submit a dispute.


Lukeyson

Hi Mitch - I might have to have alook at your products to do the job then!

HEX Values

I thought I'd do a quick write-up on hex.

Generally, any value you see relating to OBDII communications is represented in HEX. Even when not explicitly stated, in many cases the numbers will be HEX anyway. Hex numbers are written in a few ways, but of note you find a Hex value as either $01 or 0x01.

In the decimal numbering system, we have 10 digits (not so coincidentally, the same number of fingers and thumbs on a human being). So therefore the digits are 0123456789.

For binary we only have 2 digits - to represent on and off - and these are just 01.

Hexadecimal, however, uses 16 digits. They are 0123456789ABCDEF.

So 10 in decimal is decimal 10 (Hang with me here). 10 in Binary is Decimal 2. And 10 in Hexadecimal is Decimal 16.

Hexadecimal is great for use with computers, because it works well with binary, and dramatically reduces the number of individual digits needed to represent larger numbers. For example, the binary digits 1111 are equivalent to the Decimal value of 15, but in Hex it is F.

So why does Hex work well with Binary? Well each individual Hex number is made up of 4 x Binary Numbers known as 'bits'. 4 Bits are also known as a 'Nibble' - just a bit of trivia there. But 2 x Nibbles make a 'Byte' - and if anyone has even remote knowledge of computers the term 'Byte' will be familiar - as a value that is used to measure a volume of information. 'Bytes' are used to measured stored Data for example (eg 1 x Mega Byte = 1 000 000 Bytes - or 1 048 756 Bytes for the binary pedantic).

A single Byte, however, is now easily represented by 2 x Hex numbers, which makes life a whole lot easier for being able to display heaps of digits on asmall screen.

So now we have the basics, how do we convert from Hex to Decimal to Binary easily? Well I could go into the math, but for me, good old Windows Calculator is all I ever use and all I ever intend to use.

Start - Programs - Accessories - Calculator. Click 'View' and make sure the 'Scientific' radio button is selected. You'll notice that Calculator now grows to have a whole lot more buttons.

To convert from Hex to Decimal - do the following.

(1) Select the 'Hex' Radio button.
(2) Enter the inital 'Hex' value.
(3) Select the 'Decimal' Radio button

Done. And you can do this to convert between any of the 4 x listed number types - although I've yet to find any meaningful use of 'Oct'.

This kind of theory is a requirement for much of what I'll talk about later.

For example, when I open or close a door on my car, a particular 'bit' changes from a 0 to a 1 in the first byte of CAN broadcast $403.

Now lets suppose at the start the HEX values I saw in the first byte of broadcast $403 message was 00. Converting to Binary this is of course 00000000. Now say this door is the Rear Right door, so it will represent the 3rd bit from the left. When the door is open the Binary value changes from 00000000 to 00100000. If I convert this to Hex, what I will see on my scantool is that the original Hex value changes from 00 to 20.

If you're unfamiliar with Binary/hex and conversions to decimal, then I suggest you simply get very familiar with Windows Calculator until you get used to it.

Because without it I'll lose you from here on.....


Lukeyson

Last edited by Lukeyson on Sun Apr 01, 2007 4:52 pm, edited 2 times in total.

Keep in mind that the tool I bought, and the tool Mich is talking about, are 'OBDII to RS232' or 'OBDII to USB' scantools. This then implies you need a PC to connect to them.

The tool you provided a link to was stand-alone and didn't need a PC.

I didn't want you to go ahead on advice without making that bit clear. I have 2 options at home. My old 1GHz Torrent-Box is in the shed, and I run a 10Metre Serial DB9M/DB9F Cable from it to my car. I also have a Notebook supplied with work and a power converter for the cigarette lighter for doing captures while drving.


Lukeyson