TestBook CDs

I know that this has been doubtless covered hundreds of times, but I
need a full set of TestBook CDs. I believe that we could achieve the
holy grail & make them work on an ordinary laptop.

Cheers,
Chris.

In message <[email protected]>
[email protected] wrote:

> I know that this has been doubtless covered hundreds of times, but I
> need a full set of TestBook CDs. I believe that we could achieve the
> holy grail & make them work on an ordinary laptop.
>
> Cheers,
> Chris.
>

There's an software layer between windows and the actual application
(a so-called operating system, but it's isn't really) that is part
of Testbook 1 & Testbook 2 (worked on the dammed thing but cant remember
the name) - if that's not on the CD's you'll need it as well. Apart from
that, and the cable interfaces (they are on the web somewhere) Testbook
is just a ruggedised PC.

Richard
--
www.beamends-lrspares.co.uk [email protected]
Running a business in a Microsoft free environment - it can be done
Powered by Risc-OS - you won't get a virus from us!!
Boycott the Yorkshire Dales - No Play, No Pay

It's actually a hardware layer.

Unless you can get hold of the additional proprietary hardware, you will
not get Testbook to work properly on a PC.

The software is cleverer than you think, and has been designed to be as
difficult as possible to run on a non-Testbook PC.






beamendsltd wrote:
> In message <[email protected]>
> [email protected] wrote:
>
>
>>I know that this has been doubtless covered hundreds of times, but I
>>need a full set of TestBook CDs. I believe that we could achieve the
>>holy grail & make them work on an ordinary laptop.
>>
>>Cheers,
>>Chris.
>>
>
>
> There's an software layer between windows and the actual application
> (a so-called operating system, but it's isn't really) that is part
> of Testbook 1 & Testbook 2 (worked on the dammed thing but cant remember
> the name) - if that's not on the CD's you'll need it as well. Apart from
> that, and the cable interfaces (they are on the web somewhere) Testbook
> is just a ruggedised PC.
>
> Richard

ADB wrote:

> It's actually a hardware layer.
>
> Unless you can get hold of the additional proprietary hardware, you will
> not get Testbook to work properly on a PC.
>
> The software is cleverer than you think, and has been designed to be as
> difficult as possible to run on a non-Testbook PC.
>

Well - at least you need all of the OBD2 and other system interface leads
and convertors - not impossible to get, but not cheap. IIRC the set for the
Rovacom system for a Disco 2 come out somewhere around £500 just for the
leads.

P.

Yes, but Rovacom have integrated the hardware interface into their own
system. The cables are merely the physical interface between their
hardware and the vehicle.

You will not get Testbook to run on a PC unless you understand the
electronics between the PC and the vehicle.



Paul S. Brown wrote:
> ADB wrote:
>
>
>>It's actually a hardware layer.
>>
>>Unless you can get hold of the additional proprietary hardware, you will
>>not get Testbook to work properly on a PC.
>>
>>The software is cleverer than you think, and has been designed to be as
>>difficult as possible to run on a non-Testbook PC.
>>
>
>
> Well - at least you need all of the OBD2 and other system interface leads
> and convertors - not impossible to get, but not cheap. IIRC the set for the
> Rovacom system for a Disco 2 come out somewhere around £500 just for the
> leads.
>
> P.

In message <[email protected]>
ADB <[email protected]> wrote:

> It's actually a hardware layer.
>
> Unless you can get hold of the additional proprietary hardware, you will
> not get Testbook to work properly on a PC.
>
> The software is cleverer than you think, and has been designed to be as
> difficult as possible to run on a non-Testbook PC.
>
>

That may be true for Testbook 3, but Testbook 1 & 2 do not have any
addition hardware other that the cable interfaces. The "OS" layer
provides drivers for the touch-screen and "4GL" programming interface
for the screen "buttons". I wish I could remember what the dammed "OS"
is called.......it's by Hewlet-Packard and intended for Industrial/Medial
control systems.

I wrote the diagnostics software for Rover 75/New Mini Parking Aid,
Climate Control & Sunroof on Testbook 2.

Richard

