PS3 (Research/Experimental) - NEC/TOKIN Capacitors Replacement - YLOD

[squeept]

I just can't imagine they would randomly fail the rest of the way during shipment, and that the new physical damage is entirely coincidental and unrelated. Because that sawtooth sure as shit wasn't that big before I sent it. I really think it's the spot welds failing. And this got smashed, so it made any pre-existing damage worse.

I bet.... I bet if we start keeping track of the date codes on the failed ones, we're gonna find distinct batches where the spot welder drifted out of calibration. Then you just know from checking the case code that you need to replace them.

 

[Pacorretaco]

Well, too late now. I got impatient and removed it already. I'm not done testing yet but the syscon still shows a 1002 and the YLOD occurs faster now (~2s). I'm going to get some O-scope images of the noise shortly. Then I was going to try removing the tokin on the opposite side of the board (underneath the one that got struck), because that one's plastic was cracked. It looks okay otherwise, but maybe not. Not looking so great for the one bad apple spoils the bunch theory, but I haven't looked at the scope yet.

Oh well, I guess the apple test will be a bit less rigorous now.
Not the end of the world. And, since the 1002 is still there laughing, maybe the test can still have some value.

The competing hypothesis I'm talking about, is that the whole tokin array is degraded below a certain threshold and the noise is just too much now. Not necessarily just 1 of the tokins causing all the problems. (Especially since they weren't shorting, even after taking that violent hit squishing the layers)

So, in order to balance things again, 1 tantalum in parallel would probably no longer be enough now to bring the array back over this minimum threshold. The squished tokin was still pulling some weight, so now i'd expect the machine to require at least 2 or 3 tantalums more. Because you have the oscilloscope, you should be able to see what each of the additions do.


The point of the test is to see if the noise can get better (or good enough to run) "without" removing any suspicious tokins. This is competing with the notion that there's a "bad tokin" that absolutely needs to go.

 

[RIP-Felix]

The point of the test is to see if the noise can get better (or good enough to run) "without" removing any suspicious tokins. This is competing with the notion that there's a "bad tokin" that absolutely needs to go.

Yes, that's a very good point and I realized it this morning...

PS3#7 - Part 5
(Adding a Tantaum Polymer Array in place of C6231)
...continued from part 4 here.​

So I decided before I remove any more NEC/TOKINs it would be a good idea to see what mitigating effect a new TaPol array, one close to equivalent in specification to the tokin it's replacing, would have on the noise. Doing this should have no negative effect upon the testing methodology. If there is still a bad tokin spoiling the bunch, then adding a TaPol array won't fix it. However, it could show the effect of adding back in good caps and leaving tokins in place, which many people perfer.

The problem with this approach, which I have cautioned before, is that your array of caps needs to match the ESR and Capacitance of the TOKIN it's replacing. This is complicated by the fact that ESR only combines the way we've been calculating it for Identical capacitors. Now I'm mixing capacitors with different ESL, which makes the math much more difficult. I'm going to assume that the combined ESR (TaPol + 3 remaining TOKINs) is close enough that I don't need to care, mainly because I don't want to calculate it.

So the caps I chose to use are the 5x ETPSF270M6E. They are 270uF 2.5v 6mΩ ESR. 5 of them = 1,350uF 1.2mΩ. Each NEC/TOKIN was 1.5mΩ, so the extra padding in ESR should be good in case there is an ESL difference that counteracts the combined ESR. Enough writing, MORE PICTURES!!!

I went with a palisades arrangement. This provides the shortest path for current to flow from Vin to Vout. That should minimize the effects of parasitic inductance and resistance, which could be counter productive. I also like that it makes installation and removal easy. The bridge wires are built into the arrangement too. I just used some resistor legs to bridge the contacts and flipped the TaPol caps upside-down. Ideally I want to match the tokin array for both ESR and Capacitance. That would mean 18x for the RSX and 18x for the CPU. That would be 4860uF and 0.333mΩ ESR. I have enough of these left to do this whole console and I want to prove that these B case caps can work, so that's what I'm planning.

