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.

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.

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.

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.

In a separate thread, I have requested some EJ- swap wiring information from those that are intimately familiar with the engine wiring harness. This is information that I mostly could glean from the FSMs and looking at my early EJs... BUT, it is not as likely to be as accurate and compleate as information provided by the experienced. Please stop by and offer what you know. Open ECU post #28 Cheers! Pat

Everybody has a right to be skeptical. Skeptics are far more useful than wide-eyed zealots. Only a very few members have ever met me, and only a couple have spent much time with me... and that was mostly just talking cars. Add a couple years of my undiagnosed migraines making me appear flaky (really messed with my memory, with hilarity ensuing ) and you get a lot more reason to sit back with some popcorn and watch the train-wreck. When it comes to programming I have a huge ego, and that is both a gift and a curse. I have to let the ego out to do great things, but I also have to keep it reigned in to keep from alienating those with whom I am working (who also tended to have big egos). Question everything, assume nothing. I have no feelings to hurt.

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.

Whatever might result from this will be determined by the community's technical help. If there is one thing that I know, it is that there are things that I don't know. There are better ways of doing things then I would think up on my own. There is expertise spread throughout. I know that left on my own, that I will make some wrong decisions: it is just the nature of the process. People need to be willing to question, to call "bull****"... sometimes they are right. I am used to this. Cheers!

I recently started a thread on providing microcontroller-based electronic modules. In it, concern was expressed that I might not understand the scope and complexity of such an undertaking, and/or that I was shying away from wading in to electronic design. Perfectly understandable, especially considering my communication skills. (Even poor skills can be called skills. ) So, without (much) apology, my "CV": I have been working on cars and motorcycles since around 1972, and on other things mechanical since 5 years previous. I fix things; I make things work. It doesn't matter much what it is. In 1973, I got interested in computer programming, and, shortly after that, in electronics. I got a job in mainframe computers in 1979, taught myself several computer languages (including several assembler languages, micro and IBM mainframe). I got hired as a Programmer (IBM BAL) in 1987, and worked as a Programmer until around 2004. During this time, I also took college courses in Electronics Technology, missing out on my Certificate by one class. (The instructor left the program.) Most of my programming experience has been "on the metal", in machine-readable code. I understand how processors work, why they work. In Assembler/machine-code, the hardware does exactly what you tell it to do, which can be unfortunate when running in a Privileged/Supervisor state (which most of my later coding was in). With some brush-up, I can build a processor from discrete transistors. I can build a processor out of discrete logic chips. I can build a processor out of bit-slice logic. I can design and etch my own (simple) circuit boards. I can build a computer out of uProcessors. But why would anyone want to if someone else has already produced an adequate board? Why would someone want to make a commodity part from scratch? In a modular approach to hardware, it makes sense to use parts that are already readily available, and for much less than I could make them. (I don't bother doing long-division anymore, either. ) My college major was in mathematics. I also have enjoyed studying the physical sciences. I THINK in terms of math and physics. In these narrow areas, I am likely genius. (Along with that goes a bit of an ego...) I am socially inept. I currently teach children with autism, and am good at my job because I can understand them. I tend to use words in their truest sense rather than their current social context; misunderstandings arise. I have said that there is no need for a Floating-Point-Unit (FPU) for math intensive routines in my proposed gadgets. The honest truth is that there is seldom any need to use floating-point math in non-scientific and non-statistical software. Hobbyist "high-level" languages make unnecessary use of FP (really "scientific notation") to make things simpler for the novice coder; this is one reason why a lot of modern programs are such resource hogs. Enterprise-quality compilers avoid FP like the plague that it is. Why modular software and hardware? As complexity grows, this is the only way to manage that growth. There is a need for small, discrete modules of code/electronics, each one with a well-defined, limited purpose. Maintenance and future enhancements depend on the ability to understand the current functioning. Otherwise, things get real ugly. So, it is within my capability to design and build everything involved in an ECU, but I believe that is counterproductive. There are several existing processor boards from which to choose. It would also seem to be silly to design and build the control hardware when there are several highly integrated, highly capable and very cheap digital/analog interface ICs on the market. My time would seem better spent integrating the parts rather than reinventing them. I also know that perspective from others is needed in any non-trivial undertaking. I have a different perspective than most, so am that much more in need of differing views. Quality results can only come form quality input. I could do it many ways, but simpler makes more sense. For those of you who read this far, Cheers!!!

BUMP to show additional content in first post.

Not wishing to be contrary, but... When the platinum tipped sparkplugs became popular, they were marketed as needing less voltage to fire, thus more resistant to fouling. The argument was that the finer center electrode provided a more defined location for ionization, so less voltage was required to initiate the spark (physics-wise, a sound argument). The platinum was supposed to prevent rapid erosion of this finer electrode. That being said, the Bosch platinums that I tried (on and off) throughout the 1980's were horrible. The center electrode would erode withing a couple thousand miles; The electrode eroded all the way back to the insulator nose.

...and some PNW pollen?

Sounds like the best answer yet.