>
> beamendsltd wrote:
> > In message <[email protected]>
> > [email protected] wrote:
> >
> >
> >>I know that this has been doubtless covered hundreds of times, but I
> >>need a full set of TestBook CDs. I believe that we could achieve the
> >>holy grail & make them work on an ordinary laptop.
> >>
> >>Cheers,
> >>Chris.
> >>
> >
> >
> > There's an software layer between windows and the actual application
> > (a so-called operating system, but it's isn't really) that is part
> > of Testbook 1 & Testbook 2 (worked on the dammed thing but cant remember
> > the name) - if that's not on the CD's you'll need it as well. Apart from
> > that, and the cable interfaces (they are on the web somewhere) Testbook
> > is just a ruggedised PC.
> >
> > Richard

--
www.beamends-lrspares.co.uk [email protected]
Running a business in a Microsoft free environment - it can be done
Powered by Risc-OS - you won't get a virus from us!!
Boycott the Yorkshire Dales - No Play, No Pay

In message <[email protected]>
"Paul S. Brown" <[email protected]> wrote:

> ADB wrote:
>
> > It's actually a hardware layer.
> >
> > Unless you can get hold of the additional proprietary hardware, you will
> > not get Testbook to work properly on a PC.
> >
> > The software is cleverer than you think, and has been designed to be as
> > difficult as possible to run on a non-Testbook PC.
> >
>
> Well - at least you need all of the OBD2 and other system interface leads
> and convertors - not impossible to get, but not cheap. IIRC the set for the
> Rovacom system for a Disco 2 come out somewhere around £500 just for the
> leads.
>
> P.

The info's on the web somewhere - someone was selling circuit/wiring
diagrams a couple of years ago. A mate bought it, built it and it worked.
The connectors etc are all standard, OBD2 etc are just "bus" standards
that are readily available - translating what the packets mean is
manuafacturer specific (except OBD2 which give standard messages for
basic high level diagnostics accross all vehicles - in theory anyway).

Richard
--
www.beamends-lrspares.co.uk [email protected]
Running a business in a Microsoft free environment - it can be done
Powered by Risc-OS - you won't get a virus from us!!
Boycott the Yorkshire Dales - No Play, No Pay

I can't find the info on the web regarding the exact wiring of the
leads. I just need the CDs to start with & have the resources
available to make it work.

Cheers,
Chris.


beamendsltd wrote:
> In message <[email protected]>
> "Paul S. Brown" <[email protected]> wrote:
>
> > ADB wrote:
> >
> > > It's actually a hardware layer.
> > >
> > > Unless you can get hold of the additional proprietary hardware, you will
> > > not get Testbook to work properly on a PC.
> > >
> > > The software is cleverer than you think, and has been designed to be as
> > > difficult as possible to run on a non-Testbook PC.
> > >
> >
> > Well - at least you need all of the OBD2 and other system interface leads
> > and convertors - not impossible to get, but not cheap. IIRC the set forthe
> > Rovacom system for a Disco 2 come out somewhere around £500 just for the
> > leads.
> >
> > P.
>
> The info's on the web somewhere - someone was selling circuit/wiring
> diagrams a couple of years ago. A mate bought it, built it and it worked.
> The connectors etc are all standard, OBD2 etc are just "bus" standards
> that are readily available - translating what the packets mean is
> manuafacturer specific (except OBD2 which give standard messages for
> basic high level diagnostics accross all vehicles - in theory anyway).
>
> Richard
> --
> www.beamends-lrspares.co.uk [email protected]
> Running a business in a Microsoft free environment - it can be done
> Powered by Risc-OS - you won't get a virus from us!!
> Boycott the Yorkshire Dales - No Play, No Pay

>>>>> "chris" == chris <[email protected]> writes:

chris> I know that this has been doubtless covered hundreds of
chris> times, but I need a full set of TestBook CDs. I believe
chris> that we could achieve the holy grail & make them work on an
chris> ordinary laptop.

Testbook in it's latest guise needs the hand-held tester to
communicate with the vehicle. It has an ethernet interface on one
end, and the OBD-II diagnostic connector on the other. It doesn't use
the serial port on the laptop at all. The HHT will also function on
it's own to do limited diagnostics.

I tried doing all this about two years ago - then said bollocks and
bought a Rovacom as it was cheaper than the HHT, even loaded with all
the software for a P38A.

I started off thinking it was easy, and then I found out why it wasn't
as easy as I thought.

Andy


--
Andy Cunningham -- www.cunningham.me.uk

