On or around Tue, 17 Oct 2006 17:11:05 +0100, beamendsltd
<beamendsltd@btconnect.com> enlightened us thusly:

>Unfortunately it's not that simple (Ex-R75 disgnostics Engineer hat on).
>The ECU only holds data, and that has to be converted into
>information which is readable/understandable by users (particularly
>if its on the vehicle, as owners will play....). The major factor
>thought, is that the vast majority of possible faults aren't specific
>to the ECU. It could, for example, detect an injector fault - but
>is it an output trasistor failure (which the ECU could usually
>tell, on Lucas ones anyway), the injector (or part thereof), or
>a wiring fault, or duff fuel, or lack of fuel etc etc.

It could, though, put up a code that says "#4 injector not firing" and then
you'd know what circuit to look at. similarly, for example, it could say
things like "plenum temp sender out of range", which of course could be the
sender, or a short-circuit wire, or an open-circuit wire... but knowing
which circuit you want to be checking would make life a lot easier.

>ECU fault
>codes are only the very start of diagnostics, and to make sense
>of a fault code a multimeter, oscillascope and god knows what
>else is possibly required.

indeed - it's similar to traditional diagnostics, in a way: "#3 cylinder not
firing". could be the plug, lead, dizzy cap, injector fault etc etc.

My point is that the ECU codes are only readable by (in LR terms) testbook
(or, I assume, Rovacom and similar) and if you're 300 miles from the nearest
such device, you're stuffed. If the fault codes were displayed on the
vehicle (even if it says "#4 injector fault" and nothing more specific) then
someone with just a mutlimeter etc. has a sporting chance of being able to
fix it.

>You only have to look at the number of faults that auto boxes
>on 38a Range Rovers trigger that are nothing to do with it to
>see how complex things can get. And of course the 38a Front
>ABS Sensor fault which gets blamed sqaurely on the traction control

well, that, frankly, sounds like a programming issue. Granted, TC and ABS
both use the same sensor, it should be possible to detect a sensor fault.
How does the 'box trigger faults in other systems...?

Mind, it seems like the 38a is about the worst of the bunch,
diagnostics-wise. ISTR that the disco III and next RR (forgotten the code)
are simpler/better.


--
Austin Shackles. www.ddol-las.net my opinions are just that
"Plus ça change, plus c'est la même chose"
Alphonse Karr (1808 - 1890) Les Guêpes, Jan 1849

Austin Shackles wrote:

> On or around Tue, 17 Oct 2006 17:11:05 +0100, beamendsltd
> <beamendsltd@btconnect.com> enlightened us thusly:
>
>>Unfortunately it's not that simple (Ex-R75 disgnostics Engineer hat on).
>>The ECU only holds data, and that has to be converted into
>>information which is readable/understandable by users (particularly
>>if its on the vehicle, as owners will play....). The major factor
>>thought, is that the vast majority of possible faults aren't specific
>>to the ECU. It could, for example, detect an injector fault - but
>>is it an output trasistor failure (which the ECU could usually
>>tell, on Lucas ones anyway), the injector (or part thereof), or
>>a wiring fault, or duff fuel, or lack of fuel etc etc.
>
> It could, though, put up a code that says "#4 injector not firing" and
> then
> you'd know what circuit to look at. similarly, for example, it could say
> things like "plenum temp sender out of range", which of course could be
> the sender, or a short-circuit wire, or an open-circuit wire... but
> knowing which circuit you want to be checking would make life a lot
> easier.
>
>>ECU fault
>>codes are only the very start of diagnostics, and to make sense
>>of a fault code a multimeter, oscillascope and god knows what
>>else is possibly required.
>
> indeed - it's similar to traditional diagnostics, in a way: "#3 cylinder
> not
> firing". could be the plug, lead, dizzy cap, injector fault etc etc.
>
> My point is that the ECU codes are only readable by (in LR terms) testbook
> (or, I assume, Rovacom and similar) and if you're 300 miles from the
> nearest
> such device, you're stuffed. If the fault codes were displayed on the
> vehicle (even if it says "#4 injector fault" and nothing more specific)
> then someone with just a mutlimeter etc. has a sporting chance of being
> able to fix it.
>
>>You only have to look at the number of faults that auto boxes
>>on 38a Range Rovers trigger that are nothing to do with it to
>>see how complex things can get. And of course the 38a Front
>>ABS Sensor fault which gets blamed sqaurely on the traction control
>
> well, that, frankly, sounds like a programming issue. Granted, TC and ABS
> both use the same sensor, it should be possible to detect a sensor fault.
> How does the 'box trigger faults in other systems...?
>
> Mind, it seems like the 38a is about the worst of the bunch,
> diagnostics-wise. ISTR that the disco III and next RR (forgotten the
> code) are simpler/better.
>
Exactly - and the cost of cpu power and displays is such that there is no
reason why the necessary software and a simple alphanumeric display could
not be included in the vehicle. It would add no more than a few hundred
dollars at most in a vehicle selling for $50,000 or more.
JD

