series fuel gauge

'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.

On or around Wed, 18 Oct 2006 11:16:38 +1300, EMB enlightened us thusly:

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.

On or around Wed, 18 Oct 2006 11:16:38 +1300, EMB enlightened us thusly:

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.

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).

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).

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

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

As an exmaple,

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

Anyone know of anything that would fit?

David

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

"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

There certainly are - I look after several.

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.

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.

On or around Thu, 19 Oct 2006 09:27:52 +1300, EMB enlightened us thusly:

There are persistent rumours of a nuclear reactor run by a gaggle of 8 commodore pets.

Probably safer than a gaggle of 'doze machines.

On or around Wed, 18 Oct 2006 22:53:59 +0100, Ian Rawlings enlightened us thusly:

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

So've I, along with a brace of beebs, a few C64s and a range of other old geek gear, even a Mattel Aquarius with a four-colour pen plotter! Must dig it all out sometime before the bat piss rots it all away.