I'll remove one tokin then test. I'm hoping to see if there was a bad tokin causing the noise to get worse. That we can get addition by subtraction, so to speak. Once I have measured the noise and characterized the effect on the console, then I'll replace with an array of 4 or 5 TaPol caps and test again.

So for the first TaPol addition here are the results:

Spoiler: 1 TaPol Array added to RSX (C6231 replaced with 5x ETPSF270M6E)

First the console would still YLOD, but it would vary between 5-10s. Usually it would be about 5s long, but I captured a 9.5s event below. There are no more 10 1002 SYSCON errors anymore, they are all 80 1002 now. You can see that all the errors now have time/dates. They're all at the default, because I haven't been able to get in and set the date/time yet, but it does show that the console is getting far enough into the bootup process to initiate the clock and save it to the syscon. Now that all the 10 1002's are gone the clock is staying persistent. It'll only not show the date after you pull the battery, which I must do when removing a tokin or installing a cap array. Then if the console YLOD before the clock update it'll show the error code followed by 0xffffffff. If it completes POST and the clock check, it'll show a timestamp. That seems to coincide with a drop in noise in the RSX filter, so now the console is getting past that point every time...

Noticeable noise decrease in the RSX startup sequence.

Spoiler: 3 Tokins + 1 TaPol array

Spoiler: 3 Tokins only

Spoiler: 4 Tokins, as I received it

CPU noise looks the same, as expected.

The RSX now has multiple smaller peaks between larger peaks. This is the effect the TaPol are having. They are providing current when there is a voltage drop, preventing it from falling all the way down during every switching event. You can see that it's not enough, because each successive charge/discharge get's smaller until it reaches the bottom and there is another large peak. So they are doing their job, smoothing out the power delivery, but there are not enough of them to do the job. So now the large peaks are less frequent. You can see from the measurements they have decreased in frequency about 470KHz to 133KHz. Also the amplitude has decreased from 163mVpp to 144mVpp. Notice that this decrease is still larger than the noise was before with 4x tokins (121mVpp). However, the shape with 4 tokens was the same as it was with 3.

Continued in part 6 here...

 

[marciolsf]

Yes, that's a very good point and I realized it this morning...

PS3#7 Continued...
(Adding a Tantaum Polymer Array in place of C6231)​

So I decided before I remove any more NEC/TOKINs it would be a good idea to see what mitigating effect a new TaPol array, one close to equivalent in specification to the tokin it's replacing, would have on the noise. Doing this should have no negative effect upon the testing methodology. If there is still a bad tokin spoiling the bunch, then adding a TaPol array won't fix it. However, it could show the effect of adding back in good caps and leaving tokins in place, which many people perfer.

The problem with this approach, which I have cautioned before, is that your array of caps needs to match the ESR and Capacitance of the TOKIN it's replacing. This is complicated by the fact that ESR only combines the way we've been calculating it for Identical capacitors. Now I'm mixing capacitors with different ESL, which makes the math much more difficult. I'm going to assume that the combined ESR (TaPol + 3 remaining TOKINs) is close enough that I don't need to care, mainly because I don't want to calculate it.

So the caps I chose to use are the 5x ETPSF270M6E. They are 270uF 2.5v 6mΩ ESR. 5 of them = 1,350uF 1.2mΩ. Each NEC/TOKIN was 1.5mΩ, so the extra padding in ESR should be good in case there is an ESL difference that counteracts the combined ESR. Enough writing, MORE PICTURES!!!
View attachment 31092
I went with a palisades arrangement. This provides the shortest path for current to flow from Vin to Vout. That should minimize the effects of parasitic inductance and resistance, which could be counter productive. I also like that it makes installation and removal easy. The bridge wires are built into the arrangement too. I just used some resistor legs to bridge the contacts and flipped the TaPol caps upside-down. Ideally I want to match the tokin array for both ESR and Capacitance. That would mean 18x for the RSX and 18x for the CPU. That would be 4860uF and 0.333mΩ ESR. I have enough of these left to do this whole console and I want to prove that these B case caps can work, so that's what I'm planning.

