Fred's FreeEMS themed GRMC 2017 + QA

VWguyBruce said:

Thanks for starting the thread Fred. We talked at the pool Saturday night.  Our gang of misfits have already been discussing FreeEMS since then. We'll be in touch. 

I talked to at least 4 guys and 1 gal by the pool that night. Or more on the other side of the pool. Photos are the only way to roll :-D PM/email if shy :-)

Apologies for so many sequential posts; I couldn't find a way to multi-quote and make one big one.

Off topic, I have 5 Volvos now (the disease spread!), which deserve only the best, and am really looking forward to getting FreeEMS onto them ASAP :-) *cough* B234F+T *cough* ;-)

FreeEMSFred said:

alfadriver said:

What I'm interested in is WB O2 sensor direct support.  I've seen some DIY plans for UEGO circuitry, which should be capable of integrating into anyone's system. 

For this one, I should take a look at the calibration guides and the code.  See how the air charge is calculated- they go from a engine speed-map to pulse width table to fully calculating the amount of air going into the cylinder and matching that with a calcualted fuel flow.  And everything in between.

I'm personally not a fan of including wideband controller(s) into an engine controller design for a few reasons:

1. Separation of concerns, why build in obsolesence by way of a controller that supports X sensor if you may want to change in future, eg to LSU4.9
2. Electrical noise. Heater elements are high current and necessarily PWM switched which generates noise. It can be minimised, but not eliminated.
3. Bulk/heat/displacement of other features. Real estate is at a premium inside an ECU, it feels to me like a bad waste to put widebands in there, too.

FreeEMS uses a physical model with everything split out. Everything is calculated from SI units internally and as a result the math makes sense (at least to someone with university physics papers under their belt!) :-) This was one of my motivators, the "ReqFuel" concept (as used by more than one competing project) is just too weak and primitive and breaks parameterisation in many ways.

Your obsolecense concern is valid, except if you wait until there is a stable platform, you'll never get one.  Especially since there are many common ones out there.  The control of them don't really change much, but the heater control is tweaked.  So use a daughter board for it, then.

Not sure what the issue with the noise would be- it's not as if that's an unsolved problem.

I guess you buy a kit, and use it, then.  At least you can control the power to the WB kits.

And I'll have to find a way to check the code out.  Just to see what version of the calculation you use- there are a lot of them.  And how you use the side calculations as well- there are a lot of those, too.

My preference is 14point7 products, fast, accurate, and the founder/CEO/designer is a good straight up character who does the right thing. But mainly fast and accurate. I've only been tempted by AEM's newer stuff aside from that, but the promise of marginal gains combined with 3 or 4 times the price = no.

Re noise, it's an unsolvable problem in certain respects. Most things can be filtered, but that's not true of crank/cam inputs. And filtering TPS or MAP can hurt responsiveness. Even with everything done right inside the box, the coupling by way of parallel wiring runs can ruin everything quite easily.

I switch widebands on based on RPM with a hysteresis such that there is no chance of a cracked ceramic from exhaust-born liquid water. It's the only right way to do it, so there is some integration required (by way of a relay) between ECU and wideband(s).

There's only one version of ideal gas law :-) The implementation is true to that. Not sure what you mean by "side calculations", presumably some corrections? If so, some of that code isn't published right now, but it was on the Miata-truck, and is on my cars, and several others.

In reply to FreeEMSFred :

Given that WB sensors have been in production for well over a decade, I'm not sure why you would consider it an unsolvable problem.  The crank and cam noise issues were solved decades ago- the ignition noise is the worst one on that.  Last I checked, twisted and shielded pairs.

As for the WB turn on, engine speed alone isn't a great indicator of droplets in the exhaust.  A decent exhaust temp model is better- just using start temp, time since start, load, and some time constants, it's a great model.  But many modern WB systems are actually robust to drops, anyway.  For typical 70F/20C starts, one only needs to wait a few seconds before the heater is turned on.

I know there's only one ideal gas law.  But engines don't act in an ideal manner, so you have to compensate for that.  And at what point do you go from the intake measurement to the desired pulse width?  MAP, Load, modeled air mass in the cylinder, etc.  Do you have a calculation to compensate for the lack of ideal gas or a table look up?  And that air estimate- do you use that for spark timing, and what form does it take?  That form can be used for more than a few things.  I'm assuming that it's speed-density as the core calculation.