Austin Shackles wrote:
>
> It could, though, put up a code that says "#4 injector not firing" and then
> you'd know what circuit to look at. similarly, for example, it could say
> things like "plenum temp sender out of range", which of course could be the
> sender, or a short-circuit wire, or an open-circuit wire... but knowing
> which circuit you want to be checking would make life a lot easier.

'zactly. But it still comes down to diagnostic skills to intepret what
is actually causing the fault. I had a friend's Toyota a couple of
weeks ago that was showing "knock sensor no signal for more than 3rpm".
It had been to a Toyota dealer who had replaced the sensor, 2 auto
electricians who had charged lots of money to say "the ECU's buggered"
and was brought to me as a last resort in the hope I could find a second
hand ECU on the cheap. 5 minutes with the multimeter showed a short in
the knock sensor wiring, 30 minutes stripped the loom and found where it
had been crushed by a monkey changing the clutch at an earlier stage and
another hour had it repaired and running perfectly with the original
knock sensor.

The battle for a refund from the clowns who had looked at it previously
continues. And my faith in modern day garages continues to wane - real
mechanics are becoming very rare, it's all just parts fitters who are
stumped the moment changing the obvious bit doesn't alleviate the problem.

Even more scary was interviewing candidates for a mechanic's job at a
mate's garage. 2 of the young guys not long out of their time had never
lapped a valve, and one had never even had the head off an engine
despite 4 years in the trade. And just to really reduce their chances
of getting the job neither of them could weld in any way, shape or form.


--
EMB

On or around Wed, 18 Oct 2006 11:16:38 +1300, EMB <embtwo@gmail.com>
enlightened us thusly:

>'zactly. But it still comes down to diagnostic skills to intepret what
>is actually causing the fault. I had a friend's Toyota a couple of
>weeks ago that was showing "knock sensor no signal for more than 3rpm".
> It had been to a Toyota dealer who had replaced the sensor, 2 auto
>electricians who had charged lots of money to say "the ECU's buggered"
>and was brought to me as a last resort in the hope I could find a second
>hand ECU on the cheap. 5 minutes with the multimeter showed a short in
>the knock sensor wiring, 30 minutes stripped the loom and found where it
>had been crushed by a monkey changing the clutch at an earlier stage and
>another hour had it repaired and running perfectly with the original
>knock sensor.

this makes my point in several ways, doesn't it?

Because you had a message saying "knock sensor no signal", you knew where to
look for a fault. The first effort would be to replace the sensor, but the
dealer's component-swapper, like a twit, then didn't follow that with "OK,
sensor's now presumed OK, why else would it not get a signal?" The auto
electricians should have known better and were either incompetent or simply
on the make. Knowing that the sensor had been changed, you were already
predisposed to look at other things. I'm surprised the dealer hadn't tried
fitting a different ECU to see if that cured it - profit margin on ECUs must
be considerable...

But if all you'd had was a "check engine" light, you'd have been wondering
where to start. Doubtless, it *could* have been diagnosed by a lot of trial
and error, but that would imply both time and available parts to swap out in
turn. That or a detailed examination of all the ECU wiring loom.

--
Austin Shackles. www.ddol-las.net my opinions are just that
"Chuck didn't reply, so George swung round in his saddle. He could just
see Chuck's face, a white oval turned toward the sky.
'Look,' whispered Chuck, and George lifted his eyes to heaven.
(There is always a last time for everything.)
Overhead, without any fuss, the stars were going out"
Arthur C. Clarke, "The 9 billion names of God"

On or around Wed, 18 Oct 2006 11:16:38 +1300, EMB <embtwo@gmail.com>
enlightened us thusly:

>Even more scary was interviewing candidates for a mechanic's job at a
>mate's garage. 2 of the young guys not long out of their time had never
>lapped a valve, and one had never even had the head off an engine
>despite 4 years in the trade. And just to really reduce their chances
>of getting the job neither of them could weld in any way, shape or form.


is the job still open? I can weld with gas, arc and mig and I've currenty
got the head off the TDi, now gone to be refaced, not because I really think
it needs it, but as a precuation, having had one gasket start to go.

#4 cylinder showed suspicious clean pacth in the soot-mark on the head.
--
Austin Shackles. www.ddol-las.net my opinions are just that
"Chuck didn't reply, so George swung round in his saddle. He could just
see Chuck's face, a white oval turned toward the sky.
'Look,' whispered Chuck, and George lifted his eyes to heaven.
(There is always a last time for everything.)
Overhead, without any fuss, the stars were going out"
Arthur C. Clarke, "The 9 billion names of God"

In message <45353fac@dnews.tpgi.com.au>
JD <jjd@spamlesstpgi.com.au> wrote:

