Will it never end?
#22
11-17-2011, 07:27 PM
Senior Member
I went back and edited to convey this safety issue. I was very careful and so should anyone else diconnecting these cables..Thanks for warning everybody.
#23
11-17-2011, 07:34 PM
Member
Check your starter!
Rev,
Next time you try to start and it barely turns over get underneath the car and tap the outside of the starter motor with a hammer. It sounds like it is going bad and would make sense if it was marginal and you did a lot of cranking. Sometimes the brushes get hung up and dont make good contact with the armature. Tapping will sometimes work them loose. Or, you have a bad sector on the armature.
Hope It helps.
Cheers
Andrew
Next time you try to start and it barely turns over get underneath the car and tap the outside of the starter motor with a hammer. It sounds like it is going bad and would make sense if it was marginal and you did a lot of cranking. Sometimes the brushes get hung up and dont make good contact with the armature. Tapping will sometimes work them loose. Or, you have a bad sector on the armature.
Hope It helps.
Cheers
Andrew
As soon as I got my fuel pump check valve fixed another problem showed up. Now my battery drains overnight. When I try to start it the next day either it barely cranks, or I just get a click. I took it to the parts store today to have them load test the battery, and it's fine. In fact, it was supposed to have 850 cold cranking amps but it tested out at 897.
So now I need to track down whatever is draining my battery. I'm going to use the ammeter/fuse pulling method. This might take a while.
So now I need to track down whatever is draining my battery. I'm going to use the ammeter/fuse pulling method. This might take a while.
#24
11-17-2011, 07:52 PM
Veteran Member
#25
11-17-2011, 08:24 PM
Senior Member
Rev,
Next time you try to start and it barely turns over get underneath the car and tap the outside of the starter motor with a hammer. It sounds like it is going bad and would make sense if it was marginal and you did a lot of cranking. Sometimes the brushes get hung up and dont make good contact with the armature. Tapping will sometimes work them loose. Or, you have a bad sector on the armature.
Hope It helps.
Cheers
Andrew
Next time you try to start and it barely turns over get underneath the car and tap the outside of the starter motor with a hammer. It sounds like it is going bad and would make sense if it was marginal and you did a lot of cranking. Sometimes the brushes get hung up and dont make good contact with the armature. Tapping will sometimes work them loose. Or, you have a bad sector on the armature.
Hope It helps.
Cheers
Andrew
Starter motor.
This happened in a z28 I drove in college. Used to reach under and whack it with the sharp end of a jack handle.
#27
11-17-2011, 09:58 PM
Veteran Member
Plums - this sounds interesting, can you elaborate? In databases, binary search works like this:
Tables hold data. Each table has an index to show the precise location of each record.
The index is like a Dewey card catalog in a library.
In a Dewey, the cards are divided into drawers: A-C, D-F, etc. An index has a "master drawer" with A-J on the left side, and K-Z on the right.
These master cards point to a second index drawer. If looking for "Charles", the second drawer would contain cards for C on the left and D on the right.
So, by looking in the first drawer, the database eliminates all of the drawers but one, making the search much faster.
Similar?
Tables hold data. Each table has an index to show the precise location of each record.
The index is like a Dewey card catalog in a library.
In a Dewey, the cards are divided into drawers: A-C, D-F, etc. An index has a "master drawer" with A-J on the left side, and K-Z on the right.
These master cards point to a second index drawer. If looking for "Charles", the second drawer would contain cards for C on the left and D on the right.
So, by looking in the first drawer, the database eliminates all of the drawers but one, making the search much faster.
Similar?
Maybe. But what you describe is more like a chained hash table.
In a binary search as applied to the goal of seeking a particular circuit, it is a divide and conquer strategy.
1. pull out half of the fuses
2. check current drain
3. if the current drain still exists it is in the half with the fuses, if it is gone it is in the other half
4. repeat test in the suspect half as in 1,2,&3
Each iteration leaves 1/2 half as many fuses in the suspect pool as the preceding iteration.
As to its practicality, a binary search is the shortest exact solution to the problem that does not involve intuition or lucky guesses.
If the approach of pulling each of the 5 fuse box cables is used, that is already 5 rounds. If the fuse box containing the defective circuit is one of the smaller fuse boxes, containing say 8 fuses, and a linear search is applied, then by the law of averages, 4 further checks will be required. That is 9 operations on average, with a minimum of 6 and a maximum of 17.
The binary search on 128 fuses is guaranteed to locate the circuit, *if* it is a fused circuit, in exactly 7 operations.
Last edited by plums; 11-17-2011 at 10:14 PM.
The following users liked this post:
mcbeefsteak (11-18-2011)
#28
11-17-2011, 10:20 PM
rev before you panic i would make sure that that battery works. i had a problem like that and found that it was my battery. remember those batteries are really big and service a lot of electrical stuff in those cars. just make all the way sure that it is not the battery. take it out and get it charged then tested. the weather changes and batteries go dead
#30
11-18-2011, 03:11 AM
BobF might be on to something. I've seen a lot of T/S for shorts discussed, battery load test, but have you verified that the alternator is actually working. 12.5 volts with the car running is suspect of a weak/bad alternator/diode problem. Increase rpm if you still have normal battery voltage of 12.5 look @ your alternator connections.
Have you verified that battery is actually dead (less than 12 volts) when you tried to start the car? I know these sound like rookie suggestions, but it's the basics that sometimes kick our butts. Good luck with it. I have an Eclipse with the same symptoms and T/S was a pain. I isolated the short/draw to the sunroof utilizing the elimination process, what a pain! Still have yet to fix it.
Have you verified that battery is actually dead (less than 12 volts) when you tried to start the car? I know these sound like rookie suggestions, but it's the basics that sometimes kick our butts. Good luck with it. I have an Eclipse with the same symptoms and T/S was a pain. I isolated the short/draw to the sunroof utilizing the elimination process, what a pain! Still have yet to fix it.
#31
11-18-2011, 06:13 AM
Senior Member
Maybe. But what you describe is more like a chained hash table.
In a binary search as applied to the goal of seeking a particular circuit, it is a divide and conquer strategy.
1. pull out half of the fuses
2. check current drain
3. if the current drain still exists it is in the half with the fuses, if it is gone it is in the other half
4. repeat test in the suspect half as in 1,2,&3
Each iteration leaves 1/2 half as many fuses in the suspect pool as the preceding iteration.
As to its practicality, a binary search is the shortest exact solution to the problem that does not involve intuition or lucky guesses.
If the approach of pulling each of the 5 fuse box cables is used, that is already 5 rounds. If the fuse box containing the defective circuit is one of the smaller fuse boxes, containing say 8 fuses, and a linear search is applied, then by the law of averages, 4 further checks will be required. That is 9 operations on average, with a minimum of 6 and a maximum of 17.
The binary search on 128 fuses is guaranteed to locate the circuit, *if* it is a fused circuit, in exactly 7 operations.
In a binary search as applied to the goal of seeking a particular circuit, it is a divide and conquer strategy.
1. pull out half of the fuses
2. check current drain
3. if the current drain still exists it is in the half with the fuses, if it is gone it is in the other half
4. repeat test in the suspect half as in 1,2,&3
Each iteration leaves 1/2 half as many fuses in the suspect pool as the preceding iteration.
As to its practicality, a binary search is the shortest exact solution to the problem that does not involve intuition or lucky guesses.
If the approach of pulling each of the 5 fuse box cables is used, that is already 5 rounds. If the fuse box containing the defective circuit is one of the smaller fuse boxes, containing say 8 fuses, and a linear search is applied, then by the law of averages, 4 further checks will be required. That is 9 operations on average, with a minimum of 6 and a maximum of 17.
The binary search on 128 fuses is guaranteed to locate the circuit, *if* it is a fused circuit, in exactly 7 operations.
The alternative is for the database is to look at every book until the matching books are found, since they are not guaranteed to be stored in order in the table.
One might think that the index operation would always be faster, but that is a common misconception that causes many performance issues.
Imagine a scenario where the database was looking for books that contained a consonant in the title, and it is clear how much more slowly walking back to the index catalog for each book would be. It is faster just to walk to the shelf, go through all the books a few at a time, and discard the non-matching ones.
Many thanks for the lesson, it's a keeper.
B-tree - Wikipedia, the free encyclopedia
Rev, good luck with your search. Let us know if we can help.
Last edited by mcbeefsteak; 11-18-2011 at 06:18 AM.
#32
11-18-2011, 07:03 AM
#33
11-18-2011, 08:10 AM
Veteran Member
Search strategies:
Pulling *groups* of fuses at one time by disconnecting fuse blocks seems the best search strategy here, but if someone were to go at this one fuse at a time, a binary search would not be the most efficient under these circumstances.
This is so because we have to consider not the number of "steps" in the search -- binary makes for the fewest steps -- but the number of physical operations, i.e. actually pulling fuses. A "step" can involve many physical operations.
For a 128-fuse case ...
Brute force method, pull one fuse at a time:
- Maximum number of fuses to pull = 128 (all of them)
- Expected number to pull = 64 (in other words, on average we find the bad guy half way through)
Binary search. Always 7 steps ... first pull 64 fuses and test, then test with 32, etc.:
- Maximum number of fuses to pull = 128
- Expected number to pull = 96
[edit: D'oh! I had a math error here showing the answer as 85, not 96. Sorry! The following paragraph is now correct.]
Why 96? We pull the first 64 fuses and test. Half the time the trouble is in the 64 fuses not pulled, and we will have to pull 32 more for the second "step". So the expected number pulled after two steps = 64 + (1/2 * 32) = 64 + 16 = 80. To execute the third step, on average we pull 1/2 * 16 = 8 more. Then 4, then 2, then 1 then (on average remember) 0.5.
So the expected (average) number of fuses we will have to pull in a binary search = 64 + 16 + 8 + 4 + 2 + 1 + 0.5 = 95.5 ... call it 96.
So if we think in terms of the number of "steps", binary looks efficient (always 7 vs. average of 64). But measured in terms of physical operations -- what we actually have to do -- for this problem it is 96 for binary, 64 for brute force, and so brute force is a more efficient search strategy here.
At least that's how it looks from here.
[edit: also please see important assumption I made to get to this result, found in post #41, this thread]
Pulling *groups* of fuses at one time by disconnecting fuse blocks seems the best search strategy here, but if someone were to go at this one fuse at a time, a binary search would not be the most efficient under these circumstances.
This is so because we have to consider not the number of "steps" in the search -- binary makes for the fewest steps -- but the number of physical operations, i.e. actually pulling fuses. A "step" can involve many physical operations.
For a 128-fuse case ...
Brute force method, pull one fuse at a time:
- Maximum number of fuses to pull = 128 (all of them)
- Expected number to pull = 64 (in other words, on average we find the bad guy half way through)
Binary search. Always 7 steps ... first pull 64 fuses and test, then test with 32, etc.:
- Maximum number of fuses to pull = 128
- Expected number to pull = 96
[edit: D'oh! I had a math error here showing the answer as 85, not 96. Sorry! The following paragraph is now correct.]
Why 96? We pull the first 64 fuses and test. Half the time the trouble is in the 64 fuses not pulled, and we will have to pull 32 more for the second "step". So the expected number pulled after two steps = 64 + (1/2 * 32) = 64 + 16 = 80. To execute the third step, on average we pull 1/2 * 16 = 8 more. Then 4, then 2, then 1 then (on average remember) 0.5.
So the expected (average) number of fuses we will have to pull in a binary search = 64 + 16 + 8 + 4 + 2 + 1 + 0.5 = 95.5 ... call it 96.
So if we think in terms of the number of "steps", binary looks efficient (always 7 vs. average of 64). But measured in terms of physical operations -- what we actually have to do -- for this problem it is 96 for binary, 64 for brute force, and so brute force is a more efficient search strategy here.
At least that's how it looks from here.
[edit: also please see important assumption I made to get to this result, found in post #41, this thread]
Last edited by Dennis07; 11-19-2011 at 04:46 PM. Reason: corrected math error
The following users liked this post:
mcbeefsteak (11-18-2011)
#34
11-18-2011, 08:34 AM
Veteran Member
OK, that doesn't sound normal, right? But also, it doesn't seem like nearly enough to pull the battery down in one night. You'd expect to lose, what, something like 5 amp hours.
Did everything work OK right after you got the external charge? And did it then go down again next night?
#35
11-18-2011, 09:01 AM
Senior Member
#36
11-18-2011, 09:05 AM
Senior Member
#37
11-18-2011, 09:45 AM
Senior Member
Search strategies:
Pulling *groups* of fuses at one time by disconnecting fuse blocks seems the best search strategy here, but if someone were to go at this one fuse at a time, a binary search would not be the most efficient under these circumstances.
This is so because we have to consider not the number of "steps" in the search -- binary makes for the fewest steps -- but the number of physical operations, i.e. actually pulling fuses. A "step" can involve many physical operations.
For a 128-fuse case ...
Brute force method, pull one fuse at a time:
- Maximum number of fuses to pull = 128 (all of them)
- Expected number to pull = 64 (in other words, on average we find the bad guy half way through)
Binary search. Always 7 steps ... first pull 64 fuses and test, then test with 32, etc.:
- Maximum number of fuses to pull = 128
- Expected number to pull = 85
Why 85? We pull the first 64 fuses and test. Half the time the trouble is in the 64 fuses not pulled, and we will have to pull 32 more for the second "step". So the expected number pulled after two steps = 64 + (1/2)*32 = 64 + 16 = 80. To execute the third step, on average we pull 1/2 * 1/2 * 16 = 4 more. Then 1, then fractional values we can ignore.
So the expected (average) number of fuses we will have to pull in a binary search = 64 + 16 + 4 + 1 + fractions ~ 85.
So if we think in terms of the number of "steps", binary looks efficient (always 7 vs. average of 64). But measured in terms of physical operations -- what we actually have to do -- for this problem it is 85 for binary, 64 for brute force, and so brute force is a more efficient search strategy here.
At least that's how it looks from here.
Pulling *groups* of fuses at one time by disconnecting fuse blocks seems the best search strategy here, but if someone were to go at this one fuse at a time, a binary search would not be the most efficient under these circumstances.
This is so because we have to consider not the number of "steps" in the search -- binary makes for the fewest steps -- but the number of physical operations, i.e. actually pulling fuses. A "step" can involve many physical operations.
For a 128-fuse case ...
Brute force method, pull one fuse at a time:
- Maximum number of fuses to pull = 128 (all of them)
- Expected number to pull = 64 (in other words, on average we find the bad guy half way through)
Binary search. Always 7 steps ... first pull 64 fuses and test, then test with 32, etc.:
- Maximum number of fuses to pull = 128
- Expected number to pull = 85
Why 85? We pull the first 64 fuses and test. Half the time the trouble is in the 64 fuses not pulled, and we will have to pull 32 more for the second "step". So the expected number pulled after two steps = 64 + (1/2)*32 = 64 + 16 = 80. To execute the third step, on average we pull 1/2 * 1/2 * 16 = 4 more. Then 1, then fractional values we can ignore.
So the expected (average) number of fuses we will have to pull in a binary search = 64 + 16 + 4 + 1 + fractions ~ 85.
So if we think in terms of the number of "steps", binary looks efficient (always 7 vs. average of 64). But measured in terms of physical operations -- what we actually have to do -- for this problem it is 85 for binary, 64 for brute force, and so brute force is a more efficient search strategy here.
At least that's how it looks from here.
Fuse blocks might help reduce the number of steps. Postulating 8 fuse blocks of 16 fuses each, physical operations:
4 fuse blocks disconnected, then 2 fuse blocks disconnected, then 1 fuse block disconnected, then 8 fuses, then 4 fuses, then 2 fuses, then 1.
Physical operations = 4+2+1+8+4+2+1 = 22
Time = 7 days.
Q.E.D. <== (always wanted to use that, and fully expected to be proven wrong now that I have)
#38
11-18-2011, 09:48 AM
Veteran Member
Similar idea, divide and conquer. Indexes are binary trees - root drawer==>branch drawer==>leaf drawer==>table data. Four operations, on average, to find a single piece of data.
The alternative is for the database is to look at every book until the matching books are found, since they are not guaranteed to be stored in order in the table.
One might think that the index operation would always be faster, but that is a common misconception that causes many performance issues.
The alternative is for the database is to look at every book until the matching books are found, since they are not guaranteed to be stored in order in the table.
One might think that the index operation would always be faster, but that is a common misconception that causes many performance issues.
There are variations in height and depth.
Combining indexing and node walking can be beneficial in terms of performance and space utilisation.
In the problem of the fuses, it can be combined by reversing the usual order by walking the fuse box main connections first and then binary searching the remaining fuses once the proper fuse box has been located.
Whether one chooses a pure binary search or a a binary + walk combo, the main point is that an organised search is better than a random search.
#39
11-18-2011, 09:55 AM
Senior Member
Might not be a bad idea, just to check the reliability of the parts store load tester.
#40
11-18-2011, 10:04 AM
Veteran Member
And in real life ...
Search strategies:
Pulling *groups* of fuses at one time by disconnecting fuse blocks seems the best search strategy here, but if someone were to go at this one fuse at a time, a binary search would not be the most efficient under these circumstances.
This is so because we have to consider not the number of "steps" in the search -- binary makes for the fewest steps -- but the number of physical operations, i.e. actually pulling fuses. A "step" can involve many physical operations.
For a 128-fuse case ...
Brute force method, pull one fuse at a time:
- Maximum number of fuses to pull = 128 (all of them)
- Expected number to pull = 64 (in other words, on average we find the bad guy half way through)
Binary search. Always 7 steps ... first pull 64 fuses and test, then test with 32, etc.:
- Maximum number of fuses to pull = 128
- Expected number to pull = 85
Why 85? We pull the first 64 fuses and test. Half the time the trouble is in the 64 fuses not pulled, and we will have to pull 32 more for the second "step". So the expected number pulled after two steps = 64 + (1/2)*32 = 64 + 16 = 80. To execute the third step, on average we pull 1/2 * 1/2 * 16 = 4 more. Then 1, then fractional values we can ignore.
So the expected (average) number of fuses we will have to pull in a binary search = 64 + 16 + 4 + 1 + fractions ~ 85.
So if we think in terms of the number of "steps", binary looks efficient (always 7 vs. average of 64). But measured in terms of physical operations -- what we actually have to do -- for this problem it is 85 for binary, 64 for brute force, and so brute force is a more efficient search strategy here.
At least that's how it looks from here.
Pulling *groups* of fuses at one time by disconnecting fuse blocks seems the best search strategy here, but if someone were to go at this one fuse at a time, a binary search would not be the most efficient under these circumstances.
This is so because we have to consider not the number of "steps" in the search -- binary makes for the fewest steps -- but the number of physical operations, i.e. actually pulling fuses. A "step" can involve many physical operations.
For a 128-fuse case ...
Brute force method, pull one fuse at a time:
- Maximum number of fuses to pull = 128 (all of them)
- Expected number to pull = 64 (in other words, on average we find the bad guy half way through)
Binary search. Always 7 steps ... first pull 64 fuses and test, then test with 32, etc.:
- Maximum number of fuses to pull = 128
- Expected number to pull = 85
Why 85? We pull the first 64 fuses and test. Half the time the trouble is in the 64 fuses not pulled, and we will have to pull 32 more for the second "step". So the expected number pulled after two steps = 64 + (1/2)*32 = 64 + 16 = 80. To execute the third step, on average we pull 1/2 * 1/2 * 16 = 4 more. Then 1, then fractional values we can ignore.
So the expected (average) number of fuses we will have to pull in a binary search = 64 + 16 + 4 + 1 + fractions ~ 85.
So if we think in terms of the number of "steps", binary looks efficient (always 7 vs. average of 64). But measured in terms of physical operations -- what we actually have to do -- for this problem it is 85 for binary, 64 for brute force, and so brute force is a more efficient search strategy here.
At least that's how it looks from here.
The brute force method carries a severe time penalty in that each pulled fuse is both a step and an operation. Each step must be checked for quiescent parasitic current draw. That check requires a waiting time of at least 30 minutes with all systems off.
Ignoring "pull" time, the total waiting times are then:
PHP Code:
brute force: 64 steps * 30 minutes = 32.0 hours
binary search: 7 steps * 30 minutes = 3.5 hours
Last edited by plums; 11-18-2011 at 10:16 AM.