DIYEFI.org Forum

This is a subject near and dear to my heart since... I've spent months fighting it whereas everything else on my MS-II is a gimmie.

I've heard a lot of people mention that the OEMs use "very advanced" inputs which can't be copied by the amature, however I don't believe they are spending $7,000 an ECU and it's only bits of baked sand anyways. So I popped open my ecu and did a little digging:



And discovered the inputs (which had components that were very nicely numbered, kudos Mazda) were two identical circuits, one for the cam sensor, one for the crank. The crank sensor sees some very fast (angular) pulses, especially at full tilt.

The circuit is based around this chip:


and the whole circuit, including a filter cap, looks like so:



To give a little background, I started with these:

Which were based on a similar design used with some success by a friend who has his ecu in parallel with the OEM ecu. I only added a pull up resistor, but was having strange bucking issues, so added a filter cap. The trouble is finding a cap which takes the noise and leaves the signal.

This circuit worked well also:


But in general, they all had issues. Notice one input is inverting, and one is not (note, if I forget to put this in the features thread, the ability to accept either polarity signal on either sensor would be nice.). This is due to unreliable behavior of the leading tooth edge on most Hall Effect sensors I have read about, at low speed (under cranking conditions). This unreliable behavior led me to think the sensors were inverted relative to each other, although it turned out not to be.


Anyway, down to the suggestion part: Based on my experiences, I would want to see a board with the solid state buffer pictured above built on. It can be quite fast, though it's easy to slow it down by tuning the RC circuit within. I found a 10nf cap would lose sync even on an idealized pulsetrain from the JimStim at ~8,700 RPM (4 pulses per revolution, pulses ~10 degrees wide). At 1nf the circuit worked great on the simulator and mediocre on the car. After a few other values, I've settled on no cap at all, but the nice part is this is an easy to tune circuit by swapping values - once the board is there, leaving a cap in or out becomes trivial.

I will report back soon when I have a friend run this circuit in his parallel set up, to let you know if the NPN-followers are also a good idea to leave on, they certainly don't take up a lot of space - and with clever jumpering you might not even need to add much space on the board.


I'm very interested to see what other inputs people are using, or feel will work well.

One thing is for sure, I don't want to have a board with 1/3 of the total space wasted on inputs that you won't use most of except one, and that one you'll have to build a second copy of. A single opto-circuit makes good sense for converting carbed cars over, but something more sensical needs to be done in general, with an eye on keeping it flexible and small.

8InchesFlacid wrote:(note, if I forget to put this in the features thread, the ability to accept either polarity signal on either sensor would be nice.).

If you grab the latest code from the sourceforge download site, there is a draft xml config file in there. I have already included provision to set that for both inputs in that file.

This is due to unreliable behavior of the leading tooth edge on most Hall Effect sensors I have read about, at low speed (under cranking conditions). This unreliable behavior led me to think the sensors were inverted relative to each other, although it turned out not to be.

Because we will probably end up having trigger specific code, it should be trivial enough to use only trailing edges at some/all rpm depending on the requirements of the particular vehicle.

Anyway, down to the suggestion part: Based on my experiences, I would want to see a board with the solid state buffer pictured above built on.

Assuming you mean the LM339 based one, I'm in full agreement with you.

It can be quite fast, though it's easy to slow it down by tuning the RC circuit within. I found a 10nf cap would lose sync even on an idealized pulsetrain from the JimStim at ~8,700 RPM (4 pulses per revolution, pulses ~10 degrees wide). At 1nf the circuit worked great on the simulator and mediocre on the car.

That is because of the RC time constant of the circuit. Basically you want the largest cap and lowest resistance that your signal can drive to keep noise to a minimum. In the case of signals with high drive impedance you are SOL and need to have your load impedance similarly high to get a signal at all. Of course, once you do that, you lose all noise immunity. That's why a buffer like you propose is a very good idea indeed.

After a few other values, I've settled on no cap at all, but the nice part is this is an easy to tune circuit by swapping values - once the board is there, leaving a cap in or out becomes trivial.

Yes, I intend that most/all circuits have a highly configurable design/layout for just that reason.

One thing is for sure, I don't want to have a board with 1/3 of the total space wasted on inputs that you won't use most of except one, and that one you'll have to build a second copy of. A single opto-circuit makes good sense for converting carbed cars over, but something more sensical needs to be done in general, with an eye on keeping it flexible and small.

Because there is a good solution for basic carby swaps already available, we likely won't be targeting such installs at all. Because there isn't a cheap good sequential controller with generous I/O available, we will be trying to "corner that market". Coil triggering is a hack at best and has no place in a high performance EMS IMO.

However, noise on time sensitive inputs is a reality, and needs to be dealt with both on a hardware AND software level.

Thank you very much for this contribution!

Admin.