AndyC the WB wrote:
>>>>>> "chris" == chris <[email protected]> writes:
>
> chris> I know that this has been doubtless covered hundreds of
> chris> times, but I need a full set of TestBook CDs. I believe
> chris> that we could achieve the holy grail & make them work on an
> chris> ordinary laptop.
>
> Testbook in it's latest guise needs the hand-held tester to
> communicate with the vehicle. It has an ethernet interface on one
> end, and the OBD-II diagnostic connector on the other. It doesn't use
> the serial port on the laptop at all. The HHT will also function on
> it's own to do limited diagnostics.
>

The OBD-II port is RS485 link isn't it ? There was an Elektor project
recently to provide a OBD-II to 232 link.

Steve

>>>>> "Steve" == Steve <[email protected]> writes:

Steve> The OBD-II port is RS485 link isn't it ? There was an
Steve> Elektor project recently to provide a OBD-II to 232 link.

There are three difference communications standards that run over
OBD-II. One of them is RS485 or similar; the interface to RS-232 can
be built trivially.

BUT the testbook software doesn't use the serial port - at least not
in the latest revisions. It uses the ETHERNET port to talk to the
HHT. And that's a much more complex proposal - figuring out how the
HHT converts it's ethernet data to something the car can understand.

Alternatively, you could consider getting an old version of Testbook
to run on modern hardware. T4 runs happily under Windows XP until you
try to communicate with the vehicle, when it bitches about the absence
of the HHT. Don't ask how I know. The earlier versions ... are
early. They pre-date Pentium processors for one thing, and are likely
to have lots of hardware dependencies on the specific HP laptop that
was used.

Another approach is to build from existing open knowledge on the
OBD-II protocols and build your own testbook. There's a Yahoo! group
called Open Diag that's populated with people building their own
interfaces to VAG diagnostics, and if you search around you can get
the BMW diagnostic software (which should talk to the engine in a
L322, BTW) off the web along with a diagram of how to build the
interface. As an aside, there's also a group called Hack The I Bus,
which is devoted to interfacing PCs to the I-Bus used in BMWs, the
L322, and possibly other post-BMW Land Rovers so that you can, for
example, surf the web from the in-dash display. Hopefully while
stationary.

But building an interface for a Range Rover isn't just as simple as
building your own OBD-II interface. ODB-II specifies a minimum
communication protocol to communicate with the Engine Management
System (EMS) only. And the P38A has three different "OBD-II"
connections in the same interface - I forget the pinouts now, but the
Engine, BeCM, and EAS all communicate over different wires.

Many ECUs require a specific challenge-response sequence to activate
the manufacturer specific functionality: for example, encrypting a
random number supplied by the EMS. If you can't reverse engineer the
key used, you're stuck. Or, more simply, the EAS ECU in the P38A
requires that you send a specific OBD-II style request with a specifc
interval (measured in microseconds) after resetting power to the
system.

None of this is specified in the OBD-II standard. OBD-II will let you
reset the fault codes on the Engine, but it doesn't address anything
to do with EAS, or the BeCM, or anything else specific to the vehicle.

I'm not trying to put you off the project. I'm just trying to share
the benefit of what I learned two years ago, when I decided that it
wasn't going to be trivial, and went off and bought a Rovacom Lite
instead.

Andy

--
Andy Cunningham -- www.cunningham.me.uk

>
> There are three difference communications standards that run over
> OBD-II. One of them is RS485 or similar; the interface to RS-232 can
> be built trivially.
>
> BUT the testbook software doesn't use the serial port - at least not
> in the latest revisions. It uses the ETHERNET port to talk to the
> HHT. And that's a much more complex proposal - figuring out how the
> HHT converts it's ethernet data to something the car can understand.
>
> Alternatively, you could consider getting an old version of Testbook
> to run on modern hardware. T4 runs happily under Windows XP until you
> try to communicate with the vehicle, when it bitches about the absence
> of the HHT. Don't ask how I know. The earlier versions ... are
> early. They pre-date Pentium processors for one thing, and are likely
> to have lots of hardware dependencies on the specific HP laptop that
> was used.

Hardware dependencies are usually deliberate. I would make sure that the
HHT (actually the HHT docking station) and the software were
inextricably linked to stop people ripping the software off.


Incidently, with regard to EAS on the P38, unless you have the hardware
interface you will not get the testbook software to communicate with the
system. A standard PC is unable to interace directly with EAS because
of it's hardware characteristics.



