Preston's Element 14 BOM Attempt

Marcos' unmaintained, but still in-use, Puma for FreeEMS circuit board/hardware design!
User avatar
jharvey
1N4001 - Signed up
Posts: 1607
Joined: Tue Jun 10, 2008 5:17 pm

Re: Preston's Element 14 BOM Attempt

Post by jharvey »

Fred you claimed my systems were old when we started, and they still are. As you know I can't upgrade with out a very significant effort. We can get into it again, but the problems still remains. I can't open the latest format with out days of work on my end.

I've seen people get confused about the bus linking in schematics before, so I figured I'd post this picture to help those that might have trouble with it. The bus name is how these "mismatched names" get link and tracked by the layout software.

Image

Ultimately the real issue is that the analog protect 4 circuit doesn't yet have properly selected components. Those components shouldn't effect normal operation in any way, and should only influence spikes and high frequencies. The CHT circuit should send the signal up stream and it shouldn't really care how it gets there. Un-fortunetly the analog protect diodes were leaking beyond the datasheet spec, so they do influence the circuit when they shouldn't. Which then causes the problems.

Also there is a link, but it's in KICAD.
User avatar
Fred
Moderator
Posts: 15433
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Preston's Element 14 BOM Attempt

Post by Fred »

Fred wrote:check d33 d34 c30, why not used? same on aap c19 d31 d32
MAP and AAP -- protection circuits arent nessasry on components internally connected with the board.
Fred wrote:both map and aap can be substituted for off board map units from toyota, honda, gm, etc
If you are using off board sensors then it is suggested to install protection circuits consisting of D31, D32, C19 (AAP) and D33, D34, C30 (MAP)
This should somehow be part of the BOM. MAP always has parts xyz and for off board use use abc and for on board use use jkl. Ditto for AAP, although AAP should be optional for everyone anyway, many/most won't install it, at least at first.

Map is tabbed AAP is not tabbed. AAP can be selected with or without barb both non tabbed.
Fred wrote:aap should have barb for routing to correct pressure zone on car.
As above optional we can make this standard if everyone agrees.
A barbed one can be A not connected and B cut off, but a non barbed one is stuck with variable readings when your passenger winds their window up or down at high speed. It should definitely be barbed for the default part number. If silly people want to do other things, they can do it at their own risk. We shouldn't encourage it. Looking at the part numbers and the ranges, 105kpa isn't really a good idea. The 115kpa variants are much better. The code doesnt care, and the chances of it mattering are slim to none, but it is a fact that atomospheric pressure reads higher than 105 regularly in some places and it is a fact that it can sometimes get up as high as 106.5 or possibly even more. If that happened, the future AAP code would be unable to react. As such, the only good option is to order a tabbed barbed unit and either bottom side mount it or cut the tabs off with a knife or saw. This is the better option for a non barbed one, despite the fact that you probably shouldn't use a non barbed one: 1457150 This barbed one is out of stock: 1457152 And this one has tabs that could be cut off: 1457151, it is what I'd recommend, for element14 buyers wanting a good AAP solution. People in other parts of the world could order sensors with a barb. Also, you can get them with the barb on the end and not the side elsewhere, too.

Fred wrote:no mounting for either map or aap.
MPX4250A (MAP) only comes in a tabbed package - if mounting is difficult remove tabs.
I was just pointing it out, it'll be hanging off its leads and could fatigue, hence off board could be a better option.

Fred wrote:on rpm page, r212-r216 might take 1/4w but will really get that hot and should probably be taken off board into loom as trying to stand bigger packages on end on the smd pads just rips the pads off.
R212 and R216 are 0805 surface mount and 1/4 watt so should fit the current puma pad. Alternatively use fred's approach and mount in loom.
Fair enough. As jared pointed out, you'd have to sustain high RPM for a long time to cook them. No burnouts for you, Presto! :-)

Fred wrote:all caps that aren't tantalum should be X7R in final, not critical for spin 1, though.
Caps, up to you :) I have selected what will fit best with current foot prints.
Well, many values are shared in multiple places. If the final order can be simplified by having more of one type, that is a good thing. The ADC caps should be good quality ones to maintain their filter response at diff temps and be right in the first place. Most caps have a horrendous tolerance that really isn't acceptable. It's acceptable for decoupling, but not for filtering or clocks etc.