> Austin Shackles wrote:
>
> > On or around Tue, 17 Oct 2006 17:11:05 +0100, beamendsltd
> > <beamendsltd@btconnect.com> enlightened us thusly:
> >
> >>Unfortunately it's not that simple (Ex-R75 disgnostics Engineer hat on).
> >>The ECU only holds data, and that has to be converted into
> >>information which is readable/understandable by users (particularly
> >>if its on the vehicle, as owners will play....). The major factor
> >>thought, is that the vast majority of possible faults aren't specific
> >>to the ECU. It could, for example, detect an injector fault - but
> >>is it an output trasistor failure (which the ECU could usually
> >>tell, on Lucas ones anyway), the injector (or part thereof), or
> >>a wiring fault, or duff fuel, or lack of fuel etc etc.
> >
> > It could, though, put up a code that says "#4 injector not firing" and
> > then
> > you'd know what circuit to look at. similarly, for example, it could say
> > things like "plenum temp sender out of range", which of course could be
> > the sender, or a short-circuit wire, or an open-circuit wire... but
> > knowing which circuit you want to be checking would make life a lot
> > easier.
> >
> >>ECU fault
> >>codes are only the very start of diagnostics, and to make sense
> >>of a fault code a multimeter, oscillascope and god knows what
> >>else is possibly required.
> >
> > indeed - it's similar to traditional diagnostics, in a way: "#3 cylinder
> > not
> > firing". could be the plug, lead, dizzy cap, injector fault etc etc.
> >
> > My point is that the ECU codes are only readable by (in LR terms) testbook
> > (or, I assume, Rovacom and similar) and if you're 300 miles from the
> > nearest
> > such device, you're stuffed. If the fault codes were displayed on the
> > vehicle (even if it says "#4 injector fault" and nothing more specific)
> > then someone with just a mutlimeter etc. has a sporting chance of being
> > able to fix it.
> >
> >>You only have to look at the number of faults that auto boxes
> >>on 38a Range Rovers trigger that are nothing to do with it to
> >>see how complex things can get. And of course the 38a Front
> >>ABS Sensor fault which gets blamed sqaurely on the traction control
> >
> > well, that, frankly, sounds like a programming issue. Granted, TC and ABS
> > both use the same sensor, it should be possible to detect a sensor fault.
> > How does the 'box trigger faults in other systems...?
> >
> > Mind, it seems like the 38a is about the worst of the bunch,
> > diagnostics-wise. ISTR that the disco III and next RR (forgotten the
> > code) are simpler/better.
> >
> Exactly - and the cost of cpu power and displays is such that there is no
> reason why the necessary software and a simple alphanumeric display could
> not be included in the vehicle. It would add no more than a few hundred
> dollars at most in a vehicle selling for $50,000 or more.
> JD
>

20p, 100mA or 100g is a lot in vehicle production - the hoops
deisgners have to go through to meet cost/weight/current
specifications is amazing - even on £50,000 vehicle. As an exmaple,
38a's very nearly had a "space saver" spare wheel, but in the
end other systems were reduced in weight, or removed, so a
tradiational spare could be accomodated. "Just adding" this or
that because it would be nice is not an option unless it's
designed in (and costed etc) right from the start.

Richard
--
www.beamends-lrspares.co.uk sales@beamends-lrspares.co.uk
www.radioparadise.com - Good Music, No Vine
Lib Dems - Townies keeping comedy alive

In message <necaj25fv4p8fg9ftg78eq2p5184fradc5@4ax.com>
Austin Shackles <austinNOSPAM@ddol-las.net> wrote:

> On or around Tue, 17 Oct 2006 17:11:05 +0100, beamendsltd
> <beamendsltd@btconnect.com> enlightened us thusly:
>

<snip>

>
> My point is that the ECU codes are only readable by (in LR terms) testbook
> (or, I assume, Rovacom and similar) and if you're 300 miles from the nearest
> such device, you're stuffed. If the fault codes were displayed on the
> vehicle (even if it says "#4 injector fault" and nothing more specific) then
> someone with just a mutlimeter etc. has a sporting chance of being able to
> fix it.