I'll remove one tokin then test. I'm hoping to see if there was a bad tokin causing the noise to get worse. That we can get addition by subtraction, so to speak. Once I have measured the noise and characterized the effect on the console, then I'll replace with an array of 4 or 5 TaPol caps and test again.

So for the first TaPol addition here are the results:

Spoiler: 1 TaPol Array added to RSX (C6231 replaced with 5x ETPSF270M6E)

First the console would still YLOD, but it would vary between 5-10s. Usually it would be about 5s long, but I captured a 9.5s event below. There are no more 10 1002 SYSCON errors anymore, they are all 80 1002 now. That seems to coinside with a drop in noise in the RSX filter...
View attachment 31098 View attachment 31093


Noticeable noise decrease in the RSX startup sequence.View attachment 31097

CPU noise looks the same, as expected.
View attachment 31094

The RSX now has multiple smaller peaks between larger peaks. This is the effect the TaPol are having. They are providing current when there is a voltage drop, preventing it from falling all the way down during every switching event. You can see that it's not enough, because each successive charge/discharge get's smaller until it reaches the bottom and there is another large peak. So they are doing their job, smoothing out the power delivery, but there are not enough of them to do the job. So now the large peaks are less frequent. You can see from the measurements they have decreased in frequency about 470KHz to 133KHz. Also the amplitude has decreased from 163mVpp to 144mVpp. Notice that this decrease is still larger than the noise was before with 4x tokins (121mVpp). However, the shape with 4 tokens was the same as it was with 3. Now that the TaPol are there the peaks are sharper (which could indicates harmonics in the triangle wave, probably not a good thing). This suggests to me that mixing these caps is not a good idea. Stick with all tokins or all TaPol or all AlPol, mixing a them may be bad.
View attachment 31095
View attachment 31096

Very interesting findings, and it's awesome to see so many previous assumptions properly tested and documented. Also thanks for including the error code prefixes, I appreciate it.

Your tapol arrangement looks very tidy! This layout and cap selection will probably become gospel truth now It would be good to settle on that front, it would answer all the "which caps should I get?" questions.

EDIT: removed a partial, incomplete and incoherent post

 

[Pacorretaco]

Yes, that's a very good point and I realized it this morning...

PS3#7 Continued...
(Adding a Tantaum Polymer Array in place of C6231)​

So I decided before I remove any more NEC/TOKINs it would be a good idea to see what mitigating effect a new TaPol array, one close to equivalent in specification to the tokin it's replacing, would have on the noise. Doing this should have no negative effect upon the testing methodology. If there is still a bad tokin spoiling the bunch, then adding a TaPol array won't fix it. However, it could show the effect of adding back in good caps and leaving tokins in place, which many people perfer.

The problem with this approach, which I have cautioned before, is that your array of caps needs to match the ESR and Capacitance of the TOKIN it's replacing. This is complicated by the fact that ESR only combines the way we've been calculating it for Identical capacitors. Now I'm mixing capacitors with different ESL, which makes the math much more difficult. I'm going to assume that the combined ESR (TaPol + 3 remaining TOKINs) is close enough that I don't need to care, mainly because I don't want to calculate it.

So the caps I chose to use are the 5x ETPSF270M6E. They are 270uF 2.5v 6mΩ ESR. 5 of them = 1,350uF 1.2mΩ. Each NEC/TOKIN was 1.5mΩ, so the extra padding in ESR should be good in case there is an ESL difference that counteracts the combined ESR. Enough writing, MORE PICTURES!!!
View attachment 31092
I went with a palisades arrangement. This provides the shortest path for current to flow from Vin to Vout. That should minimize the effects of parasitic inductance and resistance, which could be counter productive. I also like that it makes installation and removal easy. The bridge wires are built into the arrangement too. I just used some resistor legs to bridge the contacts and flipped the TaPol caps upside-down. Ideally I want to match the tokin array for both ESR and Capacitance. That would mean 18x for the RSX and 18x for the CPU. That would be 4860uF and 0.333mΩ ESR. I have enough of these left to do this whole console and I want to prove that these B case caps can work, so that's what I'm planning.