Fred wrote:fuel pump page, r66, what is that for? mine isn't populated, but it could be a good thing to have. R68/C37 should not be populated. No mods are required for d46 and r67, cept maybe the value of r67 and the part number of the d67 led. Drive fet is not included in this page and should be.
R66 = pull down, Q8 added (note in schemaitics this under general drive and not fuel) D46 and R67 up to you wont make a difference, I moved them as I felt that the fuel pump wires may obscure view of the led.
OK, R66 is a good idea, but it's on the wrong side of the 1k, really. As for your idea to hack the led and resistor over to the GP drive, no, don't do that! The correct one is perfectly visible and you only have one wire and it goes from underneath with the led on top. Even if you wire it from the top like a monkey might, you would be able to see the led shining past it without issue.

Fred wrote:CHT stands for Cooland/Head Temperature
Cooland/Head Temperature not sure what this is? But I can change it to "Coolant/Head temperature"
Yep, add the slash in there too. What it is is an engine temperature indicator for warm up and overheat and fans and so on. Water cooled engines use cooland and air cooled engines use head temp directly. What we really care about is manifold wall temp, cylinder temp, piston temp, chamber temp, but we can't know those accurately.


Fred wrote:afaik, no zeners should be installed on the board.
Zeners replaced with Schottky's
Hmmm, if a zener was suitable, then the only replacement suitable is nothing. Let me check your spreadsheet. OK, remove teh schottkys from the ignition page, i can't see them being out of place anywhere else. The ones in the ignition page are duplicates anyway, the red ones with 'not populated' are correct.

Same goes for the resistors in the ignition page, they should be jumpers, not open circuits. Or they should be 1k and the ones that are 1k should be jumpers, same circuit at the end.

Also on the ignition page, you spec 2k resistors for the LEDs, 2.4k is a better choice and will allow part sharing with the other 2.4k parts, also in MF 1% :-)


Fred wrote:all resistors should be 1% MF as they are cheap and easy to get and just better in every way
Maybe for a final version :) but I see it making a masive difference, except for where it counts.
Same applies as for caps, merging orders can be a good thing both for cost and simplicity of assembly and so on. Anything for clocks and bias and filters must be this, stuff for current limit can be crappier, but why?


Fred wrote:TPS value changes not colourised.
Sure.
I meant R173 being 470 ohm.

Fred wrote:Injector page, didn't check your part numbers, but assume they are good from previous discussion.
Anyone else want to double check?
1017798 is OK, but has no protection.
1775617 is no good. This requires a FET driver. It's also too low voltage. Remove from BOM ASAP.
1739424 is GREAT but very expensive.
1739425 is GREAT but even more expensive.

Fred wrote:Ignition should consist of cpu > 1k > xor > 1k > fet (with 100ohm pull up) (with LED setup on either output of XOR or output of FET, whatever pcb allows for)
This setup has been alowed for.
Good, generally I don't like it, but it seems like the best option for a spin 1 puma to follow.


AAP Stands for Atmospheric Absolute Pressure, not Altitude :-)

Good work presto! Will hit submit on this and have another review, possibly catching up on power and usb and cpu and clock, better, etc.

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: 15433
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Preston's Element 14 BOM Attempt

Post by Fred »

jharvey wrote:I can't open the latest format with out days of work on my end.
What is it, some crappy redhat distro? :-) My eee is on 2+ year old install of debian unstable and is stable and upto date :-)
I've seen people get confused about the bus linking in schematics before, so I figured I'd post this picture to help those that might have trouble with it. The bus name is how these "mismatched names" get link and tracked by the layout software.

Image
The trouble is that these don't make it into the PDF which makes it a nightmare to decode for anyone downstream and not using kicad. Something to raise with the kicad devs?
Un-fortunetly the analog protect diodes were leaking beyond the datasheet spec, so they do influence the circuit when they shouldn't. Which then causes the problems.
It was the digi zeners, not the analogue schottkys, that were leaking and affecting the RPM signal (and perhaps other circuits, though 9 months later that was never tested), hopefully they are not on the RPM sheet of preston's bom. I will check. RPM sheet is missing 3 components per input. two resistors of which one should be 1k and the other bridged and one zener which should NOT be used. Please fix :-)

Preston, mouser want 40 bucks shipping, which is the cost of the max chips at quanitity = 10, not too bad if 5 of you share it, i guess @ 16nzd per person. would it be worth using mouser for everything in that case? VNP14N04 = 2.82nzd each on mouser and is a superior part to the one you have listed and only a fraction more cost. http://nz.mouser.com/ProductDetail/STMi ... P14NV04-E/ just a thought.

