DFH - Defacto FreeEMS Hardware in KICAD

[Fred]

1. Cool.
2. Cool.
3. Provide a connection to pin 5 for mode selection. Pin 5 can either be left unconnected, connected to 5V, or connected to ground to select the different modes which can be useful with certain VR sensors.
   In that case, put 3 pads for each option around the pad to that pin such that any can be configured easily without board mods and jumpers
4. This won't change the board layout but pin 14 can be grounded and the cap and resistor left out. This will generate a square wave output instead of the timed pulse (with a pulse width determined by the RC components).
   Ditto here, make it possible to easily ground that pin OR have those components in place.
5. Cool.

Assuming it's not too difficult of course :-)

Configurability with ease should be an aim IMO :-)

Fred.

[jharvey]

1. Injector drivers are PT2 - PT7 not PB0 - PB5
2. RPM inputs are PT0 and PT1 not PH0 and PH1
3. Ignition drives are PB0 - PB5 not PT0 - PT5
4. You have your current sensing pins connected to the number one CAN chips lines PM0 - PM3, use PM4 - PM7 and PE3 and PE4 instead.
5. You have your thermistor PWM attachments on PA5 and PA6, firstly, why two? turn both on, read both, turn both off? Secondly, I assigned PA6 to the tacho output so if you still want to use two pins for that, perhaps connect them to PA4 and PA5 instead.
6. I would like to see PA6 hooked to a to92 autoFET for tacho driving use.

I took a very rough stab at port placement. I figure that the PCB layout will determine if your list or my list will work nicely. I suspect neither is right, at the moment. I haven't read the firmware yet, and I'm also assuming that you have a software list some where, that maps your code names to ports. So once the PCB layout determines the exact layout, we can simply update this software table and we should be good to go. Is that correct? If so I won't worry to much about what port is what until laying out the PCB.

The thermistor fets will be shorted for now, but a possible software solution would be to base it off the code at the end of the injector IRQ. So IRQ 1 will turn on the fet. IRQ2 will take a temp reading (waiting this time gives it time to settle out some), IRQ 3 will turn off the temp sensor. IRQ 456789 leave the sensor off, IRQ 10 starts over. Yes individual control per sensor. Some measurements will be wanted more often then others, so control of each could be handy so that you can change how often you take a look at them. Engine temp once a second is more then enough, but intake air, might be handy for faster reads.

Hmmm, sounds like I should have a couple generic fet drivers. I'd probably aim for the protected fet's because I'll be buying them anyways, and they are rugged. Your right, I don't need the feedback on things like fuel pump relays, or tach outputs.

Perhaps a layout something like this



Note, the wires don't go to one location. The leave where ever it's handy for them to leave, reducing the number of times things want to cross over each other, and decreasing cross talking. Many of the sensor input's will reside right under the Tech Arts board, reducing the lead lengths, and a pinch of noise. Seeing the EURO card is larger then the Tech Arts board, I've added a generic FET section in the bottom middle. I know there will be missing items, so I'm leaving easy access to a bunch of AN and IO pins on the right. On the left, you can choose the number of injectors by cutting off the end of the board. I put injectors across the top, and ignition across the bottom. I figure, it's based on a per cyl base, so you can cut off one injector with one ignition.

