DFH - Defacto FreeEMS Hardware in KICAD

Jared's unmaintained and never-used TA based "Defacto FreeEMS Hardware" design.
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: freeEMS_1.0 rev A KICAD

Post by Fred »

I've officialised it :-)

All schematic releases : https://sourceforge.net/project/showfil ... _id=286538

The latest 0.7 release : https://sourceforge.net/project/showfil ... _id=617663

Beware of zips without base directory inside! Zips now contain the pdf and the rest of the parts.

Nice to see that I didn't have to add the TAPR stuff :-) Good work!

A few little things :
1) Pretty please zip a directory up such that if some poor soul unzips it in his home directory he doesn't end up with 5000 files spread around that he can't delete with * because 50 of them are his files from before the unzipping incident. (I took the precaution and didn't get screwed, but sometimes we forget and zips filled with 508943 files and no base dir are nasty)
2) (just lazy here) Zip the PDF up in there too so I don't have to when I put it up as a release. (you could still post it up separately as well for casual observer types)
3) Do you have a sourceforge account yet? If so, do you want access to publish them yourself? I don't mind doing it if you just wanna keep posting them to the forum, that is totally fine.

Sweet,

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
jharvey
1N4001 - Signed up
Posts: 1607
Joined: Tue Jun 10, 2008 5:17 pm

Re: freeEMS_1.0 rev A KICAD

Post by jharvey »

Fred wrote:You have the inj FET hooked up to blow a fuse again :-)
Oh yeah, I forgot to mention that in the list of new features. It's the sucide feature. Makes it more fun when you get sparks and smoke.... One of these days I need to find enough time to actually look at this before I send it out. Thanks for catching that.
Fred wrote:The digi protect circuit :

For output duty we will want a lower resistor value in the order of 1k (I forget the exact value that I calculated was correct). For what reason do we need a zener on a hard wired output pin? It's isolated by the FET device already and current protected by the resistor.
I've changed the 10k to 1k.

I'd agree that with the protected fets, we don't need the zener, but if someone is using a non protected fet, a couple holes or pads might come in handy.

Something else I'd like to do, is to make a prediction about the impedance of the protection circuits. Impedance matching gets the most power through, and less noise. I'd like to predict it and perhaps offer adjustment if your analog system has a different impedance.
Fred wrote:For input duty a resistor needs to be outside the zener, and same applies value wise to the inner one. I'm still not certain that a zener is a good idea. I think the dual standard diode setup will be a better choice for a few reasons, but can anyone tell me that I'm wrong here because I'm mostly just guessing.
Perhaps we should have two resistors, one inside and one outside? This circuit shouldn't do anything under normal conditions, it's there for when something goes wrong. Then I'm not sure if it's an input, or an output.
Fred wrote:Most of the pin rearrangement is good, but you banged inj feedback 5/6 on pj6/pj7 which are A two interrupt pins and B our I2C channel. Best to move them to PE3 PE4 which you have labeled as ECLK and LSTRB on the schem. I'd strongly prefer that the PORTE pins were labeled as such, their original special use meaning is irrelevant to us. They are just more pins and they are port E pins, so let's call them that from the start. (In MS land stuff often exists by two names and it causes no end of headaches)
I'll have to also look into the footprint and make sure they match there as well. I agree with labling them as just PE. I'm thinking of noting the specail pins with some kind of indicator. Perhaps an _ or a + for each specail extra on that pin.
Fred wrote:I've mentioned some other stuff before, so I'll forget about that for now.
At this point I've probably forgotten, disagreed, or missed it when I read it. I don't think there have been many disagreements. I think that has been mostly about the PCB layout, and PCB layout is only starting to grow, so I'm sure we'll come to resolutions there in time.
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: freeEMS_1.0 rev A KICAD

Post by Fred »

