DFH - Defacto FreeEMS Hardware in KICAD

Jared's unmaintained and never-used TA based "Defacto FreeEMS Hardware" design.
Post Reply
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 »

1. I plan on putting in some PCB pads for the snubber. Sounds like you prefer it across the switch rather then the inductor? It can go in either place, I went with the inductor so the current didn't have to run across the ECU board traces, as much. Hmmm, I'm not sure if I should put a pad across the switch, I think testing will prove this isn't needed there are better off where it is. What do folks think?

2. I've been wondering what's best for this part. Perhaps one of the aux FET's could be used to turn on a relay for this. You don't have to wire it to the PCB, but we also want to steer folks to a typical install. I'll have to think this out some. Should we have both? Should we support only one way? Should we include a relay or two on the PCB?

3. As shown in the spice modeling included in the hardware releases and posted about here http://www.diyefi.org/forum/viewtopic.p ... a&start=10 I think snubbers are simply old school. New tech has made injector control more accurate and faster, but to prevent ringing, you need a resistor. I chose the 70R because it prevents the ringing and "primes" the injector. The cap is probably not needed, but might be required to help prevent ringing. I had it in the spice model, but it's so small that the real world might take care of it with out the need to add it. (New tech allows for this to happen in a small package, removing much capacitance and ringing issues when done with discrete components.)

4. It can be removed, but I want it, so I'm keeping it ;) personally I think we want to keep the pads, and such, and the end product should come with a simplified schematic. Once the PCB is laid out, we'll see how likely it is that someone gets confused.

I expect this to branch off as time goes on, the current release doesn't lend it's self to nicely to a netlist, but will probably work well after this weekend. So if you plan to branch it, you can start playing with it now, but I wouldn't try a serious attempt for a little bit. The key problem I haven't fixed yet is that I need to copy the sub schematics from their current template files, to the real files. I made these template files so that when I made a change, I didn't have to change it 6 times. All the sheets on the top schematic should reference their own sheet, but right now, there is only one injector 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 »

jharvey wrote:Sounds like you prefer it across the switch rather then the inductor?
Going from FET out to 12v IS going across the injector. I'm not sure how a non zener would work connected any other way. Enlighten me :-)
2. I've been wondering what's best for this part. Perhaps one of the aux FET's could be used to turn on a relay for this.
The ignition key controls the coil ecu and injector power through one or more relays. The ECU only controls the fuel pump power through one relay. That fuel pump relay should be mounted remotely to decrease the voltage drop (pumps can draw up around 20A or so easily enough) and keep noise away. No coil and injector power feed control required.
Should we include a relay or two on the PCB?
No way!

Now is probably a good time to mention that some signals may need inversion. We need everything to be OFF when the bootloader is enabled such that nothing burns out. You could say "just pull the fuses when upgrading code" but experience with MS has taught us that people always forget and fry their stuff. We should take care of this up front. I'll have to document the bootloader state of each pin in the pinout document before we go too much further I guess. I'll try to get that done later today.
3. I chose the 70R because it prevents the ringing and "primes" the injector.
Am I wrong to be concerned about this priming current slowing the turn off time? I guess the fuel pressure will push them closed pretty quickly without sufficient electrical force so it's probably not an issue. I agree with damping the output slightly with both the cap and resistor. The are small values, but little things count some time. Again, they can be left out if people find they are problematic or not required.

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
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 »

MotoFab wrote: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.
Freescale wrote:There are four 8-bit pulse accumulators with four 8-bit holding registers associated with the four IC
buffered channels 3–0. A pulse accumulator counts the number of active edges at the input of its channel.
Jim, your entire post is incorrect. When the diagrams say P0 and P7 they mean from the timer port. Just take a look at 7-68 on page 354 to see that. All the chapters are written independently in a modular fashion hence the lack of an absolute name. I personally don't find it particularly difficult to decipher.

Port T 7 is only available as an extra function for 4, 5, 8, 10 cylinder vehicles, 6 and 12 will already be using it for something else. So far the only thing that we need PA functionality for is the 360 slot nissan/lt1 wheels. Even that isn't a certainty yet. Port T 0 is already assigned to RPM input and is just waiting for Sean's implementation to get used.

Back to the discussion...

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 »

Wow you folks are going crazy, I don't have enought time to read it all, with any real level of retention, so I'll wait until it settles down. Sound to me like we are still 6+6 and some extra's, but not the extras I want. That's fine, I'll draw it up the way I want, and if later on it branches into the main branch, and this version is a sub branch, that's find with me.

I put 8 LED's with 1K resistors across PK0-7. It's over kill I know, but what the heck, there wasn't anything there at the moment, and it lets you display a full byte if you wanted it for some unknown reason.
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 »

