NorthWet

CISC processors don't like the heat. Ever see that YouTube vid of the AMD processor powered-up without a heatsink? Mykeys Toy: Your opinion is far more useful then my bloviating on obscure tech stuff. I may know a fair amount about the inner workings, but it doesn't mean jack if that knowledge does not lead to something useful. You know what is useful to you. IMHO, one of the biggest problems with tech is that the self-proclaimed "gurus" want to be priests relied on by the great unwashed masses. Tech is just everyday mechanics that are put together in a clever, useful way. It should be shown no more awe then would a toaster, and should be played with like Lego blocks. Figure out what would be useful, and lets find the blocks to put together.

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.

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.

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.

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.

A vacuum solenoid... IIRC (I am tired, and my memory of details is suspect), there are 2 on a USDM SPFI: One for fuel-vapor-canister purge, and one for the EGR valve. I think ours don't look like that, as they are slightly different shape and more plastic-y. (That may be just the angle/perspective of the picture.)

Are you reasonable sure that you are installing the pads in the calipers correctly? The caliper piston has a raised section, and the pins that are on the pad for the piston-side need to slip into the non-raised section. (Implying that the pistons need to be oriented in a certain way.) I screwed up once, and drove about 5 miles before that caliper "locked-up" enough to make me stop; after it cooled a little, I could go a little further, but not much.

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!!!

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.

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.

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.

No problem!

Ummm... there should not be any sort of exhaust leak. That hot-air riser should be intaking fresh air heated up in the gap between the exhaust and the shield that the riser connects to. Only fresh air, pre-heated to improve driveability and emissions, should be getting to the air-cleaner housing.. The foil risers, though cheap, flimsy and generally second-rate to any OEM tubing, still should be serviceable: My only problem with them through the years is that they don't take well to being bumped, banged and readjusted.

I keep hearing (yes, just "hearsay") that the walbro...or maybe just their clones... can be really noisy. May not matter to you one way or the other. There is also the often-mentioned Ford truck unit that is supposeed to be common and inexpensive.

One thing you might verify is that the pan bottom has not been dented upwards under the pickup. Another member usually suggests checking this, as the clearance between the pickup and pan is minimal.

I think that your use of "line pressure" is proper, as I think that is what the FSM refers to as the regulated (by duty-A solenoid) hydraulic pressure. (Sorry, I'm not in a situation where I can verify the term.) Regardless, I understood what you meant. My recollection is that it is the POWER light that blinks rather than the AT Temp, but I might be confusing the EA version of the "4EAT". My memory is VERY suspect at the moment, though. Take the accuracy of my inline filter "info" with a grain of salt: It was what a parts person at the dealership told me, and I am not too impressed with this dealership. However, the explanation did make sense. The guy said that the issue is caused by friction material from the TC's lockup clutch shedding into the ATF in the TC, then flowing out into the cooler lines where the passages in the in-radiator cooler are narrow enough that the debris tends to get stuck. (The rest of the story is why I called: I was trying to get a new filter under the TSB to replace one I suspected of being plugged. He claimed that they were just debris screens and meant as a one-time, lifetime install. So, a possible conflict of interest on his part.) Edit: I don't suppose that you still have the old filter to do a post-mortem on, do you?

First, let's try to get some clarity... Is there a reason that you think that the line pressure is low? Has someone hooked a gauge to the pressure port, or is this best-judgement based on symptoms? I would assume that you would have already mentioned this if true, but are you getting an error from the TCU (blinking "POWER" light when you turn on the ignition)? Solenoid-A, IIRC, modulates the line pressure and commonly throws a code. The inline "filter" (my local dealership said that it is a screen to catch coarse particles, and that it was a life-time part) is in the return path from the torque converter to the fluid pan. It would seem to me that any affect it would have on line pressure would be to cause a mild increase rather than a decrease. Replacing the filter screen in the pan is a lot of work and not likely to give you much reward... unless you find something else, such as a leaky o-ring or transfer pipe. (The pan is pretty heavy and has lots of bolts; R&R'ing the valve body is even less fun.)

Yes, they are just slip in... but I have had a few that refused to slip back out with merely kind words.

Doing the HLAs in situ shouldn't be too tough... unless they are stuck in their bores, which might require some ingenious "persuading". I assume that you had the the cam case off to do the rockers the first time, right? The HLAs are just a slip-fit in their bores.

IF the cam followers have fallen off, there are other likely causes other than oil pump pressure/flow. There is some amount of technique involved in reassembly (usually involving a thick grease); did you verify that all of the followers were in place before putting on the cover? You could also have collapsed/bad hydraulic lash adjusters, a plugged oil gallery passage, bad cam-tower/head sealing ring, excessive venting at the tower oil-relief valve (not its proper name).

The wire to the sender is grounding-out somewhere. My guess would be somewhere between where it leaves the engine loom (near the t-stat) and heads down the front of the engine to the sender.

is 85 psi the top of the scale? (as in, did the gauge just pin itself to the high end of the gauge?)

Oil pumps are different, but I have not had eyeballs on the ER27 one to see if it could be modded to fit (it has about 50% more capacity). Amazon has an inexpensive "quick oil change" kit which is really a remote filter kit with some other stuff to allow "easier oil changes" for under $30. Great deal. With this, you can easily add an oil cooler.

I am reasonably sure that it was meant as a happy comment, a form of "laughing at myself" sarcasm. Idioms do not translate well, do they? Cheers!

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...