Nice work thus far. Along the lines of what I've wanted to do, but I haven't had the time.

I'm currently using (software wise)
Pro-Scan and,
PCMSCAN

PCMSCAN dashboard

(it's fully configurable)

I hadn't seen PCMSCAN before, and looking at the website, it only becaome compatible with the ELM327 around February, and there has been a lot of development activity since then.

I downloaded it, and it looks nice. Some stuff is locked out until you pay - they advertised it as a fully functional demo so i was a bit bummed. You must have spent some time doing the custom layout, because I hit that page and had no idea what to do. An RTFM will undoubtedly help.

I notice from teh screen shots - assuming they are yours - that you have a GT-P. Is there any chance that you have an ELM327 scantool? If you do, I'd love to hit you up for a scan of broadcast messages from your CAN Bus. I've got data from a BAXR8, SX Territory Ghia and a BFXR6T and would love to be able to expand my data set to match some values.


(EDIT - Oops, I now see that PCMScan has been working with ELM327 since Feb 2006 - quite some time. My bad.)


Lukeyson

Last edited by Lukeyson on Thu May 03, 2007 10:35 pm, edited 1 time in total.

Check my sig, yes I've got a GT-P, and the screen shot is mine.

What do you use to gather the broadcast messages? All the software I've used, only reads stuff you ask it for.

Happy to help if possible.

edit: I got a licensed copy of PCMSCAN with the scan tool I bought. And yeah I've got an ELM-327.

OK. Time for me to finally get to some tutorial stuff then eh?

Enough with the theory, and into the practice.


ELM327 based Scantool.


In order to get going, I bought myself an ELM327 based serial scantool from www.OBD2allinone.com. There was nothing special about their unit other than their price.

The one thing I chose to do to the unit is to make it run as fast as possible, and for that reason I have to manually open the unit in order to set the jumper to 38400bps. It comes by default set to 9600 bps. I believe all of the genuine ELM327 based units require this manual jumper setting. There are other ELM327 compatible systems out there that can be soft-set to 115200bps.

PICS attached, and then the tutorial shall continue.

 

 

Attachments:

File comment: The OBD2AllInOne Serial Scantool with OBD2 and Serial Cables. I also bought a 10Metre Serial Cable to allow be to use an old PC in the Garage for scanning. IMG_0926_Web.jpg [ 17.36 KiB | Viewed 453 times ]

File comment: The small screwdriver points to the location of the Jumper that has to be set to 38400bps IMG_0932_Web.jpg [ 24.21 KiB | Viewed 525 times ]

Software


If you want to pull out the Standard J1979 stuff, then you can make do with any one of the free utilities. The PCMSCAN listed in the previous posts looks pretty damn good to be honest. Digimoto was my preferred software before that came along. But PCMSCan is $100 US so it's not cheap.

For my work, I use Windows Hyperterminal.

In Windows, do the following:

Start - All Programs - Accessores - Communications - Hyperterminal

In some versions of windows, if it's not there, you may need to go into Control Panel - Add Remove Programs - Add/Remove Windows Components - Accessories and find Hyperterminal to add from in there.

Now, when Hyperterminal Starts Up I do the following:

* New Connection - Give it a name like 'Serial Scantool' then Next
* 'Connect-Using' needs to be set to your COM Port (eg COM1) then click CONFIGURE
* bps = 38400, then bits=8, parity=none, Stop Bits=1, flow-control=none
OK
OK

Now, plug your Scantool into the OBD2 Port on you car to get power (even with no key in the ignition) and the lights should come on. You should get an 'ELM' Prompt of some sort.

There's very little available to you at this point because the CAN modules are not powered. So insert a key and turn the ignition past accessories to ON.

Now we're in business.

You should be able to issue an 'ATZ' to Hard Reset the unit, or an ''ATWS' to soft reset the unit. If you get a response, then you're ready to go. If not, then check your cables, that you have lights on the ELM unit, that you have the unit set to 38400 and that the serial settings for the device were as described, and that you're using the right COM Port.

When you type something that starts with an 'AT' (it is not case sensitive) than the Scantool will assume the following text is directed at it and will change configuration according to the command.

When there is no AT command, the message is translated to the OBD2 Port and the message is transmitted on whatever Bus is being used.

To see what Bus has been auto-detected, type 'ATDP' to Describe the Protocol. You should see that it has auto-detected CAN 11-bit 500kbps. There is another bus on the OBD2 port called ISO9141, and we can change the Module to issue queries and look at that Bus, but for now we'll stick to CAN and get to that stuff later.

You'll find the ELM327 Data Sheet attached to this post. You can find all of the AT COmmands in there and what they do.

So let's move on to the stuff that's more fun.

 

 

Attachments:

File comment: ELM327 Data Sheet ELM327DS.pdf [182.99 KiB] Downloaded 1393 times

Last edited by Lukeyson on Thu May 03, 2007 9:26 pm, edited 2 times in total.

J1979 DATA


Let's get going.

At this point, the ELM327 unit is configured to make life as nice for you as possible. It inserts and rips off the headers, the byte-length, the PCI byte and the padding and CRC bytes for you. What could be better than that!

If we go back a few pages on this thread - on page 2 I list the Modes and PIDS for many of the J1979 data. SO lets have a go at that.

We'll try the first option - listing the supported PIDS. This is a Mode 01 PID 00 request. So in Hyperterminal type:

0100

The response on my BA XR8 was:

BF 9F B9 10

So WTF does that mean?

Well, Mode 01 consists of PIDS 00 to 1F in hex. Put 1F into your windows calculator and you get 31. However, when you include PID 00 this is really 32.

So if every HEX values is 4 bits, with 8 Characters that means we have 32 bits right? So that 8-Character string above represents the supported PIDs on the BA Falcon using a Bitwise mapping.

Therefore, for every bit that's a 1, we have a supported PID. For every bit that's a 0, the XR8 doesn't support that PID. Back on Page 2 you'll notice that I've skipped a few numbers from 00 to 1F - and you guessed it, those that I skipped are the PIDS that are not supported on the BA Falcon/SX Territory.

So let's try another one. Mode 01 PID 01 has 2 lots of information, and I covered off on this before. Byte 1 tells me the number of Fault Codes logged, or DTC's. The 2nd, 3rd and 4th Bytes are a bitwise representation of supported and completed Mode 06 Diagostics Tests.

So I type
0101

and I get
00 06 60 60

So no fault codes. Beauty. If I did have a fault code I would issue a mode 03 request in order to list the codes like so:
03

And to clear the codes I would issue a mode 04 request like so:
04

On page 3 I talked about Mode06 and what it is, as the '06 60 60' refer to that.

You can issue single byte PID queries to your hearts content. All of the Scantools on the market use this polling technique to get live data out of your car, but only this data.

There's a lot more data to be had yet.

Modes 01, 02, 05, 06 and 09 require PIDS. You can get your VIN number out of Mode 09 PID 02 for example. The BA Falcon doesn't support storing the results of Continual Diagnostics, so there are no Mode06 values to be had I'm afraid. Other Modes don't require PIDS and are used for clearingDTC's or listing saved data.

There are a few other modes not described by J1979. Of interest is Mode 22 - which is where all of the Ford Proprietary data is kept using double-byte PIDS. You can explore yourself by issuing commands that look like this:
220000

Mode 2F is for issuing Diagnostic Mode Commands. These things trigger the diagnostic tests that you see in the Workshop Manual and are very specific.

And Modes up around 35, 36 or 37 are for raw data transfers between Modules and the Diagnostic Tool. If anyone has a CAPA, Herrod or BPT (or any other rebrand SCT Flash tool) then I'd like to see captured messages to see if these are the modes being used. There may be an issue with the 38400bps limit on the serial side, but I think it would be worth at least trying to capture. I'll hopefully do this myself come the new financial year if all goes well.

All of these modes are defined generally in standard J2190, but the actual PIDS and what they mean are proprietary to Ford - and we may never know these without reverse engineering a WDS/IDS/NGS tool, or finding someone compassionate to our interests within Ford.

But the bit that triggered this, and the bit that might be of interest to all of us, is the Module-to-Module communication that I've been calling 'Broadcasts', and which carries much of the data we're all interest in real-time without having to issue any queries.

And that's next.

Last edited by Lukeyson on Sat May 05, 2007 12:44 am, edited 2 times in total.

Scanning Broadcasts


I have to state right now that things from this point do get a little bit complicated because of one reason - the slow bitrate on the Serial Side of the ELM327 unit. When traffic is being received at 500kbps on the OBD2 side, the poor ELM327 can't pump out the data fast enough on the 38.4kbps side to keep it's buffer from overflowing.

So what we have to do is filter the data.

Not only that, but we need to turn on 'Headers' so that we can tell which 'Address' the message is using.

So let's do it.

First of all, I turn on headers:
ath1

Then I set what is called a 'Mask' - which tells the system which 'bits' in the filter I need to match. Since I want specific messages at a time, I mask the whole header with masked bits so that they must match the filter exactly. Stay with me here. So I issue the command:
atcmfff

Next, I want to select the 'broadcast' messages that I want to observe. I'll start with a nice one first - 307. 307 is a message from the ICC and shows from Manual Climate Control cars the Fan Blower Speed, Temperature setting and has bitwise values for the pressing of the buttons on the ICC. For Auto Climate Control cars the manual fan/temp bits are set to F each, and we now see values for all of the extra buttons - passenger&driver temp up/down, manual fan speed up down, and different vent outlet buttons.

So I issue the command to set the filter so that only messages with the header of '307' get through:
atcf307

Now I want to listen to all of the messages. being sent with header 307, so I have to turn on the listening mode. With the filter and mask in place, only messages with the 307 header will get through. So to start listening to all filtered messages I issue the command:
atma


Note that if I did not set the mask and filter, that ALL messages will come through, and this quickly overflows the buffer. But it would give you a quick snapshot of many of the messages that are available. To listen to everything, do thw following:

Soft Reset the unit:
atws
Turn headers back on
ath1
Turn on listening mode with no filters
atma

Messages will look like this:

307 00 00 00 80 00 00 00 1E

The 307 is the header. The Byte length, PCI Byte and CRC have all been stripped off, so the 8 bytes visible are all data bytes.

In the MCC excample, if you turn the TEMP dial you should see the 12th Hex Data Character change value (Don't count the header characters). If you change the Fan speed you should see the 14th Hex Character change value.

If you press the A/C button, you should see the 1st Character increment by 8 - so if it is 0 it will become 8. If it is 3 it will become the Hex value of 11 - which is B.

All of the possible headers are listed toward the bottom of page 2. That Page will get a bit of an edit soon, as I have done quite a lot of mapping to get a much better idea of what does what. I plan to add an attachment showing all the values I've translated, and will update it if any more information comes to light from shared logging. Some of the listed 'YTFO' messages have been partially uncovered. And for the rest I now have a list of many of the 'Messages' sent between modules as listed in the workshop manual, which will help me locate even more messages.



So, to take a data-log of a car, at the moment you need to the do the following (until i write a utility to automate much of this):


(1) In Hypterm, select 'transfer' and 'Capture to Text' and create a new file to capture the data to. Use the type of car (Say BAXR8 or SXTG for Territory Ghia, or BFFG for BF Fairmont Ghia) and the DATE (eg BAXR8 3-5-2007 9-16pm.txt)
(2) issue all of the commands up until setting the filter
(3) Set the Filter address one of those listed on page 2.
(4) Issue the ATMA command and capture for a minute or so, then hit any key to stop the capture
(5) Issue the 'ATCF' command with the next Header in the list
(6) Go back to (4) and reiterate until all headers have been captured.
(7) When done, stop capturing data in Hyperterm 'transfer' - 'Capture Text' - 'Stop'

(8) Edit the capture file and Record some relevant data - like:-

* whether your car was hot or cold,
* fuel tank level,
* car running idle, driving or off,
* Sunny, Cloudy or Dark (If you have acc or auto-lights off)
* what settings you have on your Air Con
(MCC recirc/fresh, which vent, rear demist, ac on/off, fan speed and temp settings)
(ACC - Pass Temp set, Drivers Temp set, Auto, Semi Auto, Fan Speed, rear demist)
* your trip computer settings (Avg Economy, Avg Speed, Trip Time, Instant Economy),
* engine type,
* Climate Control Type,
* transmission type (M5, M6, A4, A6)
* If Territory, 2WD or AWD
* If Territory, if HDC is fitted
* reverse Sensors fitted
* Side Airbags fitted
* traction control only or stability control

And then post it here or PM through and we'll add it to the Data we already have.


Lukeyson

Summary of Commands used so far, and addressing other Module



ATZ - Hard Reset
ATWS - Soft Reset

ATCM = Set the Mask
ATCF - set the filter
ATMA - listen to all packets let through by the filter

ath1 - turn headers on
ath0 - turn headers off



Lukeyson

Last edited by Lukeyson on Wed Mar 12, 2008 7:33 pm, edited 1 time in total.

Seems there's quite a strong movement in the US to stop manufacturers keeping all their ECU codes proprietary.

http://www.righttorepair.org/


And as a bit of an update, I'm currently coding up a tool in VB using .net 2.0 that will help me do more thorough scans, and help me find PIDS in other ECU's that respond.


Lukeyson

Give us a copy of your proggy (I also program in VB.net, so if you need any help), I'm on leave shortly so will have some time to play around with this stuff.

Great source of info, Lukeyson and others
Thanx guys!

Anyway, I am going to start a design of a new digital cluster for my F6, ie. use a few 6" LCD displays to do RPM, Speed etc, so they will completely replace my stock cluster, this way I can decide what info I want to display, and at the same time I can do away with the carputer.

I have an Autoenginuity scantool, so for now it will do as a diagnostics interface to the carputer, but I will most likely end up getting a Canbus-USB interface directly onto the new microcontroller I will develope for the instrument cluster.

I will post a link to my worklog here, if you guys are interested.

Thanx anyway for all the quality info and effort you guys are putting in, it makes things a lot easier (and faster) to get my project underway.

Best regards,
MrBean.

Sounds like an interesting project. I'm just wanting to show some stats and graphs on the ICC screen.

Yep, interested.

And the proggy is 'still in development'. I'm having to clear some serious rust and cobwebs out.... It's going to be a few weeks at this point till I have something useable.


Lukeyson

I am using a new Xenarc 7" LCD to display my data, I found that the text resolution on the factory ICC TFT screen to be poor quality, ie notcrisp and clear, difficult to read, grainy.... I am using an Apple MacMini as my Carputer, please see this thread at Mp3car

The last page or so have info and a few pics of the built, where I installed it, the converter used for the ICC, which showed crappy res text, I then tried my Ultimarc ATi-based card which can drive the 15khz CGA-type ICC too - same results.

I will post new pics on Friday of where and how I mounted the Xenarc, 1000% better quality, and much better display resolution - 800x600 vs stock Ford ICC of 640x480.

edit: Pics posted

It works like a dream now, still need to sort a few small issues, mainly GPS software, etc.....and a decent frontend.

Browse over and have a looky, might give you some ideas.

Will keep you guys posted.

Best regards,
MrBean.

ps: Soz for offf-topic, it's still semi related.

@ Lukeyson:

Maybe you want to have a lookie at this

I use Softing Profibus Gateways in our Industrial Process Control DCS, and they are a top-class manufacturer of Gateways.

I see they have a wonderful range of interface cards for both 11- and 29-bit CANbus, as well as decent analyzers for these protocols.

Would be of great help to our cause.

I will contact a few of the Softing distributors, and see what/if I can arrange, at what price.

The pcmcia model certainly has my interest......let me know what you think, and I will come back to you.

edit1: On the same note, I am a certified profibus specialist, which, similar to devicenet, uses the same osi 7-layer model as the protocol, and also similar to canbus, of course not all 7 layers of the osi model is used, in the case of profibus 1,2 and 7 (physical, data, application layers)

Now, I have a spare profibus card, and my feeling is profibus protocol would be the same as canbus, but the electrical characteristics are different, eg the transport medium - profibus is electrically really only RS-485.....

Me being a DCS System Specialist at Metso Automation, one of the largest suppliers of Automation Systems in the Pulp and Paper Industry in the world, have got very, very nice software/analyzers etc for profibus - if I can interface canbus to profibus, I can use our standard tools to display every little detail graphically, numerically, whichever way I see fit on our Operator Station displays.

It would make analyses so easy And quick. I will have a chat to one of our Finnish R&D developers, and see if they maybe can develope some DCS programming blocks to directly interface our programming language to CAN, that will make it even easier - as mentioned, I think software protocol is very similar, if not the same, between profibus and canbus.

I will get back to you.
End of rant.

edit2 Just a quick thought, have you tried to use Ethereal (nowadays called Wireshark) network analyzer to study your messages?

Or can't you select the obd-scanner as a device? I will try my Autoenginuity tomorrow.

edit3 "old" DYI Automotive CANbus interface with software

edit4 Just realized that Devicenet is actually based on CANbus, it anyway uses the CANbus Datalink Layer, but it's own Application LAyer - pity, as I can also get my hands on Devicenet modules to interface to PC