Member Since: 05 Feb 2006
Location: ¯\_(ツ)_/¯
Posts: 17932
galwaygreen wrote:
glad im a chippy...but it all looks very impresive...good luck
Wish you could repair the wood cladding either side of my dormer windows as I am rubbish with wood!Land Rover - Turning Drivers into Mechanics Since 1948
Member Since: 24 Jul 2010
Location: Malta
Posts: 1163
I am very interested in this and commend Alex for his work. I have 10 years software development (desktop, mobile and embedded) experience but while I had looked into this a while ago, I concluded I really don't have the necessary time to develop the software so forked out the cash for an IID Tool.
Tools such as this require huge truck loads of effort, especially in the research and testing departments. They must be literally bulletproof. Hence why diagnostic tools appear to be expensive. Honestly £300 for an IID Tool is really cheap for the amount of effort that goes into developing such a tool.Dennis
2006 Discovery 3 TDV6 Commercial Manual Buckingham Blue
31st Oct 2013 10:45 pm
alex_pescaru
Member Since: 19 Dec 2010
Location: RO
Posts: 270
Episode 2: still more theory...
I've said in the previous message that any message is sent over the CAN bus network consists primarily of an ID (identifier), which represents the priority of the message, and up to eight data bytes.
Now, when starting a diagnostic session, all communications should comply with ISO15765-2 from the format point of view. And all messages/frames will have a fixed number of bytes, eight ( 8 ).
But there are cases when the data that should be transmitted is smaller than 8 bytes or bigger then 8 bytes. So first byte (or first 2 for longer than 8 bytes messages) should be the length of the message. All is standardized in ISO15765-2.
Below will focus here only on "read DTC function/service".
According to the ISO14229, the ReadDTCInformation service has a code of 0x19. It's a very complex service with many subfunctions, but for the sake of simplicity we will focus only on one subfunction, reportDTCByStatusMask.
This subfunction has a code of 0x02. And because it reads the DTC(s) by a status mask, the next byte should be, of course, the status mask.
The status mask is a bit codded byte where each bit represents the following:
bit0 - Test Failed
bit1 - Test Failed This Operation Cycle
bit2 - Pending DTC
bit3 - Confirmed DTC
bit4 - Test Not Completed Since Last Clear
bit5 - Test Failed Since Last Clear
bit6 - Test Not Completed This Operation Cycle
bit7 - Warning Indicator Requested
When requesting the stored DTC(s), we're meaning the old DTC(s), tested ones, so we will not take into consideration bit6 and bit4. So the final mask when asking for DTC should be, generally, 0xAF.
These said, all can be concluded in the followings:
When you want to read the DTC(s) from a module you need to know and do the followings:
1. Know CAN network where that module is and network speed. For example engine ECU is on high speed CAN, speed being 500 kbps.
2. Know CAN message ID at which that module responds. For example, for engine ECU, in case of Disco3, 0x18DA10F1.
3. Build a message/frame that complies with ISO14229 and ISO15765 and send it over CAN.
In short, for above example, you should send over high speed CAN, at 500kbps, a message/frame with:
ID: 0x18DA10F1, with the following bytes:
Message: 0x03 0x19 0x02 0xAF 0x00 0x00 0x00 0x00
Meaning:
0x03 - useful message length
0x19 - service code, in this case ReadDTCInformation
0x02 - sub-function, in this case ReportDTCByStatusMask
0xAF - DTCStatusMask
0x00 - filling/padding byte
0x00 - filling/padding byte
0x00 - filling/padding byte
0x00 - filling/padding byte
Notice the last 4 bytes that are 0x00. They could be any value but I've saw that some modules are "irritated" if they aren't 0. So better be 0.
Now the response from the ECU...
First the negative response.
When the ECU doesn't like something will respond in kind.
From the ID point of view, it will respond according to network architecture (11 or 29 bits), like I've said in the previous message.
For the same sake of simplicity will explain it by example.
At the above request the ECU could respond:
ID: 0x18DAF110 (notice the reversed last bytes)
Message: 0x03 0x7F 0x19 0x78 0x00 0x00 0x00 0x00
0x03 - useful message length
0x7F - error
0x19 - service that triggered the error, in our case 0x19, ReadDTCInformation
0x78 - error code, this means: Request Correctly Received - Response Pending, meaning "wait a little, I am busy..."
0x00.... - padding bytes
Now the positive responses:
The positive responses, for the ReportDTCByStatusMask subfunction, are defined by the ISO14229 like this:
0x59 - positive response. Always, when a positive response, it will be built by adding 0x40 to the initial function code, in this case 0x19.
0x02 - subfunction code, in this case ReportDTCByStatusMask
0xXX - DTC Status Availability Mask, meaning which bits from the requested DTCStatusMask are supported and returned.
...., ...., - DTC(s), if any, grouped in 4 bytes records.
Each for 4 bytes records has the following structure:
DTCHighByte, DTCMiddleByte, DTCLowByte, statusOfDTC.
DTCHighByte and DTCMiddleByte form the DTC error code.
DTCLowByte form the subcode of the DTC
statusOfDTC is any combination of the DTCStatusMask's bits telling what kind of error is this: Intermitent, Permanent, Historic, Pending, etc.
Example:
Engine ECU responds to the above interrogation like this:
ID: 0x18DAF110 (notice the reversed last bytes)
Message: 0x07 0x59 0x02 0xFF 0x06 0x1B 0x81 0xA9
0x07 - useful message length
0x59 - positive response (0x40 + 0x19)
0x02 - subfunction code, in this case ReportDTCByStatusMask
0xFF - DTC Status Availability Mask, in this case all bits set to 1, so ECU is capable of reporting all kinds of errors.
0x06 0x1B 0x81 0xA9 - DTC error code, decoded like this:
0x061B - DTC, meaning Powertrain error P061B, Internal control module torque calculation performance
0x81 - DTC subcode, meaning: Bus signal/message failure - invalid serial data received
0xA9 - DTC's status, meaning: FailedLastTime Confirmed FailedSinceLastClear MILRequested
Another example, without DTCs
ID: 0x18DAF110 (notice the reversed last bytes)
Message: 0x03 0x59 0x02 0xFF 0x00 0x00 0x00 0x00
0x03 - useful message length, only 3 bytes follows, the standard response preamble
0x59 - positive response (0x40 + 0x19)
0x02 - subfunction code, in this case ReportDTCByStatusMask
0xFF - DTC Status Availability Mask, in this case all bits set to 1, so ECU is capable of reporting all kinds of errors.
0x00... - padding bytes, no errors
Last edited by alex_pescaru on 1st Nov 2013 9:27 am. Edited 3 times in total
1st Nov 2013 8:55 am
alex_pescaru
Member Since: 19 Dec 2010
Location: RO
Posts: 270
SteveNorman wrote:
So if you have a Can Bus fault, say a wiring fault, with CAN communication fault codes, is there any way of 'seeing' which modules are offline? Or is it no different than seeing the modules on SDD?
I don't really understand where you pointing out, but if you referring to wiring faults on the physical network it could be like that:
- if you have an interrupted wire on the main network, none of the modules will communicate and be seen on SDD
- if you have an interrupted wire just on the network that leads to one of the modules, it will be like that module is not connected on the main network and only that module will not respond and seen on SDD.
- if you have a short on one of the CAN wires, none of the modules will communicate and be seen on SDD
1st Nov 2013 9:18 am
nighthawk
Member Since: 24 Jul 2010
Location: Malta
Posts: 1163
Excellent work Alex... you're almost giving me the motivation to try Dennis
2006 Discovery 3 TDV6 Commercial Manual Buckingham Blue
1st Nov 2013 10:23 am
alex_pescaru
Member Since: 19 Dec 2010
Location: RO
Posts: 270
The last thing: erasing errors.
According to the ISO14229, the ClearDiagnosticInformation it's a simple service and has the code 0x14.
After the service code, there is a sigle 3 byte parameter which represents the groupOfDTC.
The groupOfDTC parameter allows the client to clear a group of DTCs (e.g. powertrain, body, chassis, etc.), or a specific DTC.
To erase all codes, the groupOfDTC parameter must be 0xFFFFFF.
In short, you should send over CAN a message/frame with the following content (we will give example, as before, erasing engine DTCs):
ID: 0x18DA10F1
Message: 0x04 0x14 0xFF 0xFF 0xFF 0x00 0x00 0x00
Meaning:
0x04 - useful message length
0x14 - service code, in this case ClearDiagnosticInformation
0xFF - groupOfDTCHighByte
0xFF - groupOfDTCMiddleByte
0xFF - groupOfDTCLowByte
0x00 - filling/padding byte
0x00 - filling/padding byte
0x00 - filling/padding byte
As in any case could be negative or positives answers from the ECU
For a negative answer, in the response message, after the length byte will be 0x7F and a few bytes after which explains the error.
For a positive answer, in the response message, after the length byte will be 0x54, 0x14 + 0x40 as explained in the previous message.
For example, for positive answer:
ID: 0x18DAF110
Message: 0x01 0x54 0x00 0x00 0x00 0x00 0x00 0x00
0x01 - useful message length
0x54 - positive response (0x14 + 0x40)
.... - filling bytes
That's pretty covers, at a glance, the reading and erasing errors. Of course there are much more to be said, but for a complete image you should study the ISO14229 document or just ask here.
Now the practical stuff.
Below is the schematic that I've used on my diagnostic tool.
It's a modified version of the CAN BUS monitor demo kit from Microchip.
With the schematic above you can do whatever you want: set any communication speed (we are interested only on 125kbps for Low Speed CAN and 500kbps for High Speed CAN), send any command, etc.
The schematic implies an USB connection to a computer, but if you attach a LCD display to one of the microcontroller's free ports and a few buttons, you can make a stand alone fault code reader.
Or you can do both: stand alone and computer connected.
The schematic its pretty self explanatory:
- a PIC18F4550 microcontroller with USB interface - handles all intelligence stuff and USB stuff
- a MCP2515 stand-alone CAN controller - the chip that implements the low level CAN stuff
- a MCP2551 high speed CAN transceiver - handles electrical interface from tester to car
- a few passive components.
All these for just a few quids from any electronic department store.
You can build it for yourself or buy that CAN Monitor demo board from Microchip and apply the modification you see in my schematic in red.
As you have 2 CAN-buses on the car, I've used a pin from the microcontroller to switch the buses through a small PCB mounted relay.
The firmware for the PIC18F4550 controller is on the Microchip site.
The program for driving the whole electronic thingy is in this moment implemented only for Freelander 2, my car, but it can be easily adapted to Disco3 as you have to modify only the IDs for addressing Disco3 ECUs (from 11bit to 29bit) the rest of the stuff being the same as ISO14229 states.
-------------------
As an alternative for the impatient ones that have at hand an ELM329 chip or built interface, what I've posted in those 3 little tutorials can be enough to get started and read/erase errors.
The ELM329 provides a "terminal like" interactivity with the user through some "AT modem like" commands.
This chip implements the low level communications as specified by ISO15765.
Info about ELM329 is here: http://elmelectronics.com/obdic.html#ELM329
And documentation here: http://elmelectronics.com/DSheets/ELM329DS.pdf
The ELM329 is based on Microchip's PIC18F2480 microcontroller that has a CAN engine inside.
And the net is full of documentation, tutorials and schematics about ELM32x series.
It can be somehow limited, at least from speed point of view, but it's a cheap start.
All you need to do is to give/send the read and/or erase commands as I've documented above.
The commands can be sent to ELM329 even using Windows Hyperterminal if you proper interface the ELM chip with the computer.
You will also find out more about CAN communications, diagnosing and stuff on the ELM329 documentation.
Â
Last edited by alex_pescaru on 28th Nov 2018 5:38 pm. Edited 2 times in total
3rd Nov 2013 9:04 am
caverD3
Member Since: 03 Jul 2006
Location: Oberon, NSW
Posts: 6922
alex_pescaru wrote:
Have you heard of "Land Rover - turning drivers into mechanics since 1948"?
Now, with the new technology why not "Land Rover - turning drivers into geeks since 2005"....
Very good Alex. becoming more so every day. “There are only three sports: bullfighting, motor racing, and mountaineering; all the rest are merely gamesâ€
Ernest Hemmingway
D4 3.0 Active Diff, Adaptive Lights, High Beam Assist, Surround Cameras, Privacy Glass.
D3 2.7:Adaptive Headlights,Electronic Rear Diff,ARB Bar,Blaupunkt Speakers,JVC Powered Subwoofer,Removable Snorkel,Mitch Hitch,Pioneer After Market Head Unit,Steering Wheel Control Adaptor,Remote Adjustable Supension Rod System, Taxside Dual Battery System.
4th Nov 2013 2:39 am
alex_pescaru
Member Since: 19 Dec 2010
Location: RO
Posts: 270
I was asked by some people how can one access the "snapshot" data (or freeze-frame) like the SDD can.
For reading errors we used the reportDTCByStatusMask (0x02) subfunction.
Reading further ISO14229, you can see that another subfunction of ReadDTCInformation (0x19) service is reportDTCSnapshotRecordByDTCNumber (0x04).
Lets remember the previous example:
Explanation:
0x06 - usefull message length
0x19 - service code, in this case ReadDTCInformation
0x04 - sub-function, in this case reportDTCSnapshotRecordByDTCNumber
0x06 - DTCHighByte
0x1B - DTCMiddleByte
0x81 - DTCLowByte
0xFF - DTCSnapshotRecordNumber, 0xFF meaning all Snapshots.
0x00 - filling/padding byte
The response is somehow pretty long to explain, so below it's a copy of the response as stated by ISO14229.
The communication follows the ISO15765-2 standard.
3F - block len
59 04 - return response
06 1B 81 A9 - error with status
10 - snapshot record no (0x10 - first occurence, 0x11 - last occurence)
10 - 16 identifiers are following next
1. DD 00 1F 1E 26 A3 - global time
2. DD 01 00 C4 84 - odometer
3. DD 02 00
4. DD 05 40 - temperature
5. DD 06 40 - temperature
6. F4 04 00 - engine load
7. F4 05 41 - engine coolant temp
8. F4 0B 64 - intake manifold abs pressure
9. F4 0C 00 00 - engine rpm
10. F4 0D 00 - vehicle speed
11. F4 0F 41 - intake air temp
12. F4 10 1B AB - MAF air flow rate
13. F4 33 64 - barometric pressure
14. F4 46 40 - ambient air temperature
15. F4 49 00 - accelerator pedal position D
16. F4 4A 00 - accelerator pedal position E
group F4xx are standard OBD2 PIDs, where xx = PID no
Last edited by alex_pescaru on 28th Nov 2018 5:42 pm. Edited 1 time in total
17th Nov 2013 8:09 pm
caverD3
Member Since: 03 Jul 2006
Location: Oberon, NSW
Posts: 6922
eh?“There are only three sports: bullfighting, motor racing, and mountaineering; all the rest are merely gamesâ€
Ernest Hemmingway
D4 3.0 Active Diff, Adaptive Lights, High Beam Assist, Surround Cameras, Privacy Glass.
D3 2.7:Adaptive Headlights,Electronic Rear Diff,ARB Bar,Blaupunkt Speakers,JVC Powered Subwoofer,Removable Snorkel,Mitch Hitch,Pioneer After Market Head Unit,Steering Wheel Control Adaptor,Remote Adjustable Supension Rod System, Taxside Dual Battery System.
17th Nov 2013 9:48 pm
EIG
Member Since: 12 Feb 2009
Location: Enniskillen
Posts: 329
Member Since: 25 Oct 2013
Location: Harare
Posts: 110
Alex, well done. The absence of PC software diagnostic/scan tools for land rover is testament to the fact that we need more brains like yours on the subject! I'm definitely keen to get involved (unfortunately my land rover, a D3, will only arrive in a few weeks time)
The OBD cable I'm using is the same as the one I used in my VW Jetta 4 - do you have any idea if this will suffice? My intention is to use serial communication via a Windows virtual COM port.
22nd Nov 2013 6:37 am
alex_pescaru
Member Since: 19 Dec 2010
Location: RO
Posts: 270
What I've been said in this thread refers to the low level communication that will take place between any diagnostic tool and the car. Either is your hardware or SDD, MSV, IID, T4, etc.
If you are/will be able to send and receive a stream of data on the CAN bus with the above specifications you will be able to diagnose and/or program the car's modules from within anywhere.
By anywhere I mean a PC based application or an embedded (stand alone) system.
Now, regarding your OBD2 cable, we must know in the first place which type of communication it supports. I have a vague impression that Jetta4 modules communicates based on KWP1281 (some extension of ISO9141) and KWP2000 (ISO 14230) protocol. A different protocol than CAN bus.
In order to communicate with our cars, you need an interface that's able to talk in terms of ISO15765 and ISO14229.
You can buy one based on ELM329 (attention 329, with 9 at end) or you can build one for yourself.
For ELM329 look here: http://elmelectronics.com/obdic.html
Once you have the means of communicating over CAN with the car, the rest will be only sending the data in the right sequence.
Above I've detailed how you can do it for reading/erasing DTCs.
We can go into details about other things like calibration, modifying, flashing, etc if it will be interest for it.
For example, calibrating the windows' end travel is just a simple matter of running a subroutine from inside BCM module. Other things, like flashing, require a much more complex approach.
22nd Nov 2013 10:36 am
SteveMfr Site Sponsor
Member Since: 11 Jan 2011
Location: Strasbourg
Posts: 200
I find this thread extremely interesting. My posts from about 8 years ago in a similar vein to this (though not nearly as technically detailed) can be found in the archives on rangerovers.net. Since then playing with LR electronics has become more than just a hobby
nighthawk wrote:
Tools such as this require huge truck loads of effort, especially in the research and testing departments. They must be literally bulletproof. Hence why diagnostic tools appear to be expensive. Honestly £300 for an IID Tool is really cheap for the amount of effort that goes into developing such a tool.
This is very true. Four+ years ago we were prob at a similar point. We are only now reaching a point where we can really say we cover a vehicle end-to-end with full coverage - CCF editing and ECU flashing included (not just fault code reading and a few live values) - and we still have not released all models yet. Development from something like this to a useable product has to be counted in man-years vs. man-days (and forgetting man-hours).
jimbo1981 wrote:
Alex, well done. The absence of PC software diagnostic/scan tools for land rover is testament to the fact
Actually I have to disagree with you. Yes, major auto manufacturers such as VW/Audi have more aftermarket diagnostic systems to choose from - but the user base is much larger as well. For a company the size of LR, I think that the diagnostic tool market is already quite heavily populated. Amongst others:
Sub €500: Hawkeye, Lynx, BBS FCR, and our own IIDTool
Over €500: BBS MSV, our coming IIDTool Products...
And this does not include any purely professional products such as the Autologic or LR IDS/SDD.
I probably would not have started down this path even if even something with as little functionality as the Hawkeye or Lynx had been available - but I was looking at over €1000 and with that the ability to work on only my car due to the VIN lock. Who knows, if we already had the FL2 available, maybe Alex wouldn't have started...
But it is a fun thing to do (if you are a bit geeky 8) ) and I will continue to watch with interest. www.gap-diagnostic.com
22nd Nov 2013 3:21 pm
alex_pescaru
Member Since: 19 Dec 2010
Location: RO
Posts: 270
SteveMfr wrote:
Who knows, if we already had the FL2 available, maybe Alex wouldn't have started...
For sure I would've started...
My friends like to say: Alex, I believe you are always wondering why the car/things works...
And once I found out something, I believe that the best thing to do is to share it with others.
This is how progress is made. I may be a dreamer, but what's the use to know a lot of things and then take them with you to the grave?...
And regarding FL2, I've already bought a FL2 instrument cluster for playing guinea pig and trying to see if I can send and show messages on it in order to display dynamically, like I've told you, information like oil temperature, autobox temperature, intake manifold pressure, etc.
Â
23rd Nov 2013 8:39 pm
rubot
Member Since: 16 Mar 2016
Location: San Diego, California
Posts: 27
Hi Alex, I found this thread after another member pointed me in your direction. Very interesting stuff. I want to learn to interface with the Can Bus so I can read live data from sensors such as the wheel heights, air reservoir pressure, and anything else I can get my hands on. Your previous posts provided examples of how to retrieve errors codes. Is there any chance you could provide an example of how to compose a message that can retrieve live data? What about a simple action such as locking or unlocking the doors (i'm not even sure that is possible)?
I am using a Sparkfun Redboard (which is an Arduino Uno clone) and the Sparkfun Can-Bus Shield. Currently, I can only read messages from the high speed bus. My intent is to read the values into the microcontroller then "do things" with these values.
My long term goal is to replace many of the interfaces within the vehicle with a single user interface on a tablet. Interfacing with the Can Bus is the first and most difficult obstacle I foresee.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
Very good Alex. becoming more so every day. 
