DFH - Defacto FreeEMS Hardware in KICAD

[jharvey]

Ok, good to know that. I'm in the last year of electronic engineering (the 5th year), so I know a bit about schematics and pcb layout, but don't count on my experience, I barely have 22 years old, and a lot to learn.

Great. A little back ground from my end, I have a BS in Electro-Mechanical Engineering. I have some experience at the day job doing PCB layout and design. Much of my experience has been in extracurricular activities like this. Also I live in New England of the USA.

I'm running Linux, kicad version is 20090216-final, we won't have any problem with that. And, I don't like to read schematics in PDFs, so I won't touch your scripts.

The PDF's were primarily for those that are either new to the setup and want a quick look, or for those that don't know how to navigate KICAD. Sounds like you can run it vai KICAD, which is golden.

I'm still looking at your design, not touching anything yet. I see some strange things, but then I read some posts that clarifies them

I'm guessing you reference the funky hall current sensor thing, or perhaps the several jumper-able options. Some of the options are perhaps a bit hidden, or not exactly intuitive.

[nitrousnrg]

Sounds like you can run it via KICAD, which is golden.

Yep, I've been using kicad for a while. A year at least.

I'm guessing you reference the funky hall current sensor thing, or perhaps the several jumper-able options. Some of the options are perhaps a bit hidden, or not exactly intuitive.

Yep, the LM1815 options (I think adaptive mode is the only one you need), current sensing, and the 4 bulky 2200uF caps seems like too much. Is there a reason to implement the buffers with ANDs?

Also, I'll probably go smd.

[jharvey]

I drew this up SMD and thru hole. The modules contain both pads, and via's.

2200uF may be bulky, basically it should be as large as reasonably possible, but also hasn't been built yet, so perhaps it's to large. I copied that for a schematic some where, and physical size hasn't come into question yet.

The AND's were something Fred pointed out, I seem to recall it had to do with start conditions.

[nitrousnrg]

I drew this up SMD and thru hole. The modules contain both pads, and via's.

I saw it has both smd and thru, but it turned out quite difficult to look at. LOL I cant follow a fuc*ing track! I prefer to stick with one, if it turns out that I want to go thru, I can fork, and replace the modules in the netlist.

2200uF may be bulky, basically it should be as large as reasonably possible, but also hasn't been built yet, so perhaps it's to large.

Yes, one or two big capacitors well located should be enough.

The AND's were something Fred pointed out, I seem to recall it had to do with start conditions.

The ANDs are something that I must understand first. That surely can be polished.

The second power regulator is something I'd get rid off if it were my design, just to KISS. I wonder which is the real advantage of shutting down everything except the micro (maybe avoid a regulator failure?). If it is a noise problem that could come from the digital part, then there are simpler workarounds to avoid such noise. I also don't think you need 2 of them because of power requirements.

EXCELENT work populating the BOM! I'm doing that from now on :-)

[jharvey]

I would agree, the bulk caps can likley be shrunk down, I seem to recall I put in a foot print, and figured imperical data would determine the largesy caps that would fit. Something like that, it's been a while and I may have forgoten the details slightly.

I seem to recall that one reg was for sensors, and the other was for power/noisy devices. I'll have to refresh to remember the details there.

BOM population this way takes a bunch of time, and is kind of a pain to modify, I think the CMP thing can help stream line that. It uses the netlist to associate certain properties with the schematic symbol. I still have some to learn about that. Time will iron some of that out.

[AbeFM]

I must agree on that. Ignition timing becomes critical at high RPMs, while I think fuel timing isn't as important. It is important how long you are injecting, but not so important *when* you start the injection -and the time scales are totally different-.
I'd use the hardware timers on ignition. usec errors at 12000rpm are quite noticeable in terms of ignition timng. If you want to achieve an error less than 0.1° on the ignition at 12000rpm, you can't have more than 1.3 usecs of error in the timing.

And, IMHO, I'd like to see P&H from the start. Here -Argentina- there are many all-motor, or turbo car that has low impedance injectors. I wouldn't like to have to use other EMS than FreeEMS only because of this.

I was going to argue, but you're right, the time you start injectors doesn't matter one bit. I want good control over the duty cycle, the net fuel delivered, but the start time can float around a few degrees, especially when the close time is shorter than the open time.

Without P&H you're shooting yourself in the foot. And me in the inspiration.

Any board with P&H inside would have to have enormous heat sinking capability, and noise issues designed very very carefully. IE, we're asking for trouble to include what is essentially an optional feature as a default feature by not keeping to KISS. Keep in mind, this will just be a first/base/basic/reference board design, or something to that effect. Any number of variants will spring up later. Goal for this should be simple, reliable, stable, complete. Pins should be correct, power/grounding should be done RIGHT, and be exemplary, and input conditioning should be excellent, including VR, hall, ADC, digital.

<respectfully>You putz!</respectfully>
OMG you are so wrong. You might as well leave ignition off because there is lots of diesel. This is a high performance ecu, and folks serious about performance quite often use P&H. I think we were making good progress in P&H designs.

