Gauging Interest: Open-Source/-Hardware Engine Management.

[NorthWet]

BUMP to show additional content in first post.

[crazyhorse001]

In my work as a robotics technician, I deal with DeviceNet technology. This allows a robot cell to control multiple robots, and hundreds of sensors with one (admittedly bulky) PLC (programmable logic controller) I mention this only as ready made alternative, which uses simple cabling, and off the shelf components for most if not all sensors youd need on an engine. Ladder logic programming is easily understood by novices as well.

[NorthWet]

EJ wiring gurus, I would like to know some stuff from your well of experience:

 

(Edit: Post updated based on later responses.  Response count:1)

 

!) Does the engine wiring harness have the same chassis-side connector(s) across different years and engines?  (As in, could we just use one style of chassis-side connector wired to the ECU and connect the existing engine harness into it?)

(96 - 99 ODBII harnesses are the same. Probably 95 ODB1 is the same as those early ODBII: connectors are physically compatible.)

 

2) Are there any important signals for the ECU that do NOT go through the engine harness?

(MAF/MAP, Ignitor, O2. On OBDI harnesses, crank, cam,  knock and vacuum/purge? solenoid.)

 

Edit/New: 2a) Is there an engine related harness that needs to be included?

 

3) For an EJ swap, does using the existing engine harness seem like the right path to take?

(Yes: 1

No: 0)

 

4) Does anyone know a source for the chassis-side connector(s)?  If not, does it seem practical to use/rework the connector on the chassis loom?

(No other source identified.  Donor would be needed.)

 

5) I would like a list of sensors and actuators that an EJ swap will require.

(MAF/MAP, CTS, TPS,  EGO(O2), CrankPS, CamPS, knock.

Ignitor, injector, purge solenoid.)

 

6) Are the injectors individually pulsed, pair-pulsed, or gang-pulsed? (More accurately, are there separate wires for each injector?)

(Individually pulsed through separate wires.)

 

7) What is the tooth count/pattern for the crank position sensor?

 

8) What is the tooth count/pattern for the cam position sensor? 

 

Yes, I can almost certainly look up most of this stuff, but book info is not the same as experience.  And probably no book will give me a decent answer to "1)".  The first 3 questions would be good to know early on, while the later ones are farther-out goals.

 

Any input is appreciated.

Edited June 8, 2013 by NorthWet

[NorthWet]

In my work as a robotics technician, I deal with DeviceNet technology. This allows a robot cell to control multiple robots, and hundreds of sensors with one (admittedly bulky) PLC (programmable logic controller) I mention this only as ready made alternative, which uses simple cabling, and off the shelf components for most if not all sensors youd need on an engine. Ladder logic programming is easily understood by novices as well.

I have never dealt with PLCs, but an unfounded prejudice makes me feel that they would be less field-flexible as well as (perhaps) less capable,  I understand from where such prejudices come, so am willing to consider that PLCs might be a better path.

 

That being said, my "gut feeling" is that capable commodity parts that are available the world-round (a bit of an assumption for someone sitting in one small corner of the world )  supported by a large user/producer/developer community, with open architecture and a cheap price is a more useful way to go. 

 

Currently, I do have a preferred set of parts in mind for myself.  I think it would be hard to beat the availability, the support, the openness and the price.  But, if designed well, it should not matter what is used by an individual, as long as the part provides the needed functionality.

[MR_Loyale]

One could go around all day, "Why not this processor, or that processor?", any of which would have pros and cons.  Projects have gotten stalled due to stuff like this.  The NXT processor might be nice... but it is one among dozens, and it is still just a bare chip.  The time, energy and cost of making a board-level product is not trivial.  Another point is that even a simple low-cost Arduino unit has something like 10 times the capability of the original EA ECUs.

 

Another contender for a processing platform is one I came across yesterday, the WANDBOARD project.  Similar concept to Arduino, newer, so less established, and unclear whether it will become community supported like the Arduino.  A full-on, high-performance management system might make use of this.  If functional modules are designed properly, we should be able to just plug-and-play. 

 

Or instead of a specific processor, a virtual processor P-Code such as is done with JAVA, but with better performance of course. That way the flavor of the month hardware becomes irrelevant as the only thing needed is the P-Code interpreter.

[NorthWet]

Interpreters suck, and big-time in a real-time application:  They are all resource hogs.  It is just the nature of something that, every time it has to process an item, has to read in the verbose instructions, parse them, recognize the platform that it is running upon, and figure out what generic machine-code needs to be executed for that instruction each and every time that instruction is referenced.

 

