jonathan909

Perfect. See, you don't need a bracket - the one you have is just fine. Those four threaded holes? That's where the AC compressor goes. And it's hard to tell from this angle, but there should also be two threaded holes on the front of that casting that the tensioner bolts into. Then there's just one more piece (and I don't have an EJ22 older than '95, so yours may vary), a little casting that the bottom two AC compressor bolts pass through and which in turn bolts onto the top of the head to stablize the whole assembly.

Why don't you post a picture of the alternator (and AC compressor) bracket on your engine? No point in getting another from the US if it's the same as you have now.

You may not have been careful enough in your choice of contact cleaner. It's easy to get one that's a cleaner and killer degreaser that, as you say, flushes out any lube. I always go for the cleaners that have added lubricant.

You still need to lift the hood and localize it. To the fuse/relay box, perhaps?

The fuel pump is in the tank, so it's not going to sound like it's under the hood. I suggest you lift the hood and localize the buzz.

That's starting to sound like a plan. I just spoke to the dealer (and confirmed online) that the switch is not a separate part from the lock, so the whole assembly has to be replaced (~ $150 USD, $300 CAD). And that assembly was only used for a couple of years, so the idea of getting one from a much newer donor car is a nonstarter; one from a car of the right vintage is probably going to be as worn and noisy as the one you're trying to replace.

I've now hacked the security module onto my test jig and answered the question I started with last spring. "Valet mode" does not inhibit the programming of new key fobs (transmitters). I suspected that it does because my '02 Forester arrived in valet mode, without a working fob, I couldn't get it into programming mode to connect a new fob, and someone over on NASIOC claimed that a Subaru tech told them that it does. I've now disproven that theory, and think that the same problem normally experienced preventing entry into programming mode was at work: A badly worn keyswitch. I continue to work toward (dis)proving this thesis.

Oh, who knows... could have been a designer with a formal stick up his butt over using a JEDEC pinning (however screwy), or the rep or disty giving them a good price on these ones because they're oddball and nobody was buying them... any number of stupid reasons. Certainly not to prevent reverse-engineering - too trivial a change, and the microcontroller's software (the part that counts) is locked up in mask ROM that effectively can't be read out anyway.

Buggah! Figured out why I couldn't read the 93C46 - turns out it's available in this funky alternate "rotated" pinout - it's not shown in the ST datasheet (that's whose part is in here), but it is shown in the Atmel datasheet, and that's the version that Alpine used (for whatever ungodly reason). It's a packaging option that's only available in the SOIC (not the DIP), so (of course) Data I/O only supports it in their SOIC socket. Which I don't have - I only have the DIP and PLCC sockets on the Unisite, which is why I mounted the SOIC on a DIP adapter. So now I've made another adapter to rewire all the pins and it's reading like it oughta. Cool.

Exactly - the part isn't full of zeroes - I know that because the module works. This is definitely a problem with the Unisite failing to read it - I'm going to fiddle with the device codes to see if that makes a difference. I just wish I had some DIP 93C46s in stock here to play with. Can't see any.

Yes, essentially. When you do the programming, the MCU stuffs the fob's code into the E^2. Then, in normal operation, when the MCU gets a signal from a fob, it looks it up in the E^2. If it matches, it does its thing. The interesting part from a reverse-engineering standpoint is that the system supports up to four fobs. You can't erase a fob's code - you overwrite it. So if you want to clear out the existing codes, you take your new fob and program it in four times. That has the added feature that if we then look at the contents of the E^2, we should see the same block of data repeated four times, which will tell us where and how the fob codes are stored in that memory. Not that knowing that is actually useful, but it's cool to know. And now that we know what the MCU is, we've confirmed that the E^2 is where the fob codes go, because the 750008 only has RAM and ROM on board - no E^2. The other thing I'm interested in is how the keyless entry and security modules communicate with each other. They're connected with three wires, which suggests they talk via the same SPI/Microwire/whatever synchronous serial interface as the MCU uses to communicate with the E^2 - except that there's usually a select line in addition to the Din, Dout, and clock lines. So I'm not there yet - still have to add the security module to my jig and throw the scope (and probably the logic analyzer) at it.