>
> Another approach is to build from existing open knowledge on the
> OBD-II protocols and build your own testbook. There's a Yahoo! group
> called Open Diag that's populated with people building their own
> interfaces to VAG diagnostics, and if you search around you can get
> the BMW diagnostic software (which should talk to the engine in a
> L322, BTW) off the web along with a diagram of how to build the
> interface. As an aside, there's also a group called Hack The I Bus,
> which is devoted to interfacing PCs to the I-Bus used in BMWs, the
> L322, and possibly other post-BMW Land Rovers so that you can, for
> example, surf the web from the in-dash display. Hopefully while
> stationary.
>
> But building an interface for a Range Rover isn't just as simple as
> building your own OBD-II interface. ODB-II specifies a minimum
> communication protocol to communicate with the Engine Management
> System (EMS) only. And the P38A has three different "OBD-II"
> connections in the same interface - I forget the pinouts now, but the
> Engine, BeCM, and EAS all communicate over different wires.
>
> Many ECUs require a specific challenge-response sequence to activate
> the manufacturer specific functionality: for example, encrypting a
> random number supplied by the EMS. If you can't reverse engineer the
> key used, you're stuck. Or, more simply, the EAS ECU in the P38A
> requires that you send a specific OBD-II style request with a specifc
> interval (measured in microseconds) after resetting power to the
> system.
>
> None of this is specified in the OBD-II standard. OBD-II will let you
> reset the fault codes on the Engine, but it doesn't address anything
> to do with EAS, or the BeCM, or anything else specific to the vehicle.
>
> I'm not trying to put you off the project. I'm just trying to share
> the benefit of what I learned two years ago, when I decided that it
> wasn't going to be trivial, and went off and bought a Rovacom Lite
> instead.
>
> Andy
>

ADB <[email protected]> uttered summat worrerz funny about:
> Hardware dependencies are usually deliberate. I would make sure that
> the HHT (actually the HHT docking station) and the software were
> inextricably linked to stop people ripping the software off.
>
>
> Incidently, with regard to EAS on the P38, unless you have the
> hardware interface you will not get the testbook software to
> communicate with the system. A standard PC is unable to interace
> directly with EAS because of it's hardware characteristics.

And here was me thinking the book of lies was complicated

Lee D

Wow, I've just read the replies ..... yeah I know it's difficult, but
at the end of the day Rovacom & Autologic did it. The Testbook CD's
can be reverse-engineered ..... and at the end of the day, what's to
stop someone buying a Rovacom, Autologic or even A genuine Testbook &
reverse engineering the whole thing ??? Rovacom want £825.00 for the
direct BeCM module, which is a software patch on top of the 'ordinary'
module .... c'mon, you're not telling me there is a means to an end
there somewhere. Who's got an old BeCM lying around? What's the make
& model of the processor for a start?

It can be done !!!!!!!!!!





AndyC the WB wrote:

> >>>>> "Steve" == Steve <[email protected]> writes:
>
> Steve> The OBD-II port is RS485 link isn't it ? There was an
> Steve> Elektor project recently to provide a OBD-II to 232 link.
>
> There are three difference communications standards that run over
> OBD-II. One of them is RS485 or similar; the interface to RS-232 can
> be built trivially.
>
> BUT the testbook software doesn't use the serial port - at least not
> in the latest revisions. It uses the ETHERNET port to talk to the
> HHT. And that's a much more complex proposal - figuring out how the
> HHT converts it's ethernet data to something the car can understand.
>
> Alternatively, you could consider getting an old version of Testbook
> to run on modern hardware. T4 runs happily under Windows XP until you
> try to communicate with the vehicle, when it bitches about the absence
> of the HHT. Don't ask how I know. The earlier versions ... are
> early. They pre-date Pentium processors for one thing, and are likely
> to have lots of hardware dependencies on the specific HP laptop that
> was used.
>
> Another approach is to build from existing open knowledge on the
> OBD-II protocols and build your own testbook. There's a Yahoo! group
> called Open Diag that's populated with people building their own
> interfaces to VAG diagnostics, and if you search around you can get
> the BMW diagnostic software (which should talk to the engine in a
> L322, BTW) off the web along with a diagram of how to build the
> interface. As an aside, there's also a group called Hack The I Bus,
> which is devoted to interfacing PCs to the I-Bus used in BMWs, the
> L322, and possibly other post-BMW Land Rovers so that you can, for
> example, surf the web from the in-dash display. Hopefully while
> stationary.
>
> But building an interface for a Range Rover isn't just as simple as
> building your own OBD-II interface. ODB-II specifies a minimum
> communication protocol to communicate with the Engine Management
> System (EMS) only. And the P38A has three different "OBD-II"
> connections in the same interface - I forget the pinouts now, but the
> Engine, BeCM, and EAS all communicate over different wires.
>
> Many ECUs require a specific challenge-response sequence to activate
> the manufacturer specific functionality: for example, encrypting a
> random number supplied by the EMS. If you can't reverse engineer the
> key used, you're stuck. Or, more simply, the EAS ECU in the P38A
> requires that you send a specific OBD-II style request with a specifc
> interval (measured in microseconds) after resetting power to the
> system.
>
> None of this is specified in the OBD-II standard. OBD-II will let you
> reset the fault codes on the Engine, but it doesn't address anything
> to do with EAS, or the BeCM, or anything else specific to the vehicle.
>
> I'm not trying to put you off the project. I'm just trying to share
> the benefit of what I learned two years ago, when I decided that it
> wasn't going to be trivial, and went off and bought a Rovacom Lite
> instead.
>
> Andy
>
> --
> Andy Cunningham -- www.cunningham.me.uk

