On board diagnostics

[MogLite]

Testbooks and Rovacom Lite got mentioned in a previous thread, as a diagnostic tool for later vehicles having ECU's and more electronics than grease nipples.

Seems like a good idea as its going to be the way we will have to go - like it or not.

I stumbled across this Diagnostic scanner

Plenty of options for Rovers -well the later ones anyway, and seems it will cost about ~£100 landed in the UK

Anyone played with this kind of stuff before ?

Anyone know if it will work on UK spec vehicles (Diesels ?)

Got to be worth a punt for a £100, even if you can only get the digital dashboard to work B) B)

Seems to offer a lot of the things that people consider a positive for MegaSquirt

[geoffbeaumont]

Testbooks and Rovacom Lite got mentioned in a previous thread, as a diagnostic tool for later vehicles having ECU's and more electronics than grease nipples.

Seems like a good idea as its going to be the way we will have to go - like it or not.

I stumbled across this Diagnostic scanner

Plenty of options for Rovers -well the later ones anyway, and seems it will cost about ~£100 landed in the UK

Anyone played with this kind of stuff before ?

Anyone know if it will work on UK spec vehicles (Diesels ?)

Got to be worth a punt for a £100, even if you can only get the digital dashboard to work B) B)

Seems to offer a lot of the things that people consider a positive for MegaSquirt