[*]No wbo2 ADC input circuit shown (I realise we only just discussed this in the other thread, but I thought I'd make the list completish)

I'll have to stew this over a pinch. Normal O2 hangs right around .7v, I'd say up to 1.5 is common. Do I recall wide band can go up to 5V? I think these should also be analog protected, same circuit as the other sensors. Probably would be good if we can get one O2 per cyl as well. Perhaps I can add that to the space on the right. I'll have to stew this a bit more. Will the A/D go to 0v, or does it not like the rail.

[*]If you want the sensor isolation useful for all users, you will want to cut power to the sensor as some sensors have the ground at the head/block.

What?

[*]I don't understand why the RPM input schem is labeled as analog in, the CPU will see a digital signal there. It could be beneficial to use normal diodes to protect digital inputs as well as analog ones though, perhaps that is what you mean? (as in, not use a zener?)
[*]I've assumed the LM1815 is wired/configured/setup correctly, someone else may want to check that, or I can at a later date.
[*]Should the digital input setup have negative protection the same as the analog input? Is there harm in using the analog style protection for all inputs, it is simple clean and can be cheaply beefed up and doesn't interfere with the signal at all (zener (despite the fact I bought a stack of them) could cause a rise/fall time issue by drawing current in the upper voltage region where they are partially on.

Look at that, I copied the analog sensors when I made the RPM, your right, that isn't right, I'll change it to something a bit better.

I followed the LM1815 data sheet example, so I'm guessing it's OK.

The analog protect uses a larger cap and includes a resistor for a low pass. That might bugger the digi signals a pinch, or we can push that low pass way up.

[*]I'd still like to see a 1k resistor on the digital inputs too. I think all the cpu pins In and Out should be current limited and all the inputs should be voltage capped too (+ and -).
[*]On the FET input the resistor to ground must be a much larger value than the input one or the voltage will never saturate to 5V in. As you have it with 1k in and 1k to ground fully on will produce 2.5V. I bought lots of 1k, 10k and 100k resistors and a few lower than that so I suggest we use 100k for that value.
[*]For the pull up resistor on the low power FET setup, I think that there should be both a 5v and 12v pad for that resistor to be soldered to. I personally will use 5v on my setup, but others may need 12v.
[*]I didn't check that the footprint of the TA card is correct, but it looks to be correct.

The digi protect looks like the analog protect, perhaps you didn't see it, after all I did toss you a curve ball by calling it analog, not digi. There are two, both have 10k resistors to the input, as well as a zener to protect for over voltage, and reverse voltage. I think that is what you are looking for.

Again a copy paste issue. Thanks for catching the 1k vs 100k issue.

Added 5v as well as 12v to the ignition driver.

[*]Battery V divider network values should be 10k and 39k to yield a 24.5V maximum reading which I think is appropriate.
[*]The battery input needs to either share the power input to the CPU 5v feed (before reg) OR (preferably) have it's very own conditioning input. Just putting a capacitor inside the two divider resistors will form a first order low pass filter that is quite suitable. It needs to be able to change fast enough during startup conditions, and provide an average voltage the rest of the time. Experimentation will be required to get a good working compromise for that. Some software averaging should be employed too.[/list]

Battery V divide is updated with 10k and 38k.

A separate list for the power supply circuit :

Summary, remove two caps, increase one caps size, add a different cap and we are good to go.

Updated and agreed.

Potentially duplicate this circuit for the MAP, TPS, Thermistors or perhaps not. Am I crazy to want a second power supply for these? It does seem a bit extreme...

OK now your just crazy. A good 5V reg, and decoupling caps at the devices should take care of any issues here. I think one 5V reg is all that's needed.

[jharvey]

The four IGBT locations should have jumperable pins such that for those running external ignitors (AKA me) the to220 locations can be used without jumper wires to run FETs there for other stuff.

Sorry still don't follow, perhaps screen capture, and paint it on the schematic, then send it to me.

If you use both sides of the board then we could possibly put 2 more to220 on each side and make it a 6 cylinder controller. That would be really nice, but just a bonus at the end of the day.

I like this idea. I'll have to think about it mechanically. Might be a bit hard to assemble/repair, but I think it can be made to work.

[jharvey]

There are a few things wrong with the LM1815 circuit:

1. Pin 9 is not the output, pin 12 is. Ground pin 9 and 11 and use pin 12 as your RPM input. The 5.6k is a pull up for the LM1815 output.
2. Use a decoupling cap (0.1uf) between pin 8 and ground.
3. You should add a cap after the input 18K resistor for noise reduction. I use 330pF on my board.

Done

[*]Provide a connection to pin 5 for mode selection. Pin 5 can either be left unconnected, connected to 5V, or connected to ground to select the different modes which can be useful with certain VR sensors.

I think you mean pin 11 input select? Pin 5 shows NC on my datasheet. I added a 10K resistor to 5v and 0R to gnd so that it defaults to hi, but you can switch them to make it default lo.

[*]This won't change the board layout but pin 14 can be grounded and the cap and resistor left out. This will generate a square wave output instead of the timed pulse (with a pulse width determined by the RC components).

Hmmm, do we want the option of timed pulse? Should I draw it up as the square wave config, then let people hack it up if they want the pulse?

[jharvey]

Here's freeEMS 1.0 A.06

This version I made various fixes like typo's ect, added generic fet driver(s) and O2 sensor input.

[jharvey]

I'm replying to myself, mostly to remind myself what I was thinking. When I pick this up tomorrow.

I think that A.07 will add analog protection to all 16 AN lines, and I guess I really should have the digi protects for all (used) digital outputs. I'll also create, then move these to the CPU block.

This will cause the top drawing to move around quite a bit, but the general flow should be about the same. Little easier to keep track of stuff the way I'll have it in A.07

[Fred]

I figure that the PCB layout will determine if your list or my list will work nicely. I suspect neither is right, at the moment. I haven't read the firmware yet, and I'm also assuming that you have a software list some where, that maps your code names to ports. So once the PCB layout determines the exact layout, we can simply update this software table and we should be good to go. Is that correct?

No, this is absolutely not correct. Most pins have special functions, for some things this means those pins must perform those duties. At the very least though, if you use PWM pins or CAN pins or SPI pins for GPIO bit bang use you are wasting that functionality and preventing it's use in future. There is some room for shuffling some things around a little, but not much. I've put a lot of time and effort into ensuring the pin outs are correct. I was thinking the same way you are until another member kindly kicked me in the nuts and said "hey, don't do that! here's why..." (Cheers Jean :-) ). They are as they are for good reasons in most cases. There isn't a lot of flexibility. For that reason the PCB will follow the CPU functionality pretty closely if it wants to be useful.