I have not heard of rocker breakage issues in the EJs, but I deal mostly with old-gen stuff. The engine (non-Subaru) that I have seen break rockers snapped the ends off in an "upward" direction due to not having reset clearances after a valve job. Some valves contacted the piston during first start-up... I think that some of the previous questions regarding cam and rockers was to find out if the cam and rockers were matched for the application: Is the cam grind designed for roller-rockers and non-hydraulic tappets? There MIGHT be some theoretical performance advantage for solid tappets, but probably far outweighed by the practicality of not having to keep the clearances properly set. Also, the solid tappets were probably cheaper to produce.

I believe that the XT/XT6 use a different mount than the others. The wagons and sedans should share the same mounting points throughout the run of the body style. The GL10 would probably show different rails because they can be height adjustable.

The other thing is, that to check/set the ignition timing, you need to tell the ECU to quit futzing with the timing while you try to check/set it. To do this, you need to connect the two single-wire green connectors that are by your windshield wiper motor. This puts the ECU into a diagnostic mode. When you are finished, you need to unplug these connectors; otherwise, your ignition timing will be locked at whatever you set it. Adding more advance probably won't get you anything except pinging. The SPFI engines are set up pretty well from the factory, with little other than disappointment when thinking that you can get more.

I am rather surprised that it broke "downwards". The only time I have snapped any rockers on anything, it broke "upwards", away from the cam lobe.

For street, I personally like the type of nozzle used on some of the Fords, ones that produce a fan spray.

My speculation would be for ground or power issues to the TCU, pretty much same reasoning/basis as GG.

Presslab, I respect your input, and would prefer if you continue to keep expressing your thoughts. I apologize if I sounded defensive: I am not. I am pretty thick-skinned, and used to lively discussions about pros and cons of things. I know that my view of things is twisted about 90-degrees from normal, so it is always good to get perspective from others. I truly have never had a need to use any floating-point, and I have worked on program debuggers, optimized search-engines, and done Systems Programming on large mainframe computers. Outside of scientific pursuits, everything is normally done with out floating-point math. Cheers!

Edit: The following is more for some future viewer than for anyone who has already commented. end Edit Amplifying a little on the whole floating-point thing: Floating point is just a representation of scientific notation, and should only be needed when working with either very large of very small numbers. It also is a human construct, one that the hardware has no need for. The fact that "high level" languages such as C encourage the common use of floating-point is more an artifact of the "psychopathy" of the language. (All high level languages are expressions of the thinking processes of their designers, so tend to exhibit psychological traits of the designers. C is a rather nasty example, as it was written by computer scientists for their own experimentation, and it escaped the lab.) There are much better ways than floating-point to perform decimal math, and decimal math is unneeded in engine management. Regarding the Wandboard being overkill, for most things this is totally true. From the literature I have seen so far, It is not clear to me what GPIO is accessible. Lots of the other I/O could be used for things such as a "glass cockpit", and data logging. The processing power would be about right for experimenting with ion-sense applications.

Oh, no, I am not trying to be strong-willed (stubborn), just that I think that most approaches have been misdirected, requiring proprietary design to do something that is actually pretty generic. As long as we are talking basic sensors like RPM, MAP, temp, and EGO, everything is pretty trivial. On the control/actuation side, a US$5 IC can handle the entire ignition and injection duty based on data passed by the processing core... whatever it might be. And this is for an MPFI (with distrib). An SPFI only needs an even cheaper chip. Need to use VRS crank and cam sensors? A US$4 dual VRS DSP can do that. Knock sensing is similar. What I want is a modular approach to engine management. MS seems stuck because of the approach they took, and everything with them is proprietary. Users suck eggs if they want something more or different. In my view, they should be able to build up their own system out of building blocks. The DYI EFI sites all seem to bog down in everyone trying to show how their way, their processor is better than anyone else's; nothing really appears to get accomplished. In the end, people doing mods are probably going to want something cheap, simple, and something that they can tweak. Openness and modularity seem the best way to go. Presslab, I certainly welcome your thoughts, suggestions, and critiques. It is differing views that encourage me to look at things from their perspective. Cheers! Edit: oops! Mea culpa. I referred to an IC as being a DSP, but it is really a digital-controlled analog signal processor.

On that second eBay link, the 10th item claims to be for 78-80 brats.

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.

The reason to use an established form factor is so that you don't have to go create it. It is there, and if your processor has a problem then you can get a replacement from Amazon for very little cash. The processor is not the star, the functional modules are. Realistically, most things do not need floating-point math. Most things that are likely to would benefit more from a DSP... which would be in the module for that function. One thing the "C-language revolution" did was allow people with no aptitude for programming think that they were good at it. Anybody with $50 bucks (or none when Linux got rolling) could easily write crap code. They never learn discipline or elegance... or how hardware REALLY works. In 15 years of Mainframe Assembler coding, I never once needed to use floating-point math. Lots of people do bizarre things in code because they don't understand any better and "C" lets them. The ion-sensing technology probably doesn't make economic sense in most markets. Its not much of a selling point, requires specialized coil hardware, and allows the deletion of stuff that pollution laws probably require. Several manufacturers use it, but none seem to advertise it in the US.