> It can be done !!!!!!!!!!

Of course it can. But it needs additional hardware as well as a PC to work.


There is nothing to stop anyone reverse engineering any tool. That is,
reverse engineering the software and (THIS TOPIC) the hardware. All of
the tools mentionned must have designed their own electronics to
interface the software that they write with the hardware on the vehicle.

Therefore, to make the testbook CD's work on a computer, you would need
a testbook so that you could reverse engineer the hardware interface.
Defeats the object doesn't it?


[email protected] wrote:
> Wow, I've just read the replies ..... yeah I know it's difficult, but
> at the end of the day Rovacom & Autologic did it. The Testbook CD's
> can be reverse-engineered ..... and at the end of the day, what's to
> stop someone buying a Rovacom, Autologic or even A genuine Testbook &
> reverse engineering the whole thing ??? Rovacom want £825.00 for the
> direct BeCM module, which is a software patch on top of the 'ordinary'
> module .... c'mon, you're not telling me there is a means to an end
> there somewhere. Who's got an old BeCM lying around? What's the make
> & model of the processor for a start?
>
> It can be done !!!!!!!!!!
>
>
>
>
>
> AndyC the WB wrote:
>
>
>>>>>>>"Steve" == Steve <[email protected]> writes:
>>
>> Steve> The OBD-II port is RS485 link isn't it ? There was an
>> Steve> Elektor project recently to provide a OBD-II to 232 link.
>>
>>There are three difference communications standards that run over
>>OBD-II. One of them is RS485 or similar; the interface to RS-232 can
>>be built trivially.
>>
>>BUT the testbook software doesn't use the serial port - at least not
>>in the latest revisions. It uses the ETHERNET port to talk to the
>>HHT. And that's a much more complex proposal - figuring out how the
>>HHT converts it's ethernet data to something the car can understand.
>>
>>Alternatively, you could consider getting an old version of Testbook
>>to run on modern hardware. T4 runs happily under Windows XP until you
>>try to communicate with the vehicle, when it bitches about the absence
>>of the HHT. Don't ask how I know. The earlier versions ... are
>>early. They pre-date Pentium processors for one thing, and are likely
>>to have lots of hardware dependencies on the specific HP laptop that
>>was used.
>>
>>Another approach is to build from existing open knowledge on the
>>OBD-II protocols and build your own testbook. There's a Yahoo! group
>>called Open Diag that's populated with people building their own
>>interfaces to VAG diagnostics, and if you search around you can get
>>the BMW diagnostic software (which should talk to the engine in a
>>L322, BTW) off the web along with a diagram of how to build the
>>interface. As an aside, there's also a group called Hack The I Bus,
>>which is devoted to interfacing PCs to the I-Bus used in BMWs, the
>>L322, and possibly other post-BMW Land Rovers so that you can, for
>>example, surf the web from the in-dash display. Hopefully while
>>stationary.
>>
>>But building an interface for a Range Rover isn't just as simple as
>>building your own OBD-II interface. ODB-II specifies a minimum
>>communication protocol to communicate with the Engine Management
>>System (EMS) only. And the P38A has three different "OBD-II"
>>connections in the same interface - I forget the pinouts now, but the
>>Engine, BeCM, and EAS all communicate over different wires.
>>
>>Many ECUs require a specific challenge-response sequence to activate
>>the manufacturer specific functionality: for example, encrypting a
>>random number supplied by the EMS. If you can't reverse engineer the
>>key used, you're stuck. Or, more simply, the EAS ECU in the P38A
>>requires that you send a specific OBD-II style request with a specifc
>>interval (measured in microseconds) after resetting power to the
>>system.
>>
>>None of this is specified in the OBD-II standard. OBD-II will let you
>>reset the fault codes on the Engine, but it doesn't address anything
>>to do with EAS, or the BeCM, or anything else specific to the vehicle.
>>
>>I'm not trying to put you off the project. I'm just trying to share
>>the benefit of what I learned two years ago, when I decided that it
>>wasn't going to be trivial, and went off and bought a Rovacom Lite
>>instead.
>>
>>Andy
>>
>>--
>>Andy Cunningham -- www.cunningham.me.uk
>
>

