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 »

Here we go :
  • You still have LEDs on port K and E that we don't need and won't be useful. = -16 components
  • The XOR chips for ignition are connected to the injection channels. The primary injector channels don't need XOR chips and the ignition ones DO :-)
  • The XOR chips are shown going to ground only. Should there be a switch per schematic so you lay it out with solderable pads correctly? ( 3 square pads close together with 5v on one and ground on the other)
  • The thermistor pullups should be 2.7k to be consistent with the majority of users running jap engines with ND sensors. This is minor though.
  • We can and should ditch the analog protect stuff from the second bank of inputs. That is perfect stuff for an expansion card IMO. = -32 components
  • Still no input impedance resistor on the inputs to the lm1815 chips. Should go from input pin to ground. = +2 components
  • You forgot to take the zener out of the power supply setup. = -1 component
  • Ignition control "low power ind dr" circuits still use a discreet fet instead of an XOR chip OR IGBT, or is that just redundant now? Is it just shown in the pdf or is it actually in the main schem?
  • The resistors on the LEDs that are destined to see 15V with larger spikes should be more like 3k than 500 Ohm. 5mA is plenty to make them light up obviously and there is no point drawing more current than we need to.
  • As Brian pointed out, they should all go to 12v not ground just like the real loads :-)
  • As discussed we can drop the digi protects for fixed on board stuff. Just a single current limit resistor to/from the XOR chips is enough for example.
  • I don't understand the diagrams well enough to know if this is an issue or not, but there should only be exactly 2 input pins/connectors/solder locations for RPM, some jumpering inside should change whether it is a square wave or VR signal and how it is processed before the CPU. So, 1 in, 1 out, and 2 paths through the middle.
  • You still have the thermistor and "current sensing" stuff in, but the chances of me convincing you not to do that experiment at this time is slim to none really isn't it? I'm just thinking, if we get 10 or 20 printed and you buy 1 or 2 then 90% of the users have a biggish chunk of PCB that won't get used. There will certainly be more board and circuit revisions later and I think that would be the time (closer to someone writing code for it) to add those things in, not now. However, you did do all the work on it, but I still think it's not ideal to include it even with the pcb jumper thing. Your (and others) call at the end of the day though.
  • So, from reading that it seems like the schem is for logic spark and high Z fuel? I don't mind the high Z fuel so much, but I think we should have the locations for spark present.
  • If we are covering exactly 8 ADC inputs which I strongly think we should then you should add a third temp circuit (preferably without the switching stuff) for the 8th one that is currently unused.
  • The order of the ADC pins is wrong. The correct order is :

    AN00 IAT – Inlet Air Temperature (Kelvin)
    AN01 CHT – Coolant / Head Temperature (Kelvin)
    AN02 TPS – Throttle Position Sensor (%)
    AN03 EGO – Exhaust Gas Oxygen (lambda)
    AN04 MAP – Manifold Absolute Pressure (kPa)
    AN05 AAP – Atmospheric Absolute Pressure (kPa)
    AN06 BRV – Battery Voltage Reference (Volts)
    AN07 MAT – Manifold Air Temperature (Kelvin)

    This will be shown in the next release clearly.
  • you have ind_dr_1(to 6) on both B0 - 5 and T2 - 7. It seems ambiguous and too general to label them that anyway, inj_dr_1 and ign_dr_1 would be more appropriate IMO.
  • I need to push the fuel pump pins and your experimental pins around a bit, but I haven't done the work I need to do to know where they need to go... Another post on that later.
That ought to keep you busy Image

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!
davebmw
LQFP144 - On Top Of The Game
Posts: 331
Joined: Sun Jul 13, 2008 2:58 pm
Location: South Wales, UK

Re: freeEMS_1.0 rev A KICAD

Post by davebmw »

OK I have had a quick look over the schematics and here are some questions:
On RPM inputs:

Why put R151 in? this will form a potential divider with R152 and present 6 volts to the input of the processor and put unnecessary load on the output of the VR IC or the Hall sensor on P42-44.
I would prefer the pull down resistor R152 to be 4.7 or 10K.
D103 is a nice touch, would like to see it a little isolated from the signal, perhaps using a small N channel MOSFET to remove the loading from the signal line.
I would like to put a jumper link in there for the output of the VR IC to remove the output totally from the circuit should Hall be the choice of sensor.

