DIYEFI.org Forum

I know we are very close to the first proto of DFH, however I can't help but be restless. I'm tempted to start the layout for the first add-on board. I know davebmw is planning on some features like knock sensing. So I thought perhaps I could drag some info out of him and perhaps others to start a draft add-on board.

So first things first, what should be included in add-on 1? A look at my TODO list notes the below.

-- crowbar / smart power regulation
-- ignition current sensing

First thoughts about what should be included are below

-- boost control (PWM)
-- IAC control (PWM / Stepper)
-- water inject control (GPIO / PWM)
-- A/C "on" input (for pre-emptive / smoother ride)
-- clutch switch input
-- WOT / TPS closed input
-- more O2 inputs (tune per bank) / wide band
-- EGT (exhaust, gas, temperature)
-- knock sensing
-- multi fuel input (propane, gas, NO2, coolant boost, ADC, flex)
-- map/table selector switch
-- error light / idiot light output
-- temperature probe(s)

Things that should be planned for add-on 2 are

-- ion sensing
-- return PID error path (for generator 60/50 hz sync, ect)
-- disco ball w/ dmx and lasers (for some flash and shine)
-- ???

I think the most important is the knock sensing. Are there any recommended schematics or starting points for knock sensing? Do we want a knock chip, or roll our own?

jharvey wrote:I know we are very close to the first proto of freeEMS_1.0, however I can't help but be restless.

I'm not sure we're as close as you think, but anyway...

-- crowbar over voltage protect

How do you intend to do this through the tiny dil 50 sockets? This needs to go wherever the powersupply is if at all. We had massive discussions about just that and in the end decided the issues outweigh the benefits. How has it cropped back up? The place for such a device is inline with the EMS in a box of it's own. It doesn't need or want to be in the case for any reason I can think of unless it's integrated into the main power inlet.

-- ignition current sensing

Again, the ignition drivers will usually be on the other board, how do you plan to route this? Or is it some funky off to the side sensor you are talking about? We really don't have the spare CPU to act like a scope and binary data on that is not overly useful. See comment on ion sensing.

First thoughts about what should be included are below

-- boost control
-- IAC control
-- water inject control
-- A/C "on" input
-- more O2 inputs (tune per cyl - only useful on naturally aspirated cars which rarely if ever need it. This is usually done with EGT if at all.) / wide band
-- EGT (exhaust, gas, ?) - ? = temperature
-- knock sensing
-- multi fuel input
-- map/table selector switch
-- error light / idiot light output

These all seem reasonable.

-- ion sensing

Umm, the add on will need a powerful cpu all of its own for that.

-- return PID error path (for generator 60/50 hz sync, ect)

ey? lol

I think the most important is the knock sensing. Are there any recommended schematics or starting points for knock sensing? Do we want a knock chip, or roll our own?

This is something that is very tightly integrated into the core logic and is AGAIN a software comes first thing. We need to plan an approach, confirm that it is plausible with the resources we have and THEN think about specific hardware for it.

You may be jumping the gun a bit here. I'd expect most of those features to START development 6 months out, maybe more. We are still at least a month from running an engine at all. After that there is a lot of work to do to make it more generally useful than just the toyota out the front.

I'm not trying to be negative about it, I just don't want to put the impression out there that any of these things will be available any time soon. Putting expectations in peoples minds will lead to disappointment and drive them away when they may otherwise have been keen to hang around.

There is certainly no harm in discussing the future, but it needs to be clear that it is the future, not the present.

Fred.

Fred wrote:

-- crowbar over voltage protect

How do you intend to do this through the tiny dil 50 sockets? This needs to go wherever the powersupply is if at all. We had massive discussions about just that and in the end decided the issues outweigh the benefits. How has it cropped back up? The place for such a device is inline with the EMS in a box of it's own. It doesn't need or want to be in the case for any reason I can think of unless it's integrated into the main power inlet.

Perhaps it doesn't need to be in the list, I seem to recall it wasn't required for the first board and was pushed off the first board. I would think power would come in the connector board, with a big fat wire, then up to the add-on2, with a fat wire, then smaller wire to add-on1, then to the TA card. However, that's what's up for discussion.

-- ignition current sensing

Again, the ignition drivers will usually be on the other board, how do you plan to route this? Or is it some funky off to the side sensor you are talking about? We really don't have the spare CPU to act like a scope and binary data on that is not overly useful. See comment on ion sensing.

I seem to recall it required a resistor, likely off board, that produced a signal, then on board would be some protection, I think it was basically the digi-protect. The input would be a digi in.

-- ion sensing

Umm, the add on will need a powerful cpu all of its own for that.

Hadn't thought much about external CPU's. I like the idea.

I think the most important is the knock sensing. Are there any recommended schematics or starting points for knock sensing? Do we want a knock chip, or roll our own?

This is something that is very tightly integrated into the core logic and is AGAIN a software comes first thing. We need to plan an approach, confirm that it is plausible with the resources we have and THEN think about specific hardware for it.