Fred wrote:
MotoFab wrote: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.
Freescale wrote:There are four 8-bit pulse accumulators with four 8-bit holding registers associated with the four IC
buffered channels 3–0. A pulse accumulator counts the number of active edges at the input of its channel.
Jim, your entire post is incorrect. When the diagrams say P0 and P7 they mean from the timer port.
I think I see. For example, P0 and P7 refer to the 'pin number' of the IOC port then?

Just take a look at 7-68 on page 354 to see that. All the chapters are written independently in a modular fashion hence the lack of an absolute name. I personally don't find it particularly difficult to decipher.
Ahh. Thanks, Fred. That's what got me, the lack of an "absolute name" as you say. Sort of like how MS does things. I think you commented on that before.

For instance, another variable naming example; According to fig. 7-71 on page 356, Port T is also known as Port 7.


Port T 7 is only available as an extra function for 4, 5, 8, 10 cylinder vehicles, 6 and 12 will already be using it for something else. So far the only thing that we need PA functionality for is the 360 slot nissan/lt1 wheels. Even that isn't a certainty yet. Port T 0 is already assigned to RPM input and is just waiting for Sean's implementation to get used.
Re: Port T 7.
I was looking at 7-69 on page 355, and 7-70 on page 356. Maybe I'm not understanding it. It seems that to cascade the accumulators into a 16-bit registers, one of the external pins changes from pin number 1 of port T (Port T 1), to pin number 7 of port T (Port T 7).

If that is correct, Are you using the any of the PA registers for either of the two RPM inputs? Or, are the RPM inputs used as a pure Interrupt On Change?

A question regarding RPM inputs; Are there 3 of them? On the Rev A.07 schematic I see RPM_IN_0, RPM_IN_1, and RPM_IN_2. Having 3 inputs may be a good thing.

- Jim
Costa
Banned!
Posts: 92
Joined: Sat Mar 08, 2008 3:57 am
Location: Sydney, NSW, AU

Re: freeEMS_1.0 rev A KICAD

Post by Costa »

Fred wrote: Now is probably a good time to mention that some signals may need inversion. We need everything to be OFF when the bootloader is enabled such that nothing burns out. You could say "just pull the fuses when upgrading code" but experience with MS has taught us that people always forget and fry their stuff. We should take care of this up front.
I agree.
This means we won't have the option of inverting or non-inverting spark output, which is a good thing :)
We don't want problems like this http://www.microsquirt.com/viewtopic.php?f=89&t=22953 :cry:
previously: ca7
User avatar
AbeFM
Post Whore!
Posts: 629
Joined: Sat Feb 16, 2008 12:11 am
Location: Sunny San Diego
Contact:

Re: freeEMS_1.0 rev A KICAD

Post by AbeFM »

Ok, have some real catching up to do in this thread, even for a long read, it's likely worth it. I haven't looked at this "priming" thing yet, but I have the sense right now I'm against it. Insofar as it's repeatable, then... You don't care what opening time is. It's easy enough to figure it out, by switching injections per cycle and seeing if the AFR's move. COuld be done in software. :-)

But overall, I'm in huge support, and think I will be in on any group buy, ifnothing else than to give myself an incentive to get back up to speed on this. :-)
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 »

ca7 wrote:This means we won't have the option of inverting or non-inverting spark output, which is a good thing :)
Thank you very very much! I hadn't put much thought into this, and I certainly hadn't realised the implication of what I was saying either.
We don't want problems like this http://www.microsquirt.com/viewtopic.php?f=89&t=22953 :cry:
Wow, no, no we don't!

Thread to discuss this aspect of the system :

http://www.diyefi.org/forum/viewtopic.php?f=41&t=365
8InchesFlacid wrote:But overall, I'm in huge support, and think I will be in on any group buy, if nothing else than to give myself an incentive to get back up to speed on this. :-)
Welcome back! Good to know you still care :-)

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
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 »

With regards the diode protection on the output, the PIP datasheet specifically states this : "Overvoltage clamping for turn off of inductive loads"

The VNP device sheet says "OVERVOLTAGE CLAMP PROTECTION: internally set at 70V, along with the rugged avalanche characteristics of the Power MOSFET stage give this device unrivalled ruggedness and energy handling capability. This feature is mainly important when driving inductive loads"

Do we actually need the output diodes or not? It seems not. I guess if the pads are there they can be left unpopulated if not required by a particular user.

Toyota use an internally clamped device too. It's at 60V too. Also, toyota do not have any resistor or capacitor external to the driver. I think perhaps we are over-complicating it? Again, the pads won't take up much space, so I guess we should have them anyway, but it seems like they aren't required either.

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
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 »

Based on what I found inside the Toyota ECU (I trust Toyota) I'd like to see the values of the VR input circuit changed and an extra resistor added. I'd like to see 6.8k to ground for each VR input and 5.1k serial resistance (instead of 18k) with a larger 0.045uF capacitor on the inside. I guess so long as you add the extra resistor location I can put in different values quite happily.

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