I woudn't disagree with that - infact I made myself rather unpoular
at Rover by very versifrously (sp?) stating that on an off-road
vehicle the user should always have the option of overriding
errors, but acknowleging that damage may be caused. At the
very least there should be a worth-while limp-home mode (it can
be done - even a dual failed crank and cam sensor can be got
over by calculating when the cylinder has fired by monitoring
the acceleration of the piston - Lucas ECU's can do this).

>
> >You only have to look at the number of faults that auto boxes
> >on 38a Range Rovers trigger that are nothing to do with it to
> >see how complex things can get. And of course the 38a Front
> >ABS Sensor fault which gets blamed sqaurely on the traction control
>
> well, that, frankly, sounds like a programming issue. Granted, TC and ABS
> both use the same sensor, it should be possible to detect a sensor fault.
> How does the 'box trigger faults in other systems...?

It's not triggering a fault - an error code is created, but why?
That's the diagnostics part - how to determine what the root fault
is - is it the sensor, or the wiring, of the ECU's attached to the
sensor? That's not a programming issue, it's down to the diagnostics
Engineer, the designer ("Feature Owner" in Roverspeak), and others
doing an FMEA to determine all possible faults, and the diagnostics
engineer working out how to prove (or eliminate) all possible error
conditions, which will mostly be "outside" the ECU.
e.g. - the gearbox can't get into third gear, so the box raises
an error. Is it a problem with the box, a sensor failure, the
engine not getting the right speed to allow the change, etc etc.
Just telling the driver/owner that "third gear can't be engaged"
is far more likely to lead to a false diagnosis ("Bugger, me grabox
is knackered") than just raising a "Gearbox Fault" error (which
the user probably knows anyway!) and requesting a session with
diagnostics tools to look at all possible problems. What it must
not do, in my book, is stop the engine (in off-road situations
certainly - a la Td5).

>
> Mind, it seems like the 38a is about the worst of the bunch,
> diagnostics-wise. ISTR that the disco III and next RR (forgotten the code)
> are simpler/better.

Well, they do have more extensive CAN bus conectivity, which
allows more devices to be interrogated which in turn helps
pin-point the problem without getting the tools out - but this
can lead to other problems, like the Discovery III rear light
bulb issue, if an unforseen (shouldn't happen, but Engineers
*hate* FMEA sessions) circumstance occurs.

What's needed is a full-blown computer on-board to give the
diagnostic ability, but designers will assume this needs to be
a PC, and will draw far too much current, and add weight
to the vehicle (both of which are considered very serious issues
in vehicle design). The solution is sitting under my desk though,
it draws just 2W and runs on 5V and could easily use and in-car
entertainment screen on the vehicle - but it ain't Windows, so
it won't get used! Car designers/manufacturers are *exteremely*
conservative - we had a fully CAN (and other bus standards)
4-wire "harness" in a Jag 10 years ago, but the technology
is still only being fiddled with in production vehicles
(except Citroen, who did a short production run of XM's about
8 years ago).

Richard

>
>

Richard

--
www.beamends-lrspares.co.uk sales@beamends-lrspares.co.uk
www.radioparadise.com - Good Music, No Vine
Lib Dems - Townies keeping comedy alive

On Wed, 18 Oct 2006 09:30:15 +0100, beamendsltd
<beamendsltd@btconnect.com> wrote:

As an exmaple,
>38a's very nearly had a "space saver" spare wheel, but in the
>end other systems were reduced in weight, or removed, so a
>tradiational spare could be accomodated.
>
>Richard

Would actually like one of those now, as LPG tank sitting in spare
wheel well.

Anyone know of anything that would fit?

David

beamendsltd wrote:

> In message <45353fac@dnews.tpgi.com.au>
> JD <jjd@spamlesstpgi.com.au> wrote:
>
>> Austin Shackles wrote:
>>
>> > On or around Tue, 17 Oct 2006 17:11:05 +0100, beamendsltd
>> > <beamendsltd@btconnect.com> enlightened us thusly:
>> >
>> >>Unfortunately it's not that simple (Ex-R75 disgnostics Engineer hat
>> >>on). The ECU only holds data, and that has to be converted into
>> >>information which is readable/understandable by users (particularly
>> >>if its on the vehicle, as owners will play....). The major factor
>> >>thought, is that the vast majority of possible faults aren't specific
>> >>to the ECU. It could, for example, detect an injector fault - but
>> >>is it an output trasistor failure (which the ECU could usually
>> >>tell, on Lucas ones anyway), the injector (or part thereof), or
>> >>a wiring fault, or duff fuel, or lack of fuel etc etc.
>> >
>> > It could, though, put up a code that says "#4 injector not firing" and
>> > then
>> > you'd know what circuit to look at. similarly, for example, it could
>> > say things like "plenum temp sender out of range", which of course
>> > could be the sender, or a short-circuit wire, or an open-circuit
>> > wire... but knowing which circuit you want to be checking would make
>> > life a lot easier.
>> >
>> >>ECU fault
>> >>codes are only the very start of diagnostics, and to make sense
>> >>of a fault code a multimeter, oscillascope and god knows what
>> >>else is possibly required.
>> >
>> > indeed - it's similar to traditional diagnostics, in a way: "#3
>> > cylinder not
>> > firing". could be the plug, lead, dizzy cap, injector fault etc etc.
>> >
>> > My point is that the ECU codes are only readable by (in LR terms)
>> > testbook (or, I assume, Rovacom and similar) and if you're 300 miles
>> > from the nearest
>> > such device, you're stuffed. If the fault codes were displayed on the
>> > vehicle (even if it says "#4 injector fault" and nothing more specific)
>> > then someone with just a mutlimeter etc. has a sporting chance of being
>> > able to fix it.
>> >
>> >>You only have to look at the number of faults that auto boxes
>> >>on 38a Range Rovers trigger that are nothing to do with it to
>> >>see how complex things can get. And of course the 38a Front
>> >>ABS Sensor fault which gets blamed sqaurely on the traction control
>> >
>> > well, that, frankly, sounds like a programming issue. Granted, TC and
>> > ABS both use the same sensor, it should be possible to detect a sensor
>> > fault. How does the 'box trigger faults in other systems...?
>> >
>> > Mind, it seems like the 38a is about the worst of the bunch,
>> > diagnostics-wise. ISTR that the disco III and next RR (forgotten the
>> > code) are simpler/better.
>> >
>> Exactly - and the cost of cpu power and displays is such that there is no
>> reason why the necessary software and a simple alphanumeric display could
>> not be included in the vehicle. It would add no more than a few hundred
>> dollars at most in a vehicle selling for $50,000 or more.
>> JD
>>
>
> 20p, 100mA or 100g is a lot in vehicle production - the hoops
> deisgners have to go through to meet cost/weight/current
> specifications is amazing - even on £50,000 vehicle. As an exmaple,
> 38a's very nearly had a "space saver" spare wheel, but in the
> end other systems were reduced in weight, or removed, so a
> tradiational spare could be accomodated. "Just adding" this or
> that because it would be nice is not an option unless it's
> designed in (and costed etc) right from the start.

