DFH - Defacto FreeEMS Hardware in KICAD

Jared's unmaintained and never-used TA based "Defacto FreeEMS Hardware" design.
User avatar
jharvey
1N4001 - Signed up
Posts: 1607
Joined: Tue Jun 10, 2008 5:17 pm

Re: DFH - Defacto FreeEMS Hardware in KICAD

Post by jharvey »

This is mostly for DeuceEFI. As a reminder/intro check out the wiki page http://wiki.freeems.org/doku.php?id=freeems_dfh It's the boiled down version of this and a couple other threads. Also feel free to ask questions.

Now I'll start trashing my baby for every ones enjoyment :) Per discoveries in PUMA, there are many circuits here that should/could be updated. These include the RPM input circuit, MAP's, injector grounds, the "current sense" feature on the injectors should be replaced with a purchased chip ACS714, the injector LED should have a schottky to prevent reverse conductivity, ignition circuit should better match Ravage, and the fuse thing should go away.

I don't plan to update this any time soon, as I'm quite busy. However I can offer help if there is a branch, or what ever, of this board. Basically I can help in 10 to 15 minute windows of time. Here's a little more each of the above notes.

RPM, The op-amp circuit is probably OK, but the LM chip isn't good. It should be a MAX9926, same as schematic found here https://github.com/jharvey/Cinch_enclos ... mplate.pdf See page 4.

MAP's, These should also be modeled after PUMA, as they allow a BOSH sensor and MPX sensor(s). See page 44 of 56 here http://puma.freeems.org/docs/Puma_spin1_schematic.pdf

Injectors, The BOM calls for an older hard to obtain chip. That chip can be updated to the VNB10N07 or equiv. There are versions of that chip that can do some 20 or 30 amps. I'd recommend the larger ones as they will have less resistant heating, however the 10 amp chip should be fairly cool as well. I had an experimental current sense circuit in there, however that can be purchased these days with this ACS714, so it should be updated. Also it's grounding isn't ideal, so we should address that. I'd like to see them isolated via optocoupler, however if it's only highZ and 6 cyls, you can probably get by with one fat wire. So it's likely easier to just limit the design scope to highZ only. If one want's lowZ, they can use JBperf's external box.

Ignition, Follow Ravage instead of what I did here. Look at page 7 found here https://github.com/dvisser/Ravage/blob/ ... Ravage.pdf

Fuse thing, The intent was that if you shorted something, and if the traces were designed to handle the same current, the failed trace would happen who knows where. So I put in these mock up fuses, such that if you did bugger it, the trace between the fuse pads would be the thinnest and would be the location of a failure. Then you could replace it with a real fuse instead of having to do some kind of misc jumper. In reality, the device should be fused up stream, and this could lead to bad practice, as the fusing should happen closer to the bat. Also fuse theory is more complicated than that, and if this thinner trace were to burn, you would likely have to rework some chips any how. So it probably should go, but eh, it's there so I guess it can stay.

Power supply, Oh yeah, I feel there is a power issue with this linear design, but Fred feels linear(s) are fine. As long as the current is low, the vregs should be fine, but I believe the current is more than what Fred has measured on a couple builds. I believe he simply hasn't seen the right combo of components to see the max current draws. So I might recommend the switching supply from PUMA, it bumps from Vbat down to 6V, then the linear takes it from there, such that they don't make more heat than required.

Oh yeah, also the digi protects and AN protects are buggered, but footprint wise should be OK. The 10k's on the digi protects are to high, they can be dropped down around 1k to 1.6k total resistance. Once that happens the filter caps can be adjusted. Not a huge deal, the footprints on the PCB are the same, but the values that go there should change.

An how, that a quick rough up of my baby.

A feature note done there, but might be nice, would be to add the USB chip from Ravage as well. I think when the RPM shrinks, you'll have room for that under the TA card. So if it can fit, it might be nice to add it.
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: DFH - Defacto FreeEMS Hardware in KICAD

Post by Fred »

I agree with most of that. DFH was a too many back seat drivers project with Jared trying to find a path that suited everyone. Puma was next and changed a few things but was mostly a miniaturising exercise over DFH. Ravage is the third in the short line of hardware attempts and I feel that its schems are getting close to ideal. During each of these, RavAGE included, we've all learned a lot and a lot of discussion and hashing out of details has gone on. Hopefully a lot of stuff from RavAGE will end up back in DFH and Puma before the end and no work will go to waste. In fact, even if neither DFH or Puma are ever used (more than my lonely Puma) a lot of good learning has occurred and we're much better off as a result. I could sum it up by saying the devil is in the details. :-)

The 5v currents required really aren't significant. We can plot it out in a spreadsheet if there is any concern, but at 15v dropping 10 a free standing to220 could probably stay under max temp and supply everything just fine. That is speculation, however!

Thanks for the detailed reply, Jared! :-)

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
DeuceEFI
LQFP144 - On Top Of The Game
Posts: 578
Joined: Thu Feb 25, 2010 3:57 am
Location: Gosport, IN USA
Contact:

Re: DFH - Defacto FreeEMS Hardware in KICAD

