DFH - Defacto FreeEMS Hardware in KICAD

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

Re: freeEMS_1.0 rev A KICAD

Post by Fred »

8InchesFlacid wrote:Ok, that's awesome. Before the chip, after the electronics.
Yep, visual confirmation of a good input signal (really important) and visual confirmation that the ECU is doing something valid with it (equally so).
I sure hope this board supports VR *AND* digital ins (such as my mazda-copied circuit). Doesn't take much space, and looks the same to the CPU, makes it MUCH more flexible and prevents boards which look like mine.
That is the intent. If you have any thoughts on the best way to achieve this, please post them in that thread that you put up ages ago and link it here.
I spent so much time with an oscope in there, trying to figure out what was being SEEN by the CPU, and by the circuit, that would be a huge help. Ground a line, look for a response. That simple.
Exactly. Plus when it's actually trying to function you can watch the LEDs strobe and confirm that it's smooth and in order and happy.
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 »

8InchesFlacid wrote:As Fred alluded to, I'm really against this priming the injector thing. I don't see any advantage. Is it just so you can run injectors 87% duty cycle instead of 85%?
Actually it's worse then that, its more like 85.0% and 85.2%, I had remembered several times to do the math, when I was driving home, however I simply kept forgetting to do it when I had the time. I agree the 70R is bad, but we do still want some kind of resistor there to prevent oscillation. I think 2.2k is just fine and I've changed that in A.10, but I haven't been able to get QUCS to model it yet, so I can't really predict the oscillations. I'm sure it's OK in the real world.

Sounds like I should post a reference to the injector page where I was playing with QUCS, http://www.diyefi.org/forum/viewtopic.p ... a&start=40 The top pictures on this page show a fair bit of what I'm talking about with regards to needing the resistor. Note the graph shows voltage on the left, current on the right and time on the bottom.

Running short on time, Can't reply to the rest. Keep up the critiquing. Makes it more robust.
User avatar
Fred
Moderator
Posts: 15433
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: freeEMS_1.0 rev A KICAD

Post by Fred »

Delta wrote:eg M1 VND5N07 TO-220 so they could easily spec a replacement part that suits.
For that particular example I would really like to see a list of part numbers included as it's the one part that variation does matter a lot on that you can't get various versions of in certain places.

VNP5N07, VNP20N07, PIP3104, etc ones we know will work. you don't need a supplier for that at all. Just these parts, then they can get a data sheet and check the pin outs and get all the details and get an equivalent if none of the "approved" ones are available.
but most systems engineers will create a BOM of their own which sources parts from their own stocks or from their cheapest suppliers anyway, and only use your BOM as a guide.
Exactly, me included, and I've had to try and get a local BOM out of a @#$%ing digikey BOM before and it's a NIGHTMARE. A real pain in the arse. If it had said 1n4004, vnp5n07, 1/4w 1k 1% MF, etc I'd have had NO trouble. It's not that I'm against there being a part number, but I am FULLY against there ONLY being a part number. The sheet needs to stand alone as a reference without the reader knowing what the digi part number even means. Provided that is the case, do as you please :-)
By all means put a part number in to indicate what part you designed the pads/footprints for but you will find not many people will use it for personal builds.
OK, let's go for KISS here. Jared, for components that are only one type of mounting include only a digikey number and use what you need to from the other fields to describe it in detail enough to not use the digikey site. For stuff that is either smd or TH supply two digikey part numbers, one for each, possibly comma separated in the same field or / separated. Or in two fields. Use the rest to describe your part in an independent way.

What's to stop you using the first field for ALL of the description? We don't HAVE to use all 8 so why not just use the first field to describe all aspects required of a given component and the last field as your digi reference?

Just a thought.

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 »

One of the things I'm disappointed in, that it hasn't come up is what fields or chunks of descriptive data we need. I took a quick stab, and I'm sure I forgot some of the common specs.

Fore example should field 3 specify footprint(s)? If you say yes, I've already got a counter argument, because that data is in a separate more standard field called footprint. But the point is, what data should go in the fields? Especially when I look at some of them and see I only have fields 1 or 2, out of 4. I'm sure there is data we can or should put there.

We can use field 1 to describe it completely, but I think we may want to have the ability to turn on and off data when a BOM is created from KICAD. So how about we set up names for fields 1-3, then field 4 will be what ever else is preferred for describing the part.

I like tab deliminator for normal formating, it seems to read nicer in normal text editor(s) by putting things in columns. Perhaps we can fake it by using comma's for field 4... Or better yet, we can flip fields 1-4 with 5-8, so that field 8 is the general purpose descriptive section. I like that. Then we can use it as tab and comma delimited. If you want the last columns split up you can open it in a spread sheet with comma and tab delimination, and you'll have fields you can modify.

See revised PDF
Attachments
symbol fields.pdf
field designators for schematic symbols
(9.19 KiB) Downloaded 376 times
User avatar
Fred
Moderator
Posts: 15433
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: freeEMS_1.0 rev A KICAD

Post by Fred »