Temp sensors:
Why are we using 2 CPU ports to measure the temperature?
if this is a requirement to have this one shot sample facility we would benefit from using a CMOS analogue switch like 4066 this has 4 switches and is very suited to small signal switching with extremely low distortion. QUAD Hi-Fi use them lots in their good stuff.

Ignition drive:

Most coils are high side therefore switching is done lowside.
Why don't we put the LED in parallel with the coil both connected to the Drain of the FET, but the coil highside connected to dirty power and the resistor and anode of the led connected to clean power.
back EMF protection has to be a Shottky diode and RC snubber arrangement.

spark sense (if required) can be obtained by putting a 240R resistor in the HT ground return line of the coil and conditioning the signal with a zener diode.
A spark at the plug equals a nice controlled pulse across the resistor and easy to monitor too. BMW use this it works well and snubs RF emissions.

Digital protection:
I'm not to sure about the 100n caps that with the 10K resistors looks a bit too much like an integrator to me it will add slew to the signal.

O2 input will be from wide-band controller will it not? should it have the same protection as the analogue channels?

Injector channels:
Nice low-side FET with snubber I think that the same should go in this circuit as the coil drive, high-side LED from clean supply.

What do you guys think??
hope this is not too harsh an assesment ;)
93'BMW 325is M50B25TU, Rebuilt 06/06, JE10.5:1, polish&port. Scorpion BB, K&N CAI, TEJ21 WBO2, '07 M3 Evo 18" 225F, 255R, EBC Kevlar, Bilstien Sprint, Polyflex. Head rebuild Oct'08, OEM+FSE FPR, MS2v3.0_DJB Custom, Extra 2.0.1
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 »

davebmw wrote:I would like to put a jumper link in there for the output of the VR IC to remove the output totally from the circuit should Hall be the choice of sensor.
Agreed.
Temp sensors:
Why are we using 2 CPU ports to measure the temperature?
One is digital and the other analog. He wants to be able to switch off the current bias to the thermistor when not sampling to avoid self heating. I'm anti this, but he's designing it, so...
Why don't we put the LED in parallel with the coil both connected to the Drain of the FET, but the coil highside connected to dirty power and the resistor and anode of the led connected to clean power.
back EMF protection has to be a Shottky diode and RC snubber arrangement.
If coils are controlled on board it won't be with a FET, it will be with an IGBT. You definitely don't want to catch the spike as it will screw up the spark big time.
spark sense (if required) can be obtained by putting a 240R resistor in the HT ground return line of the coil and conditioning the signal with a zener diode.
Please no :-( We really have to remember the context of the application. These things are to be home tuned and dyno tuned by enthusiasts and modfied and tweaked and fiddled with. They aren't going into an OEM vehicle with a warranty that needs to self diagnose itself and report problems. If the owner is useless enough to cause a problem he needs to fix it himself. The ECU should run the engine and the owner should maintain the car. The ECU shouldn't be trying to maintain the car too... at least, not IMO anyway :-)
I'm not to sure about the 100n caps that with the 10K resistors looks a bit too much like an integrator to me it will add slew to the signal.
Values can be tweaked later easily enough, but you are right about that. then again, 10k is only suitable for inputs anyway, for output use I think 1600 Ohms is the correct drive resistance from CPU pin to other device pin. For outputs there should be no cap installed at all and no place for it for fixed outputs like ign and inj etc.
O2 input will be from wide-band controller will it not? should it have the same protection as the analogue channels?
I think so, yes. It will be another bare wire outside the box capable of being attacked by damaged wires or fried up controllers etc.
Nice low-side FET with snubber I think that the same should go in this circuit as the coil drive, high-side LED from clean supply.
Agreed, the leds should come from the clean supply. The switched clean supply to be specific.

No such thing as too harsh, we aren't little girls around here.

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!
davebmw
LQFP144 - On Top Of The Game
Posts: 331
Joined: Sun Jul 13, 2008 2:58 pm
Location: South Wales, UK

Re: freeEMS_1.0 rev A KICAD

Post by davebmw »

Fred wrote:
No such thing as too harsh, we aren't little girls around here.