Agreed, resource available is important. I'm not a huge help with the soft side, however, I can offer hardware resources. So that's what I figured I'd try to help and offer. I also hope the sofware folks don't spend much time with this thread. Keep it up on the softer sided of EMS.

I'm not trying to be negative about it, I just don't want to put the impression out there that any of these things will be available any time soon. Putting expectations in peoples minds will lead to disappointment and drive them away when they may otherwise have been keen to hang around.

Also agreed. I don't see much harm in creating schematics, then after the 1.0 board is better backed by soft, we can start thinking of making the schematic into a board.

There is certainly no harm in discussing the future, but it needs to be clear that it is the future, not the present.

Remember, the future is now... no now... no now.

Yup it's pre-alpha / pre-planning stages. Very young. Just figuring those of us that are a bit more hardware oriented, could start a draft.

Just a thought:
Is it anticipated that the pinout allocation of the core module/processor will be global & fixed, rather than varied depending on add-on boards? I strongly hope (& expect) it's the former. Is a procedure required for this, or does it need ownership, or 'not just yet!'?

I also vote that EGT & knock sense would be very nice to see. I think EGT would require thermocouple inputs, which are quite interesting to design properly.

EdG wrote:Is it anticipated that the pinout allocation of the core module/processor will be global & fixed ... ?

Yes, that is what I am trying to achieve for the core items. For other items I believe the best approach is more or less total flexibility, however that will take significant effort to produce in terms of a HAL. I'll be nailing out a semi final version of the pin out pretty soon and maybe some sort of hardware compatibility document to go with it.

Fred.

jharvey wrote:
-- crowbar over voltage protect:
Ooooh no! thats a bit brute force IMO why not make the power supply a little intelligent and get it to auto shut down when a maximum threshold is reached, the regulators I am using have shutdown pins. it would be a simple matter to arrange an op amp to monitor the supply voltage.
-- ignition current sensing
This is used on my BMW to give the ECU a feedback signal which tells it that there has been a successful fire on a plug and as the plugs get fouled the ECU can compensate by increasing the dwell and burning the shite of the plugs electrodes. the signal is also monitored by the ODB system and logs repeated misfires, which lights the "check Engine" light on the dash.


-- boost control
Requires a PWM channel does it not?? have we any spare at the moment?? but i would say it would be a very popular feature after all MS2 has it!
-- IAC control
Same as above and I would say a must!
-- water inject control
That should be easy as it is just a digital on or off
-- A/C "on" input
software controlled closed loop idle control will take care of that
-- more O2 inputs (tune per cyl) / wide band
you should only need a maximum of 2 WBO2 sensors you could calculate the mixture per cylinder based on RPM and MAP in software
-- EGT (exhaust, gas, temperature)
I thought long and hard about this and to get the microvolt signals back to the ECU would be challenging to say the least, so a remotely sited thermocouple interface feeding back digital/PWM signals back to the ECU for interpretation would be one way of doing it
-- knock sensing
I vote roll our own using op amps and use some logic to create a window based upon ignition events
-- multi fuel input
I like the idea of propane as a second supply of fuel and coolant under boost
-- map/table selector switch
Also like the idea of an MOT test setting an all out power setting and i'm driving to work and want MPG setting
-- error light / idiot light output
Hmmm? maybe a "Head Gasket Destruction imminent" light could be handy

Things that should be planned for add-on 2 are

-- ion sensing
if you have really good knock sensing why would you need ion sensing?
-- return PID error path (for generator 60/50 hz sync, ect)
wtf
-- disco ball and lasers, for some flash and shine
see if the software guys can write a DMX interface
-- ???
I still maintain a passive mode facility to monitor and map the FreeEMS based upon the existing ECU's signals would be a great selling point. this would be something no other aftermarket does, it would allow noobs to take up the project and get it running easily and stop complete R' tards like me blowing head gaskets!

I think the most important is the knock sensing. Are there any recommended schematics or starting points for knock sensing? Do we want a knock chip, or roll our own?

Agreed knock sensing is easily done with an Op amp and a 555 as a monostable use pin 4 reset to be gated by ignition events and hey presto you have an output based upon actual knock. trouble is the humble 555 chip is not exactly automotive grade. but it will work. i am building such a circuit for my MS2 to see how well it performs. a PIC based circuit for the final roll up would be much better.

davebmw wrote:-- boost control
Requires a PWM channel does it not?? have we any spare at the moment?? but i would say it would be a very popular feature after all MS2 has it!

All of them :-) 8 8 bit or 4 16 bit or some combo of the two types. If we have any spare room for a couple more fets on the main pcb, this is definitely where they should be hooked up.

-- IAC control
Same as above and I would say a must!

Agreed, same as above with regards my spare room comment too. PWM only by default, stepper control should definitely be an option.

-- water inject control
That should be easy as it is just a digital on or off

It can be on/off, or it can be full pwm with the fuel channels. In the latter case it could use or piggy back the staged outputs.