I'll remove one tokin then test. I'm hoping to see if there was a bad tokin causing the noise to get worse. That we can get addition by subtraction, so to speak. Once I have measured the noise and characterized the effect on the console, then I'll replace with an array of 4 or 5 TaPol caps and test again.

So for the first TaPol addition here are the results:

Spoiler: 1 TaPol Array added to RSX (C6231 replaced with 5x ETPSF270M6E)

First the console would still YLOD, but it would vary between 5-10s. Usually it would be about 5s long, but I captured a 9.5s event below. There are no more 10 1002 SYSCON errors anymore, they are all 80 1002 now. You can see that all the errors now have time/dates. They're all at the default, because I haven't been able to get in and set the date/time yet, but it does show that the console is getting far enough into the bootup process to initiate the clock and save it to the syscon. Now that all the 10 1002's are gone the clock is staying persistent. It'll only not show the date after you pull the battery, which I must do when removing a tokin or installing a cap array. Then if the console YLOD before the clock update it'll show the error code followed by 0xffffffff. If it completes POST and the clock check, it'll show a timestamp. That seems to coincide with a drop in noise in the RSX filter, so now the console is getting past that point every time...
View attachment 31098 View attachment 31093
Noticeable noise decrease in the RSX startup sequence.

Spoiler: 3 Tokins + 1 TaPol array

View attachment 31097

Spoiler: 3 Tokins only

Spoiler: 4 Tokins, as I received it

CPU noise looks the same, as expected.
View attachment 31094
The RSX now has multiple smaller peaks between larger peaks. This is the effect the TaPol are having. They are providing current when there is a voltage drop, preventing it from falling all the way down during every switching event. You can see that it's not enough, because each successive charge/discharge get's smaller until it reaches the bottom and there is another large peak. So they are doing their job, smoothing out the power delivery, but there are not enough of them to do the job. So now the large peaks are less frequent. You can see from the measurements they have decreased in frequency about 470KHz to 133KHz. Also the amplitude has decreased from 163mVpp to 144mVpp. Notice that this decrease is still larger than the noise was before with 4x tokins (121mVpp). However, the shape with 4 tokens was the same as it was with 3. View attachment 31095View attachment 31096

Nice work.
Now, what you describe is looking very very similar to the L model I posted about a couple times.
I bet if you put another of those tantalum modules on top, the machine will boot.
I initially suggested 4+1. You tried 3+1 and it's almost working. What about 3+2?
It's more or less what I was talking about.

Let's say you now replaced 1 dodgy tokin with a working substitute. Ok. That's now a team of 3 dodgy tokins and 1 new replacement. But that 1 "good' module is almost, but still not able to bring the whole array over the boot threshold.
For the sake of argument, Let's assume the whole group of old tokins was working at say, ~40% of their full health capacity. And the system needs at least 60% to boot. You removed 1 dodgy (now ~30%) and replaced with 1 good (now ~50%?)
So you can still try adding a little bit more, without removing. The thing is almost working.

Of course these are just tests. As you mentioned, there are a number of reasons why this is not advised and is not going to perform like a proper replacement, instead of mixing like madmen. But the findings can be valuable.

 

[RIP-Felix]

PS3#7 - Part 6
(Start-up/Shut-down count and PWR ON time)
...continued from part 5 here.​

Thanks to a "becount" command in the SYSON I was able to obtain this little gem:

223 hours??? I'm mean if that's true this console had a BGA defect from the factory! Remember this was originally an Instant YLOD with a single 40 4034 that @squeept reballed. I can tell you that the motherboard is greener and brighter than any MB I've seen before. Even the ground plane around the outer edge has bright copper. I thought that was weird, but didn't know what to make of it. I've seen about 5 other COK-001 motherboards and none of them have been this dark/bright, but now I'm thinking it's because this console never saw much use before it died. Basically, a manufacturing defect caused it to prematurely fail!