Fred.
Don't make me get the SpideyFred photo back out again! :lol2:
93'BMW 325is M50B25TU, Rebuilt 06/06, JE10.5:1, polish&port. Scorpion BB, K&N CAI, TEJ21 WBO2, '07 M3 Evo 18" 225F, 255R, EBC Kevlar, Bilstien Sprint, Polyflex. Head rebuild Oct'08, OEM+FSE FPR, MS2v3.0_DJB Custom, Extra 2.0.1
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 »

Lets see how much of this I can overlook ;) Don't worry about harsh, worry about content, and keep it up.

- LED resistors are now 3k so much less loading, a 5v signal should produce 1.6ma
- Deleted R151 (12v to signal) from RPM schematic, added 1k to pin 5 for both gnd and 5V mode selection. Fred did you mean I should have a R for pins 9 and 11?
- Moved the injector LED such that it lights when current flows. I originally didn't put these there because they pull up that side of the injector, but I guess that doesn't matter. I was picturing doing polarity tests on the injectors, if both are high, then it's harder to know what one goes to the battery. Do injectors care about polarity, I haven't tested to see if the ones I have care.
- Changed AN's per Fred's request, but don't plan on them there, I expect to let PCB layout rule what should go where. I don't know of physical reasons why they should be that way, so if I can avoid crossing over wires at the PCB, I'll likely change them around. I will try to keep them as noted above.
- ignition current sensing... I wonder if that is what the 4th wire in my wife's Jetta is doing. I'll add this to the TODO 2.0 list. Don't tell Fred, but I'm kind of tempted to move the injector current sensing to 2.0 as well.
- FET on the thermistor is required for my application, and is a good idea on a normal setup. I don't have a heat sink for the thermistor, and it will go up in flames with out the FET duty cycle keeping the overall power draw down. I plan on default wiring it as shorted, then I'll have to cut a trace to make it work Most people will simply ignore three little holes.
- about "an protect" and "digi protect", they show extra parts, most will probably be jumpered thru anyhow. For now I'm leaving in the pads so we can add parts if required. I expect after a proto of 1.0 is done, many parts can go away, like the 0R in the injector schematic.
- about the clean and dirty supply, is there a dirty supply on the PCB? Injectors, fuel, ignition, ect will be directly wired through relay's to the battery, then grounded via PCB. I know the injectors show a 12V lead, but that really shouldn't be connected right. Ignition also drives external power IGBT's right, so dirty is even farther away there.
- I think we want some LED's from the CPU. One min to tell us CPU is running, and other(s) for potential feedback, but mostly for places to solder wires if we want to connect something to them. If we have something else that goes there, I'm happy to remove LED's.
- ignition vs injection channels, I found a typo, I had two sets of ind_dr's I changed PB to injector drive so ind_pd not ind_dr.

Tell you what, I'll do another release. Stay tuned.
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 »

freeEMS 1.0 A.13 is up for review see here

https://sourceforge.net/project/showfil ... _id=621212

Quick note, R43 is not the same R43 this time. It has likely changed, perhaps something like R41, or close, but not the same.


Hmmm, I don't think the LED in the ignition schematic works this way. Also Fred is this the way you objected to? Should I put it back the way it was, or should I put it differently.

- about the zener in the reg, I know it's not a crow bar, but it does help with OV. Should it stay? Don't have to populate it if you don't want to.

Some notes about where I envision 1.0 going. Right now we are making a proto, that will have extra stuff in it. Like test points for inserting in line amp meters, and extra holes for parts we may or may not want. Rev's will remain A.XX or (heaven forbid A.XXX) until the proto is ordered.

Then we will clean it up, removing extra crap, and making tweaks as required per the test results. A this point it will change to B.XX. B.XX is the bare min setup, so unused digi protects, ect will show up as jumpers. This is probably where most DIYers will start to play.

Then we can have the advanced version titled C.XX where we add some of the extra features like current sensing, test points, inverting signal configs ect.

I picture B.XX and C.XX to resolve to the same PCB which will closely resemble A.XX.

Oh also still looking for footprints for the ignition driver FET/IGBT. Should I just use a TO220? I'm guessing it's going to be a much smaller package.
davebmw
LQFP144 - On Top Of The Game
Posts: 331
Joined: Sun Jul 13, 2008 2:58 pm
Location: South Wales, UK

Re: freeEMS_1.0 rev A KICAD

Post by davebmw »

