Sparkfun posted some board design tips recently.
http://www.sparkfun.com/commerce/tutori ... als_id=115
http://www.sparkfun.com/commerce/tutori ... als_id=114
DFH - Defacto FreeEMS Hardware in KICAD
Re: freeEMS_1.0 rev A KICAD
Nice links, thanks! :-)
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!
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!
Re: freeEMS_1.0 rev A KICAD
Here's freeEMS 1.0 A.20 P.01 for review
https://sourceforge.net/project/showfil ... _id=640732
For those with out KICAD, I've released a full PDF with the PCB layout as the last four pages. So this PDF is 45 pages, 41 schematic, and 4 PCB layout.
The only big issue that I'm currently aware of is that traces from the CPU to the "run ways" have not been routed. I don't think this should be a big deal to get these from point A to B. It should be a small amount of work when we have a CPU pin-out to work against.
Key thing done in this release is the BOM(s) that can be uploaded to Newark. The only part that isn't included in these BOM's is the PIP3104. Look for the BOM's in the BOM folder. I made a master BOM that is for 1cyl. You will need at least 1cyl, if you want say 2cyl's then you upload the other bom. If you want 3-6 upload the smaller BOM several times until you have the right cyl count.
https://sourceforge.net/project/showfil ... _id=640732
For those with out KICAD, I've released a full PDF with the PCB layout as the last four pages. So this PDF is 45 pages, 41 schematic, and 4 PCB layout.
The only big issue that I'm currently aware of is that traces from the CPU to the "run ways" have not been routed. I don't think this should be a big deal to get these from point A to B. It should be a small amount of work when we have a CPU pin-out to work against.
Key thing done in this release is the BOM(s) that can be uploaded to Newark. The only part that isn't included in these BOM's is the PIP3104. Look for the BOM's in the BOM folder. I made a master BOM that is for 1cyl. You will need at least 1cyl, if you want say 2cyl's then you upload the other bom. If you want 3-6 upload the smaller BOM several times until you have the right cyl count.
Re: freeEMS_1.0 rev A KICAD
Glad to see the release, been a while since I've seen it.
Quick question: There's *no* vias in this design?
Will check it out sooner or later.
Quick question: There's *no* vias in this design?
Will check it out sooner or later.