Over the years people have experienced over 1000 YLOD trying to power on this console...lol!

To anyone more up on the SYSCON than I am, is there any way that could be wrong? Is that always counting up, as in nothing causes it to get reset?

EDIT: Now I'm really considering @squeept's speculation about bad laser welds. Another hypothesis I've heard that makes sense is solder fatigue on the tokins. What I don't get is how the tokins could have gotten this bad if the console only ever saw 9 days of use. WTF???

Continued in part 7 here...

 

[Coro]

PS3#7 Continued...
(Start-up/Shut-down count and PWR ON time)​

Thanks to a "becount" command in the SYSON I was able to obtain this little gem:
View attachment 31104

253 hours??? I'm mean if that's true this console had a BGA defect from the factory! Remember this was originally an Instant YLOD with a single 40 4034 that @squeept reballed. I can tell you that the motherboard is greener and brighter than any MB I've seen before. Even the ground plane around the outer edge has bright copper. I thought that was weird, but didn't know what to make of it. I've seen about 5 other COK-001 motherboards and none of them have been this dark/bright, but now I'm thinking it's because this console never saw much use before it died. Basically, a manufacturing defect caused it to prematurely fail!

Over the years people have experienced over 1000 YLOD trying to power on this console...lol!

To anyone more up on the SYSCON than I am, is there any way that could be wrong? Is that always counting up, as in nothing causes it to get reset?

i don't know about syscon...but when webman reports the runtime it seems that any bad shutdowns are not counted. basically the time is added to the count DURING shutdown so bad shutdowns do not get added in.

it would be 253 hours over 347 power cycles. over 1000 cycles didn't add any runtime to the count.

 

[Pacorretaco]

Well, as far as I know, everytime there's an unsafe shutdown, the uptime doesn't increase. So when there are that many, the number is not that accurate.
Would have been nice to check the SMART data uptime of the hdd, but I guess that's not possible now.

Actually high unsafe shutdowns could even be a possible trait /clue of systems with tokin fault. If it's supposed to be common to YLOD under load.
Now that I think of it, my L model with the fault had bizarrely high unsafe count. In the thousands.

Still, that looks like not very used anyhow.

 

[RIP-Felix]

Yeah, but wouldn't we expect the uptime to be higher than that before the tokins started to go bad? I mean, they must have been defective to begin with to have failed so soon. And what could have caused a BGA failure in such a short amount of time?

Sounds like crap quality assurance to me!

 

[RIP-Felix]

Wait a minute...

Weren't a bunch of PS3's used as a super computer or something? I think I remember reading that somewhere. If this console were used as a computer or linux machine and never turned off unless there was a power outage or such, would that explain how it might have had extensive uptime that wasn't recorded?

 

[Pacorretaco]

Yeah, but wouldn't we expect the uptime to be higher than that before the tokins started to go bad? I mean, they must have been defective to begin with to have failed so soon. And what could have caused a BGA failure in such a short amount of time?

Sounds like crap quality assurance to me!

Well, it's a mystery I agree.

My guess is this sytem probably sat unused many years, and maaybe the (defective) tokins also degrade when unused? (Uglier things come to mind too, like the also defective underfill degrades over time unused as well)
Because if it had failed so fart in the early days, it would have been under warranty.

Still it's a mystery.

Anyhow,
@squeept now has a way of checking uptime without webman. How didn't I think of this? It's mentioned in the pdf syscon guide.

(I guess it's because I didn't begin reading it thoroughly until now that I got the dongle in the mail btw)

 

[marciolsf]

Wait a minute...

Weren't a bunch of PS3's used as a super computer or something? I think I remember reading that somewhere. If this console were used as a computer or linux machine and never turned off unless there was a power outage or such, would that explain how it might have had extensive uptime that wasn't recorded?