My vote for high power fets, TO220 easy to mount vertically or horizontally and plenty of devices to chose from.
93'BMW 325is M50B25TU, Rebuilt 06/06, JE10.5:1, polish&port. Scorpion BB, K&N CAI, TEJ21 WBO2, '07 M3 Evo 18" 225F, 255R, EBC Kevlar, Bilstien Sprint, Polyflex. Head rebuild Oct'08, OEM+FSE FPR, MS2v3.0_DJB Custom, Extra 2.0.1
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 »

Hmmm, should I title one of the general outputs as fan? Kind of like I did with the fuel.
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 »

You buggers beating me to it again...
My vote for high power fets, TO220 easy to mount vertically or horizontally and plenty of devices to chose from.
That's no good for ignition on board and a terrible waste (2mA with a to220?? lol) for driving external ignitors.
Hmmm, should I title one of the general outputs as fan? Kind of like I did with the fuel.
If you are installing GP FETs put them on the PWM pins as that is what will be top of the list of things to code for.

My post :
jharvey wrote:- LED resistors are now 3k so much less loading, a 5v signal should produce 1.6ma
It should be 12v for a bunch of reasons. Number one, keep the load AND noise off the regulated lines. Number two, reduce the reverse potential applied to the LED by kick back. Number 3, 1.6mA is pushing it ;-) 3k is a good value for 15v, hook em up just like the load.
Fred did you mean I should have a R for pins 9 and 11?
No, I meant across the points P45 and P46 as an input impedance that the VR signal must drive.
- Moved the injector LED such that it lights when current flows.
To 12v right?
- Changed AN's per Fred's request, but don't plan on them there, I expect to let PCB layout rule what should go where. I don't know of physical reasons why they should be that way, so if I can avoid crossing over wires at the PCB, I'll likely change them around. I will try to keep them as noted above.
There is more to where they go than just making the PCB simplest. Firstly I have and have had for 6 months a setup on my desk using them in this way which will be a pain to change. I don't want to waste time (significant time) reworking that for a small benefit. Secondly, we need to have them in some consistent and sensible order for clarity of instructions. If you show me a good reason to change them at some point, I'll consider, but if you do, thats more time I'm NOT developing the firmware that we need to make this thing happen. Having a couple of traces crossing is way way way less important than me wasting half a day screwing around changing hardware IMO. Obviously if it makes the board a mess, I'll change, but if it's minor the traces should cross.
- ignition current sensing... I wonder if that is what the 4th wire in my wife's Jetta is doing. I'll add this to the TODO 2.0 list. Don't tell Fred, but I'm kind of tempted to move the injector current sensing to 2.0 as well.
Shhhhhhhhhhhhhhhhhhhhhh Image
- FET on the thermistor is required for my application, and is a good idea on a normal setup. I don't have a heat sink for the thermistor, and it will go up in flames with out the FET duty cycle keeping the overall power draw down. I plan on default wiring it as shorted, then I'll have to cut a trace to make it work Most people will simply ignore three little holes.
This I care about a lot less than the injector ones, esp with the trace bridged. I have to ask though, what the hell kind of sensor are you using that will "burst into flames" let alone distort the reading enough to care about with a 2k ish resistor feeding it? Hell, you could feed 5v straight into most thermistors and they would be OK. Were you just speaking colourfully?
- about "an protect" and "digi protect", they show extra parts, most will probably be jumpered thru anyhow. For now I'm leaving in the pads so we can add parts if required. I expect after a proto of 1.0 is done, many parts can go away, like the 0R in the injector schematic.
but but but, the 8 EXTRA ADC channels are extra. IE, they are for functions that code won't be written for for months. As I see it, the board should be focussed on "what we will need now/soon" rather than "what we might need one day". This goes for all aspects. We need injector drive, but we want low Z drive. We need separate grounds and powers up front, we want an RTC on board. We need the 6 core sensors, we want the other 8 adc inputs. etc.
- about the clean and dirty supply, is there a dirty supply on the PCB? Injectors, fuel, ignition, ect will be directly wired through relay's to the battery, then grounded via PCB. I know the injectors show a 12V lead, but that really shouldn't be connected right. Ignition also drives external power IGBT's right, so dirty is even farther away there.
We want a 12v dirty in the case so that people that need 12v to expand the system don't steal it from places that would screw up the system. We shouldn't be putting extra stuff on the board, but we should be planning to plug in another card with xyz functions on it.
- I think we want some LED's from the CPU. One min to tell us CPU is running, and other(s) for potential feedback, but mostly for places to solder wires if we want to connect something to them. If we have something else that goes there, I'm happy to remove LED's.
Well, those are supposed to be the staged injector channels. If you just want to verify the thing is on and running, put a single one on the same pin as the "user led" is on the TA board, one of the PWM pins. Past that LEDs are a total waste of space/time/effort when you have serial comms functioning properly. The only reason I wanted any LEDs on the board is to visually verify that outputs we are actually using are being switched as they should be. Give the fuel pump drive a led, the injectors and coils a led each and past that, nothing IMO, though you can put one on the pwm pin as an "i'm alive" indicator. That is useful. Each LED should show that something real is happening, not be there on it's own as some signal. If you are going to put any on, you should use a 2k resistor to keep heat out of the CPU. We shouldn't be encouraging people to "connect something to them" at all. Everything should be buffered. People that show us non-buffered outputs should be kicked firmly in the goulies and told to fix their setup before being helped :-)