Which is exactly what should have been done - let's face it, digital engine
and vehicle system management computers are not exactly new. Eventually the
sort of thing I am talking about will become commonplace some time in the
future, and should be much higher up the priority list than some of the
other things that are done.
JD

In message <45360746@dnews.tpgi.com.au>
JD <jjd@spamlesstpgi.com.au> wrote:

> beamendsltd wrote:
>
> > In message <45353fac@dnews.tpgi.com.au>
> > JD <jjd@spamlesstpgi.com.au> wrote:
> >
> >> Austin Shackles wrote:
> >>
> >> > On or around Tue, 17 Oct 2006 17:11:05 +0100, beamendsltd
> >> > <beamendsltd@btconnect.com> enlightened us thusly:
> >> >
> >> >>Unfortunately it's not that simple (Ex-R75 disgnostics Engineer hat
> >> >>on). The ECU only holds data, and that has to be converted into
> >> >>information which is readable/understandable by users (particularly
> >> >>if its on the vehicle, as owners will play....). The major factor
> >> >>thought, is that the vast majority of possible faults aren't specific
> >> >>to the ECU. It could, for example, detect an injector fault - but
> >> >>is it an output trasistor failure (which the ECU could usually
> >> >>tell, on Lucas ones anyway), the injector (or part thereof), or
> >> >>a wiring fault, or duff fuel, or lack of fuel etc etc.
> >> >
> >> > It could, though, put up a code that says "#4 injector not firing" and
> >> > then
> >> > you'd know what circuit to look at. similarly, for example, it could
> >> > say things like "plenum temp sender out of range", which of course
> >> > could be the sender, or a short-circuit wire, or an open-circuit
> >> > wire... but knowing which circuit you want to be checking would make
> >> > life a lot easier.
> >> >
> >> >>ECU fault
> >> >>codes are only the very start of diagnostics, and to make sense
> >> >>of a fault code a multimeter, oscillascope and god knows what
> >> >>else is possibly required.
> >> >
> >> > indeed - it's similar to traditional diagnostics, in a way: "#3
> >> > cylinder not
> >> > firing". could be the plug, lead, dizzy cap, injector fault etc etc.
> >> >
> >> > My point is that the ECU codes are only readable by (in LR terms)
> >> > testbook (or, I assume, Rovacom and similar) and if you're 300 miles
> >> > from the nearest
> >> > such device, you're stuffed. If the fault codes were displayed on the
> >> > vehicle (even if it says "#4 injector fault" and nothing more specific)
> >> > then someone with just a mutlimeter etc. has a sporting chance of being
> >> > able to fix it.
> >> >
> >> >>You only have to look at the number of faults that auto boxes
> >> >>on 38a Range Rovers trigger that are nothing to do with it to
> >> >>see how complex things can get. And of course the 38a Front
> >> >>ABS Sensor fault which gets blamed sqaurely on the traction control
> >> >
> >> > well, that, frankly, sounds like a programming issue. Granted, TC and
> >> > ABS both use the same sensor, it should be possible to detect a sensor
> >> > fault. How does the 'box trigger faults in other systems...?
> >> >
> >> > Mind, it seems like the 38a is about the worst of the bunch,
> >> > diagnostics-wise. ISTR that the disco III and next RR (forgotten the
> >> > code) are simpler/better.
> >> >
> >> Exactly - and the cost of cpu power and displays is such that there is no
> >> reason why the necessary software and a simple alphanumeric display could
> >> not be included in the vehicle. It would add no more than a few hundred
> >> dollars at most in a vehicle selling for $50,000 or more.
> >> JD
> >>
> >
> > 20p, 100mA or 100g is a lot in vehicle production - the hoops
> > deisgners have to go through to meet cost/weight/current
> > specifications is amazing - even on £50,000 vehicle. As an exmaple,
> > 38a's very nearly had a "space saver" spare wheel, but in the
> > end other systems were reduced in weight, or removed, so a
> > tradiational spare could be accomodated. "Just adding" this or
> > that because it would be nice is not an option unless it's
> > designed in (and costed etc) right from the start.
>
> Which is exactly what should have been done - let's face it, digital engine
> and vehicle system management computers are not exactly new. Eventually the
> sort of thing I am talking about will become commonplace some time in the
> future, and should be much higher up the priority list than some of the
> other things that are done.
> JD

