DFH - Defacto FreeEMS Hardware in KICAD

[jharvey]

It appears that Fred's copy in git hub is set at A.09, while the SF zip file is A.20, so that copy is very out of date. Fred had put that into git back when I was too ignorant to know how to use git. I'm now at least partly de-igorantized, and liking git. I just checked it into git, and it can be found at this link.

http://github.com/jharvey/FreeEMS_1.0_hardware

It contains a bunch of garbage that I don't think I included in the SF download. For example, the .bak files are probably un-important to anyone but me, ect. I also just ran the ERC, and it produced three mild complaints about power pins being set to input when they were actually outputs, ect. Nothing that severe.

[nitrousnrg]

Oh crap, I'll wait for the latest version then.
I'm interested in your hardware, it's a shame you are all alone in the hardware design. Lets see what can I do :-)

[jharvey]

Certainly wouldn't mind a helping hand. Feel free to critique, ect.

[Fred]

Jared, quickly, before others grab it, .gitignore the .bak files and any other temporary files that you don't need to generate the board design, except the board output files themselves. When you've done that, use git commit --amend to add those changes which will remove them from ever having been there. Then git push --force to put it all back up. I ran through this with Marcos, so he can probably help you get it done right if you need help. Mean while, I'll blow away my hardware git repo so there is no confusion.

Fred.

[Fred]

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 used to think the base design should have P&H and ignitors on it. Now I think the opposite. I think that we should have only high Z injector drivers (simple auto fets with nothing around them at all) and some sort of current buffer to drive external ignitors. 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. I think it's pretty close to good at the moment, but I'm not spending time on hardware till there is some use for it. It's too much of a time sink for me if I do.

You pretty much do not see OEMs with P&H drivers inside the case, hell, you don't see them with low Z without resistor packs, mostly. Nor do you see ignitors inside the ECU... reasons for these things are excess electrical noise that can easily be pushed out to a better location along with the heat and other issues.

Fred.

[jharvey]

Jared, quickly, before others grab it, .gitignore the .bak files and any other temporary files that you don't need to generate the board design, except the board output files themselves.

Those files have value to me as well I see value in having them on an offsite second location. Perhaps the better approach is for you to fork this or merge it with the copy you have / had.

[nitrousnrg]

Fred wrote:
Jared, quickly, before others grab it, .gitignore the .bak files and any other temporary files that you don't need to generate the board design, except the board output files themselves.

Those files have value to me as well I see value in having them on an offsite second location. Perhaps the better approach is for you to fork this or merge it with the copy you have / had.

I understand, but keep in mind that every commit is like a backup. You can restore your project as it was one commit before.

Jared, I have your project in my hands. It looks *much* nicer. Give me some time to look it.

[jharvey]

I'm not sure what PCB layout skills you have, or how much of the above thread has stuck in for you, ect. There are some items that might be of interest.
* I have populated the schematic components with both MFG and Vendor info, such that the schematic drives the BOM.
* I have a TODO file, that includes reminders about some odds and ends that I wanted to do. I can elaborate on those if required, and if I can figure out my comments.
* The SPICE folder holds files for the QUCS sims I was doing.
* Also the scripts I have in there for making PDF's and such don't appear to be all that handy on a windows platform. If on a windows platform, simply print to PDF seems to work for most of it, then just combine the two with pdfmerge.
* 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.
* If you want to roll your own, this set of files should lend itself nicely to such activities. You can add or remove sub circuits on the top level drawing, and make it your own variation fairly easily.

Any how, I think those items might be of interest. Feel free to be critical with it. I won't cry, also I won't make changes unless a good case has been put forth. Basically, I won't react much to emotion, but will react to logic/laws of physics, ect.

[nitrousnrg]

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.
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. In real hardware, all I can do are some tests with the oscilloscope, and the signal generators at the university. We usually have problems getting rare components, but simple passive circuits -quite popular in your design- are easy to implement. I recall to have tested an lm1815 a few years ago, VR, MAP, thermistors and narrowband lambda too.

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 :-)

[Fred]

Jared, please listen to what Marcos said. Keep your .bak for local stuff. Commit every time you would do a .bak and then you have the same thing, but not split over two different files. If you're double paranoid, do offsite backups in some other fashion. They do not belong in a git repository. Trust me here, please, to quote Austin Powers, "this is my bag baby" :-)

Marcos, tell us about the odd things you find and why you find them odd. No harm in rediscussing any weirdness.

Fred.