Yeah, story goes that the air force bought a whole ton of them to run linux and create some kind of cluster -- making linux clusters was all the rage back then.

Found a link! -- US Air Force connects 1,760 PlayStation 3's to build supercomputer (phys.org)

edit: wrong branch

 

[RIP-Felix]

...Anyhow,
@squeept now has a way of checking uptime without webman...

"lasterrlog" and "becount" are internal commands only. @squeept doens't like to perform the endian byte swap needed to get the checksum to match after setting the eeprom to allow internal command access. He's dyslexic. It's easy, but he doesn't trust himself to get it right each time. So he accesses to the ERRLOG in external command mode instead. It doesn't provide as much information, but it gives the codes he cares about and doesn't require him to eff with the checksum.

Yeah, story goes that the air force bought a whole ton of them to run linux and create some kind of cluster -- making linux clusters was all the rage back then.

Found a link! -- US Air Force connects 1,760 PlayStation 3's to build supercomputer (phys.org)

edit: wrong branch

So what you saying is, I might be reversing engineering an air force supercomputer? Lol! Maybe when I get it working I should slap a USAF sticker on it.

 

[squeept]

Playing with the hex editor on the attempted 65nm swap was kind of nerve racking, lol.

As you finish tearing them off, try to capture each time the board is missing one entirely before you put the new ones on. Keeping at the "bad apples" idea and all.

 

[RIP-Felix]

PS3#7 - Part 7
(2nd TOKIN removed, C6232 - plastic was cracked. Side B opposite the one that was damaged.)
...continued from part 6 here.​

On the left above is PS3#7 and on the right is PS3#1 (dead donor board now). Notice the color difference. Most of the boards I've seen are more like the one on the right. @squeept is that normal? Are some boards just greener? Or is that because of your drying oven or cleaning process?

Spoiler: SYSCON, 2 RSX TOKINs removed (C6231 & C6232)

Spoiler: O-Scope, 2 RSX TOKINs removed (C6231 & C6232)

Spoiler: Tokin Delid & inspection

Interesting this this time is that I'm getting primarily 09 3004 (Power Failure). Notice that 09 is sooner than that one 10 1002 I got with just 3 + my TaPol array. Makes sense, this time it had a YLOD in 300ms. Before, 144mVpp wasn't quite enough to make the console pass the startup sequence every time, but close. So I'd say the threshold for getting past POST is less than about 140mVpp. This time I got a similar result...

I only got one 80 1002, but it wasn't long enough for the clock to update (notice the 0xffffffff timestamps continued). Most of errors this time were 09 3004. I like to perform the SYSCON after doing all my o-scope images, because the log fills with a bunch of errors as I mess with scope settings. We get different errors and how often they appear given each change. This time the tokin noise threshold for a 09 3004 is around 144-200mVpp. We can see the larger the amplitude the sooner the YLOD occurs. This confirms what users have been saying all along. Consoles that tended to be fixed with the tantalums capacitors had longer YLODs (grater that 5 seconds).

The large peaks are 200mVpp @92KHz now. It was 144mVpp @133KHz before I removed C6232. So the noise has increased by 56mV. When I removed the first tokin the noise increased by 42mVpp (from 121mVpp to 163mVpp). So it appears that the tokin noise tends to be increased by about 40-50mV for each tokin removed. I was also a bit concerned to see my first TaPol array didn't decrease the noise as much as the tokin did. It only fell 19mVpp (from 163mVpp to 144mVpp). When I replaced all the tokins on PS3#2 with 18x of the same TaPol caps I'm using here, I was getting 20-40mVpp. If there isn't a bad apple spoiling the bunch then the noise reduction must not be a linear decrease. Perhaps the second array will have a larger influence than the first did. We'll see.

Oh...and for some reason the CPU noise unexpectedly increased? I'll keep an eye on it, but WTF??? I didn't even touch them?

Enough for today. I'll try another 5x TaPol array tomorrow...

Continued in part 8 here...

 

[marciolsf]