-- A/C "on" input
software controlled closed loop idle control will take care of that

Agreed, BUT, a clutch switch or tps closed or open switch or both could be nice for various features. Still, digital in = small footprint.

-- more O2 inputs (tune per cyl) / wide band
you should only need a maximum of 2 WBO2 sensors you could calculate the mixture per cylinder based on RPM and MAP in software

Please explain how? I'm unaware of this technique.

-- EGT (exhaust, gas, temperature)
I thought long and hard about this and to get the microvolt signals back to the ECU would be challenging to say the least, so a remotely sited thermocouple interface feeding back digital/PWM signals back to the ECU for interpretation would be one way of doing it

That member that abandoned use called Alex linked a nice little CAN chip that could do this sort of thing a while back. A good search should find it.

-- knock sensing
I vote roll our own using op amps and use some logic to create a window based upon ignition events

I'd also like to see at least rough windowing. However for variable sensitivity it needs an ADC which would simplify the software, but would mean a complexish hardware implementation. We should discuss this in detail, decide on a game plan, and assign some hardware channels to it for good.

-- multi fuel input
I like the idea of propane as a second supply of fuel and coolant under boost

ADC based for flex fuel is the normal approach, otherwise its just table switching which I already have logic for. Just need to wire up a pin :-)

Also like the idea of an MOT test setting an all out power setting and i'm driving to work and want MPG setting

Noob ;-) One tune to rule them all! econ + power are one tune. emissions can be separate depending on your testing requirements and conscience ;-) One tune is usually enough for all three though. If you are at WOT you want it richish and with the correct advance. Always. When you are cruising you want it leanish and advanced to hell. Always. etc.

-- error light / idiot light output
Hmmm? maybe a "Head Gasket Destruction imminent" light could be handy :lol2:

I'm undecided on that one. I wouldn't mind a single diagnostics pin like that. I'm not sure it's worth the effort though.

-- ion sensing
if you have really good knock sensing why would you need ion sensing?

Because really good knock sensing is a bit of a dream and everyone likes to experiment. Ion sensing enables you to tune for power, not just prevent detonation. You can know the pressure curve in the cylinder and shape it with your tune for best effect. It's pretty cool, but like other cool things, advanced, difficult and expensive :-)

I still maintain a passive mode facility to monitor and map the FreeEMS based upon the existing ECU's signals would be a great selling point. this would be something no other aftermarket does, it would allow noobs to take up the project and get it running easily and stop complete R' tards like me blowing head gaskets!

That would be a separate firmware if ever done. I may do something basic like this for my attempt on the carina, but I may just go in boots and all and try to run it :-)

Agreed knock sensing is easily done with an Op amp and a 555 as a monostable use pin 4 reset to be gated by ignition events and hey presto you have an output based upon actual knock. trouble is the humble 555 chip is not exactly automotive grade. but it will work. i am building such a circuit for my MS2 to see how well it performs. a PIC based circuit for the final roll up would be much better.

Start a thread talking about knock if you like, or pick up an old one already on that topic.

Fred.

Maybe I'm not getting the concept of the "add-on" correct in my head but I'd think a couple of those things are absolutely mandatory (IAC comes to mind).

I updated the top post. I was putting in the [Edit] things, but that got reall messy, so I've simply updated it. I'll likely move it to a wiki so we can have the history thing.

Some notes,

-- davebmw, do you think the ignition sensing is easy to implement? I would wager it will be a while before software implements it, perhaps it might be better off in add-on2, not add-on1? Sounded quite simple to me, but I might be off on that.

-- about "Hmmm? maybe a "Head Gasket Destruction imminent" light could be handy" that's easy, just wire it to +V.

--

-- return PID error path (for generator 60/50 hz sync, ect)
wtf

We seem to focus on variable frequency motors, I suspect fixed frequency motors is a place many would like to experiment with. If we allow some form of feed back, at a very small hardware cost, we may see some inovative ideas.

-- I like the DMX idea. I already have some C that could do it... So I added it to the list.

-- About knock, yes perhaps we should discuss in a seperate thread. I like knock as well as variable sensitivity. Do we have a knock sensor(s) to use as a base input signal? Lets talk about that else where.

BenFenner wrote:Maybe I'm not getting the concept of the "add-on" correct in my head but I'd think a couple of those things are absolutely mandatory (IAC comes to mind).

I agree that it would be nice to have PWM idle and boost control on the main board. Space could be an issue though. We'll have to distill down the schematic a bit and see if we can find some extra space. Once i have the pin docs done we can make some progress on hardware again.

In my mind PWM idle, boost control and knock are pretty important. Knock is a safety net though. Many engines don't have boost control. Engines idle just fine with wax stat warm up modes etc.

So none are mandatory.

I think the compromise required is to have jumpers for some of the FET IO channels to more than one cpu pin such that if you have a 4 pot you have those features and if you have a 6 pot you don't.

We'll see :-)

Fred.