Still- is there a list of computers this works with?

Just something that I'm interested in.  

Noise on your crank/cam inputs is unsolvable. There needs to be none, or close to none, such that timings can be read accurately and without excess latency. The only solutions to it are to prevent it in the first place with routing and placement and connections and suppressors and softeners, etc. Nothing to do with widebands whatsoever, nor their production date range. Everything to do with noise sources such as your cited ignition source, my cited sensor heater PWM source, and various other sources including but not limited to fans, relays, and injectors. What's solvable is how to prevent them in the first place, and how to mitigate them as much as you can at the destination input. If they're on that input, though, you're screwed.

Disagree re wideband turn on. By the time the engine has reached some sub-idle RPM (IIRC mine is 700) there has been a lot of strong wind and a lot of flame-grilled heat passing through the wideband sensor and any moisture short of vapour is long gone. With hysteresis the wideband will stay on until the engine is stalled (sub cranking, IIRC mine is 200), if configured as such. Leaving it unpowered longer than the bare minimum is not good for sensor life, and thus unacceptable.

I'm completely unsure what you mean by "WB systems are robust to water drops" - the system isn't important, just the sensor itself, and they're inherently *not* robust to it, through their fundamental design/structure. LSU 4.9 is actually worse than the older LSU 4.2 in this respect, but through the same changes, it's a faster sensor.

It's not called a law for nothing! :-D Engines obey it, as do your lungs :-) What's tricky is getting accurate and timely sensor readings that reflect the reality of the engine closely. Some of those deficiencies require special code (eg warm up, starting, transient behaviour) and others end up implicit in the VE table (sensor and calibration issues, for eg). An engine with well designed hardware surrounding it and accurate sensors and solenoids and regulators and so forth with correct and accurate calibration data, is a joy  to tune. Trivial, in fact. On the flip side, a poorly setup engine (eg ITBs with insufficient or no balance manifold), or one with incorrect calibration data (temperature, pressure, injectors, coils, etc) can be an outright pain. As for tables and so forth, multiple algorithms are included, your choice of load for timing lookups. My crappy old "hotel hyundai" has almost two full tunes, one SD, one AN. I can drive on either, but for some reason I couldn't get it starting on AN in the 2 minutes I spent trying before giving up. The FSAE CBR600RR had AN to 2k and SD from 3k and a blend between that, or something like that. I've not bothered doing any MAF code yet as no one in the performance scene likes to use it. Hopefully that answers your strangely worded questions :-)

The last question about computers, though, I do not understand at all. Can you be more specific/explicit and reword that one for me, please?

Also, this is all a bit heavy and deep and techy for what I hoped would be a fun thread about GRM hacked car humour and various related media such as the sweet little van :-D The QA I was expecting was along the lines of "can you run a <insert marque> <insert engine code> engine properly? If anyone's curious about that for their particular application, sing out! :-)

I hope to get my fancy-camera pics off the memory card one of these days and get some cool photos uploaded for everyone to enjoy. I'll post them here when I do :-)

In reply to FreeEMSFred :

What I'm pointing out his how OEM's solve those problems.  I've been dealing with WB sensors, and cracking them for over 10 years. 

The heaters are turned on based on an exhaust temp model.  You may not agree with that, but millions of cars on the road demonstrates it's a pretty good way of doing it.  Once they are on, WB systems control the heaters just fine- no need to turn them off.  I'm sure we leave them on during a start-stop event.  Again, they work in the field for over 150k miles, as required.  They are not heated at full blast all the time- the temperature controller is a key element in their ability to span a wide range of a/f.

And there really are sensors out there that are robust to drops.  That's not a proposition, that's stuff in production.  To the point that it's not going to be long before cars will be in production with the sensors running and providing feeback before the engine starts.  That is going to happen.

Ok, so you deal with the non-ideal nature of engine breathing using VE tables.  That's what I'm curious about.  With fixed cams, you can also write a decent set of equations that calculate the changing breathing nature of an engine.  And with the calculation, you get a "load" output that is a good representation of the actual charge amount in the cylinder- which is a better way of determining the spark timing.  If you are using just MAP for spark, correcting that with the VE tables is more accurate.