PS3#7 Continued...
(2nd TOKIN removed, C6232 - plastic was cracked. Side B opposite the one that was damaged.)​

View attachment 31133
On the left above is PS3#7 and on the right is PS3#1 (dead donor board now). Notice the color difference. Most of the boards I've seen are more like the one on the right. @squeept is that normal? Are some boards just greener? Or is that because of your drying oven or cleaning process?

Spoiler: SYSCON, 2 RSX TOKINs removed (C6231 & C6232)

View attachment 31123

Spoiler: O-Scope, 2 RSX TOKINs removed (C6231 & C6232)

View attachment 31126 View attachment 31125 View attachment 31128 View attachment 31124 View attachment 31127

Spoiler: Tokin Delid & inspection

View attachment 31129 View attachment 31130 View attachment 31131 View attachment 31132

Interesting this this time is that I'm getting primarily 09 3004 (Power Failure). Notice that 09 is sooner than that one 10 1002 I got with just 3 + my TaPol array. Makes sense, this time it had a YLOD in 300ms. Before, 144mVpp wasn't quite enough to make the console pass the startup sequence every time, but close. So I'd say the threshold for getting past POST is less than about 140mVpp. This time I got a similar result...

I only got one 80 1002, but it wasn't long enough for the clock to update (notice the 0xffffffff timestamps continued). Most of errors this time were 09 3004. I like to perform the SYSCON after doing all my o-scope images, because the log fills with a bunch of errors as I mess with scope settings. We get different errors and how often they appear given each change. This time the tokin noise threshold for a 09 3004 is around 144-200mVpp. We can see the larger the amplitude the sooner the YLOD occurs. This confirms what users have been saying all along. Consoles that tended to be fixed with the tantalums capacitors had longer YLODs (grater that 5 seconds).

The large peaks are 200mVpp @92KHz now. It was 144mVpp @133KHz before I removed C6232. So the noise has increased by 56mV. When I removed the first tokin the noise increased by 42mVpp (from 121mVpp to 163mVpp). So it appears that the tokin noise tends to be increased by about 40-50mV for each tokin removed. I was also a bit concerned to see my first TaPol array didn't decrease the noise as much as the tokin did. It only fell 19mVpp (from 163mVpp to 144mVpp). When I replaced all the tokins on PS3#2 with 18x of the same TaPol caps I'm using here, I was getting 20-40mVpp. If there isn't a bad apple spoiling the bunch then the noise reduction must not be a linear decrease. Perhaps the second array will have a larger influence than the first did. We'll see.

Oh...and for some reason the CPU noise unexpectedly increased? I'll keep an eye on it, but WTF??? I didn't even touch them?

Enough for today. I'll try another 5x TaPol array tomorrow...

Maybe its interesting to note that I also got a 09-3004 when I removed the bridge wire for the rsx tantalums, and my tantalum arrays were very much inferior to the ones you have in place. Maybe that particular error maps to a breakdown in the connectivity between the capacitors?

 

[Jawad]

Is it possible to replace the capacitors from a fat ps3 who's bricked (ylod) due to fail xploit to a slim one ?

 

[squeept]

I've got all shades on my scrap pile, but they do appear to be darker on average when they have rework done as opposed to the boards I called early due to heatguns. I usually follow near the IPC guidelines on baking and rework times and temps, but sometimes I forget and leave them in the oven for a day or three. ¯\_(ツ)_/¯

 

[Pacorretaco]

Maybe its interesting to note that I also got a 09-3004 when I removed the bridge wire for the rsx tantalums, and my tantalum arrays were very much inferior to the ones you have in place. Maybe that particular error maps to a breakdown in the connectivity between the capacitors?

It's still soon to conclude what a good/bad tantalum replacement looks like.
That's why we can thank Felix here for doing all the tests. To find out.