From the manufacturers point of view, adding on board diagnistsics
is a way, way down the list - its heavy (realtively speaking), draws
"unncessary" current, would be of no interest to the vast majority
of users, wastes quite a lot of real-estate on the dash (or wherever),
is an "unecsessry" on-cost, etc etc.

And not forgetting that main dealers have an interest and have to be
kept happy!

Now putting a PlayStation in, or an extra cup-holder - customers
*want* them, so in they goes..... sadly.


Richard

--
www.beamends-lrspares.co.uk sales@beamends-lrspares.co.uk
www.radioparadise.com - Good Music, No Vine
Lib Dems - Townies keeping comedy alive

On Wednesday, in article
<e953a6774e%beamendsltd@btconnect.com>
beamendsltd@btconnect.com "beamendsltd" wrote:

> What's needed is a full-blown computer on-board to give the
> diagnostic ability, but designers will assume this needs to be
> a PC, and will draw far too much current, and add weight
> to the vehicle (both of which are considered very serious issues
> in vehicle design). The solution is sitting under my desk though,
> it draws just 2W and runs on 5V and could easily use and in-car
> entertainment screen on the vehicle - but it ain't Windows, so
> it won't get used! Car designers/manufacturers are *exteremely*
> conservative - we had a fully CAN (and other bus standards)
> 4-wire "harness" in a Jag 10 years ago, but the technology
> is still only being fiddled with in production vehicles
> (except Citroen, who did a short production run of XM's about
> 8 years ago).

"if it ain't Windows" isn't conservative, not if you want support for
the life of a vehicle. Windows 98 support has gone. A car company should
be looking at real-time embedded systems, where they can get the source
code. Some features will be overkill for fault indication, but neither
the vehicle nor the external support systems can depend on an OS with
the support lifespan shown by Windows.

This is nothing to do with the intended use of a Land Rover, or anything
special to any particular vehicle. It's just a simple, obvious,
consequence of the design life of a road vehicle, compared to a
computer. And if those engineers really thought that an in-car system
had to use Windows, I would find it hard to consider them competent. Not
because of the computer resources that Windows (or, to be clear, Linux)
needs to run, but because the idea fails to address the problem at some
of the most obvious practical levels.

Now, if you want the support software at a dealer's to run on a general-
purpose machine, you probably are stuck with Windows. Though I've seen
astonishingly old computer hardware attached to test rigs in workshops,
such as an Epson PX-8 (?) on a dynanometer.

--
David G. Bell -- SF Fan, Filker, and Punslinger.

"I am Number Two," said Penfold. "You are Number Six."

In message <20061018.1256.107445snz@zhochaka.org.uk>
dbell@zhochaka.org.uk ("David G. Bell") wrote:

> On Wednesday, in article
> <e953a6774e%beamendsltd@btconnect.com>
> beamendsltd@btconnect.com "beamendsltd" wrote:
>
> > What's needed is a full-blown computer on-board to give the
> > diagnostic ability, but designers will assume this needs to be
> > a PC, and will draw far too much current, and add weight
> > to the vehicle (both of which are considered very serious issues
> > in vehicle design). The solution is sitting under my desk though,
> > it draws just 2W and runs on 5V and could easily use and in-car
> > entertainment screen on the vehicle - but it ain't Windows, so
> > it won't get used! Car designers/manufacturers are *exteremely*
> > conservative - we had a fully CAN (and other bus standards)
> > 4-wire "harness" in a Jag 10 years ago, but the technology
> > is still only being fiddled with in production vehicles
> > (except Citroen, who did a short production run of XM's about
> > 8 years ago).
>
> "if it ain't Windows" isn't conservative, not if you want support for
> the life of a vehicle. Windows 98 support has gone. A car company should
> be looking at real-time embedded systems, where they can get the source
> code. Some features will be overkill for fault indication, but neither
> the vehicle nor the external support systems can depend on an OS with
> the support lifespan shown by Windows.
>
> This is nothing to do with the intended use of a Land Rover, or anything
> special to any particular vehicle. It's just a simple, obvious,
> consequence of the design life of a road vehicle, compared to a
> computer. And if those engineers really thought that an in-car system
> had to use Windows, I would find it hard to consider them competent. Not
> because of the computer resources that Windows (or, to be clear, Linux)
> needs to run, but because the idea fails to address the problem at some
> of the most obvious practical levels.
>
> Now, if you want the support software at a dealer's to run on a general-
> purpose machine, you probably are stuck with Windows. Though I've seen
> astonishingly old computer hardware attached to test rigs in workshops,
> such as an Epson PX-8 (?) on a dynanometer.
>