Hmmm, sounds like I should have a couple generic fet drivers. I'd probably aim for the protected fet's because I'll be buying them anyways, and they are rugged. Your right, I don't need the feedback on things like fuel pump relays, or tach outputs.

Cool :-)

Perhaps a layout something like this

http://i324.photobucket.com/albums/k352 ... ut_PCB.gif

Note, the wires don't go to one location. The leave where ever it's handy for them to leave, reducing the number of times things want to cross over each other, and decreasing cross talking.

I hear what you are saying, BUT, I think you will find most people installing this on a real car (this is the project goal) will want the wires to come out in one place, esp those that want to be able to seal the case. I'll be looking for one exit point, at which point my wires will be a birds nest inside the case and there will be much more cross talk etc than otherwise.

If you control the way the "wires" move and interact via the way they are routed on the board then you standardise any issues to all users. This is a good thing as it means everything is predictable and it will be easy to support. If you don't fix the wires to the board as traces on the board then there will be 100000 variations of configuration and 100000000000 more problems from people doing it strange ways.

On the left, you can choose the number of injectors by cutting off the end of the board. I put injectors across the top, and ignition across the bottom. I figure, it's based on a per cyl base, so you can cut off one injector with one ignition.

I don't think that is very practical, do you? It seems to me that most people won't want to butcher their freshly printed board in order to save 1.5cm of in car space. I personally would just leave the locations unpopulated if I didn't need them. I suspect others would do the same.

Normal O2 hangs right around .7v, I'd say up to 1.5 is common.

Normal O2 isn't supported in the software intentionally to ensure that users don't even attempt to use it to tune their cars. It has one purpose and one purpose only and wideband can fulfill that almost as well.

Do I recall wide band can go up to 5V? I think these should also be analog protected, same circuit as the other sensors.

Yes, 0 - 5V and yes, analog protected and yes, same as others more or less.

Probably would be good if we can get one O2 per cyl as well.