I guess that looks good yes. But now that you mention that, I'm not sure if those resistor legs in between the capacitors and the board will add any meaningful resistance. My guess is it should be OK, since there are many of them even if they could be thicker. Removal and installation of the modules should be streamlined too. Also it could be easily made more compact to fit more modules in the same space.
A small trade of ease of handling vs taking advantage of the small size of the capacitors and putting them all as close as possible to the RSX.
Yeah It's a trade that makes sense
(those leggy modules make easier to stack in weird configurations for tests, but oh well)

Again, That's the good thing. We don't need to guess

 

[RIP-Felix]

...But now that you mention that, I'm not sure if those resistor legs in between the capacitors and the board will add any meaningful resistance...

Yeah, I'm a bit worried about the resistor legs not being enough to handle all the current once I remove the last tokin. Especially once I get to stress testing. I measured the thickness and it's 0.35mm. That equates to 27AWG and each has a transmission amperage limit of 0.288A. At most I would have four so the total current they can handle together is 1.152A, which isn't enough. That is likely to become a problem. I'll start using 22AWG Solid core instead of resistor legs from now on. Before I do the third tokin I'll replace the other 2 arrays with thicker gauge. Thanks for the reminder!

PS3#7 - Part 8
(Adding 2 Tantalum Polymer Arrays in place of C6231 & C6232)
...continued from part 7 here.​

C6232 is the RSX tokin on Side B of the motherboard opposite the Side A tokin that was struck hard in shipping. This capacitor had the plastic casing broken from the impact, but the inside looked otherwise fine. After it's removal the noise got much worse and the YLOD became instant, so it was functioning somewhat. Now let's turn our attention to the effect the second Tantalum Array is having. Here are the results:

Spoiler: SYSCON, 2 TaPol Arrays on RSX (C6231 & C6232 are ea. 5x ETPSF270M6E)

Spoiler: O-Scope, 2 TaPol Arrays added to RSX (C6231 & C6231 ea. replaced with 5x ETPSF270M6E)

First, the YLOD has pretty much become random. Sometimes it could be called Delayed (10s - 1min), but most of the time the consoles stays booted and doesn't YLOD. It's unstable, and will YLOD easily, but is no longer instant or non-instant - like it was before. You can see there is a significant decrease in the startup noise. The SYSCON shows the 80 1002 has returned and the timestamp is back, meaning the console is not only making POST, but also getting far enough to update the timestamp.

If you recall from my pervious post I was concerned by how much the noise increased and how little effect the first TaPol array had in lowering the noise. I said, "It only fell 19mVpp (from 163mVpp to 144mVpp). When I replaced all the tokins on PS3#2 with 18x of the same TaPol caps I'm using here, I was getting 20-40mVpp. If there isn't a bad apple spoiling the bunch then the noise reduction must not be a linear decrease. Perhaps the second array will have a larger influence than the first did. We'll see." So here it is with 2 arrays...

The noise has reduced from 204mVpp to 85mVpp. A decrease of 119mVpp. So I my hypothesis about noise reduction not being linear was correct. I was expecting this, because of the RLC. I speculate that the tuning of the filter capacitance of 4800uF is the sweet spot. Since the tokins were clearly bad, their capacitance "probably" had fallen outside the ideal range, causing the noise. When I removed one bad cap, the other three were still off. But now that half the caps are good, the total capacitance is closer to ideal, hence the noise reduction is falling in range of the sweet spot. The larger peaks have been completely eliminated and now all we're left with are the smaller ones I noted before. The amplitude has decreased immensely and the console is almost stable in menu. Encouraging results today!!!

Another interesting thing I noted before was that the CPU noise had increased. Well look at it now...

The CPU noise dropped in half (from 60mVpp to 30mVpp) and the "bad waveform" (rectified sine wave) has disappeared! This is the good waveform and if I saw this level of noise I would say there is nothing wrong with the CPU tokins. Apparently the CPU's noise can be affected by the amount of noise on the RSX. This does make sense actually. The two chips are connected electrically and they communicate between one another. So bad tokins on the RSX probably would have cross-talk on the CPU. I didn't expect that, so we're learning good stuff here!

Continued in part 9 here...