Ok, I think this thread is beginning to lose track slightly. All I
want to do (& think that it *can* be done) is create an open source
Testbook / Rovacom / Autologic alternative. There appear to be 3 ways
of doing this;

1) Make the Testbook CDs work on an ordinary PC, either by hacking the
software and / or reverse engineering the genuine hardware. Yeah, the
latest Testbook uses the LAN port....... so why can't a PC with 2
bridged network cards & a packet sniffer be used to intercept the data?
Why not use an older Testbook?

2) Find out how Rovacom / Autologic do it

3) Start from what we already know about OBD2 & take it from there.

Yes I know it's going to be difficult & it's easier to just go out and
buy what's already out there, but that's just missing the point as far
as I'm concerened. I will probably buy a Rovacom anyway & have a play
with that to start with.

So the plan is to start an open source project, donate all the
information I have gained so far & try to get as much knowledge &
information & help together as possible.

On or around 14 Dec 2005 01:38:43 -0800, [email protected] enlightened
us thusly:

>So the plan is to start an open source project, donate all the
>information I have gained so far & try to get as much knowledge &
>information & help together as possible.

Ah, now there I support you 100%. And if I do end up buying a disco II then
I might well get involved...
--
Austin Shackles. www.ddol-las.net my opinions are just that
"Ask yourself whether you are happy, and you cease to be so."
John Stuart Mill (1806 - 1873)

May be of interest, but recently was surfing the net searching stuff along
these lines. What I came across was a chip called "elm" it's no rocket
science thing but is simply a dedicated interface built into one chip which
has multi protocol, the circuit to make it work is simplicity its self,
however the software seemed to be another problem. Hadn't even concidered
trying to get it to work with testbook. However I did comeacross a very
basic package which comes with software for not much money, the only
drawback being that the functionality was somewhat basic. Try a google with
EOBD elm should point you in the right direction.
"Austin Shackles" <[email protected]> wrote in message
news:[email protected]...
> On or around 14 Dec 2005 01:38:43 -0800, [email protected]
> enlightened
> us thusly:
>
>>So the plan is to start an open source project, donate all the
>>information I have gained so far & try to get as much knowledge &
>>information & help together as possible.
>
> Ah, now there I support you 100%. And if I do end up buying a disco II
> then
> I might well get involved...
> --
> Austin Shackles. www.ddol-las.net my opinions are just that
> "Ask yourself whether you are happy, and you cease to be so."
> John Stuart Mill (1806 - 1873)

There used to be a chap on the web offering the test book CDs for 250
dollers or pounds.

most of the cheap gizmos sold are just voltage level shifters between
RS232 computer serial and the ecu. The circuit is not rocket science and
appears many times at various sites. Much harder is the software as
messages are transmitted in fairly complex packages. You have to send
specific requests to the ecu, again as complex packages, to which the
ecu responds.
The transmition speed for ISO was incresed at some point and ISTR that
the higher speed message packages were different in some way.

Originally the RR used ISO 9141, there are about 4 essential papers
about this standard which cost about 180 UKP from British Standards
Institute, then for OBDii you need the Society of Automotive engineers
(USA) Manual for onboard diagnostics about 70 UKP (I think Amazon listed
it possibly Amazon.com not UK) There are also manufacturer specific
codes in OBDii but listings I have seen suggest that the classic RR just
mirrored the standard codes for these.

If you go to the next stage on, LR used GEMS and you can/could download
ecu reader software from their web site,