The processor overhead is somewhere around 2-3 orders of magnitude (100-1000 times) higher than executing native code.  The context switching that is required in an interrupt-driven process (arguably, the best choice for a real-time task like injection/ignition) would likely produce unacceptable latencies.  There are processors available that we could choose that could conceivably handle this, but cost and "commodity-ness" become casualties.

 

(Plus, there is something just philosophically WRONG about having a nice, sleek RISC processor bumble along trying to get overly-complex code to run.    )  

 

It would be far better to write the routines in a compiled language.  And, IMHO, it would be best to write as much as possible in assembler language (and not just because that is the sandbox that I enjoy playing in).  In spite of what some may think, machine code on a RISC processor is relatively simplistic:  There are only 7 basic arithmetic and logic instructions, though most of these MCUs add what used to be routine-based, complex instructions such as multiply and divide.  Throw in a couple move, I/O and branch commands, and that is it.  Everything else is pretty much a variation of those.  If done right, the instructional differences between processors would be less than the architectural  differences (ports, timers, ADCs) between the processors.  There is much that can be done to make Assembler as easy to code and understand as BASIC.  Most changes could be specified in compile-/assemble-time configuration files.

 

What I think it would come down to is that if we used an interpretive language, then the MCU hardware would have to be at the top-end/"bleeding-edge" just to run basic management tasks.  If we used a compiled language, we would likely need a mid-range MCU for basic functionality unless we were careful to avoid floating-point math.

Edited June 8, 2013 by NorthWet

[Numbchux]

EJ wiring gurus, I would like to know some stuff from your well of experience:

 

!) Does the engine wiring harness have the same chassis-side connector(s) across different years and engines?  (As in, could we just use one style of chassis-side connector wired to the ECU and connect the existing engine harness into it?)

 

2) Are there any important signals for the ECU that do NOT go through the engine harness?

 

3) For an EJ swap, does using the existing engine harness seem like the right path to take?

 

4) Does anyone know a source for the chassis-side connector(s)?  If not, does it seem practical to use/rework the connector on the chassis loom?

 

5) I would like a list of sensors and actuators that an EJ swap will require.

 

6) Are the injectors individually pulsed, pair-pulsed, or gang-pulsed? (More accurately, are there separate wires for each injector?)

 

7) What is the tooth count/pattern for the crank position sensor?

 

8) What is the tooth count/pattern for the cam position sensor? 

 

Yes, I can almost certainly look up most of this stuff, but book info is not the same as experience.  And probably no book will give me a decent answer to "1)".  The first 3 questions would be good to know early on, while the later ones are farther-out goals.

 

Any input is appreciated.

 

 

Alright, I'll offer what I can. This project sounds like a nightmare, but more power to you if you can make it work!!

 

There are a lot of electrical changes throughout the whole life of the EJ engine series. But my expertise is primarily '90-99. Some of this will apply to some of the newer stuff, but anything '02+ and factory turbo is going to be a completely different can of worms. I also have no experience with jdm setups.

 

 

1. There were 2 or 3 different combinations for OBD I. I know the early OBD II (96-99) harnesses are all the same. I think 95 is the same on the engine side. I know the later OBD I engine harness will actually plug into the OBD II ones, but I do not know if the pinouts are the same.

 