Just looking at A13... the purpose of on board LEDs is to verify at the end of the signal path that stuff is happening. For the outputs, it should be on the output outside everything else. For the inputs it should be after absolutely everything else, ie, right on the CPU input or just outside the 1.6k resistor or something, not at the input from the world. We need to verify that the CPU pin itself is seeing signal, and for outputs we need to verify that the device, or at least connector is seeing signal. Do you see what I mean?
Hmmm, I don't think the LED in the ignition schematic works this way. Also Fred is this the way you objected to? Should I put it back the way it was, or should I put it differently.
I don't know which are ignition as none are labeled as such. All the LEDs appear to be connected to 12v with a 3k though, so thats all good :-)
- about the zener in the reg, I know it's not a crow bar, but it does help with OV. Should it stay? Don't have to populate it if you don't want to.
The thing is, if there is an extended fault it will burn and may take the board with it. Caps will "just" explode if exposed to higher than spec voltage. I think it should go as in it's current form it is not useful. If you want to force it low then Deltas idea is a good one, but we decided not to do either I thought.
Oh also still looking for footprints for the ignition driver FET/IGBT. Should I just use a TO220? I'm guessing it's going to be a much smaller package.
I thought we decided to use IGBT on board as the default configuration? We definitely decided to use XOR chips as the buffers/drivers for them anyway. The actual IGBTs are to220 devices, so if we are going with on board ign then that is what you should use. Some options are :

BIP373 : http://www.megamanual.com/ms2/bip373_datasheet.pdf - new default MS ignition driver with protection (copy url and paste in new tab)
ISL9V5036P3 : http://www.fairchildsemi.com/ds/IS/ISL9V5036P3.pdf - people are using this with success
irgs14c40l : http://www.irf.com/product-info/datashe ... 14c40l.pdf - people are using this with success

I think they all have the same pin out, but double check that.
Right now we are making a proto, that will have extra stuff in it. Like test points for inserting in line amp meters, and extra holes for parts we may or may not want. Rev's will remain A.XX or (heaven forbid A.XXX) until the proto is ordered.
Dude, it's an EMS which in it's basic form is a dead simple circuit, what exactly would we want to measure with an ammeter? If you put in test points like that, they should be hard wired by default like the thermistor stuff. I think we already know what we do and don't want on the board, it's more a matter of figuring out how much of it can fit reasonably.

Good work, I still haven't figured out the correct pins for a few things, so I need a little more time for that.

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!
davebmw
LQFP144 - On Top Of The Game
Posts: 331
Joined: Sun Jul 13, 2008 2:58 pm
Location: South Wales, UK

Re: freeEMS_1.0 rev A KICAD

Post by davebmw »

May as well leave that upto the end user some will stick with the fan control they already have or viscous coupling etc.
I would find it less confusing if I were a complete idiot too! :lol:
93'BMW 325is M50B25TU, Rebuilt 06/06, JE10.5:1, polish&port. Scorpion BB, K&N CAI, TEJ21 WBO2, '07 M3 Evo 18" 225F, 255R, EBC Kevlar, Bilstien Sprint, Polyflex. Head rebuild Oct'08, OEM+FSE FPR, MS2v3.0_DJB Custom, Extra 2.0.1
Post Reply