I'm a huge fan of programmable logic - have been for a really long time. Even before I bought the Advin for doing PALs in the late 80s I was using small bipolar PROMs for memory decoders and stuff via the 29A and Unipak2, since I couldn't afford a LogicPak. In the modern era, though, my work has had a lot of Xilinx FPGAs and FLASH CPLDs (and some Atmel parts as well), and all those things are ISP via JTAG, etc., so the old programmers largely gather dust - they get dragged out for weird gigs like this one. I don't know about your background, but I'm guessing you'll get a kick out of this (I wrote it just a few weeks ago): https://nitpickingbastard.wordpress.com/2019/03/28/on-the-trail-of-the-mcu-part-2-what-the-hell-is-a-lattice-gal-doing-in-my-stove-hood/ Yes, exactly - these serial E^2s are too small and slow for code, so they're used for configuration data that needs to persist (like fob codes). The 44p QFP you see in the corner is what's doing the work, but I don't know anything about it - it has an Alpine house number. But I'm beginning to think it isn't a full-custom part, as I have a newer rev of this module (fetched from the junkyard) that has a sorta-similar layout, but a NEC part in the same package in the same spot. So it may be a mask ROM MCU that I can actually look up, which makes a lot of sense... Yup, that's exactly what it is - a NEC (now Renesas) uPD750008 4-bit mask ROM MCU. And the security module has a similar layout as well, right down to those two same packages in the same corner, which is where I started thinking about this last spring: Wondering whether I could find the (presumed) bit in that E^2 that tells it that it's in valet mode. I'll get there...

Could do that (and once upon a time I did some life cycle testing on a custom switch assembly over exactly this kind of contact wear), but I'm not interested in getting that obsessive about it, since the jig gives me an effective workaround. Actually, now that I think about it, the logical next step would be to just hack a pushbutton onto the module (across the pins where the keyswitch goes) and see if it will get me into programming mode. If it works, we can reasonably infer that the problem is keyswitch noise without getting way into the deep end trying to characterize that noise.

No, just 1K(bit) - organized as 128x8 or 64x16, neither of which take much scrolling. The giveaway is that the Unisite reports a $0000 checksum, so that tells you at a glance it got nothing but zeroes on read. It's not a uC, just a memory, so there's nothing like a security bit. It's really bugging me that the Data I/O is having trouble reading it, so I'm going to have to mess around, see if I've got some more of these chips I can experiment with i.e. burn some random data into. And annoying that it seems to be the only programmer I have that's supposed to support them - I've got a 29A, 29B, Advin Sailor PAL, etc. Friend of mine has an Advin Pilot (which is supposed to support them as well), but he can't find it. Grrr...

And here's another unit, out of its box and with the EEPROM socketed so I can take it out and spill its gutz.

Pulled the module from the car. Programmed it on the bench using this jig. Reinstalled it in the car. Works perfectly. I haven't tried programming it in the car, but I don't expect it to work. When I get the time and inclination I'll probe the connector and see if I can see anything wrong, but I still strongly suspect a worn ignition switch. This also doesn't solve the stuck-in-valet-mode problem that I had with my '02 Forester last year. That's a function of the optional security module, which ties into the keyless entry module. I don't want that part, so I don't care much, but sooner or later (probably sooner) curiosity is going to get the better of me and I'll add it to this jig. p.s. Other than the chunk of harness taken from a car in the junkyard, built entirely of stuff I had lying around.

[later] The good news is that my test jig is done and works perfectly. I've tried a few of the keyless entry units and they function exactly according to the description. So I can program one for the key fob(s) I want to use, then install it in the car and assess it for operation, both in "normal" use and in programming mode. If it doesn't work for normal use, isolating the fault in the car wiring should be quick work. If it does work, but won't enter programming mode, the keyswitch is still my first suspect. [geek mode] The one weird problem I'm having in the lab, though, is with the EEPROM that Alpine (presumably) stores the fob codes in. It's a serial E^2 - 93C46, an old and very common part, and the Data I/O Unisite I'm trying to read it with is returning all zeros - nothing that looks like proper data. Not sure what's going on there. [/geek mode] Will post a picture later.