I should have made it clearer that I meant it would be the end
users who would be resistant to non-Windows systems, I think
I unintentionaly implied the actual Engineers. Having worked
as a freelance software engineer in embedded systems (often
automotive) I think I can say the industry is very well aware
of embedded systems (in the loosest sense), and the vast array
of OS's available.
Outside the automotive world, there are an awful lot of
process-control/machine control/etc systems still running
DOS quite happily, and probably will for a long time to
come - Windows just gets in the way (and reduces reliability
quite a lot), and also it requires completely uncessesary
overheads, e.g. a hard disc and a fair proportion of the
National Grid.

There is an OS however, which is used in an lot of high
reliability embedded systems in areas that don't get much
publicity, that has the OS in ROM, requires no hard drive and
runs on ARM processors (it's on my little ARM9 2W box under the
desk, which is actually just a rather neat industrial
controller!), but no ones ever heard of it. It would be
ideal for on-board automotive applications, it actually uses
less power that most alarm systems. It'll never catch on
though - it's British........


Richard

--
www.beamends-lrspares.co.uk sales@beamends-lrspares.co.uk
www.radioparadise.com - Good Music, No Vine
Lib Dems - Townies keeping comedy alive

beamendsltd wrote:

> In message <20061018.1256.107445snz@zhochaka.org.uk>
> dbell@zhochaka.org.uk ("David G. Bell") wrote:
>
>> On Wednesday, in article
>> <e953a6774e%beamendsltd@btconnect.com>
>> beamendsltd@btconnect.com "beamendsltd" wrote:
>>
>> > What's needed is a full-blown computer on-board to give the
>> > diagnostic ability, but designers will assume this needs to be
>> > a PC, and will draw far too much current, and add weight
>> > to the vehicle (both of which are considered very serious issues
>> > in vehicle design). The solution is sitting under my desk though,
>> > it draws just 2W and runs on 5V and could easily use and in-car
>> > entertainment screen on the vehicle - but it ain't Windows, so
>> > it won't get used! Car designers/manufacturers are *exteremely*
>> > conservative - we had a fully CAN (and other bus standards)
>> > 4-wire "harness" in a Jag 10 years ago, but the technology
>> > is still only being fiddled with in production vehicles
>> > (except Citroen, who did a short production run of XM's about
>> > 8 years ago).
>>
>> "if it ain't Windows" isn't conservative, not if you want support for
>> the life of a vehicle. Windows 98 support has gone. A car company should
>> be looking at real-time embedded systems, where they can get the source
>> code. Some features will be overkill for fault indication, but neither
>> the vehicle nor the external support systems can depend on an OS with
>> the support lifespan shown by Windows.
>>
>> This is nothing to do with the intended use of a Land Rover, or anything
>> special to any particular vehicle. It's just a simple, obvious,
>> consequence of the design life of a road vehicle, compared to a
>> computer. And if those engineers really thought that an in-car system
>> had to use Windows, I would find it hard to consider them competent. Not
>> because of the computer resources that Windows (or, to be clear, Linux)
>> needs to run, but because the idea fails to address the problem at some
>> of the most obvious practical levels.
>>
>> Now, if you want the support software at a dealer's to run on a general-
>> purpose machine, you probably are stuck with Windows. Though I've seen
>> astonishingly old computer hardware attached to test rigs in workshops,
>> such as an Epson PX-8 (?) on a dynanometer.
>>
>
> I should have made it clearer that I meant it would be the end
> users who would be resistant to non-Windows systems, I think
> I unintentionaly implied the actual Engineers. Having worked
> as a freelance software engineer in embedded systems (often
> automotive) I think I can say the industry is very well aware
> of embedded systems (in the loosest sense), and the vast array
> of OS's available.
> Outside the automotive world, there are an awful lot of
> process-control/machine control/etc systems still running
> DOS quite happily, and probably will for a long time to
> come - Windows just gets in the way (and reduces reliability
> quite a lot), and also it requires completely uncessesary
> overheads, e.g. a hard disc and a fair proportion of the
> National Grid.
>
> There is an OS however, which is used in an lot of high
> reliability embedded systems in areas that don't get much
> publicity, that has the OS in ROM, requires no hard drive and
> runs on ARM processors (it's on my little ARM9 2W box under the
> desk, which is actually just a rather neat industrial
> controller!), but no ones ever heard of it. It would be
> ideal for on-board automotive applications, it actually uses
> less power that most alarm systems. It'll never catch on
> though - it's British........
>
>
> Richard
>
An on-board diagnostic system should not concern the vehicle owner/mechanic
WHAT operating system is used - it simply interprets the CPU's error
outputs into human readable statements - possibly even just numbers to be
used with a list in the owners handbook, although there is no reason why it
can't use plain English.

