ECU Input Multiplexer

[twdorris]

We've had this device in a prototype stage for over a year now. Well, we're finally at a point where we can blow the dust off and start working on integration. I wanted to post this thread up to get a little discussion going on the concept to make sure it all makes sense and that there's actually interest.

The idea is to multiplex multiple sensors into one ECU input. You connect up to 4 sensor inputs on one side of this device and then the device output routes to an ECU input. The ECU code tells this device which of the four sensors to connect to the input at any given moment and then samples that value when it's ready.

Control of the device (input selection) is done via two output pins of the ECU. You can select whichever output pins you want (EGR, Evap, FPS, WGS, etc).

So that's the upside. You can log more sensors than you could before. That's the good news.

The bad news is that the sample rate will be lower than the other inputs. This isn't because of the multiplexer itself. We can make that sucker switch as fast as we want. And it's not because of code limitations or processor limits or anything like that.

The problem is with the ECU hardware between the connector pins and the processor. There's a LOT of capacitance (filtering delay) built into that circuitry! I mean a LOT. We can offer ECU mods to correct this, of course, but that's not currently the plan because we'd rather not start hacking ECUs if we don't have to.

So, what's the sample rate? Based on testing, it seems we can sample each input at about 15 samples per second. At least on the 2G ECU. Doesn't seem bad, but when you're logging MUCH faster than that, those updates look a little slow.

Any thoughts on this? Would you rather do some mods to your ECU to get faster sampling or would you be happy with 15 samples per second? The things I could see this being used for would include fuel pressure, oil pressure, oil temperature, more air temp sensors, etc. The things this would NOT be appropriate for would include the boost sensor for speed density operation.

And how many would seriously consider wiring this up? It's not exactly trivial because you have a lot of wires to mess around with. Selector wires, sensor wires, power, ground, etc.

Thomas Dorris
ECMTuning, Inc.

 

[Calan]

I definitely think it would be worth it, and would use it in a heartbeat when I upgrade to V3 and go speed density. I'll be rewiring everything anyway at that point.

I don't think the sample rate would be an issue, if the multiplexed inputs are used for signals that don't change rapidly. (i.e oil temp, oil pressure, IAT, etc.). As long as the other 3 inputs (1G) are available for critical fast-changing signals, it seems like a nice option. And as long as the slow sampling isn't TOO slow

How much time/effort/cost would be involved with modding the ECU? Are we talking about a new PCB and redesigned ground plane or something?

EDIT:

After reading your post again, I'm a bit confused. Why do you have to select which input to read? Wouldn't Link be reading and logging all 4 multiplexed inputs? Or are you referring to how you tell Link what type of sensor is connected to each input? (In which case I still don't understand where the output lines come in to play).

Wait...are you just referring to timing signals for the multiplexer coming from any two outputs of the ECU?

 

[Hal]

I already have a use for it and the sample rates you posted up would be just fine.

Hal

 

[twdorris]

How much time/effort/cost would be involved with modding the ECU? Are we talking about a new PCB and redesigned ground plane or something?

No, no. Nothing like that. Just possibly removing a few components and replacing with new ones that reduce the filtering delay.

Wait...are you just referring to timing signals for the multiplexer coming from any two outputs of the ECU?

Yeah, the ECU code just needs some way to tell the multiplexer when to connect each sensor to the ECU's input at an appropriate time for the ECU to sample the value and store it away before moving on to the next one.

Thomas Dorris
ECMTuning, Inc.

 

[twdorris]

I already have a use for it and the sample rates you posted up would be just fine.

I'll get in touch with you in a few days, then, and see if we can get you a prototype board to test with.

Thomas Dorris
ECMTuning, Inc.