What's hard about the computer question?  Kinda hard to use the system unless you have a working ECU.  What ECU's work with it?  I'm not a computer engineer, so I'm not going to design my own.  So what computers operate with this?   It's a much, much more important question than will the system work with X powertrain or not.  As long as the engine is simple enough, it does not matter who makes it.  All you are controlling is spark and fuel, with some kind of air input.  Anything with fixed cams, a real manifold, and PFI can be run on virtually any aftermarket controller.  It's only when VCT, ETC, and DI are added that aftermarket control capability gets really stretched.

As for the deep and heavy nature of the questions- sorry, but I'm a calibrator with Ford (as everyone here knows), and I'm interested in the controller.  Should we start another thread, or should I just go away?  Sorry that I'm not making funny banter posts, but actual technical ones.

Maybe a silly question. Why can't we just take something super ubiquitous, like say a Toyota Camry ecu, and load the free ems software on to it?

Robbie said:

Maybe a silly question. Why can't we just take something super ubiquitous, like say a Toyota Camry ecu, and load the free ems software on to it?

 

It would require modification to either or both to work and yield an inferior solution to picking up a CoolEFI basic that is specifically designed to run FreeEMS. At the moment the owner of CoolEFI is the only hardware developer that is producing a complete ecu ready to run FreeEMS. There have been others in the past, but such is the nature of small, free projects with small prospects for generating revenue.  

IMO the current state of the project is working towards perfecting the core functions of the firmware. Extending capabilities comes after that- but a WB controller is definitely beyond the scope of this project now. The more people involved in the project, the better the firmware and hardware becomes. The CoolEFI basic makes participation as user/tester affordable and simple IF somebody wanted to get involved. 

In reply to FE3tMX5 :

Seems like the only reason an OEM ECU would be inferior is that it can't run FreeEMS.  Otherwise, the ECU is quite a bit superior to any aftermarket module out on the market.  They have inputs and drivers that aftermarket systems don't have, let alone a whole set of robustness development.

So working on a major chip replacement would net a better system.

For you- sure, Ok. For me- I don't know of any options with an OEM ECU that allow me to participate in an open source engine management project, gives me a tuneable engine management system in my Mazda using the stock sensors/triggers OR those of my choice, and does it for $150 as a wire-in-ready ECU. 

Robbie said:

Maybe a silly question. Why can't we just take something super ubiquitous, like say a Toyota Camry ecu, and load the free ems software on to it?

Embedded code only runs on the platform(s) for which it's designed. In the unlikely event that you found a piece of hardware that could run FreeEMS at all, there's a high probability that the CPU would be configured incorrectly and the pinouts would be wrong, and the input or output circuitry for the pins would be wrong, etc. So no, FreeEMS firmware only runs on hardware specifically designed for FreeEMS use, and no other hardware. Hopefully this answers alfadriver's computer question too. I think the confusion may have stemmed from this post:

FE3tMX5 said:

FreeEMS is the software/firmware that runs on the hardware you buy/build. There's a hardware section on the DIYEFI forum specific to FreeEMS, but I'm sure Fred will revisit this thread. He's on his way to CA now, then back home to NZ.

Good post, but let me clarify: The intent was always to have a well designed firmware with a good architecture at the core of the project. Around that was supposed to be many hardware designs and many diverse pieces of software to interact with the firmware. On the hardware front, for example, you might want something 4-cylinder specific to minimise cost, weight, size, complexity. Or you might want something more fully built out with dual drive by wire, a stack of IO, and enough injector/ignition drivers for a V12 with dual fuel rails. Or something smaller and simpler for a single cylinder lawnmower.  Or anything in between, such as PNP solutions for various cars. Off the top of my head I can think of at least 6 distinct designs from 4 distinct designers, but only one is currently available commercially. Software wise there's been at least 4 different tuners, 3 different log viewers, and 4 different firmware loaders. All of various up-to-date-ness and quality levels. Some good. Some broken/old. I'd say my vision has been somewhat fulfilled by reality at this point. What's needed is to up the quality of each part of the package and *then* promote it more widely. I posted here because the aim of the game here is CHEAP and it's hard to beat for that purpose :-)