Post by DeuceEFI »

Jared, Thanks for for overview, I have pulled down your KiCAD drawings and will mark them up with your suggestions.

What is the standing on a stepper motor driver? My 3.1L from the factory has one for Idle Air Control, or should I change it out for a Fast Idle Valve and get rid of the stepper? I read all of the Cheetah posts as of this afternoon and I noticed AbeFM wasn't in favor of including it on your Cheetah design... Just curious... :-)

Andy
User avatar
jharvey
1N4001 - Signed up
Posts: 1607
Joined: Tue Jun 10, 2008 5:17 pm

Re: DFH - Defacto FreeEMS Hardware in KICAD

Post by jharvey »

I don't think PUMA's stepper has been tested. Do you think that PUMA's might work? If not I have another one in KICAD, again untested, but could work as another reference design. As the board layout is drafted now, it won't fit and maintain the thru hole/smt design practice. That might be best on a connector card, or another layer of the stack. The goal of this first board was for the bare min to run a vehicle, the next layer in the stack was going to include things like knock/ion sense, and other common/misc items. The connector card was going to be the interface to some specific application. Such that the stack was standard, then the connector card was the custom interface to what ever harness you might have.

I don't know what might be required of the software to get a stepper included.
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: DFH - Defacto FreeEMS Hardware in KICAD

Post by Fred »

Andy, we need to support it at some stage, so if you want to build prototype hardware for it, and keep the cpu side connections VERY flexible, I'm happy to work with you to create usable code for it. I've done some research on them, but I'm still not 100% sure of what they require resource wise. That's the deal :-)

The reason I'm not for having one on the Cheetah and Dan isn't in favour of having one on RavAGE is simply that they are less common for the type of engines that we target, typically not GM or US-Ford stuff :-)

FreeEMS will have stepper support, and you're welcome to be the first to try it.

You can get your engine to idle perfectly without it, though. Just give it enough air to hold up any non clutch loads it has to deal with (alternator/electrical and air con and power steer) and then dial in the idle by reducing the timing such that if rpm falls you can add timing to recover from that. Again, code yet to be written, but simple control strategies and perfectly possible.

In summary, leave it on the engine, you can bleed air in to get the thing running pre stepper dev.

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
DeuceEFI
LQFP144 - On Top Of The Game
Posts: 578
Joined: Thu Feb 25, 2010 3:57 am
Location: Gosport, IN USA
Contact:

Re: DFH - Defacto FreeEMS Hardware in KICAD

Post by DeuceEFI »

Cool, I don't mind being the guinea pig for the stepper code, I have extra engines all about the same vintage, all US GM 60* V6 blocks that use the same stepper motor. You might say I have a small collection, my wife certainly does... lol :-)

I will take a look at the Puma and DFH designs and see if we can't come up with a hardware design to test with.

I can also help with how the stepper works and supply feedback once we get to that point :-)
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: DFH - Defacto FreeEMS Hardware in KICAD

Post by Fred »

You could do that with an engine running on OEM control! Just hand control of the stepper position to the controller and wind a pot to get more or less air flow :-)

I've had to get up to avoid keeping my friend awake with this tickly cough, so I might do some research on that now.

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!
jonr
QFP80 - Contributor
Posts: 46
Joined: Mon Aug 29, 2011 12:59 pm

Re: DFH - Defacto FreeEMS Hardware in KICAD

Post by jonr »

I used to program EEC IVs for Ford, so I'll give my opinions. Write in C vs assembler. Processors are cheap, so use one of the best (fast, lots of ram/rom/features) available. Buy a cpu board and spend your effort on the I/O board. For example, perhaps the lpc1769. For very high accuracy output (like high rpm ignition), you want to look for timers that can output the pulses without an interrupt. And/or use other external hardware (like EDIS). From day 1, plan on on running on various hardware and cpus - so keep the code very modular and portable.

http://www.embeddedartists.com/products ... 69_xpr.php
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: DFH - Defacto FreeEMS Hardware in KICAD

Post by Fred »

Thanks for your advice. I agree with all of it, and funnily enough, as a professional software developer, that's exactly what I've done. The trouble is, done is past tense, the ECU is all but finished in a basic way. It only remains to polish software, add features and complete some reliable hardware. We're very close now.

Thanks for your input! :-)

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: DFH - Defacto FreeEMS Hardware in KICAD

Post by jharvey »

I also like ARM's, but I'm not that good with software, and I don't have enough time to try it from scratch on my own. I believe one key issue your above noted board will have is the number of IO. Also I'm not aware of an ARM based ECU or EMS, so software for such an approach is limited and much needs to be written before an ARM could potentially be used. That board is pin limited, but I'm also sure most of the LPC's pins on that board aren't being put out the headers. One feature of ARM's that I like is the potential to simulate with out the need for the hardware. That would really expand the potential base of software developers.

As Fred noted, it's a balance of software and hardware. In this case Fred and crew have done much software dev on a processor that has suitable processing power and signal flow resources for most needs. So there is a good chance of success if one uses the TA card as the brain.

Are you thinking of trying an ARM approach?
Post Reply