2. MAF, Ignitor, O2. On OBDI harnesses, crank, cam and knock sensors. on OBD II there is a MAP and vacuum solenoid (I believe it's canister purge, though) on the strut tower that also do not run through the engine.

 

3. IMO, yes

 

4. Only way I know of is used. Donor/junkyard cars.

 

5. I don't quite follow this question. An EJ swap requires what the management it's running off requires. And since this thread is about custom ground-up management, that is dependent on the program/tune within that management

 

6. Individually. Separate signal wires

 

7. Not sure off the top of my head. I know this stuff has been documented on the megasquirt sites. Crank sprocket teeth did not change from 1990 until the PZEV models in the 2000s

 

8. Really no clue. see 7

 

 

 

 

My $.02 on the project. I don't know much about microprocessors and programming. But my main concern about a universal management for "all" EJ swaps, is the tune. I don't think there's any chance to have a base tune that can hold a candle to an OEM tune. You might be able to program some auto-tune features into it, but I think ultimately each application will require a professional tune to get close to OEM performance. This custom-tune will not likely yield almost any extra power.

 

I know the technology in the hardware has improved immensely, but I still find it very unlikely that an open-source low-budget option will have the software quality that Subaru put out.

Edited June 8, 2013 by Numbchux

[NorthWet]

Numbchux, thank you for your response and information.  My questions may sound naive or simplistic (or ignorant ), but the biggest pitfall in something like this is for me to assume that I know everything and what is important.  Your presentation was excellent, especially in the places where you felt my questions were vague, or where you expressed concerns: this type of feedback keeps a project from wandering off course... or shows when the project is simply not feasible.

 

I think grossgary had also mentioned the commonality on the 95-99 EJs, and that may be the best basis from which to start.  The early ones should be relatively minor changes that could be handled as they might appear, and the newer engines may not be as readily available or popular for this kind of change.  Minor differences in the way a sensor works (electrical signal variations) is manageable in the software, and most sensor-type differences (distributor CPS vs crank CPS) can be managed with functional-module selection and wiring differences.

 

Unless I misread your response, my question 5 was answered in your response to question 2.  I may have been sloppy in how I wrote these 2 questions, as for Q2 I was looking for things like VSS1/2 and/or transmission neutral switch that don't originate in the engine harness (or so I assume). I did misread it.  I guess that I need to know if there is an engine-related harness that needs to be included in a retrofit.  I will update my question-post.

 

Most of the technical information I can glean from the FSMs or by checking an engine , especially Q7 and Q8.  (And these would likely be handled by some initialization values in the software.)  But if someone knows this stuff "off the top of their head", that is just one less thing for me to be concerned about.

 

I absolutely agree with you that nothing I/we can initially produce will, as you so aptly put it, "hold a candle to an OEM tune".  They had, and continue to have, resources and time that can't be recreated by any lesser organization.  It would be hubris to think otherwise. 

 

But, we can have different goals and hindrances than did/does Subaru.  My first goal with the EJs is to untether the engine from the chassis.  Second would probably be to allow configuration tweaks to the engine, such as MAP instead of MAF, COP instead of coil-packs.  Engine tune can be addressed along the way.  Our advantages over Subaru include a different price/performance structure than Subaru had when they selected their ECU hardware, and much more leeway in its cost.  We also don't have to chase ever-changing government regulations and the tech needed to meet them.

 

First-cut cannot meet the quality of Subaru's OEM tune.  I accept that as a given.  But we can get close through observation, emulation, and duplication.  Running a prototype system in an auditing/monitoring mode should get an adequate baseline, matching its sensor inputs to what the OEM ECU chooses for Ignition/injection events.  This should give a set of crude but acceptable maps.  The software can be designed so that it can refine these base maps based on the trim that the closed-loop sensors say is needed.  The system can be designed to learn.

 

If I get no further than this point, and at acceptable hardware costs, I would be content.

 

Edit: Another advantage that a private, "Open" approach has is that instead of trying to protect intellectual property and profits, this can be released into the world of the enthusiast where ideas cross-pollinate and expertise can be added.  It might be my idea when started, but it wouldn't be mine to control.

 

!Viva! the information revolution.

Edited June 8, 2013 by NorthWet

[NorthWet]

There are (many) other wiring strategies that could be employed.

 

One that comes to mind is to place a processing module at each, or each logical grouping, of sensor(s)/actuator(s).  The module could attach to the engine-side through a cut-off pigtail from the original harness that is hard-/firm-wired (internal screw-terminal or soldered) into the module.  The module would contain the analog signal/actuation electronics, along with a $2 (USD) microcontroller.  A simple, standardized cable could run back to the control module (or be daisy-chained through the next node closer to the control module).  The node-module's ECU-side cabling only needs to supply power, ground, and 2 or 3 thin wires for communication.

 

Pros: Standarization of the cabling/connectors, control module. node modules and software.  It also offloads and distributes many housekeeping tasks to where they are actually used.  The cabling allows the wiring mods to be mostly repetitive, simple tasks of snipping, insulation stripping, and attaching a couple wires at a time.  (Stereo speaker spring-clip connectors might also work.)  The software-task offloading could allow the real-time-sensitive crank-angle monitoring to run undisturbed on its own node, which could result in major reductions to software complexity on its node and the control module.

 

Cons (so far): Extra cost incurred by node enclosures and the additional MCUs.  Extra effort to prep-attach the pigtails.  Extra time and effort to mount the nodes.

 

This method has a certain aesthetic appeal to me, which makes me question my impartiality about judging it a generally better approach.  (My ego definitely has its manic side.)  On another hand, a properly modular approach to a project like this would make any and all (mostly...) methods workable, mixable and interchangeable.

Edited June 8, 2013 by NorthWet

[Gloyale]

Wow......

 

Call me crazy.....but stripping a donor car harness sounds WAY easier.  And the software is already written pretty darm well.

 

If you want to be able to tune....get an 02+ WRX harness ECU.....those have been hacked more than US goverment by China.

 

Not hating the project......by all means I'd love to see it. Just not what I'll be doing as the software aspect is over my head.

Edited June 9, 2013 by Gloyale

[NorthWet]

Yeah, it does sound a little wacky to go through all this initial effort.  It would be crazy if it were a one-off.  It might be not-so-crazy if the general concept is practical, and lots of functional building blocks become available to help modders with various issues.  For me, even if I got an existing cracked ECU, it still wouldn't have some of the functionality that I want to play with.

 

The software shouldn't be too bad.  If done right, it should be pretty transparent to the hobbyist-user, with their main interaction the setting of values in configuration files.  The control-module platform should be able to program the individual modules via a USB connection with a personal computer on the user-interface side, and a simple connection cable on the target module side.

 

If you chose to do so, you could learn the software side of this.  This stuff really is more mechanical than geek-elite magic.  You only need to be logical and meticulous, traits that I believe you have.

 

To me, this stuff is fun, and far cheaper than Therapy...

[NorthWet]

Quick update:  I've been getting to know an electronics/PC-board design program, CadSoft's "Eagle".  Eagle is available in a free, hobbyist version that allows the creation of relatively simple PC boards to be used for not-for-profit projects.  I think that I have gotten past the steep part of the learning curve, and have even designed my first proto-module:  A crank-and-cam-position sensor interface.  It is about the size of a US dime, and should cost about US$10 to build.  Though currently, it doesn't have its own dedicated processor.  

 

I am still wavering back and forth regarding design philosophy:  Whether to use centralized or distributed processing, or something that is somewhere in between.  My current leaning is to focus on the functional modules and rely on the cheap supply of ready-to-use processing units.

 

BTW, for people interested in wide-band EGOs, Bosch makes a US$10 IC that handles their wide-band sensor.  Bosch even generously gives a reference design/schematic on how to implement the IC. 

[NorthWet]

After some thought, I designed a version of the crank/cam-sensor circuit that utilizes a dedicated MCU for each sensor.  It seems to make sense to do this for the only real-time critical processes.  It should greatly simplify the code; dedicated processes are a good thing.  It took a couple hours to change, and looks to add about US$10 to the module, but should allow the use of a less powerful (cheaper) control MCU unit.

[Twitch de la Brat]

I've read your entire thread, and I'm a total programming n00b at best.

I'm just curious if a centralized processing unit with good power would be better, as in a Raspberry Pi.

They can be had for $25 and are pretty stout little SOC's.

I'd be worried about stability, but their direct interface with USB would make updating the code cake, as well as being able to create and load your own fuel/ignition maps easily.

And I'm sure that processor has enough oomph to run most any low level code you throw at it, even making on-the-fly adjustments.

 

Just a thought.

 

Twitch

[NorthWet]

My general thought is to use a jelly-bean processing unit, such as the Pi.  I have not looked into the Pi too much yet, but am impressed with the community behind the Arduinos. The Arduinos can be gotten for as little as $15, with higher performing versions for not significantly more.

 

Considering the processing power of the original ECUs, almost anything we could use would be fast enough... given we don't use lazy coding practices.

 

I think that the rotational/positional sensing portion has some fairly tight timing requirements, so I am currently thinking that dedicating processors to this makes that task more tightly defined and localized, plus offloads significant "housekeeping" duties from a central unit.  My plan is to use cheap ($2-$3) ATMEL processors here, and they can appear as extensions to a central ATMEL-based Arduino.  (The ATMEL MCUs can be easily reprogrammed/updated by the central unit, which can be reprogrammed/updated via USB from a laptop/desktop computer. (Edit: Or via Bluetooth. According to "The Big Bang Theory", "everything is better with Bluetooth." )

 

Any and all input is appreciated.

Edited June 22, 2013 by NorthWet

[Twitch de la Brat]

The distribution of the processing may speed things up, but that amount of processors may drive cost high faster than expected...

It may be cheaper to just go with one big CPU rather than a small one and a bunch of slave units.

 

Twitch

[NorthWet]

These processors are CHEAP, I mean, really cheap.  And virtually no "support electronics" (resistors, capacitors, etc), just a clean power supply.  And there is a small case to be made that they would be worthwhile as dedicated, single-purpose blocks when dealing with up to...

 

Oh, crap!  I just realized that my calculation for maximum number of pulses-per-second from the crank sensor were actually per minute... I forgot to divide by 60.  May not be nearly as time critical.  Hmmm.  Good that I didn't throw the original design away.

 

Anyway, let me see if I can attach some images of a VRS proto-design...

 

...nope, not my day to post images I guess.  Haven't figured out images on the new BBS software.

 

Edit (06-23-2013): Looks like with a conservative guesstimate (6-cyl, 10kRPM, 20crank-pulses/rev) that a jelly-bean 16MHz processor board would have well over 4000 instruction-cycles between pulses... a near eternity in well-written code.  So, back on track with an interface board on a jelly-bean processor board.  Thanks, Twitch!!!

Edited June 23, 2013 by NorthWet

[Uberoo]

I wouldn't mind something that extended the stock phase 1 ej22 ignition and fuel maps up past 7500 RPM.Having the computer kill the fun at only 6250 RPM sucks..

[NorthWet]

One of the simpler things to do is extend the maps (I personally would prefer to call them tables, since they are just tabular data, rows and columns of data like a multiplication table).  The only constraint is memory, and, within reasonable limits, we would have as much memory as desired.  Certainly far more memory available to play with then the OEM ECU.

 

It would also be near-trivial to set rev-limiting, both soft and hard, and have it dynamically adjustable.

Edited June 23, 2013 by NorthWet

[Twitch de la Brat]

Memory is cheap.

You can buy a 1GB flash drive for a couple bucks, even cheaper if you buy in bulk.

And those original ECU's were making do with a few MB, if that. So memory constraints are nothing. Hell, RAM can be had for dirt cheap as well, so there is little to no memory constraints to be had, whether its active or storage.

 

Twitch

[NorthWet]

The flashdrive is only useful for offline storage:  It is not practical for using it for tables(maps) during program execution. It can be used to hold alternate tables or parameters, but only practical as an update medium.  Flash memory, both in the MCU and on flashdrives, has a finite number of write cycles.

[Twitch de la Brat]

That's what I meant. It could be sourced for initial bootup maps (tables) and possibly for trouble codes, but there would be a RAM bank that the processor would load everything onto for operations

And if your flash drive started getting corrupted, you could just load another one with your mapping/programming and go from there.

 

Twitch

[NorthWet]

There isn't really any practical place to load it to, other than the MCU's flash... which has a finite (around 100,000) write/erase cycles, after which the MCU is pretty much useless.  This is plenty of cycles for its intended usage, but not as a substitute for proper RAM.  The MCUs come with some SRAM, which is intended as scratch-pad memory and is minimal (up to a few Kbytes in cheaper ones, but 100Kbytes or so in more expensive units).  The "Harvard architecture" (program and data paths to memory are separate) of most of these MCUs might also cause complications.

 

I am not saying that this can't be done, just that it is likely not practical except in more expensive (though still reasonable) units. Multiple maps are readily doable, alterable at any humanly initiated time; just not so practical to do it every power-up.

 

Keep it coming... ideas are good, and questioning my preconceived notions is very useful to me.

[Twitch de la Brat]

I guess I'm too used to x86/x64 hardware

Have you looked at VMS as a viable operating system?

 

Twitch

 

PS: I still think it'd be cool to build an x64 powered computer for your car :3

[NorthWet]

Yeah, the low-level MCUs are a different world... including having little use for an operating system as you know it. I guess that one could be used, but it would eat up a lot of resources (particularly program memory) and is typically not needed when you run just one program.  I haven't looked at VMS, and would have to know which "universe" uses this VMS.  (Lots of different platforms use a virtual memory operating system, and there are just so many names to go around. )

 

BTW, I once again put my preconceived foot in my mouth:  100000 cycles could allow 3 updates per day for almost 100 years.  But still, I don't think it best.

 

The reality of an x64 (I assume that you mean an Intel processor) might leave you disappointed.  Adapting it (and the vehicle) to use as an ECU might be more frustrating than you could imagine.  No crime in thinking about it, though.