That might or might not help. The contacts aren't the only issue, either. The key/cylinder are worn and don't turn smoothly - catching sometimes - compounding the problem. The right answer is a new switch assembly, but then the (re)keying becomes a thing. What's stuck in my craw is that I haven't gotten the beep at all - not on 9, not on 12, never. And I refuse to believe that the problem is in all of the four or five modules I've tried. Nor is it something blindingly obvious like a door not being closed, and there just aren't that many inputs into this controller. So it's a puzzle, and we solve puzzles. Oh, I started with "frustrated", but I'm way past that now. Once you put yourself on a path to solving a problem, you're no longer frustrated - you're just "in the process", and the bug will inevitably fall. It's just a matter of time. Wrt "helpful", to the contrary: Any discussion that focuses thought and clarifies the problem helps, and I appreciate it.

When I say "we can be certain that it wasn't designed that way", I do so with some authority, because I design systems like this (and have done so for about 40 years). If the manual says "ten times", that means the EEs and programmers behind it built it to work that way, and you can take that to the bank. Nobody builds a sequence like this around an approximation, because: a) it's harder to do it that way, and b) they want it to work the same way every time, regardless of whether it's on their bench or out in the field. Consistent, repeatable behaviour is the norm, and deviation is a defect that suggests bugs. Nobody wants to get calls from dealers and customers complaining that it didn't work exactly that way every time it was used. Would you tolerate that behaviour from your speedometer? Your radio? Your airbags? Joe Spitz's "appr 10 times" is to be dismissed, along with his statement about the brake pedal, as myth. He's a car salesman (and I've been in touch with him over this) who assembled his page as a convenience, not an engineer who's reporting definitive data. I've been over the schematics, and with this Alpine system it's the same horn and same horn relay as the driver uses. That's the only feedback provided to indicate programming mode; whether that was a good design decision is a different discussion. So I'm becoming increasingly convinced that "fixat(ing) on the number 10" is exactly what will solve this. Switch contacts get noisier, and key cylinders get stickier, over time. I think that the designers, with brand-new keyswitches on their bench, made it work consistently, but failed to factor in the switch wear over time in building their debounce and delays simply because it's not their primary concern. The "security" aspect you raised is different - in this generation that's a separate module not present in all cars, so it carries its own implications outside of the scope of what I'm doing now.

Perhaps, but we can be certain that it wasn't designed that way. It only suggests I'm on the right track.

For anyone (?) interested, an update: Collected a few more of the modules from the boneyard today. Tried one of them in the car to no change in behaviour. I'm beginning to suspect that the problem is with the ten-key-twist. As the car gets older, so do the switches, including the ignition. If that switch becomes sufficiently noisy, then, depending on how well Alpine implemented their switch debounce, the keyless entry unit may not be able to accurately count the ten cycles, and that's all it takes for a deal-stopper. Should have my jig finished tomorrow, so I can start doing more controlled experiments.

Presumably your alternator is mounted as usual - on the AC compressor bracket. So that's your starting point - you bolt through the compressor into the four threaded holes in that bracket, so you need to find a compressor with that hole spacing.

Yikes - I was in a similar situation with my '98 Legacy wagon - somewhere along the way the AC (compressor and condenser) were removed and the PO didn't bother replacing them. When I decided to take care of that last summer I just had to dig around the wrecking yard to find the compressor+brackets that fit, as there are abundant combinations that don't.

Right - there are a bunch of those stupid little variables whose existence may or may not be rooted in fact. The manual is quite clear about the key being OFF ("LOCK") at the end of the 10 twists, but there's no mention of the brake at all. The only place I've seen the brake discussed is on Joe Spitz's page (the cars101.com piece mentioned above), and since the brake is not an input to the keyless entry module, I believe this is a myth. I'm not certain about anything. But I do have about a dozen fobs with fresh batteries, so the odds are in my favour that I have some good ones. And I'm in the process of building a bench jig so I don't have to do this out in the car. I'm annoyed enough at this business that I intend to have its pelt nailed to the wall before long.

No idea whether it's possible with the '05, but I did it with the '99. Undoing the motor mounts and firewall/xmission strut and lifting the motor a few inches would have made it easier.