Change MPG gauge into Boost gauge

[farberio]

CAT5 would be more than sufficient for running a vehicle.

 

In speed maybe, but there is more to vehicle networks then speed alone. Cat5 is not a fault tolerant system, CAN is. This is extremely important in the automotive world.

 

There are two hurdles to overcome. One is that I don't believe there is sufficient processing power in a standard ECU to be able to operate vehicle controls at the speeds a CANBUS allows. This is, really, a marginal fault. It can be done quite easily, but not quite cheaply. It's like comparing a TI-83 to a MacBook Pro. The TI will get the simple jobs done, but start feeding it complex data at an extraordinary rate and you will stall while the MBP will chug it out without so much as a blink. We are talking about processing rates faster than you can comprehend.

 

We will see CANBUS operated vehicles as Hybrids and electric vehicles become more prevalent.

 

 

CANBUS basically is the standard these days. Heck its probably due for replacement soon. Your comparison isn't really fair. Inside a macbook pro it would run the entire car, however, cars use distributed computing techniques. Meaning the distributed computing needs a fast network to share data but inside the MBP it doesn't need that. Also when you have distributed networks you can fill up that data bus really fast! CAN uses an arbitration system where the lowest message gets control of the bus, meaning all the important messages have priority over the more useless messages.

 

You already see car systems moving to a higher speed CAN as well as putting some systems on a LIN bus to move traffic off CAN.

 

The other speedbump in this development is the sensory input. To go FULL-CANBUS, you'd need each sensor to transmit it's value through CAN signal, which means "smart" sensors and solenoids. This can be done, but durability will be a concern for now. Things are getting better every day, though.

 

As the Green push gets heavier, I expect CAN control will be the only thing that will save the ICE.

 

This makes no sense. Those solenoids and sensors will always have to be controlled by a microprocessor. Sticking them on the CAN bus instead of straight to the controlling micro is just extra cost for no benefit. Also CAN won't save the ICE, CAN is just a network, its the ECU's on the CAN bus that do all the thinking. The ICE will eventually die, there is no arguing that.

[ehsnils]

If you want to do some real fun you may look at this little box - all you have to do is program it!

http://www.stw-technic.com/products/canbus-modules/freely-programmable/esx-3xl/

[nemo]

Pretty much everything that BAC has said should be interpreted as: you're not going to do it.

 

Just buy one of these and call it a day: http://legacygt.com/forums/showthread.php/vent-boost-gauge-digital-led-bars-numerics-125083.html?t=125083&highlight=lossol

[BAC5.2]

You are on the right track.

 

The ONLY way to do this is to perform a man in the middle attack on the MPG gauge.

 

This means you have to have a new micro that has (count them) 2 CAN controllers on them. From the MPG Gauge to the outside world you simply pass through and don't modify the data. But messages going to the MPG Gauge you modify the contents to perform your action.

 

So basically, as BAC5.2 pointed out, you override the message to the MPG guage with your own algorithm to scale the boost across the needle.

 

You need to keep any message the MPG Gauge sends to the outside world because if you stop them other controllers that are looking for the MPG module to exist will throw a code.

 

Nothing on the low-speed bus will set a code, as far as I can tell. In fact, I don't think ANY CAN miscommunication will trigger any kind of CEL or otherwise. You can unplug the OE NAV unit, which will cease CAN requests, and throw no errors. At the same time, you can add an OE NAV screen, which will request items never before requested without any error.

 

That said, I think you could so all of this with a single CAN controller. Simply block the MPG needle request from going to the ECU and fabricate your own return value scaled to the needle. Let everything else pass through. That should work. The question is formatting and scaling. Tracing down the CAN request code is difficult, but not impossible. Just monitor the low-speed bus while you cycle through the display settings.

 

The trick will be inputting the boost value, since you'll have to request that info on the high speed, then copy it and output a scaled version on the low-speed bus.

 

After all of that, the gauge still says MPG on top of it, which is kind of lame.

 

 

I think cars will always use internal networks to communicate within the car, but a wired connection will pose a problem when cars start talking to other cars, traffic lights, and the road.

 