Using something "because it's there" is pretty much always a bad idea. I still don't see why you need two vendors given that the vendor information is solely for you. For general use we won't have a BOM as manufactured by KiCAD, we'll have an HTML page as manufactured by one of us (me probably) based on the contents of your BOM and fleshed out into something generally useful to everyone with links to pages for common distributors etc.

So, why not just your vendor of choice as a single reference for you?

Change of topic :

I've had a few people say to me that they don't like the SMD AND TH idea all that much. It seems that it could be that rather than making something interesting to both parties, if we do that we are making something that is interesting to neither party. It certainly needs consideration though. I'd like to see those people (and/or others) come forward and say what they will about this.

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

Fred wrote:
I sure hope this board supports VR *AND* digital ins (such as my mazda-copied circuit). Doesn't take much space, and looks the same to the CPU, makes it MUCH more flexible and prevents boards which look like mine.
That is the intent. If you have any thoughts on the best way to achieve this, please post them in that thread that you put up ages ago and link it here.
Er, build whatever you're going to do anyway, add my dual fet opamp and 8 resistors, and put a jumper to use either circuit? It's not a lot of wasted board space, and you can always use the op-amp as a buffer for some other input if you don't use it for timing signals.

Re: SMD
Unless it really drives the cost, I don't see a lot of reason not to use SMD everywhere. Should ease layout. Holes here and there are nice for jumpering things, but since we can add another board on top of our stack, there's very little that would need tweaking. And lower power, lower cost, etc, is good. It's getting hard to find stuff in TH anymore. So much more selection in SMD.
After the first 30 seconds of thinking "oh god, how will I solder this" everything works out.

If you can use the same pads, though, whatever, I'd say I'm indifferent.
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 »

Pardon my amazing ignorance: Where do I get the latest KiCAD file?
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 »

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 »

8InchesFlacid if your looking to help with the KICAD files, I've been trying to keep it segregated so that others can work on different parts fairly independently. If you'd like to work together on it, I can note some areas that might help prevent redundant efforts.

If you're looking at them as a starting point for your on variation, go ahead. The draft I've started is what I feel is the best approach, and I'm sure there will be variations. My guess is that in the long run the variation I'm working on is just that, a variation. Given time I suspect the base model will emerge, but for now I'm keeping my own interests a bit more up front.

If you have any questions about why I did something a certain way, toss me a line, I'm more then willing to help out.
User avatar
Fred
Moderator
Posts: 15433
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: freeEMS_1.0 rev A KICAD

Post by Fred »

Re SMD vs. ThroughHole :

There is WAY more to this than just the "oh my god I can't solder THAT factor" for us here on the board. Clearly we CAN solder absolutely anything, so that is simply not a concern.

One of the primary purposes of this board surely has to be to aid adoption of the system and help recruit valuable on car testers. IMO it is REALLY important that there is no mental barrier to those people EVEN if it's not real.

Additionally, hobbyists that buy locally can't "just get" SMD stuff at all. It is OK to have to order 8 FETs, but stuff like regulators and caps and diodes and resistors should be able to be bought from a crappy retail shop. If such retail shops aren't available to US shoppers anymore, that is truly sad, but don't punish the rest of us for that.

"Slacker Cam" said this to me the other night :
(09:01:02) Cam Walker: my honest opinion is that we should go smd for most components straight up
(09:01:14) Cam Walker: not tiny 0402 packages or anything
(09:01:26) Cam Walker: normal 0805s are easy as to solder by hand
(09:01:39) Cam Walker: although that has 2 side effects
(09:02:14) Cam Walker: we will mostly only get the on to it guys wanting to buy boards which will be a good thing at first
(09:02:45) Cam Walker: but we will get some idiots who have no idea how to assemble smd and therefore we will get lots of questions and possibly even a bad rep for being 'too hard'
(09:02:49) Cam Walker: so maybe th is the way to go
(09:03:15) Cam Walker: but no way would it be a good idea to put both on the same board
<snip>
(09:05:36) Cam Walker: but yeah, personally i like smd because its cool, components are cheaper, its more of a challenge, and its less prone to vibration problems etc
(09:05:45) Cam Walker: good points for both side
Another factor is that a large part of the point of this whole effort was to NOT DO SMD. The first iteration how ever basic was supposed to be a simple TH board that is easy to print and build for any noob. Something future MS products will fail at as they are all going factory SMD assembled. After that foundation is there for that type of people the world is your hardware oyster and lots of compact SMD ONLY stuff can be designed and built. I **REALLY** want to see a predominantly or only TH solution available up front for those that don't want to or can't do SMD work. This applies whether I can or not. I hope you can all see why.

This comes back to separating NOW from EVENTUALLY again. My personal dream for a FreeEMS solution is one that is barely bigger than the TA board in total size. All SMD and hand assembled and capable of running a 4 cylinder with a couple of spare IO channels and high Z injectors from your pocket. I think we can all agree that that can certainly wait till much later though :-)

Anyway, I urge you guys to look at it from a wider perspective and not the "optimal hardware solution" one. I sincerely hope you all see my point(s).

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