Even more broken retainers found
Registered User
Joined: Sep 2002
Posts: 171
Likes: 0
From: Walnut creek
Does anybody know of a place in Bay area , ca where I could take my car to have valves adjusted and reatiners checked. Due to bad prior experience with local dealers I would not have faith letting them touch the car. Anybody out in this area who we know has done many of these? Billman can u please clone yourself and move to the west coast 
Registered User
Joined: Jan 2003
Posts: 8,482
Likes: 3
From: Wylie, TX
Originally Posted by waterhound7,Nov 11 2006, 04:46 PM
Does anybody know of a place in Bay area , ca where I could take my car to have valves adjusted and reatiners checked.
https://www.s2ki.com/forums/index.php?showforum=18
krazik has a "Bay Area" image in his sig... maybe he can do it for you.
Registered User
Joined: Feb 2004
Posts: 7,087
Likes: 2
From: Dry Branch
Originally Posted by mikegarrison,Nov 11 2006, 02:59 AM
I'm pulling the tach signal off the same wire for the beeper and the datalogger. A different wire feeds the ECU, which drives the tach display. But it's probably the exact same signal.
What happens afterwards, though, depends on the computers using that signal. The accuracy of reading the signal depends on the sampling rate. Let's assume they are all sampling often enough to be reading the signal correctly.
Then what happens? With the datalogger, it feeds the display and also records to a file. I'm not sure what the rate of either of those is. But if the RPM suddenly shot up and back down again faster than the datalogger was recording, you could miss the event. The data logger is logging multiple times per second, though, so RPM isn't going to change that quickly.
The beeper is just watching the RPM and going beep if it hits certain levels. It was never really designed as a datalogger, so the memory of the peak RPM is not necessarily very accurate. I don't know how often it checks to see if the current RPM is higher than the saved RPM.
The ECU is reading the RPM and then doing a lot of things with it. One of those things is the fuel cutoff. Another is deciding how many bars to show on the tach.
All of these probably have some time averaging built in to them, to avoid giving spurious signals.
What happens afterwards, though, depends on the computers using that signal. The accuracy of reading the signal depends on the sampling rate. Let's assume they are all sampling often enough to be reading the signal correctly.
Then what happens? With the datalogger, it feeds the display and also records to a file. I'm not sure what the rate of either of those is. But if the RPM suddenly shot up and back down again faster than the datalogger was recording, you could miss the event. The data logger is logging multiple times per second, though, so RPM isn't going to change that quickly.
The beeper is just watching the RPM and going beep if it hits certain levels. It was never really designed as a datalogger, so the memory of the peak RPM is not necessarily very accurate. I don't know how often it checks to see if the current RPM is higher than the saved RPM.
The ECU is reading the RPM and then doing a lot of things with it. One of those things is the fuel cutoff. Another is deciding how many bars to show on the tach.
All of these probably have some time averaging built in to them, to avoid giving spurious signals.
OTOH, I have absolutely no idea how Modifry's beeper is designed, so for all I know he does sample the signal. I suspect the ECU controls the tach display using softwar, and Modifry may just mimic the tach control; I really don't have a clue. I've just assumed that it was a counter and a little logic, without any sampling, because the highest PRF is so low it's easy to do that way. I'd also assume that the high RPM indicator follows the counter when the value in the counter is greater than the value in the high RPM register (IOW, a lag of no more than one pulse interval). I have a hard time imagining doing it any other way, because it should be straightforward to do with simple hardware logic, but I also have a limited imagination.
Interesting info, but I feel bad about having this discussion in a retainer thread. The main thing that got us off track was the issue of engine speed at fuel cut, and in spite of what the shift beeper memory is telling us, it looks like the fuel cut is just before 9,000 RPM. If I ever run into Modifry at another S2kI meet I'll try to get him to explain the details of the beeper's operation.
Thanks for the input Mike.
Registered User
Joined: Apr 2003
Posts: 22,888
Likes: 3
From: Covington WA, USA
Originally Posted by RED MX5,Nov 11 2006, 08:50 PM
I agree, except that I'm not sure that we'd have to sample the signal, because I think it's already digital. We should see a maximum of 9,600 pulses per second (the limit of the beeper), and each pulse should just incriment a counter (hence no sampling). At most the sensor output might require a little conditioning, but I don't see a need for sampling.
When I think of digital I think of "8900" being sent (in binary) as opposed to the actual signal being sent. Maybe that's wrong?
Furthermore, the beeper may be limited to 9600 RPM, but the data logger definitely is not, nor is the signal itself. If you overrev (hey wait, is that on topic?) the signal that is sent will not be limited to 9600 RPM (which, I'm pretty sure, is actually a 640 Hz square wave).
Registered User
Joined: Feb 2004
Posts: 7,087
Likes: 2
From: Dry Branch
Originally Posted by mikegarrison,Nov 12 2006, 02:20 AM
It's a square wave pulse being sent down the wire. And it's actually flipping back and forth at 4x the RPM, I think. Sampling might not be quite the right word to use, I'm not an electrical engineer. But the chip monitoring the pulses has to be fast enough to pick up each pulse -- that's what I meant.
When I think of digital I think of "8900" being sent (in binary) as opposed to the actual signal being sent. Maybe that's wrong?
Furthermore, the beeper may be limited to 9600 RPM, but the data logger definitely is not, nor is the signal itself. If you overrev (hey wait, is that on topic?) the signal that is sent will not be limited to 9600 RPM (which, I'm pretty sure, is actually a 640 Hz square wave).
When I think of digital I think of "8900" being sent (in binary) as opposed to the actual signal being sent. Maybe that's wrong?
Furthermore, the beeper may be limited to 9600 RPM, but the data logger definitely is not, nor is the signal itself. If you overrev (hey wait, is that on topic?) the signal that is sent will not be limited to 9600 RPM (which, I'm pretty sure, is actually a 640 Hz square wave).
Think of the signal as a serial data stream that uses PRF modulation. Higher PRF indicates higher revs. Trigger a counter on a rising or falling edge, and you are "counting the bits" in the data stream. 9000 RPM is 150 revs/second (RPS) and 600 bits/second. 1000 RPM is 16.66... RPS and 66.66... bits/sec. 100 RPM is 1.6... RPS and 6.66... bits/sec. To see at least one bit per 100 RPM change we have to run the counter for at least 1/6th. of a second. In a sense this is "sampling," but it doesn't have the kind of errors we get when we are sampling an analog signal, because we're really just counting bits over time.
Somebody check my math (I'm not known for mathematical accuracy
); Unless I got something wrong it looks like we're limited to an update rate of 6 Hz. if we want 100 RPM resolution.We could also calculate the revs with every pulse using the time between pulses as the indicator (IOW, actually using the PWM directly). This could be more accurate, but seems more complex. I have no idea of which way the OEM tach or shift beeper does it; For all I know they have a totally different approach.
LOL, since the pulses are of a constant amplitude but vary in frequency, I suppose you could charge a capacitor through a resistor and use the cap voltage to determine the pulse rate. Too many different ways to do things to be guessing I guess. Looking at the data rate, a counter is going to have reasonable accuracy at a reasonable update rate, but there are lots of other ways it would be accomplished.
As far as the limits of the beeper go, If I hit 9,600 (or even 9,200), as far as I'm concerned, that constitutes an over-rev.
I think my PLX may store the raw pulses, but the ICPC is down right now and I can't get to any of the data to see.
I guess we are on topic, at least a little.
The shift beeper won't tell you in absolute terms how badly you over reved, but it *will* tell you that you went past the red line, and it will give you some indication if you didn't exceed 9,500-9,600 RPM. If I see anything over the usual 9,100 I see when the limiter engages I'll be doing an immediate retainer check.(There, now we are totally back on topic.
)