Should work for the standard stuff on ODB-II compliant vehicles (pretty much anything post '96). It won't work on most older vehicles (RR classic for instance is ODB-I - even if you can find a scanner for it, I think it's pretty poorly standardised). It also won't handle 'extended' features like air suspension, possibly some other toys found on higher spec land rovers. Should do all the basic engine stuff though. Maybe gearbox, too?

[simonr]

As you know - I'm pretty in-to techy add-ons and unnecessary computerisation of things.

I have to admit though, with this, I'm unsure how much of the huge amount of info it displays is actually going to be useful.

If you just want it for the digital dash - surely you'd be better buying a speedo and some blue LED's and at least be secure in the knowledge it's not going to crash or become virus infected!

There are a few people selling little LCD gauges which show a number of selectable different readings (and look quite bling) . I'd be more confident about their reliability (particularly in the wet).

Unfortunatly, your engine is not fitted with the sensors to provide useful in depth diagnostics, save perhaps for the lambda sensor. Fortunatly, you only really need them if you are running a scratch built prototype engine or entering F1.

Stick to nice mechanical dials!

Si

[MogLite]

Simon

Its not for MogLite with its somewhat cheesy implementation on OBD1.

MogLite has got this going into the roof panel - this is the MkII version, the current MkIII version has warning lights in it too

I'm thinking P38a.

The wife has got a 98 4.6, and I'm thinking about a cheap DSE as a daily driver.

I've had a very generous offer to get one into the country, so let the un-necessary computerisation begin

[white90]

nice dash

[fisha]

i think the diagnostic thing you link to will only get you the basic OBD2 standard set of information out of the P38 . . . most of which will be related to the engine and its current running ( like O2 sensor, advance, fuelling, throttle, rpm and possibly some ABS - not sure tho )

but you'll certainly not get any of the other features like the interior controls, air-con, air suspension etc etc.

The OBD2 connector standard has many pins and only a few are needed to work OBD2 data transfer. Manufacturers can then use all the other pins to get links to their own systems using protocols specific to the vehicle - which is what LR do.

NB: I could be wrong with this:

Now, as I currently understand it, the P38 system works the majority of its other systems on one of these spare pins using a K-line 2way setup of data transfer.

Its also my understanding that the P38 sends all of the system data on this line continuously. The trick of things like Rovacom is to be able to decipher it ( is it encrypted? - i dont know ) . Previous discussions seemed to indicate that the P38 sends its data at an unusual baud rate compared to a normal serial port. ( could find that out on an oscilloscope i suppose )

When you pay for your software modules in rovacom, i expect your simply paying for an unlock on the listening chip which will allow the relevant bit of datafeed to pass through to the computer. i.e. you not paying for additional software which enables the rovacom to talk to the P38 systems, your paying for the rovacom not to ignore that part of the data.

all that being said, it guess it would be possible to figure out what the data stream is and how to decode it.

how would I do it?

well, first off, i'd try and simply capture a data log of the what goes on with the data stream on that ODB2 connector pin. It might be simple to decode. Heck it could even be something like:

GEMSrpm=2340,GEMSadv=3,EASLeftFront=50,EASRightFront=51 etc etc ( but i doubt it! )

then if you've got the balls, plug in a rovacom and data log the rovacom outputs and P38 outputs and see what happens when each talks to each ( which is probably highly dodgy in terms of your user agreement for the Rovacom )

once you know all that, make your own programmable chip to do the talking.

[geoffbeaumont]

all that being said, it guess it would be possible to figure out what the data stream is and how to decode it.

how would I do it?

well, first off, i'd try and simply capture a data log of the what goes on with the data stream on that ODB2 connector pin. It might be simple to decode. Heck it could even be something like:

GEMSrpm=2340,GEMSadv=3,EASLeftFront=50,EASRightFront=51 etc etc ( but i doubt it! )

then if you've got the balls, plug in a rovacom and data log the rovacom outputs and P38 outputs and see what happens when each talks to each ( which is probably highly dodgy in terms of your user agreement for the Rovacom )

once you know all that, make your own programmable chip to do the talking.

It doesn't need to be done using low level stuff. All the communication can be done in software on a conventional PC - that's what the cheapest Rovacom option does.

I briefly looked at doing this with the range rover classic EAS (which is some kind of extended version of OBDI), but decided it was far more work than I could justify. There's a reason there are only a couple of suppliers of aftermarket LR systems and they both charge a lot of money - without interface documentation it's painstaking trial and error work, especially if you can't sniff the traffic from an existing system (which you won't be able to do with either the after market or LR systems - as you say, it'll be in breach of the licensing agreements).

You could only justify the work if you could either do it as a collaborative effort (ie. set up an open source software project or similar) or did it as a business venture so that you got some financial payback. Either way you need to make sure you stay on the right side of the law as you're distributing the software.

[simonr]

I believe that the main issue in talking to the proprietry land rover data pins in baud rate. Perfectly possible to doon a PC - but you need to talk directly to the serial chips to persuade them that the data is not corrupted.

Rovercom might not like you sticking a logic analyser on their kit - but it's what they must have done on the LR test book so I'm not sure they will have much of a leg to stand on.

One day, when I get a landy with this kind of technology, I'll have a go at building / writing something.

SteveG & I talked about reverse engineering the EAS control protocol and writing a simple control app for a PDA to let you override the EAS calibration (in order to raise / lower or lean the vehicle on demand). Sadly, never got beyond the talking stage.

Si

[02GF74]

MogLite has got this going into the roof panel - this is the MkII version, the current MkIII version has warning lights in it too

MkIV will have flashing lamps?

Damn, someone has more guages then me I'd better get busy and fit those twin ameters I have lying around.....

[FridgeFreezer]

Andy / Geoff - I have some data-comms software you may find useful, I'll e-mail it to you when I get a moment. (So 2010 then )

[fisha]

SteveG & I talked about reverse engineering the EAS control protocol and writing a simple control app for a PDA to let you override the EAS calibration (in order to raise / lower or lean the vehicle on demand). Sadly, never got beyond the talking stage.

Something that had crossed my mind too. At the end of the day, you're only reading the voltages of the sensors and opening and closing valves to make those sensor reading reach a pre-set range of values.

[donaldh]

You're reasonably close to the mark with your description of OBD-II and the K line. In fact, the OBD-II standard and hence the connector supports three standards, ISO-9141, SAE-J1850 and ISO-15765. The variant used on the P38A is ISO-9141 that uses the K line and an "optional" L line.

Normally, a stream of information flows on the K line in the form of OBD codes, each one a sequence of 1 or more values. But it's possible to send command sequences that either ask for specific information or ask to perform specific operations. Unfortunately, as several folk have said, all the interesting stuff on the P38A uses proprietery command and response codes that you would need to get hold of first.

There is an open-source project to write an OBD scan tool and several projects to build interface hardware.

http://freediag.sourceforge.net/

http://www.andywhittaker.com/ecu/obdii_hardware.htm

I have got a version of Andy Whittaker's interface board and I will eventually get around to putting an old PC in my garage so that I can play around with it. I'd be very interested to hear if anyone else has success with one of the cheap / free tools that are available.

Cheers,

Donald.

[fisha]

all the interesting stuff on the P38A uses proprietery command and response codes that you would need to get hold of first.

Do you mean by that comment that in order to get any of the P38 information you first have to put a specific command request its output?

or that the P38 continually feeds its custom stuff, and there is custom codes that you can tell the P38 what to do ( such as adjust heights )

the disco2.com site had tantalising tit-bits of information on how the diagnostic systems of the modern LR worked ( such as the k-line's output ) but the site seems to have gone

[donaldh]

Do you mean by that comment that in order to get any of the P38 information you first have to put a specific command request its output? or that the P38 continually feeds its custom stuff, and there is custom codes that you can tell the P38 what to do ( such as adjust heights )

I think it will feed some custom stuff such as manufacturer specific fault codes. But as far as I know, most P38A things require custom codes to tell it what to do.

Some of the maufacturer specifc codes can be found here:

http://www.troublecodes.net/landrvr/

I think this is just the same info as available in a workshop manual though.

Cheers,

Donald.

[geoffbeaumont]

Something that had crossed my mind too. At the end of the day, you're only reading the voltages of the sensors and opening and closing valves to make those sensor reading reach a pre-set range of values.

You're talking about a slightly different thing though - replacing the EAS ECU rather than interacting with the existing one. I've still got plans in that area (or more accurately I have a mate who needs a project for his electronic engineering degree... B) ).

The standard EAS ECU does a little more than just move to preset heights, in as much as it also monitors vehicle speed (with some historisis built in) and determines which heights are available and/or automatically selected based on this (this, by and large is a good thing, although I'd take one or two of the restrictions out) and does a few things like try to level the car up when it's parked by lowering springs in rotation and raising the vehicle to 'extended mode' if it thinks you're stuck (which are bl***y stupid - leaving them out would be a big improvement). Unlike the current vehicles which have all sort of dynamic stability stuff in them, though, the earlier systems are really pretty basic and would be easy to replicate.

Next step would be to implement a few nice extras like leaning the car for side slopes. Even better, with a couple of extra valves and a bit more pipework you could implement the connected opposing bladders of the later system for a lovely smooth off-road ride and much better cross-axle performance

[fisha]

I suppose i am talking about a slightly different thing i suppose.

If your wanting to interact with the current system in a non-damaging way, then all you would need to do is have 4 voltage modifiers. With the modifiers under the control of the PDA / whatever, then to raise or lower a corner, you just tell the modifer to adjust the sensor voltage that the EAS ECU sees.

That approach would allow side slope adjustment pretty easily.

[MogLite]

Well despite being an IT geezer, all this electronics talk of oscilliscopes etc is beginning to be a bit scary.

But I've ordered one anyway, to see what it will/wont do.

I can plug it into our 38a and see what it says.

I ordered the one for a 1997 Range Rover, so if that is just to get the right connector, or if there is any custom s/w remains to be seen.

[geoffbeaumont]

I suppose i am talking about a slightly different thing i suppose.

If your wanting to interact with the current system in a non-damaging way, then all you would need to do is have 4 voltage modifiers. With the modifiers under the control of the PDA / whatever, then to raise or lower a corner, you just tell the modifer to adjust the sensor voltage that the EAS ECU sees.

That approach would allow side slope adjustment pretty easily.

Or just do what someone on this forum has suggested before and stick some variable resistors in series with the height sensors. Crude, but should be perfectly effective!

[Niall_CSK]

and a bit more pipework you could implement the connected opposing bladders of the later system for a lovely smooth off-road ride and much better cross-axle performance

And lovely smooth rolling over if you get it wrong, can I come & watch Deano

I have been thinking about this but I have a feeling it could be a bit harder to do safely than it might look.

[nas90]

Interesting that it is for MY1996 onwards. The NAS which is MY1995 has a digital error code readout unit, which when the ECU encounters a problem gives me a 2 or possible 3 digit error code. Apparently the USA consumer regulations stipulate that buyers of cars with an ECU must be able to recognise the faults themselves and not be dependant on returning the car to their stealership. Maybe there was a change in the States +1996, anyone from USA know the regulations? The big problem for me is that although I know the code number I do not have a list of fault code numbers = fault, unless I ring our local Horsham car electronis guru Angus. For instance error 42 = LH Nox sensor, error 44 = RH Nox sensor, error 68 = Lost motion sensor. Once the fault is rectified turning the ignition on and then off for 10 seconds and then back on again clears the fault code reader screen. There is also a covered button, on the digital readout, which sends a fault signal every 60,000 miles for the Cats to be replaced. Apparently the garage (or me with my NAS) reset the button after every Cat replacement.

I do not know of any UK spec vehicle with the readout unit.

Edited March 5, 2006 by nas90

[siggy]

One of the elctronic techs at college was using a Z81 to do the on board diagnostics had a load of additional circuitry using AND, OR and Not gates....

I.e switch would tell the computer that you turned lights on it would then wait for you to receive back a signal from the lights if no lights a light flashed etc

basic but was expandable

[SteveG]

Or just do what someone on this forum has suggested before and stick some variable resistors in series with the height sensors. Crude, but should be perfectly effective!

That was me. When mulling ideas as the P38 height sensors are just sealed pots too.

With three pots you get the fullest range. One on the common return to the ECU that can raise or lower the height of all four corners to any height you need. For side slopes you can use two pots that adjust each bank of sensors corresponding to the lean you want. Just need some tipex to mark the standard height and max heights.

When talking with Si, simonr, it was agreed that the best method was the PDA route, where you are dialing in numbers into the ECU to adjust everything and that way you could have stored settings etc. Sniffing a testbook to strip out the ECU commands would not be difficult. You could use some of the low cost or shareware sniffing s/w to do this, http://www.aggsoft.com/serial-port-monitor.htm. I think this is ok for this kind of use as you are not trying to put the diag companies out of business.

Remember that LR made the protocol available to these suppliers as they are required to by law to offer the diagnostic capability to independents. I think what they charge for single one off use is way too high and to introduce unecessary hardware to justify the price is ludicrous. It's like the P38 to coil conversion kits that charge $500+ for a box of tricks that does fk all! you can turn off the lights alarms etc with a few commands etc and no need for a box.

In my view they miss the market. Make this all s/w plus a lead and a low download price and they would sell tens of thousands not hundreds. Support for multi vehicle, update support etc still enables them to keep their garage market intact.

rant over

[geoffbeaumont]

And lovely smooth rolling over if you get it wrong, can I come & watch Deano

I have been thinking about this but I have a feeling it could be a bit harder to do safely than it might look.

You missed the risk of overinflating a bladder and popping it off a plunger... Fixable, but a pain in the proverbial. Plus the bang will make you jump a bit...

The main reason I haven't tinkered with this even though it would be easy to do is that I really don't fancy persuading my insurers that it's a good idea...

I also think it needs some kind of lockout so the suspension doesn't accidentally get adjusted on the road - say a switch on the hi-lo lever so you could only use it when in low range, or maybe just an activation key so you have to deliberately put the pots in the circuit.

[geoffbeaumont]

In my view they miss the market. Make this all s/w plus a lead and a low download price and they would sell tens of thousands not hundreds. Support for multi vehicle, update support etc still enables them to keep their garage market intact.

Hmm, maybe. There are two basic ways to make money from a product - sell a few of them for a lot of money (high margin, low volume) or vice versa (low margin, high volume). Okay, three if you're a supermarket and can manage high margin and high volume...

There are pros and cons to both, but with something that's very technical in nature such as this one of the big cons to a high volume approach is the very high cost of providing adequate support. Chances are garages send their mechanics on courses to learn how to use the kit (possibly included in the cost of the more upmarket options). You and I wouldn't be prepared to fork out for them, nor to attend on a weekday, but we'd still expect the manufacturer to help us when we got stuck...

[SteveG]

Hmm, maybe. There are two basic ways to make money from a product - sell a few of them for a lot of money (high margin, low volume) or vice versa (low margin, high volume). Okay, three if you're a supermarket and can manage high margin and high volume...

There are pros and cons to both, but with something that's very technical in nature such as this one of the big cons to a high volume approach is the very high cost of providing adequate support. Chances are garages send their mechanics on courses to learn how to use the kit (possibly included in the cost of the more upmarket options). You and I wouldn't be prepared to fork out for them, nor to attend on a weekday, but we'd still expect the manufacturer to help us when we got stuck...

People have a different perspective on tech support when they spend $50 on something compared to $1000+

Also I'd question the amount of support you actually get for the 1000+. You can do a lot with FAQ boards, and self download patches these days - eliminating vast majority of support requests.

Steve