But a wired connection for engine management, and a wireless communication protocol for interacting with other vehicles, lights, and the road, are two very different things.

 

In speed maybe, but there is more to vehicle networks then speed alone. Cat5 is not a fault tolerant system, CAN is. This is extremely important in the automotive world.

 

You say that as if our cars use CAN for anything other than superfluous information. They don't. The CANBUS is only for in-vehicle communication, but not at all for actual control over the engine. That much of the ECU is very much the same as it ever was.

 

I think CAT5 would be suitable for engine management, but ideally as I pointed out, I think CAN is a direction that ICE's will have to take in future iterations.

 

CANBUS basically is the standard these days. Heck its probably due for replacement soon. Your comparison isn't really fair. Inside a macbook pro it would run the entire car, however, cars use distributed computing techniques. Meaning the distributed computing needs a fast network to share data but inside the MBP it doesn't need that. Also when you have distributed networks you can fill up that data bus really fast! CAN uses an arbitration system where the lowest message gets control of the bus, meaning all the important messages have priority over the more useless messages.

 

You misunderstood my comparison.

 

I'm not talking about running the radio, and turning on and off lights. I'm talking about engine management only. Existing ECU's are much slower than a CAN network. Case-in-point is datalogging through CAN. You can read 100 parameters/second, faster than the ECU can receive data from the sensors on the engine.

 

Car's don't use distributited computing to run the engine. That was my point. In order to take advantage of the speed that a CANBUS would allow, you'd need an ECU far more powerful than what we currently have. Hence the TI-83 to MBP comparison.

 

