DIYEFI.org Forum

stumbled upon this

http://www.digikey.com/scripts/DkSearch ... 055-I/P-ND

this $5 chip is bloody great: analog ins, GP and pwm outs, CAN

this can also be used to expand MS to have more analog ins and PWM outs.


Alex

Nice! Would be even nicer if it had more pins.

i think this chip is for remote sensors/actuators. Since they are cheap enough, one can easily use one of those for several different locations and chain them on CAN, while minimizing the analog signal path (to fight noise).

btw, maybe it'd be a good idea to make a very sturdy cam/crank sensor amplifier, and put it right beside the sensor itself, and by this, minimize the undesirable noise/distortion effects.

All the optical and hall devices already consist of that. You can still stuff them with poor wiring technique though. VR is the only one really susceptible to it and even that is not really with a good conditioner with hysteresis.

There is no coincidence that my setup didn't have a single noise, heat soak, voltage offset, grounding etc issue :-)

It would be nice though if we minimised load on these grounds that matter by isolating the grounding systems that are not appropriate to tie together.

Putting it in remote locations seems like a nice idea :-) 2 wires out of the box and round the car and devices at the locations you need them.

Admin.

FYI the stock 2000 miata cam/crank sensors are VR sensors which get called hall effect but aren't, due to the same reason, they spit out a nice hall-like signal, but internally they watch for sharp transitions, and send a digital signal.

And I had lots of trouble with noise on that signal, not sure if it's from the sensor or....?


The chip is interesting, why on earth is it 1 wire? It's not some form of LVDS? That's just odd.... I thought, you know, people would want to get the signal there?

125*C? You could mount it in the valve cover. In the oil pan! Anyway, it's pretty awesome. I wonder if it's fast enough to handle things like triggering, after all the can bus issues and CRC's and all that.

8InchesFlacid wrote:I wonder if it's fast enough to handle things like triggering, after all the can bus issues and CRC's and all that.

No way :-) Nice try, no cigar ;-)

Fast enough for cam tooth, lamer, 'did it happen or did it not' type stuff...... Let the crank give you timiing....

8InchesFlacid wrote:Fast enough for cam tooth, lamer, 'did it happen or did it not' type stuff...... Let the crank give you timiing....

Well, in many cases (vvt for eg) you want the relative timing too. It is nice to have the relative timing anyway to compare against everything else if you should so desire. Certainly a fixed latency like that is a bad thing when everything else is scaling with speed. Hence our ignition calcs need to be padded a little to keep error small with rpm.

Hence, I don't see it as "did it or did it not".

Admin.

Reasonable, and I was thinking it myself. I'm not sure a fixed latency is so hard to deal with, it's the easiest thing to deal with there is! No math for that one. My concern is you don't know if something had to get sent twice, and that's an unfixed latency, and I'll admit that would ruin timing.

Unless (as it's a 1 Mhz communication I think?) 1e-6 seconds doesn't matter to you. 9,000 rpm/60sec is 150/sec * 360 = 18 us/crank degree. So, if it's 2 bytes of data, sent twice, yes, you're in the ballpark of a crank degree of error, so I could see you'd find this unplesant.

Now, if the data is somehow time stamped, it's a different issue, no trouble at all to put things back in order for a world class programmer such as yourself.

8InchesFlacid wrote:no trouble at all to put things back in order for a world class programmer such as yourself. :-)

LOL, yeah right....