A driver board, fine, but then don't bother using big fets at all. Either put out a pure digital low power signal (like with spark - the ECU is the brains and you deal with how to make it do something useful), or support P&H. I think there's always been a strong case for a stacking connector, and a card whose sole job is to run big power things like spark and (P&H) injectors... and you just do your isolation there. The power loads will be reasonable.

* I seem to recall someone opened the files on a windows based machine, and had some mild trouble. The copy of KICAD I was using at that time, was slightly outdated. I've opened these files with the windows current version of KICAD, and it seems to work just fine. Any how, beware there may be some kind of bug across different platforms. I seem to recall that we resolved that issue when I upgraded my KICAD to a newer version, so I believe that issue has gone away.

KiCAD is pretty sensitive to versions - I've had the same thing with my own designs - I thought it was the platform, but upgrading everything to current magically fixed everything.


--------------
I'm thinking the and gates are just that - keep from firing plugs and injectors, etc, till you are really controlling them. NEEDed? Probably not. Nice? Sure. It might actually mask issues in development. Not hard to work around if you wanted to "disable" it, I guess I'd leave it.

There was a lot of talk about separate power supplies. Likely overkill, but it'll be nice to not have to worry. Certainly if that's what it takes to have some "power" apps in the case - like running real injectors or even old skool ignition, I'd support it.

[nitrousnrg]

Hi Abe,
Well, I'm a big fan of integration, so if I were designing it, it would come with P&H, at least in a basic, not-so-polished form. After all, if I make the board, I'm the only one who will use the first version. It must be a problem with me, but no matter how many hours of thought I put in the first prototype, the second one is which works without a flaw. When I say integration, i'm meaning that i kinda dislike to have many boards to do one thing. The microcontroller kit-FreeEMS board are a must in a so young prototype, but once it is stable and well designed, FreeEMS should come in only one board. I don't think a real user would upgrade his processor.
Mmm, this is going too much in the future...

Kicad worked fantastic for me. My only issue was the 3D display. Didn't work for a year -driver issues probably-. In fact, a long time ago, when I saw your board designed in kicad, I was pretty amazed.

With respect to the power supplies, I understand your ideas. The only thing that bothers me is that I never saw a dual power supply, nor my dad. As I said, I don't have much experience, but daddy is working for the Argentina army since the 70's, and military stuff do overkill everything. Maybe we were overlooking the power supplies all this time, I'll pay more attention.

[jharvey]

I have mixed feelings about integration. I've seen many good designs with a backplane, and many good designs with a single board design. I see pro's and cons of both approaches. For example, if you ESD the MCU, you can replace it, while keeping the rest on a modular design. However, snapping together a pile of parts increases complications. I drew up FreeEMS 1.0 using a layered design. The theory was that we get the basics working on a board, then we can add more complicated features or connector cards to make it work for other applications, and allow for room for growth.

I've seen redundant power supplies on industrial equipment before. I think a common reason why military applications don't need them is that they often don't need the power supply. The build the things that robust.

About P&H, for now I say use jbperf's board for now, and lets focus on the basics. Once it's working, we can make a better board, or an add-on that will include this feature. The idea of the board I titled 1.0, is that it's the bare min to get it started. Look how long it's taking for basic injection and ignition. Lets not complicate it by adding more features.

http://www.jbperf.com/

[jharvey]

I don't have supports.mod and diyefi.mod. Where can I get those?

Good question, I just searched my FreeEMS folder and didn't see them. So my first thought is that they are in the KICAD working directory, not the project directory. However, my windows KICAD doesn't have access to that folder. I think it asked me for these files once, but now it's not asking me for them. Do you still need these? Perhaps they aren't needed and KICAD has cleaned itself up such that it doesn't ask for them again after you specify to continue.

[nitrousnrg]

Good question, I just searched my FreeEMS folder and didn't see them. So my first thought is that they are in the KICAD working directory, not the project directory. However, my windows KICAD doesn't have access to that folder. I think it asked me for these files once, but now it's not asking me for them. Do you still need these? Perhaps they aren't needed and KICAD has cleaned itself up such that it doesn't ask for them again after you specify to continue.

Cool, I solved it. In PCBnew, Preferences->Library I had this footprints library files: support, diy, and Free_EMS (but the last one relative to your PC path). So I removed support, diy and your Free_EMS, and added the Free_EMS.mod located in *my* PCB-modules/. Not sure if that wrong config belongs to my machine or yours. Anyway, it can be worked out.

About P&H, for now I say use jbperf's board for now, and lets focus on the basics. Once it's working, we can make a better board, or an add-on that will include this feature. The idea of the board I titled 1.0, is that it's the bare min to get it started. Look how long it's taking for basic injection and ignition. Lets not complicate it by adding more features.

I get the point. Just ensure that you have some way to use jbperf's P&H, otherwise... people here wouldn't buy it :-)
Should we add a jumper to get access to the ind_pd_* signals?

The integration thing, lets leave it for later. It doesn't makes any sense to plan this now :-)

Thanks for the jbperf link!