Re: freeEMS_1.0 rev A KICAD
I've been reading through the PDF today: http://dfn.dl.sourceforge.net/sourcefor ... l_A.20.pdf.
Some comments:
Pages 2-3:
Will have to check whether the regulator likes driving such a big capacitance at C10 (2200uF), it can trigger overcurrent protection in the regulator
and even send it into oscillation. Regulator application notes should have data on this.
Pages 4-9, 18-21, 27:
depending on the purpose of the inputs, the filter may be excessive, it's a lag of about 1ms in response.
Pages 10-15:
Pulldown resistor should not be the same value as the series resistor, the purpose of it is not to divide the drive voltage of the mosfet in half, is it?
Grow pulldown to 10k or bigger (100k perhaps), it doesn't have to be strong.
I don't know about how much power this chip can supply but many processors have limits per bank of output pins that you can reach if you have strong pullups/pulldowns on every pin.
Depending on the purpose of this output, the drive impedance may be too high, slowing down the turn-on and turn-off times of the mosfet.
Pages 22-23:
Overvoltage protection goes to supply rail. Does analog supply rail have anything to sink that voltage? Last time I checked most linear regulators don't sink current, only supply it. May be a better idea to use zeners so you don't drive noise into the analog supply rail.
Pages 25-26, 28:
Looks fine but what is the purpose of R94?
Pages 29-34:
Pages 35-36:
May want to look into just using a schmitt trigger IC rather than opamp for hall effect input. Not sure if the TL082 will work right on a 5-0 supply.
Pages 39-40:
What is the purpose of having the ground to the thermistor switchable? Low power operation when engine is stopped but ECU powered on?
Pages 43-45:
I realise the layout isn't ready but....
I see voltage regulators are sharing ground with the power MOSFETs, bad idea.
it seems the two pins of L1 are bridged on page 45, it's also a pretty long way to route the injector current.
Is the board not supposed to have a connector to the outside world?
Some comments:
Pages 2-3:
Will have to check whether the regulator likes driving such a big capacitance at C10 (2200uF), it can trigger overcurrent protection in the regulator
and even send it into oscillation. Regulator application notes should have data on this.
Pages 4-9, 18-21, 27:
depending on the purpose of the inputs, the filter may be excessive, it's a lag of about 1ms in response.
Pages 10-15:
Pulldown resistor should not be the same value as the series resistor, the purpose of it is not to divide the drive voltage of the mosfet in half, is it?
Grow pulldown to 10k or bigger (100k perhaps), it doesn't have to be strong.
I don't know about how much power this chip can supply but many processors have limits per bank of output pins that you can reach if you have strong pullups/pulldowns on every pin.
Depending on the purpose of this output, the drive impedance may be too high, slowing down the turn-on and turn-off times of the mosfet.
Pages 22-23:
Overvoltage protection goes to supply rail. Does analog supply rail have anything to sink that voltage? Last time I checked most linear regulators don't sink current, only supply it. May be a better idea to use zeners so you don't drive noise into the analog supply rail.
Pages 25-26, 28:
Looks fine but what is the purpose of R94?
Pages 29-34:
Pages 35-36:
May want to look into just using a schmitt trigger IC rather than opamp for hall effect input. Not sure if the TL082 will work right on a 5-0 supply.
Pages 39-40:
What is the purpose of having the ground to the thermistor switchable? Low power operation when engine is stopped but ECU powered on?
Pages 43-45:
I realise the layout isn't ready but....
I see voltage regulators are sharing ground with the power MOSFETs, bad idea.
it seems the two pins of L1 are bridged on page 45, it's also a pretty long way to route the injector current.
Is the board not supposed to have a connector to the outside world?
Re: freeEMS_1.0 rev A KICAD
Thanks for taking a look! :-)
Fred.
I'll let Jared respond to the rest, but even if you are right about this, you can't use a zener to effectively protect the CPU pin as the ones with low enough voltages begin conducting far too early and badly skew the ADC readings. If you are right, then I'm not sure what the solution is, except to rely on any +ve going spikes being short enough to flow into a cap happily.baldur wrote:Pages 22-23:
Overvoltage protection goes to supply rail. Does analog supply rail have anything to sink that voltage? Last time I checked most linear regulators don't sink current, only supply it. May be a better idea to use zeners so you don't drive noise into the analog supply rail.
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!
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!
Re: freeEMS_1.0 rev A KICAD
Well, you have some margin for that. If you use a 5.6V zener you should be fine.
Re: freeEMS_1.0 rev A KICAD
That's what I ordered, checked and used. It's not fine though. If you google the conduction curve of a zener it is apparent why too. The curve is a curve and doesn't approach zero closely enough for quite some distance away from the threshold voltage. So that isn't a solution unfortunately (and i have a lot of 5v6 zeners that need a home lol).
Fred.
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!
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!
Re: freeEMS_1.0 rev A KICAD
I've been doing some infrastructure work, so Internet has be intermittent at home here. I should have that straighted out in a little bit, when it's back up I'll reply to baldur comments, for now I'll start with a thanks, and I look forward to reading them in more depth when I'm finished my upgrade.
Re: freeEMS_1.0 rev A KICAD
Good news, my network is back up. Not done, but when is anything done. Anyhow its FreeEMS time.
pg 18,19 are the RPM digi inputs. Stability here is likely the most important, as we will be faced with shift not matter what we do. 1ms is perhaps more of a shift than preferred. I think this one will likely want some adjusting from the value(s) noted, perhaps this one also wants to be inductive, to help reduce natural shift, rather that just calibrating it out.
pg 20,21 are the misc digi outputs 27 is the fuel pump output. I think 1ms is OK here, perhaps we might want bigger, for spike suppression.
You raise good points. I hadn't thought about the filters shift all that much, I was planning to face that one empirically. I felt that even though these are all the same values, the final values would likely change. The components for the injectors likely won't be the same for the misc outputs, and perhaps the values for injector 1 might be slightly different from injector 2, ect.
Once I got into that frame of mind, I was focusing on making sure we had holes and traces where we might want them, and a bit less on values. Do you have some recommended values? I'm was pushing hard a while back, but now I'm waiting for the soft to develop. Extra predictions won't hurt here.
Because the AN inputs will likely have fairly high impedance(s) they shouldn't have significant power supplied by misc spikes. Energy we see here is likely to be just RF stuff that doesn't really need much of a sink or source. The diodes as shown would keep the reverse V around .5 to .9.
What we don't know is how rugged this chip really is, or which design is really the better design. I suspect the chip can handle more that -.2, however I suspect it can't handle sinking much more that -.2. So in the end I suspect we will end up using the zener design, not the one currently drawn up. This design was used because it offers the holes and wiring for both versions. Then a user can choose which is best for their application.
Another fellow purposed these protection circuits, one with the zener protection and the protection as drawn with normal diodes. I know it's in here somewhere. I recall it as a hand drawn scanned image.
I'd like to see us get closer to that -.2 with slinking capabilities, however I don't know how to do it, with out buggering the signal. These are after all fault protection, so I tend to feel they should be transparent to normal operation.
Also in my specific goal, it's a small engine. Most things that cars have had for 30 years, don't exist in my target machine. When I use it for intake air temp, it will likely be at that 80F to 90F range without a heat sink. I want to switch it out, allowing for an increase accuracy of the sensor, as well as prolonging the sensor life.
On a temperature sensor, a reading once every 10 seconds is more than quick enough for most applications. If you turn on the temp sensor for say 10ms, while you take a reading, the off for the 9+ seconds. You haven't self heated the sensor much. So your readings will be more accurate. If your sensor is in free space, like mine will be, you also haven't burnt the sensor off the leads either.
I posted a xls spread sheet about it here.
[edit] updated below links
Direct link to the xls file
http://jaredharvey.com/Files/projects/F ... _curve.xls
My general page
http://jaredharvey.com/Files/projects/F ... blower.htm
[/edit]
About the gnd, I think your right, I should probably break that trace next to the ignition drivers. I have a gnd via right next to the reg's, and the ignition is expected to go through that other via. However if it felt like it, it could go via way of the reg's, perhaps making the clean signal dirty. I'll break that trace and you'll see that in the future release. Also feel free to comment, the only think I don't consider proto type ready is the traces going from the "run ways" to the CPU pins.
About L1, yup they are bridged, as is the drawing. You found the other item I tossed in there for my purposes. I jumper-ed it out for the normal user. L1 is an inductor that should allow hall sensor Q11 to confirm your actually driving the load. I found that small amounts of resistance in your wiring, will create large variations in your injector duty cycle. I seem to recall it was something like .1ohm with a 50% duty cycle was actually on for 60% or 70%. That resistance is kind of hard to measure with a meter, could cause a bunch of gremlins. I figured it was easier to put it in, then jumper it out by default, than it was to add it later. So it's there as a hidden feature, that may some day may be supported in software. For now, it's wasted board space.
Thanks for the feed back, and if you see anything else, by all means let me know.
Good thought, and honestly I don't know the real answer. My suspicion is that the oscillations would be very high frequency, and only when under extreme loading like on first charge. I wouldn't expect oscillations during normal use. If so we would really want a more powerful regulator. I believe we are already over beefed, so I don't expect this to be a problem. I'll try to remember to check it with a scope when we build a proto.baldur wrote:Pages 2-3:
Will have to check whether the regulator likes driving such a big capacitance at C10 (2200uF), it can trigger overcurrent protection in the regulator
and even send it into oscillation. Regulator application notes should have data on this.
pg 4-9 are the digi injector output, 1ms is likely not preferred here, however the warp is likely just a small shift, not a change in duty cycle or frequency. I know there will be other warping along the way, perhaps we want an inductive filter here not a capacative to help keep shift minimal, or perhaps that's just being picky. The effects here would depend on the "turn on" voltage of the following FET's.baldur wrote:Pages 4-9, 18-21, 27:
depending on the purpose of the inputs, the filter may be excessive, it's a lag of about 1ms in response.
pg 18,19 are the RPM digi inputs. Stability here is likely the most important, as we will be faced with shift not matter what we do. 1ms is perhaps more of a shift than preferred. I think this one will likely want some adjusting from the value(s) noted, perhaps this one also wants to be inductive, to help reduce natural shift, rather that just calibrating it out.
pg 20,21 are the misc digi outputs 27 is the fuel pump output. I think 1ms is OK here, perhaps we might want bigger, for spike suppression.
You raise good points. I hadn't thought about the filters shift all that much, I was planning to face that one empirically. I felt that even though these are all the same values, the final values would likely change. The components for the injectors likely won't be the same for the misc outputs, and perhaps the values for injector 1 might be slightly different from injector 2, ect.
Once I got into that frame of mind, I was focusing on making sure we had holes and traces where we might want them, and a bit less on values. Do you have some recommended values? I'm was pushing hard a while back, but now I'm waiting for the soft to develop. Extra predictions won't hurt here.
Oops that's my bad, I had thought they were 10K. I guess I made a typo in my template file. I just updated them. That change will be included in my next release. Thanks for pointing it out.baldur wrote:Pages 10-15:
Pulldown resistor should not be the same value as the series resistor, the purpose of it is not to divide the drive voltage of the mosfet in half, is it?
Grow pulldown to 10k or bigger (100k perhaps), it doesn't have to be strong.
I don't know about how much power this chip can supply but many processors have limits per bank of output pins that you can reach if you have strong pullups/pulldowns on every pin.
Depending on the purpose of this output, the drive impedance may be too high, slowing down the turn-on and turn-off times of the mosfet.
I seem to recall the jury wasn't out on this one quite yet. The AN pins want something like min -.2v from GND, and like 1V max above the input rail. One version that didn't exactly make the cut (or at least wasn't drawn that way) was to replace D54 with one zener and remove D53, instead of 2 normal diodes. This would allow sinking spikes with significant energy. However the expected reverse voltage would be getting far away from the -.2V. Perhaps a couple volts - before the diode really started to conduct.baldur wrote:Pages 22-23:
Overvoltage protection goes to supply rail. Does analog supply rail have anything to sink that voltage? Last time I checked most linear regulators don't sink current, only supply it. May be a better idea to use zeners so you don't drive noise into the analog supply rail.
Because the AN inputs will likely have fairly high impedance(s) they shouldn't have significant power supplied by misc spikes. Energy we see here is likely to be just RF stuff that doesn't really need much of a sink or source. The diodes as shown would keep the reverse V around .5 to .9.
What we don't know is how rugged this chip really is, or which design is really the better design. I suspect the chip can handle more that -.2, however I suspect it can't handle sinking much more that -.2. So in the end I suspect we will end up using the zener design, not the one currently drawn up. This design was used because it offers the holes and wiring for both versions. Then a user can choose which is best for their application.
Another fellow purposed these protection circuits, one with the zener protection and the protection as drawn with normal diodes. I know it's in here somewhere. I recall it as a hand drawn scanned image.
I'd like to see us get closer to that -.2 with slinking capabilities, however I don't know how to do it, with out buggering the signal. These are after all fault protection, so I tend to feel they should be transparent to normal operation.
Hmmm, I'll have to see if I can come up with a story about this one. I suspect that won't play nice with the LED either. I think it was put in there as a place for folks that want a snubber diode, resistor, or cap. However, I like the PIP's protections, so I don't see a need for any of the three, so I chose one and went with it. I added a resistor, that I expected wouldn't be installed, and didn't pay much attention the value. I've added a note for clarity that will be in future releases.baldur wrote:Pages 25-26, 28:
Looks fine but what is the purpose of R94?
Yeah! we left you speachlessbaldur wrote:Pages 29-34:

This design is actually from a OEM Miata if I understand it right. I believe it was brought to the table by 8InchesFlacid who had to create and use it on his Miata with MS inside. I really don't know much about it, all I know is that folks have found it to work well. Perhaps we can get 8InchesFlacid to elaborate on it a bit more.baldur wrote:Pages 35-36:
May want to look into just using a schmitt trigger IC rather than opamp for hall effect input. Not sure if the TL082 will work right on a 5-0 supply.
I was waiting to see that one come up, also note it's bypassed by default. I put that in there because I discovered most thermistors are pushed beyond their limits with a constant V supply and resistor alone. The max they can handle in free air was around 2mW, but at specific temps they would consume like 4 or 5mW. Granted this temperature range was around 80 to 90F, then the disapated power went back to within spec. When used as a coolant sensor, you go above that temp fairly quickly. So in reality, it's not in that range much, as well it's usually in a brass plug with a larger heat sink, so the limits can probably be pushed with out immediate failure. However it's pushing the limits.baldur wrote:Pages 39-40:
What is the purpose of having the ground to the thermistor switchable? Low power operation when engine is stopped but ECU powered on?
Also in my specific goal, it's a small engine. Most things that cars have had for 30 years, don't exist in my target machine. When I use it for intake air temp, it will likely be at that 80F to 90F range without a heat sink. I want to switch it out, allowing for an increase accuracy of the sensor, as well as prolonging the sensor life.
On a temperature sensor, a reading once every 10 seconds is more than quick enough for most applications. If you turn on the temp sensor for say 10ms, while you take a reading, the off for the 9+ seconds. You haven't self heated the sensor much. So your readings will be more accurate. If your sensor is in free space, like mine will be, you also haven't burnt the sensor off the leads either.
I posted a xls spread sheet about it here.
[edit] updated below links
Direct link to the xls file
http://jaredharvey.com/Files/projects/F ... _curve.xls
My general page
http://jaredharvey.com/Files/projects/F ... blower.htm
[/edit]
My general intent is that there would be an addon connector card. The connector card would allow interfacing to a variety of OEM connectors. I picture a DB connector on one end that interfaces with the JimStim for testing and diagnostic purposes, and a connector of your choice on the other end. My small engine and other small vehicles don't really need an OEM connector, so we will likely skip the connector card and go straight to harness wiring. My theme here has been heavy on modular design. You may also find the sub schematics can be worked into other work fairly easily with the files in the template folder. Making it easier for folks to roll their own. For now I plan on a harness connection, so I'm leaving it up to someone else to make the first connector card. I do have a red project suby, so maybe I'll make card, but for now, I'm gunning for the small engine.baldur wrote:Pages 43-45:
I realise the layout isn't ready but....
I see voltage regulators are sharing ground with the power MOSFETs, bad idea.
it seems the two pins of L1 are bridged on page 45, it's also a pretty long way to route the injector current.
Is the board not supposed to have a connector to the outside world?
About the gnd, I think your right, I should probably break that trace next to the ignition drivers. I have a gnd via right next to the reg's, and the ignition is expected to go through that other via. However if it felt like it, it could go via way of the reg's, perhaps making the clean signal dirty. I'll break that trace and you'll see that in the future release. Also feel free to comment, the only think I don't consider proto type ready is the traces going from the "run ways" to the CPU pins.
About L1, yup they are bridged, as is the drawing. You found the other item I tossed in there for my purposes. I jumper-ed it out for the normal user. L1 is an inductor that should allow hall sensor Q11 to confirm your actually driving the load. I found that small amounts of resistance in your wiring, will create large variations in your injector duty cycle. I seem to recall it was something like .1ohm with a 50% duty cycle was actually on for 60% or 70%. That resistance is kind of hard to measure with a meter, could cause a bunch of gremlins. I figured it was easier to put it in, then jumper it out by default, than it was to add it later. So it's there as a hidden feature, that may some day may be supported in software. For now, it's wasted board space.
Thanks for the feed back, and if you see anything else, by all means let me know.
Last edited by jharvey on Thu Dec 03, 2009 11:00 am, edited 1 time in total.