Ok, I can see that. I'm normally all for maintaining flexibility, but it's true that a car without electronic ignition is likely not one that NEEDS more than 2 or 3 outputs. And I'm sure someone who wants to could find a way to hack it in, but leaving it out will make a lot more sense.

I wish I had more of a sense of which cars require VR sensors. Is there a better way to do it? There are other products which use op-amps to read out VR sensors, I have a feeling with some *careful* layout, a system of jumpers or other trickery could make a generic input with the same chip useful for both VR (2 op-amps per input) or Hall Effect (1 op-amp per input) detection. I looked at this briefly but discovered many traces would have to be cut. I may revisit this at some point but the circuit I made was trivial to proto-board.

That would be awesome for board space if so! I look forward to reading about your research.

Trying to stuff 50 input conditioners on one board and 50 output buffers and a power supply on the other is going to be tight and that would help a lot.

Admin

Not to belabor any points I've made offline, but I'm interested if anyone else has input: there are many simple in-line packages with many simple discrete in parallel. They are generally low-cost, and have many components in one package, for instance you might find a "pull up chip" which is a single inline package with 30 pins, and 29 of them would be one side of resistors, and the last pin would be a common ground (or high) for them all. Great when used with jumpers/DIP switches, you could have 30 input channels independently selectable for pull up/down/float in minimal real-estate. Banks of LEDs and even amplifiers can be found that way.

Certainly an eye for ease of getting them, cost, and the trade-offs for single component replacement verses the cost/complexity savings of a multi-component pack would need to be considered. Once you start to get an idea for what your inputs and outputs will look like, it will be time to look at this.

Along with those points I mentioned last night offline, another reason to not do it is that many channels that will be laid out the same may be used very differently. so having a 10k pullup might be ok for 1 - 6, but 7 and 8 need 1k pull up etc.

I'm very keen on discrete, and I've said this before, at least for the first version. One must remember that the primary purpose of this site is DIY, the second is making a KICK ARSE EMS to rule all others. i.e. component choice and ease of construction etc are primary factors for the first version. This will not be the sort of EMS that you can "order online", at least, not at first. It will be one that you build 100% yourself with parts you can get easily.

I think it's very important to keep sight of this and resist the temptation to go towards SMD and unique/odd ball/non std parts that you cant pick up from the local retail place even if it does suck. must of the circuits on the board will be very basic with a very low number of components.

I have some thoughts about how to lay it out in certain respects to allow configurability with discretes Achieving the same thing with banked parts may be a lot more difficult and less versatile. I see where you are coming from, and I like the idea too, but there are downsides.

Thanks for pointing it out though. I'll be sure to keep an eye on the idea. For LEDs I like it : you can get them in most small crappy shops, and it doesn't affect the jumperability.

Admin.

Look what I found :-)

http://www.fortunecity.com/silverstone/ ... ddis2.html

Note the interesting input filter circuit.

Admin.

Nice find! A good write up. Someone running 8 teeth on that chip on a 10,000+ rpm motor is wise to mention the concerns of having time for your code to finish between teeth as he did.

I really liked the chip for self-adjusting the dwell times on the coils. Perhaps it's less of an issue on a COP set up, as you'd have to monitor a whole additional line, but it's not impossible. Not easy, though, on COP, but the idea of self-monitoring on both ignition and injectors appeals to me. More so on injectors where even a small error will wreak havoc with getting a smooth predictable idle.

The input filter I both like and dislike. One the one hand, it's easy to modify, etc. And it should work well, but keeping noise out and signal in may not be a trivial task.
Much more importantly, it's not a "zero crossing" detector, so you're looking for a rising spot on the tooth (or falling) - means it is more susceptible to noise (at least, it'll introduce timing errors of even a few degrees?). A 'Zero crossing' circuit looks for when you transition from seeing more tooth to less tooth, i.e. the center of the tooth passing the center of the detector. The nice part about this is even if the tooth is more or less pronounced than expected/usual due to really any effect, you still "cross zero" at the same point.

It bears more looking into, but my initial reaction is that I would look for this "tooth peak" instead.

I'm quite a bit late on the discussion, but I'm using this on my board. I have a simple single sided gerber to put up if anyone wants to make it (smt) .. it only does mode a1/a2/b .. the c mode peak detect can be mimicked w/a simple cs1124 so I didn't bother trying to accomodate it. mode c is intended for something like rpm (tranny/wheelspeed) inputs.

That's an interesting chip. I don't think I can make it, but I would find the gerbers interesting to look at. I see it's a 10 pin device, but the block diag shows 3 pins, 5 if I assume one ping for each V+ and V-. I wonder what other bits it has and how it preforms relative to the LM1815 we have in the 1.0 schematics. Appears both do nearly the same thing. Is this some thing you have connected to a reluctor?