Loggable generic inputs

[wes kiser]

This has likely been covered in 40 places, but I haven't found it.

Will there be generic user configurable analog and digital inputs? IE, a place to give an input a custom name, general transfer curve, etc...

[muythaibxr]

Nope hasn't been covered.

We've not considered it at all. Sounds like a good idea, but will likely have to wait until the 2.0 firmware.

Ken

[wes kiser]

For me, that is the only thing I miss when using MS compared to the REALLY high end ecu's. I have encountered situations at work(fuel pressure for example) that the ability to log turned a complex diagnosis into a 3 second glance at a log.

[muythaibxr]

We will definitely support logging of generic ADC inputs, and you can mess with the ini to name it something useful, and the log viewer can even let you input an equation to convert it to useful units (assuming the transfer function is linear). That will work in 1.0, although it's a little bit time consuming.

For 2.0, we can probably add the way you describe it as a feature though.

Ken

[jsmcortina]

(I just split this off from the MS3 update topic)

Funnily enough I wanted this feature on Saturday as I have connected a second map sensor to measure exhaust back pressure. Consequently it is likely that it WILL make it into the 1.0 code...!

What I did find was that two theoretically identical MPX4250AP sensors have different enough calibrations that I can see. For my work I hard coded the calibration into the code. I was short on time so didn't investigate whether there was an electrical difference in my circuit or a real sensor issue.

I connected the two sensors to a syringe with a T-piece and played around with the calibration parameters until they were "close enough."

Linear transform inputs are easy enough with a 0v and 5v reading.

For curve inputs, it would be more involved. Using the same transfer function as CLT or MAT is straightforward and I guess this would cover many installs. e.g. if you want to measure intercooler temperature drop etc then using a same-type sensor should give a reasonable calibration.

James

[jsmcortina]

This will be in the next code snapshot, with a choice of
-raw
-linear transfer function
-same transfer functions as CLT, MAT or EGO

Hopefully the last option will make it easy add multiple same-type air temp sensors for example.

James

[UnaClocker]

Yeah... Intercooler delta temperature monitoring, here we come.. ;) hehe..

[jsmcortina]

I've got a MAP sensor hooked up to my exhaust (just before the collector on one bank) to measure exhaust back pressure. Seems to work ok with the new sensor code, but I need more smoothing as the signal is very noisy when the engine is running and I only really want to see the average. I might need to use some physical damping with the fuel filter method etc.

James

[racingmini_mtl]

Would it make sense to do the same timed sampling as the MAP sensor? I would imagine it has a similar behaviour but probably with more amplitude.

Jean

[jsmcortina]

Quite possibly yes, however that makes it rather a special case and only applies to the 5 local spare ADCs. Syncronised sampling won't work with CAN-extended sensors except at very low rpms.

I'll probably try adding the timed sampling though as an experiment. (This will just be a hardcoded test for now though.)

If there are other general case where timed sampling would help, then it could be added as an option.

James

[UnaClocker]

Maybe the remote CAN units could do the timed sampling on board, before sending the data onward..

[racingmini_mtl]

It's always possible but that means the remote CAN unit needs some tach signal to synchronize on. If this signal is coming from MS3 then it would be relatively easy but if it's coming directly from the crank/cam wheel(s) then that means it has to have a wheel decoder which starts to be quite involved.

But some sort of tach signal output (other than the standard tach output and maybe with more resolution) might be good for external devices which could then sample or process inputs according to a specific angle or window. But to really know the actual engine position would require either 2 signals or a missing tooth type of signal. Or it could be a simple windowing type of signal which is on during the sampling window and off elsewhere.

Jean

[jsmcortina]

This sounds like a lot of work unless we decide there is a good reason why we'd need it.

James

[racingmini_mtl]

I agree that there might not be a need for it. But once you have the angle clock, it should be quite easy to have one output go on for the duration of some angle window. That might be useful for an external knock detector. It might even be possible to use the tach output for this. But I'm not suggesting that there should be any meaningful priority put on that.

Jean