Once you get to the time of the BECM package you run into more problems
as ISTR there are about 8 computers tagged into a common bus, and it
used other bus standards as well as ISO9141 protocol, and other pins in
the OBDii connector to talk to the various systems.

I have some notes on the diagnostic pin output for the Lucas 14cux,
which I might just get round to loading onto my site.

I also need to update the ecu links as I have megabytes of stuff on my
harddrive, drop us an email I might just be persuaded to copy it all to
a Cd and send it to you, but lots of bad medical vibes in the family at
moment so I might be some time getting round to it.

The Elm package is ISTR just a level shifter, covers Ford, GM and ISO
protocols, but they have a good website/forum at scantool.net I think.

--
If you received this through the miracle of modern technology then all
is well; if not then situation normal.
Chris father of ( also at [email protected] )
www.users.zetnet.co.uk/barnes_firsnorton

In message <[email protected]>
Warwick Barnes <[email protected]> wrote:

> There used to be a chap on the web offering the test book CDs for 250
> dollers or pounds.
>
> most of the cheap gizmos sold are just voltage level shifters between
> RS232 computer serial and the ecu. The circuit is not rocket science and
> appears many times at various sites. Much harder is the software as
> messages are transmitted in fairly complex packages. You have to send
> specific requests to the ecu, again as complex packages, to which the
> ecu responds.
> The transmition speed for ISO was incresed at some point and ISTR that
> the higher speed message packages were different in some way.

Each message on the bus is in a packet or packets - the message has
a header, a data section, and a footer.
The header and footer are specified by the bus standard being used and
are irrelevant to the data contained (often the headers are about 70-90%
of each packet).
To read an ECU a message is broadcast to all devices on the bus (there's
only 1 on a RS232 "bus"). All devices recieve the message and examine the
data to see if the message is meant for them (it's up to the system
designer to make sure each has a unique ID). If it is, the device
can look at any additional data (it will know that the next three bytes
are some new parameters for, say, the temperature for example) if it
is programmed to do so, and then send out an acknowledgement that it has
clained the message (not essential, but it avoids messages clogging up
the system). If the mesage is a request for data, this will be added to
the acknowledgement and broadcast (it's entirely possible that more than
one device may need to know about the change - water temperature for
example will be of interest to the engine ECU, and body controller/HVAC
ECU's).

The only hard part is finding out the address of the ECU, and what the
parameters mean (if any) - for that you need the maufacturers specs.
The transport is provided by the bus specification - e.g CAN. You
can quite happily connect any device with a CAN controller (high speed
and low speed can be mixed, theortically) from any manufacturer and things
will work. If you look at the traffic on a bus monitor you can see the
device addresses and any data to see what is going on. What that data
tells you is the only manufacturer- specific bit. I once had a Jaguar
in a cardboard box inder my desk (i.e. all the ECU's) and it would
have been perfectly feasible to another box with a Bentley in it, all
on the same CAN bus - in this cae I know there would have been no clashes.



>
> Originally the RR used ISO 9141, there are about 4 essential papers
> about this standard which cost about 180 UKP from British Standards
> Institute, then for OBDii you need the Society of Automotive engineers
> (USA) Manual for onboard diagnostics about 70 UKP (I think Amazon listed
> it possibly Amazon.com not UK) There are also manufacturer specific
> codes in OBDii but listings I have seen suggest that the classic RR just
> mirrored the standard codes for these.
>
> If you go to the next stage on, LR used GEMS and you can/could download
> ecu reader software from their web site,
>
> Once you get to the time of the BECM package you run into more problems
> as ISTR there are about 8 computers tagged into a common bus, and it
> used other bus standards as well as ISO9141 protocol, and other pins in
> the OBDii connector to talk to the various systems.
>
> I have some notes on the diagnostic pin output for the Lucas 14cux,
> which I might just get round to loading onto my site.
>
> I also need to update the ecu links as I have megabytes of stuff on my
> harddrive, drop us an email I might just be persuaded to copy it all to
> a Cd and send it to you, but lots of bad medical vibes in the family at
> moment so I might be some time getting round to it.
>
> The Elm package is ISTR just a level shifter, covers Ford, GM and ISO
> protocols, but they have a good website/forum at scantool.net I think.
>

Richard

--
www.beamends-lrspares.co.uk [email protected]
Running a business in a Microsoft free environment - it can be done
Powered by Risc-OS - you won't get a virus from us!!
Boycott the Yorkshire Dales - No Play, No Pay