2 max for standard setups and only one for this board IMO. Besides, for V12 users there simply are not enough ADC inputs and we don't want special case code everywhere... Lastly, if the flow difference between cylinders is large enough to warrant that, throw the engine away, even the yankee V* lumps aren't that bad :-)

Will the A/D go to 0v, or does it not like the rail.

Yes, 0 - 5V, it *loves* the rail :-)

[*]If you want the sensor isolation useful for all users, you will want to cut power to the sensor as some sensors have the ground at the head/block.

What?

The thermistor switching FETs... if you switch ground you limit to two wire thermistors whereas some are grounded at the block with only the high side wire exposed.

The analog protect uses a larger cap and includes a resistor for a low pass. That might bugger the digi signals a pinch, or we can push that low pass way up.

Exactly, it's nice to have it there on the board to be ignored or populated aggressively or populated conservatively. It will skew the rise and fall times and soften the edges of a square wave and the values need to be chosen intelligently to ensure that it's good at high RPMs. I had caps on my RPM inputs and it buggered it up totally...

The digi protect looks like the analog protect, perhaps you didn't see it, after all I did toss you a curve ball by calling it analog, not digi. There are two, both have 10k resistors to the input, as well as a zener to protect for over voltage, and reverse voltage. I think that is what you are looking for.

There was one of each in A05 that I opened and read. "digi" had a 5.1 zener.

Battery V divide is updated with 10k and 38k.

You mean 39k right? 39k is a standard value.

OK now your just crazy. A good 5V reg, and decoupling caps at the devices should take care of any issues here. I think one 5V reg is all that's needed.

I'm not totally crazy. The logic is to ensure that under a short circuit fault condition on a sensor 5v power feed line the CPU feed remains solid. Another solution would be to fuse the external 5v supply on the board. Can you get blade recepticals for PCB mount? That seems like a good solution to me if we can get values low enough.

The four IGBT locations should have jumperable pins such that for those running external ignitors (AKA me) the to220 locations can be used without jumper wires to run FETs there for other stuff.

Sorry still don't follow, perhaps screen capture, and paint it on the schematic, then send it to me.

I'm hoping the 4 ignition locations can be dual purpose. IE, some people populate with IGBT for ign, others use external ignitors for ign duties and are free to populate with FETs for staged injection or GPIO. To facilitate that I was hoping that traces from both IGN and STAGED cpu pins could be run to these devices and the PCB laid out in such a way that either could work, potentially with jumper configuration. It may be difficult/too much of a pain, but if it's not too hard it would be nice.

I suspect you didn't follow because you didn't realise that the CPU pins are highly specialised and have to be particular pins for certain things.

I think that A.07 will add analog protection to all 16 AN lines, and I guess I really should have the digi protects for all (used) digital outputs.

I doubt you will have space by the time you lay everything else out. If you do and it doesn't impact anything else significantly, great! But I doubt it. It would be nice if all 8 of the first bank were handled though.

Given how easy it is to sandwich a board on top or underneath to expand the capabilities I think it's really important to stay focused and simple for this board.

I can see this thread becoming a long one. Looking forward to A07 :-)

Fred.

[jbelanger]

There are a few things wrong with the LM1815 circuit:

1. Pin 9 is not the output, pin 12 is. Ground pin 9 and 11 and use pin 12 as your RPM input. The 5.6k is a pull up for the LM1815 output.
2. Use a decoupling cap (0.1uf) between pin 8 and ground.
3. You should add a cap after the input 18K resistor for noise reduction. I use 330pF on my board.

Done

Actually, put the 330pF cap at pin 3 not between the resistor and the sensor.

[*]Provide a connection to pin 5 for mode selection. Pin 5 can either be left unconnected, connected to 5V, or connected to ground to select the different modes which can be useful with certain VR sensors.

I think you mean pin 11 input select? Pin 5 shows NC on my datasheet. I added a 10K resistor to 5v and 0R to gnd so that it defaults to hi, but you can switch them to make it default lo.