alfadriver said:

What I'm pointing out his how OEM's solve those problems.  I've been dealing with WB sensors, and cracking them for over 10 years.

Sounds like OEMs and I solve them the same way. I've been dealing with WB sensors and *not* cracking them for over 10 years. The second sentence, of both this paragraph, and yours, was not necessary.

alfadriver said:

The heaters are turned on based on an exhaust temp model.  You may not agree with that, but millions of cars on the road demonstrates it's a pretty good way of doing it.  Once they are on, WB systems control the heaters just fine- no need to turn them off.  I'm sure we leave them on during a start-stop event.  Again, they work in the field for over 150k miles, as required.  They are not heated at full blast all the time- the temperature controller is a key element in their ability to span a wide range of a/f.

What you're trying to model, and what they're probably actually modeling, and what I'm successfully modeling, is probability of exhaust borne liquid water. That's what my simple model provides, and it works most excellently indeed on my setups. If your WB sensor was on the lower side of the exhaust tip you'd need to wait significantly longer, but that's not a realistic placement anyway. Yes, something that simple is a model. A model is anything that approximates the reality you're trying to match. If you have access to OEM models/algorithms for wideband control, I'd be interested to see them on the table, though I suppose that would be guarded private IP and not for sharing. No bother, I already know what I'm doing :-)

I'm going to have to correct you on the way it works, though. Those ECUs are not going to "turn the heater on" at all. They're turning on control to the sensor, which through its very function ramps up the heater from 0% (off) to N% (on, assuming N != 0). This might be done through simple PID control, or something more bespoke and performant. It might include ramp rate limiting to avoid thermal shock from the heater (as opposed to exhaust borne water). And it will probably output some form of status to imply that it's not ready to produce a reliable reading until the heater is within range.

And there really are sensors out there that are robust to drops.  That's not a proposition, that's stuff in production.  To the point that it's not going to be long before cars will be in production with the sensors running and providing feeback before the engine starts.  That is going to happen.

Did you mean drops or drops? I read it as let go and fall type drop, not water droplets type drops. We weren't talking about the former, and all of the sensors have various protections to help break up and slow and stop the water from hitting the ceramic element, but if enough hits it, it's done for. There's also zero value in measuring stale exhaust gas in a pipe that has been difusing with air out through the exit point for some period of time.

Ok, so you deal with the non-ideal nature of engine breathing using VE tables.  That's what I'm curious about.  With fixed cams, you can also write a decent set of equations that calculate the changing breathing nature of an engine.  And with the calculation, you get a "load" output that is a good representation of the actual charge amount in the cylinder- which is a better way of determining the spark timing.  If you are using just MAP for spark, correcting that with the VE tables is more accurate.

No, VE tables are part of the Speed Density approach, there are multiple approaches available. VE in speed density doesn't deal with non ideal ideal gas law behaviour, it deals with, as you've now said, non-ideal head/manifold breathing behaviour by parameterising it in a useful way.

As for "better" for determining spark timing. You don't calculate spark timing, you empirically define it from others experience, or your own measurements via your ears or equipment better at listening to resonances in the cylinder than your ears. The only thing you need is a reliable way of mapping a particular desired/required/entered/specified timing value to a certain corresponding set of in-cylinder conditions. Many axis styles provide this ability just fine, depending on the state of the engine (ITBs, hot cams, single plenum, turbo, super charged, etc). MAP is good for some, TPS for others, and yes, you can stick a calculated cylinder fill value in there, too. There's something to be said for intuitive interfaces for tuners, though. If they don't understand the tables they're messing with, how can they do a good job of manipulating the values in them? Simple > optimal, sometimes.

What's hard about the computer question?

Just that it wasn't understandable at all in the original form. Your clarification helped. Robbie's question helped. And I had a "shower moment" this morning re FE3tMX5's post being potentially confusing, so I hope my clarification answers your question aptly.

As for the deep and heavy nature of the questions- sorry, but I'm a calibrator with Ford (as everyone here knows), and I'm interested in the controller.  Should we start another thread, or should I just go away?  Sorry that I'm not making funny banter posts, but actual technical ones.