Also Preston, the mouser part numbers work as a link, and the element14 ones dont, but they look like they should. Maybe an OO issue, unsure.

Jared, see attached for current spreadsheet at the time of this post.

Fred.
Attachments
PumaBom-WithMods-Element14.ods
For Jared <3
(23.95 KiB) Downloaded 544 times
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: 15433
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Preston's Element 14 BOM Attempt

Post by Fred »

1017795 http://nz.element14.com/fairchild-semic ... dp/1017795 - good enough and cheap. Under a buck if you get 25 which you likely will for 5 orders. 7 necessary and perhaps 3 gpio fets per build = 50 in the order. Just a thought.
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: 15433
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Preston's Element 14 BOM Attempt

Post by Fred »

LED reverse v max is 12v, will likely work OK, but probably should find a better unit.

OK, I've checked over the USB stuff and it looks good. I endorse your changes to it.

MCU power looks good!

Secondary power:
  • Jumper should go from opposite sides of Q19 to D3, you state U4, which although true is much less practical.
  • C11 can be either left off or populated with another tant same part number as C8, but should NOT be a BFO electro.
  • I would reorder to have reg at top, and all left off or jumpered stuff together at bottom. It's hard to see the reg at the moment and
  • the shit you dont want comes before the shit you do.
CPU stuff I've still not checked, will check when I check RavAGE CPU stuff, maybe tomorrow.

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: 15433
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Preston's Element 14 BOM Attempt

Post by Fred »

BTW, preston, above posts would not have been possible in today's time frame without you doing the page refs as you did. THANK YOU!

Just CPU and full list vs your list to go. Then we can make sure everything is accounted for by either exclusion, jumpering, addition, or normal use (with possible value change).

Close! :-)
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: 15433
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Preston's Element 14 BOM Attempt

Post by Fred »

One addition that is required! The CPU pins for the XOR inputs need pulling down with 100k. That's 4 channels. I think all of the other FETs have it built in, but the ign ones are on the far side of the XOR so need it twice, once on the FET and once on the CPU pin.

They need to be attached from the CPU side of R230-R233 and go to ground. I don't know what the best solution is, but possibly a through hole 1/4 each laying on the surface somewhere?

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: Preston's Element 14 BOM Attempt

Post by jharvey »

Fred wrote:What is it, some crappy redhat distro? :-)
Yeah, the machine I've got up and running well, is Mythdora 5 (I think it was 5). I'm working on getting Mythbuntu going, but that's still not very accessible. I'd spend many hours running up and down the stairs to use that machine. It's an old system, and I am migrating to a newer platform, but it takes time. I've got the file now, and it looks good. I'd suggest saving in early-ish version of xls, as it can be opened by anything, and you won't participate in the stupid formatting battles they do now. Why is my modified (with several additions) xls 42kb and the original xlsx is 44kb. Most of the bulk is the additional encryption MS put in the header so we can't figure out what they are tracking in our files. There's a bunch of junk in the new format. I prefer a format that's better known. You'll find better stability across platforms, and you'll find less portability problems.

Here are my primary concerns/suggestions.

Use VNP28N04 for all MOSFET's, as it has a lower Rds, handle all current loads, and limits to 40V such that LED's and such are smacked less.

Use Transient Suppression Diodes (TVS) not schottky in the AN / Digi protects. Schottkies are good for bulk mostly rugged diodes, but they have reasonably high capacitance, which prevents them from shunting RF to the rails. The RF is what we are primarily trying to prevent from causing damage.

Some claim the VR's will get to 300V so C125 is potentially to weak.

I'm concerned about the LED's reverse 12V, but they also seem to have worked empirically, so they may be stronger than the data sheet notes. I'd suggest replacing the resistor with a schottky, and using an LED with an included resistor. It's a bit more $, but not horrible. Something similar to http://datasheet.octopart.com/SSL-LX304 ... 524239.pdf I know SMT versions exist, but I can't seem to find them right now. The currently chosen MOSFET will allow 70 to 80V on that side of the injector, so I expect a reverse potential of up to 70V, the 12V won't cut it. Perhaps those are better left as modified or removed. I don't trust them. Or perhaps one of the 40V FET's instead.