No I meant pin 5. The example is a bit misleading because it does show pin 5 NC but look at the rest of the data sheet and you'll see that it is actually mode selection. Pins 9, 10 and 11 have a different function and would be used if you had an external signal with a known frequency that you wanted to use as a reference. This is not the case here. So you just want to not connect pin 10, ground pins 9 and 11 and have the possibility to connect pin 5 to either 5V or ground or neither. By the way, you don't need resistors for those connections, you can just have 3 pads (one to pin5, one to 5V, one to ground) and out a jumper in the right place if wanted. This can also be done with a 0.1" pin header and a shunt which has the advantage of allowing a quick reconfiguration if you're testing a new sensor/wheel pattern.

[*]This won't change the board layout but pin 14 can be grounded and the cap and resistor left out. This will generate a square wave output instead of the timed pulse (with a pulse width determined by the RC components).

Hmmm, do we want the option of timed pulse? Should I draw it up as the square wave config, then let people hack it up if they want the pulse?

I think it's better to leave the resistor and cap for a timed pulse and have the choice to just leave out the resistor and put a jumper in place of the cap to use the square wave config. Depending on the teeth configuration, it will be useful to have the timed pulse easily configured. So I wouldn't do anything other than what you have now because grounding pin 14 is simply done with a jumper in place of the cap so both configuration are easily done.

Jean

[jharvey]

Here's freeEMS 1.0 A.07

I've changed the top schematic around a bit, should be easier to follow now, and a bit more consistent.

I've changed the VR per Jean's recommendations, and updated the symbol to include the mode pin.

All power driving outputs are now digi protected, and I've changed the analog protect to a batch of 4 circuits on one schematic. All AN's are analog protected because they are a bit more sensitive.

Next steps include adding footprints to symbols, checking naming conventions for consistence (Vreg vs Vref, ect), and preparing for a netlist. I'm not far from generating the first netlist. Yeah!

Some notes, I don't think the connector at the edge of the board will be feasible, at least not with the planed 2 layer PCB. There are simply to many traces crossing over each other. I've designed 4 layer boards before, and I'd recommend we don't go that route here. It hides much, which can be a bugger to trouble shoot. Perhaps we should have two PCB's that stack on each other. One that connects via pins to the main board and routes the "picked points" to the edge of the board. That way folks like me who want less parts, can run the harness wires directly to the PCB. Those that want a single connector, can still have it while at the same time, they can see a burnt trace if it exists, or hook up a scope to trace noise issues.

I think the blank page in the PDF is un-important. I think it was added by mistake, but I had already deleted the files that create it when I saw it, so there it is.

I figured we should have all AN's analog protected such that we can use them as mini scopes. Solder a little wire to them, then get some feed back.

[Fred]

You have the inj FET hooked up to blow a fuse again :-)

The digi protect circuit :

For output duty we will want a lower resistor value in the order of 1k (I forget the exact value that I calculated was correct). For what reason do we need a zener on a hard wired output pin? It's isolated by the FET device already and current protected by the resistor.

For input duty a resistor needs to be outside the zener, and same applies value wise to the inner one. I'm still not certain that a zener is a good idea. I think the dual standard diode setup will be a better choice for a few reasons, but can anyone tell me that I'm wrong here because I'm mostly just guessing.

On the cpu interface first page you have duplicated the names ind_dr_X for both ign and inj.

One set is 0 - 5 and the other 1 - 6, they should be standardised. I think I would prefer 1 - 6 at this level of abstraction.

Most of the pin rearrangement is good, but you banged inj feedback 5/6 on pj6/pj7 which are A two interrupt pins and B our I2C channel. Best to move them to PE3 PE4 which you have labeled as ECLK and LSTRB on the schem. I'd strongly prefer that the PORTE pins were labeled as such, their original special use meaning is irrelevant to us. They are just more pins and they are port E pins, so let's call them that from the start. (In MS land stuff often exists by two names and it causes no end of headaches)

I've mentioned some other stuff before, so I'll forget about that for now.

Looking good!

Fred.