CANBUS would allow the speed necessary to do things never really before possible. Like eliminate "open loop", tune cylinders independently, and even do things like adjust bank valve and ignition timing DURING combustion. That's a processing challenge the current ECU's aren't capable of doing, and replacement standalone's are clumsy at accomplishing (by attempting to utilize brute computing power, when that's not the solution).

 

 

This makes no sense. Those solenoids and sensors will always have to be controlled by a microprocessor. Sticking them on the CAN bus instead of straight to the controlling micro is just extra cost for no benefit. Also CAN won't save the ICE, CAN is just a network, its the ECU's on the CAN bus that do all the thinking. The ICE will eventually die, there is no arguing that.

 

What doesn't make sense about it?

 

Current sensors aren't controlled in most cases. Look at the knock sensor. A simple piezoelectric microphone. In order to meet the demands of new ECU speed allowed by CANBUS, you'd have to have sensors allowing a much higher degree of precision. Integrated sensors are the only real way of doing this. I'm not talking about relying on microprocessors on each sensor to handle the computations associated with controlling the engine. The resolution of sensors we are using now is blunt, at best.

 

You entirely misunderstand me if you think I'm ONLY talking about replacing the current network with CAN and thinking that will save the ICE. I'm not. I'm saying CAN will allow the use of an ECU capable of handling the demands of efficient control of an ICE. Will that save the ICE? It could help extend it's life, at least.

[farberio]

For starters, I took all CAN comments earlier to mean the whole car, not just the Engine Controller.

 

 

Nothing on the low-speed bus will set a code, as far as I can tell. In fact, I don't think ANY CAN miscommunication will trigger any kind of CEL or otherwise. You can unplug the OE NAV unit, which will cease CAN requests, and throw no errors. At the same time, you can add an OE NAV screen, which will request items never before requested without any error.

 

It may not throw an code that is visible to a driver, but certain modules keep track of other modules to verify that they are present and working. The error may not be present to the user, but believe me when I say some poor engineer gets a phone call when one of those errors pop up during development.

 

 

That said, I think you could so all of this with a single CAN controller. Simply block the MPG needle request from going to the ECU and fabricate your own return value scaled to the needle. Let everything else pass through. That should work. The question is formatting and scaling. Tracing down the CAN request code is difficult, but not impossible. Just monitor the low-speed bus while you cycle through the display settings.

 

 

The trick will be inputting the boost value, since you'll have to request that info on the high speed, then copy it and output a scaled version on the low-speed bus.

 

You need two controllers because you would need to isolate the unit from the original message. Otherwise the unit will receive two messages, one with the MPG data and one with the boost data. The unit would try to react to both and we would not get good results as a boost controller.

 

 

After all of that, the gauge still says MPG on top of it, which is kind of lame.

 

Agreed. And it wouldn't even have the numbers on it.

 

 

But a wired connection for engine management, and a wireless communication protocol for interacting with other vehicles, lights, and the road, are two very different things.

See first sentence. I think we can all agree that the Engine Controller talking to wireless system would be a bad idea.

 

You say that as if our cars use CAN for anything other than superfluous information. They don't. The CANBUS is only for in-vehicle communication, but not at all for actual control over the engine. That much of the ECU is very much the same as it ever was.

 

I think CAT5 would be suitable for engine management, but ideally as I pointed out, I think CAN is a direction that ICE's will have to take in future iterations.

Speaking just from the engine controller, correct, the canbus is more limited in its use. Except for some sensors and fuel pump.

 

 

You misunderstood my comparison.

 

I'm not talking about running the radio, and turning on and off lights. I'm talking about engine management only. Existing ECU's are much slower than a CAN network. Case-in-point is datalogging through CAN. You can read 100 parameters/second, faster than the ECU can receive data from the sensors on the engine.

 

Car's don't use distributited computing to run the engine. That was my point. In order to take advantage of the speed that a CANBUS would allow, you'd need an ECU far more powerful than what we currently have. Hence the TI-83 to MBP comparison.

 

I disagree. I know for a fact that the Mazda RX8 runs two micro's inside of its Engine Control Unit and I would bet money on the fact that they aren't the only ones to do so. As far as chip to chip communication they are likely doing direct communication, SPI ports are the fastest and can go faster then 10Mbps. (CANBUS is 1Mbps in theory. The fastest I have used was more like 500kbps)

 

CANBUS would allow the speed necessary to do things never really before possible. Like eliminate "open loop", tune cylinders independently, and even do things like adjust bank valve and ignition timing DURING combustion. That's a processing challenge the current ECU's aren't capable of doing, and replacement standalone's are clumsy at accomplishing (by attempting to utilize brute computing power, when that's not the solution).

 

At some point you have think of economies of scale. The cost of doing what your proposing sounds like the benefits of doing it won't be that great. Also, the Engine Control Unit likely would be broken up inside one box and not across multiple boxes so using a different communication protocol from micro to micro would be more ideal.

 

 

What doesn't make sense about it?

 

Current sensors aren't controlled in most cases. Look at the knock sensor. A simple piezoelectric microphone. In order to meet the demands of new ECU speed allowed by CANBUS, you'd have to have sensors allowing a much higher degree of precision. Integrated sensors are the only real way of doing this. I'm not talking about relying on microprocessors on each sensor to handle the computations associated with controlling the engine. The resolution of sensors we are using now is blunt, at best.

 

I still don't follow you? If you talked to a sensor over a canbus you must have a microcontroller built into the the sensor. Secondly, just because the canbus would be faster doesn't mean the sensor HAS to be better.

 

 

You entirely misunderstand me if you think I'm ONLY talking about replacing the current network with CAN and thinking that will save the ICE. I'm not. I'm saying CAN will allow the use of an ECU capable of handling the demands of efficient control of an ICE. Will that save the ICE? It could help extend it's life, at least.

 

CANBUS inside the Engine Control Unit is still silly, unless they break up the Engine Controller into multiple physical boxes. As a footnote, saying 'ECU' is not very descriptive because it duals as "Engine Control Unit" as well as "Electronic Control Unit". Where the "EngineCU" is a subset of the "ElectronicCUs" on the whole system.

[ShadowImg]

So I was hoping to find that someone on here had dug into the CANBus message IDs for the Legacy, or on NASIOC for Subarus in general. Unfortunately, I've found nothing of the sort. I did stumble on this thread which has some good explanations of how the CANBus works, and some hypotheticals that depend on exactly this:

 

Gonna throw it here in case anyone else is interested. I've backed it to get one, and plan to wire it in and start trying to decode the messages. If anyone has any reference material on the CANBus message IDs for the Legacy and their message contents, please share.