Thanks for the introduction! :-D It doesn't change anything. Once again, I know what I'm doing :-) You can do as you please, but a couple of things:

1. You're dominating the thread with strange tech bi-logues, others may want to get 2c in.
2. I've not had a chance to upload the rest of my media yet, and it's going to end up on page 30 at this rate, lol.
3. As of next week I'll have a lot less time to reply over here, and will spend my time as I see max benefit from it, as such I may ignore posts that are trying to split hairs on the likes of control algorithms and wideband water resistance (like a fake casio watch).

Gasp. Hopefully this post goes through OK! Copy before submit, fingers crossed.

And in a smaller post, I was motivated to update my garage on here: https://grassrootsmotorsports.com/reader-rides/garage/FreeEMSFred/

I added all 13 current rides. No pictures, yet, but requests welcome.

And to those who think they must be rusty wrecks in the back yard: Best I've done so far is drive 9 in one day. Another day I drove 8 and towed both of my trailers (which I didn't add to the garage, yet). And another day I drove a slightly different 8. Both 8s were fully street legal, but the 9 included one car without safety inspection or registration.

I'll try to get to my GF1 pics up at some point in the nex t week or so :-)

In reply to FreeEMSFred :

Ok, so you know better.  Glad to hear you are open to input.

Thanks for saving a lot of time for me.

Have fun.

In reply to FreeEMSFred :

In for more pix!!

Sorry Steve! All I've got for you at this point is some SoCal and pre-trip pics:

SoCal:

VW TDi swapped 1992 Volvo 240 wagon and sometimes-FreeEMS-powered B18C style classic mini:

Stuff I brought home to NZ:

Mint RHD Volvo 240 headlights/corner lights, various tools/safety gear, mucho Volvo engine components:

Stuff I took to the USA for my hosts:

About $250nz/52lb/1bag of kiwi foods/snacks/drinks like chocolate, chips, "candy", etc.

That's all I've got for now, sorry! :-D

Hopefully some of the shiny things strike up some conversation? Looking forward to the sleeper 740 sedan:

Cheers!

FreeEMSFred said:

The QA I was expecting was along the lines of "can you run a <insert marque> <insert engine code> engine properly? If anyone's curious about that for their particular application, sing out! :-)

ok can I run a Chrysler 2.4 (stratus/srt4) using the factory cam/crank sensors and the factory coil pack?

If that's the same as the dodge neon series of engines, then probably already yes. If not, I can probably write a new decoder for it. I wrote the neon one from the other side of the world with a helpful chap up in Maine giving me data from his engine to base my work on. It worked first time and we refined it from there :-)

See caveat about not doing it unless you need it (I'm assuming boost is your goal?).

This is the guy, it's running now, but he's not updated the thread: https://grassrootsmotorsports.com/forum/build-projects-and-project-cars/1998-dodge-neon-challenge-car/132999/page1/

In reply to FreeEMSFred :

Boosted application and motor is swapped into an older chassis.  I have other solutions but I am wanting a standalone.  MS is my first choice but I am open to other options, especially if it is something that would make for good web/video content.

Cool. So is that thing I linked the same or similar? The one I developed against has cutouts in the counter weights that are read by the crank sensor, and some cam signal that corroborates that in a certain way. And there are possibly a couple of variants of the code needed for front/rear intake and/or 8/16 valve. Which is yours? Link to thread?

In reply to FreeEMSFred :

https://grassrootsmotorsports.com/forum/build-projects-and-project-cars/the-most-interesting-89-caravan-in-the-world/55425/page1/

Engine is a combo of 98 stratus 2.4 and 95 eclipse 2.0 DOHC so it should be the same as a dohc neon.

Sweet project! My big project is doing similar things to an 88 B2000 mini truck:

Where are you based? I saw various place names but didn't settle on your current location. Just wondering how close/far you are to/from boostedcabbage and his neon challenge car project. Come to think of it, maybe he's not in Maine, <checks map>, yeah, he's in Massachusetts, somewhere central, IIRC.

Anyway, we can definitely get it running, even if it takes a little bit of trans-pacific collaboration :-)

Here's his fastest drag pass in his other non-challenge Neon: https://youtu.be/0-J8zTrgWn8