Peter.N. wrote:Mmm, I was in electronics all my working life but I still only fully understand things with valves in them, you could usually just look at a circuit and see what was wrong with it, a fat chance of that now. BUS lines were just coming along in TV when I retired and although I could see what they did I couldn't see how they did it, repair was largely a matter of guesswork, as it seems to be with most aspects of car repairs now.
Peter
I think that as you get older there comes a time when the brain just refuses to climb the next" vertical learning cliff" certainly true in my case
To understand BUS's in general terms is not so difficult, generally from a troubleshooting point of view what you need to know is what the various bits connected to the bus produce in the way of data and what data they need to do whatever it is they do. e.g Auto gearboxe's need to know what Torque the engine is producing as does the ESP system so logically the Engine ECU calculates engine Torque, just need to get that data to the Autobox ECU and the ESP ECU i.e via "the BUS" . However if you want / need to see what is actually happening on the bus then you need to know much more about how it works both at a hardware level and a software protocol level.i.e electrically how many data wires are there and what voltage levels represent a 0 and 1.
Some buses may consist of many wires each with a predefined function i.e a processor bus on a PC motherboard where you may have 16 address lines and 8 data lines, these are generically known as parallel buses and are quite easy to interrogate and understand with a logic analyser. However most modern buses that are used to connect different modules separated by some distance are serial in nature often using no more than two wires. The advantages are reduced wire count and a reduced number of connections all of which equals reduced cost and increased reliability which is why they figure so much in modern cars (and before cars aeroplanes). If you want an example just look at the number of wires and connectors that go to the Dashboard on the XM and then look at the C5.
Taking the previous PC motherboard example and converting it to a serial data stream requires that the address data and the data data are put into a serial stream in such a way that it can be reliably decoded at the other end. This would require as a minimum 24 bits being transmitted however to complicate things there needs to be a way of indicating the start of the message packet and a way of separating the two parts of the message i.e address data and data data into individual sub packets add to this extra bits for proof of data integrity and the complete message packet might be as long as 32 bits or considerably longer if data is represented as ascii characters. To actually read the data of a serial data bus requires something a bit more complicated than a logic analyser something like a PC with the correct hardware interface for the Bus being examined which is....yes you got it a Lexia ....well close anyway, in fact the Lexia gets all of it's data indirectly via the K line on certain ECU's or the Diagnostic CAN bus.
The Lexia only has one draw back which is that you cannot connect it directly to a data bus and read the raw data directly. However I cannot imagine any circumstances in normal troubleshooting where this facility would ever be required so it's not really a problem.
As I said at the beginning you don't really need to know about the bus in this level of detail BUT YOU DO need to know what data each ECU produces and which ECU's use the data or you can find yourself scratching your head or worse chasing things that don't exist.
cachaciero
obviously will visit a lexia owner..
Just wait until the ECUs have quantum processors 