jharvey wrote:I'd agree that with the protected fets, we don't need the zener, but if someone is using a non protected fet, a couple holes or pads might come in handy.
Sure, I agree, make it versatile, but what I am questioning isn't protection at all so much as "how". IE, why zener? The draw current well before the protection rated voltage and quite a bit, this could make it hard work for the CPU, and/or impossible for the CPU to rail the output post zener. If we go with twin diode protection just like the ADC inputs then we don't have those problems and they will handle more load before giving trouble too thanks to only dropping 0.7V rather than 5.1. Plus, cheaper and more common too. If I'm wrong on this, someone should pipe up and say so, ditto, if I'm right, please confirm.
Something else I'd like to do, is to make a prediction about the impedance of the protection circuits. Impedance matching gets the most power through, and less noise. I'd like to predict it and perhaps offer adjustment if your analog system has a different impedance.
If I understand you correctly wouldn't you do this by component value selection? If not, then what exactly do you mean?
Perhaps we should have two resistors, one inside and one outside? This circuit shouldn't do anything under normal conditions, it's there for when something goes wrong.
Indeed, there should be a 1k or so resistor from CPU to world (CPU pins should always be isolated from ALL other components through this with a possible exception of serial comms chips etc) however your protection diodes and zeners need a resistor to offer useful protection. The outer one should be chosen to current limit for the diodes etc and/or for noise filtering capabilities.
I agree with labling them as just PE. I'm thinking of noting the specail pins with some kind of indicator. Perhaps an _ or a + for each specail extra on that pin.
You can if you like, but they really aren't special in software at all and aren't labeled specially in software either. I think the naming in docs, schems, pcbs, code, tuning tools should all match and be consistent. It cost me a little time this morning sussing out what was what on there because of that.
At this point I've probably forgotten, disagreed, or missed it when I read it. I don't think there have been many disagreements. I think that has been mostly about the PCB layout, and PCB layout is only starting to grow, so I'm sure we'll come to resolutions there in time.
I hope we do too :-) I think it's important that we keep in mind that it's not for me, and it's not for you and try to make it generally applicable and robust/simple for everyone else. Our special flights of fancy can be met with an add on board if we so desire. Hence I suggested IGBT locations even though I won't use them and don't like them inside the case. Ditto, I think maybe it is a good idea to put the PWM P&H output chips on there with some appropriate spike catching circuitry IF we can reasonably fit them too. I won't use them and would rather put them outside the case and far away, but some might be put off if they have to do that. On the other hand, Jeans P&H boards are cheap as chips and work well, so perhaps it's best to not worry about that and recommend that approach for users that want it? Either way, everything on the board either needs to be optional/disconnectable or general purpose enough for almost anyone. EG we all need a power supply ;-)

BTW, if you are having any space issues, or just to be tidy, you can use this :
http://www.diyefi.org/forum/ucp.php?i=a ... ttachments

To clear out old attachments from the board storage. Perhaps each time you post a fresh one remove the last? Or at the rate you are doing them, clear out once a week so the server doesn't go down ;-) It's good to have the latest one attached at all times for sure as well as in the project release repository.

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
MotoFab
1N4001 - Signed up
Posts: 307
Joined: Thu May 29, 2008 1:23 am
Location: Long Beach CA

Re: freeEMS_1.0 rev A KICAD

Post by MotoFab »

For future development, it's a good idea to leave at least one of the Pulse Accumulator (PA) pins open. They are pp0 and pp7. The two PA inputs share pins with the two SPI peripheral ports.

I don't think both PAs are needed. But the two PAs each have different available 'signal conditioning' functions.

The datasheet is somewhat indecipherable as to what each bit of each of the dozen or so PA control registers does, exactly. And the PA control functions are related to a dozen more control registers for Timers, Prescalers, Interrupts, etc.

Also, the two SPI ports may have different functions. I haven't looked, but it's conceivable that one or the other SPI ports may be configurable to send multiple bytes, unattended.

- Jim
Attachments
freeEMS_pulse_accum_01.jpg
freeEMS_pulse_accum_02.jpg
freeEMS_pulse_accum_pinouts_144.jpg
User avatar
jharvey
1N4001 - Signed up
Posts: 1607
Joined: Tue Jun 10, 2008 5:17 pm

Re: freeEMS_1.0 rev A KICAD

Post by jharvey »

About the digi protect, I think I might lean to the zener because it uses less traces. Perhaps instead of 5.1v, it could be bumped up to 6v or 7v. The digital inputs can handle that for sure, especially if it's a small spike in voltage.
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: freeEMS_1.0 rev A KICAD

