DIYEFI.org Forum

I'd agree, KICAD and many free software packages are quite good, often better then the stuff you can buy. Another feature I like allot about KICAD is how they used a text file for their data files. I often open them to edit them manually, which is much easier to do then constantly clicking things to change things.

A recent example, when I generated the netlist, it complained that the TA board pinout didn't match my schematic. I hadn't looked at the underlying pin naming before, I simply called pins 1, 2, 3, ect, but KW1252 used a better plan and called them 1H01, 1H02, 2H01, 2H02, ect. So I had 100 pins to change. That would have been a bear to do in the GUI, but I opened the file, copied and pasted the beginnings to the pins numbers I had already done. Took like 5 minutes. That was so nice and a feature I haven't seen on any other proprietary file format. They usually encrypt / compress the files in such a manner that you can't edit them unless you use their tools to do it. I'm a big fan of KICAD.

About figuring out how to merge work together, I'll have to think about that a bit more. I had put the schematics together in a manner where someone could work on one schematic while I worked on another. It was a modular design. Perhaps we can use the SVN, or something. If you're looking for a place to work on freeEMS 1.0, I haven't looked into the 3D part of the footprints I've made. Those have been released.

Also, what is the goal of the above schematic? Right now were using XOR's for digital buffering else where, including the hall. Are you looking to use an analog hall, then turn it into a digital signal?

Also, also, curious how it went when you opened freeEMS 1.0. You extracted, then opened and it all worked OK? I beleive I used relative links not absolute links so it should work OK, but I may have missed something.

8InchesFlacid wrote:How do I get the attention of the main board design? I want to see this incorporated.

I would say your on the right track, can you give a description of what the goal of this circuit is? There are many talents out here, and many can add to what you've started.

Some ways it could be added include a module that you add after, or if it seems to match with the 1.0 goals, then we can simply add it to the RPM_input schematic. I think it should go up for review and let folks chime in. Right now I honestly don't really know what it does.

Slightly grown up version with a 2-layer board:


I'm not too worried about the resistors standing up, do you think I should be?

Will include a top-down view with silkscreen as soon as I figure out a nice way to move the labels around.

Ok, I guess I will have to look at your digital XOR's you mention. This is just something I've used, tested, and am happy with in my own car.

The miata has some "hall-like" preprocessed VR sensors, which ground when they think they see a tooth, though internally it's all VR.

They are also pretty ugly, and running this was the only thing in months that took care of it.

My idea was to have it onbaord right near your VR circuits, and people would just jumper the input pins either to this circuit or to yours. And if they use the VR ins, it would leave this free for another digitally buffered (inverting) input.

This is NOT for reading an analog hall signal.

Ok, I guess I haven't explained this circuit very well.

It has a few main advantages, all of them in the noise-handling area.

1) It automatically filters anything shorter than a gate delay, independant of amplitude
2) It displays (tunable) hyterises. I.E. 3V even for a long period will be ignored if you're in the "ground" state
3) You can still add caps for more noise rejection (shown, but not used in my car)
4) Relatively small, low part count, cheap, etc

It works by self biasing one of the pins of the comparator - so your current state moves the threshold. 1) ans 2) work together to make it very robust. The delay is fixed (I've watched it on a scope), so there's no weird issues with caps charging differently at different current/voltages and causing a variable delay, hence an error in timing.

I doubt it's the best thing out there, and am open to discussing it, but I haven't yet seen anything nearly so simple (up to the oodles of resistors) or cheap which can do this good a job.

It's worth noting that Abe didn't design this, Mazda did! IE, the QC on it is already good :-) Not that Abe is a bad designer, but Mazda is *probably* better.

Stand up resistors should be fine. Lots of components in the toy ecu were (surprisingly I thought) just hanging up there in space. The only place they should be laying down is under the TA card. Things placed under there should all be low profile for obvious reasons.

Well, looks like I'm getting more on top of editing these files.



And, with another five or six minutes of work (HAHAHAHAhahahaha.. Wow) I got this, including some stand-ins for the OEM connectors:



Anyway, it uses a sub sheet. It doesn't yet have some of the drivers, but it's the basic idea.

Let's try to keep this between friends, ok?

The more I look it over, the more I like it. I don't see much from preventing us from putting this in the RPM input schematic. Should I add this there? I'm thinking it should be added here.

I could also put in a header that give you 5V, gnd, and digi in. Then it could be added as an add-on. What way is the better way to go. If no one comments, it will likely be included in these weekend release.

Do you know the exact opamp number for the original? Opamps have many finicky variations. I'd like to compare how close this one matches the reference design.

Sure, put it in, put it in parallel to the lm1815 and before the xor chip. Worst case is you jumper it out.

jharvey wrote:The more I look it over, the more I like it. I don't see much from preventing us from putting this in the RPM input schematic. Should I add this there? I'm thinking it should be added here.

Well, I'm in support, obviously - given how I keep asking. Also glad to know it received some honest consideration and isn't just being thrown in to shut me up. I believe the board space impact to be minimal.

I could also put in a header that give you 5V, gnd, and digi in. Then it could be added as an add-on. What way is the better way to go. If no one comments, it will likely be included in these weekend release.

Er, I'm not sure I need it, just bring the signals in on the board? I would assume this is a case where not populating it would be enough of a "switch"? Certainly for Vdd and GND.

In general, though, a header is nice for debugging. You can never have enough test points. (As an aside along the lines of what Fred said earlier: Watch their height. We had to bring in a NASA certified solderer once, took a week to line up, just to remove some test points which were too tall on a board we designed.)

Do you know the exact opamp number for the original? Opamps have many finicky variations. I'd like to compare how close this one matches the reference design.

After thinking of five different clever ways to tell you No, I settled on this one: Yes.

It's a 177G from Lucas, I believe. I've been using the TL082-C since I've seen people build this on the LM393 or some NTE equivalent, and it didn't reject the noise well in their application. Then again, without scope traces, it's likely they had a bad sensor.