Here's my clone for collaboration purposes. https://github.com/jharvey/Puma-Bom-Element14

There were spelling mistakes, and missing components, especially on the injector circuit. It was drafted as OVP MOSFET's not the lowZ that Marco used.
The trouble is that these don't make it into the PDF which makes it a nightmare to decode for anyone downstream and not using kicad. Something to raise with the kicad devs?
That screen capture was on page 1 of the PDF. Would be nice if the PDF could link between pages. I've seen catalogs that do that, perhaps the KICAD dev team might become interested in creating that feature in PDF, such that you can jump from page to page.
User avatar
Fred
Moderator
Posts: 15433
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Preston's Element 14 BOM Attempt

Post by Fred »

jharvey wrote:Use VNP28N04 for all MOSFET's, as it has a lower Rds, handle all current loads, and limits to 40V such that LED's and such are smacked less.
Higher V limit = faster close. 5 amps is enough for a single injector, 14 is excessive, but fine. and 0.5ohm is sufficiently low to not pose any issues, let alone 0.035 as the VNP14N04 has. Virtually any quality reliable logic level FET is suitable here. Protected ones preferred for obvious reasons, they're almost indestructible.
Use Transient Suppression Diodes (TVS) not schottky in the AN / Digi protects. Schottkies are good for bulk mostly rugged diodes, but they have reasonably high capacitance, which prevents them from shunting RF to the rails.
What are their V drops, if it isn't significantly below 0.6, then they are worthless. Hence schottkys.
The RF is what we are primarily trying to prevent from causing damage.
False! We're mostly trying to prevent damage from eroneous 12v connections to sensitive 5v max input pins! Low energy RF stuff is handled by the CPU pins themselves.
Some claim the VR's will get to 300V so C125 is potentially to weak.
Good point! I've seen significant voltages from them, what some say is true!
Here's my clone for collaboration purposes. https://github.com/jharvey/Puma-Bom-Element14
Preston, do NOT try to pull this in, he's just put it up for you to read over, and I really like the way he's highlighted stuff in it. I'm not sure that I agree with it all, but that can come in another post.
There were spelling mistakes, and missing components, especially on the injector circuit. It was drafted as OVP MOSFET's not the lowZ that Marco used.
The original intent was to support either by simply jumpering out the low z chip and associated stuff. This is what Preston is rightly aiming for. Simple = good. Missing stuff is good to know about, as is spelling. Some of the other comments seem a bit off, though.
Would be nice if the PDF could link between pages. I've seen catalogs that do that, perhaps the KICAD dev team might become interested in creating that feature in PDF, such that you can jump from page to page.
I hope so, bring it up on that list, I've got a bad name there already with some (and multiple pats on the back from others) for sticking up for some guy, so it's counter productive for me to suggest this.
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: 15433
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Preston's Element 14 BOM Attempt

Post by Fred »

For anyone attempting to read Jared's spreadsheet, increase the zoom from 39% to 100% to read it ;-)

Jared,

BRV page, you have the protect circuit backwards! IE, that resistor was from CPU to cap, not from signal source to cap. So your comments are invalid. This highlights how confusing these schems are... Furthermore, the cap MUST be directly on the pin or ADC performance WILL be sub standard. Thus this resistor is fundamentally wrong and the cap MUST stay.

MAP page, R134 forms part of a REQUIRED filter network after the MPX sensor.

RPM page, ok, i see the cap complaint. I'd say 200 should be sufficient for this round through. High voltages are present, but 200 will cover the majority of them.

Fuel page, see page 51 of schematic from puma.freeems.org, Q8 is correct on both the schem and the board.Where do you see it saying that it's Q7? If there are schem errors I'd like to document them somewhere too. The mod/swap location thing is a waste of time and I do not want to see that in any documents being distributed to other puma owners. It's a total non issue. This can only cause trouble.

TPS page, R169, where do you see it, I couldn't find it in a quick search.

Good missing components finds on injector page! Hard to spot though, being in red instead of yellow, but comparing with presto's original revealed the truth.

Ignition page, the fets here will only handle 5 - 15 volts, so anything is suitable. No need for more than 200mA either. Footprint demands something more substantial, though. Where do you see R257? I don't. As I mentioned above, D10,12,14,16 should be left off the board. They don't belong there at all. This is more to confirm what I said above, rather than correct you, Jared.

Some good catches there, Jared! :-)
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