And I would not be surprised to hear that there were a significant number of
industrial applications in current use running CP/M.
JD

JD wrote:

> And I would not be surprised to hear that there were a significant number of
> industrial applications in current use running CP/M.

There certainly are - I look after several.


--
EMB

On 2006-10-18, beamendsltd <beamendsltd@btconnect.com> wrote:

> It'll never catch on though - it's British........

Tsk. As is the processor design it's running on, which certainly
caught on, and the most popular OS on the ARM is Symbian's, also
British.

I'm assuming you're talking about Risc OS though, which to be honest
was never very reliable, I used it for 7 years and still have it, and
I'd certainly not regard it as suitable for an embedded system, parts
of it are used in some set-top boxes but no-one would use it in
anything other than the most simple system. A proper embedded OS
designed for the task would be better.

--
Blast off and strike the evil Bydo empire!

Ian Rawlings wrote:
> A proper embedded OS
> designed for the task would be better.
>
If its proper embedded, there isn't ROOM for an OS.


Steve, writing for 8 bitters still

On 2006-10-18, steve <steve@thetaylorfamily.org.uk> wrote:

> If its proper embedded, there isn't ROOM for an OS.
>
>
> Steve, writing for 8 bitters still

8 bitters? Nancy boy ;-) ISTR PIDs coming in four bits.

One of my favourite brain-bending machines of yesteryear was a British
machine IIRC, known as the DAP. It used a one-bit processor, 1024 of
them in an array... At 10MHz it could render a high-res raytrace in 5
seconds that took a high-powered sparcstation of the day over 2 hours
to generate. That was without a floating-point unit as well, just
integer maths. Nice little machine, provided you could program FORTRAN.

--
Blast off and strike the evil Bydo empire!

On or around Thu, 19 Oct 2006 09:27:52 +1300, EMB <embtwo@gmail.com>
enlightened us thusly:

>JD wrote:
>
>> And I would not be surprised to hear that there were a significant number of
>> industrial applications in current use running CP/M.
>
>There certainly are - I look after several.

There are persistent rumours of a nuclear reactor run by a gaggle of 8
commodore pets.
--
Austin Shackles. www.ddol-las.net my opinions are just that
"The boys are dreaming wicked or of the bucking ranches of the night and
the jollyrodgered sea." Dylan Thomas (1914 - 1953) Under milk wood

Austin Shackles wrote:
> On or around Thu, 19 Oct 2006 09:27:52 +1300, EMB <embtwo@gmail.com>
> enlightened us thusly:
>
>> JD wrote:
>>
>>> And I would not be surprised to hear that there were a significant number of
>>> industrial applications in current use running CP/M.
>> There certainly are - I look after several.
>
> There are persistent rumours of a nuclear reactor run by a gaggle of 8
> commodore pets.

Probably safer than a gaggle of 'doze machines.

--
EMB

On or around Wed, 18 Oct 2006 22:53:59 +0100, Ian Rawlings
<news06@tarcus.org.uk> enlightened us thusly:

>On 2006-10-18, steve <steve@thetaylorfamily.org.uk> wrote:
>
>> If its proper embedded, there isn't ROOM for an OS.
>>
>>
>> Steve, writing for 8 bitters still
>
>8 bitters? Nancy boy ;-) ISTR PIDs coming in four bits.
>
>One of my favourite brain-bending machines of yesteryear was a British
>machine IIRC, known as the DAP. It used a one-bit processor, 1024 of
>them in an array... At 10MHz it could render a high-res raytrace in 5
>seconds that took a high-powered sparcstation of the day over 2 hours
>to generate. That was without a floating-point unit as well, just
>integer maths. Nice little machine, provided you could program FORTRAN.

I've still got a Dragon 32, somewhere. dunno if it still works, mind. 6804
processor, IIRC.

--
Austin Shackles. www.ddol-las.net my opinions are just that
Soon shall thy arm, unconquered steam! afar Drag the slow barge, or
drive the rapid car; Or on wide-waving wings expanded bear the
flying chariot through the field of air.- Erasmus Darwin (1731-1802)