Post by Fred »

jharvey wrote:About the digi protect, I think I might lean to the zener because it uses less traces. Perhaps instead of 5.1v, it could be bumped up to 6v or 7v. The digital inputs can handle that for sure, especially if it's a small spike in voltage.
Absolute maximum ratings are -0.3V and 6.0V. Sure, 5.6 or 6 if such a value exists. Perhaps 5.6 will be OK. It entirely depends on the output impedance of the drive circuit though. The CPU doesn't have much balls, so in output mode it will have to be easy to drive. In input mode though, if the signal is buffered then most stuff will be able to saturate the input just fine.

Once again though, I guess if you put them in then it's easy to leave the components out if not desired/required.

Just checked, 6.2 is the next step up so no good for us. 5.6 it is if you use them.

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
jharvey
1N4001 - Signed up
Posts: 1607
Joined: Tue Jun 10, 2008 5:17 pm

Re: freeEMS_1.0 rev A KICAD

Post by jharvey »

Some things to remember about the 6.2V, there is a resistor between the zener and the pin, so likely a voltage drop. Perhaps 6v or less by the time it gets to the pin. Also the zener starts conducting before 6.2, making it a bit harder to hit the 6.2. All of this should shouldn't happen anyhow.

Probably best to try both out, take some measurements and make a final determination. The higher it can be pushed, the better the signal. However, to high and you pop a port. The big thing is that it's the same footprint, so same schematic.
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: freeEMS_1.0 rev A KICAD

Post by Fred »

The resistance is irrelevant in input mode with pull ups and pull downs disabled. Voltage is voltage in that respect. On the negative side it won't be protecting well enough anyway, but one must hope that the absolute maximum ratings are at least slightly conservative. Of course one shouldn't base their design around that assumption.

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
gearhead
LQFP112 - Up with the play
Posts: 120
Joined: Sun Feb 03, 2008 9:30 pm
Location: Chicago, USA

Re: freeEMS_1.0 rev A KICAD

Post by gearhead »

Sorry to come in here at the last minute on this...

This looks like some great work. My first comments are on the injector drive circuit. Fred has mentioned it and I'll do the same.

1) I do not think the snubber diode should be optional. also, it needs to be placed between the drive from the FET and 12V.
2) The 12V supply for the injectors will not be in the box and will be switched by a relay outside the box.
3) the 70R and 10pf - are these needed? What do they help with? (I plead ignorance here)
4) I'd like to see the current sense portion removed. It is a lot of components for a diagnostic tool, IMO. I refer to it as a diagnostic tool as I feel it will only be used to determine the dead time of the injector. Do I have this right? Also, it leaves 2 possibility that someone leaving this portion out (me for example) could end up with NC between the drive transistor and the output pin from the box (L and R).

Your low power drive on the next page has no 100k from gate to ground.

The temp sensor... Can you go over again why we need a mosfet on this circuit? I am a fan of keeping it passive.

Gearhead
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: freeEMS_1.0 rev A KICAD

Post by Fred »

gearhead wrote:3) the 70R and 10pf - are these needed? What do they help with? (I plead ignorance here)
Damping the resonance of the coil in the injector. It's probably a very good idea, though not critical. I think those should stay.
4) I'd like to see the current sense portion removed. It is a lot of components for a diagnostic tool, IMO. I refer to it as a diagnostic tool as I feel it will only be used to determine the dead time of the injector. Do I have this right? Also, it leaves 2 possibility that someone leaving this portion out (me for example) could end up with NC between the drive transistor and the output pin from the box (L and R).
Me too TBH, but he's the man designing the board. I guess when the BB gets a bit closer we could have a poll with some different options to see which one the most people would be happy to buy.
The temp sensor... Can you go over again why we need a mosfet on this circuit? I am a fan of keeping it passive.
Me too again. As I said above again though. It would be nice if this first iteration was a for most people good enough variant and the specialty projects came later once the foundation was stronger. Once again though, he's the man holding the KiCAD skills :-)

Good spotting for the ones I didn't mention.

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
Post Reply