Hi;

I'v posted this before. You top techs out there have a chance to one-up
me. I'm not even looking for a symcure here, just advice on where to
look. Somebody helps me nail this one, not only do I owe you a favor,
I'll actually _humble_ myself. That is a rare enough occasion to be
priceless, but I am at a dead end.

The set blanks the video every eight seconds then fades back. Heat does
not affect it at all. I have scoped the ABL line and everything to the
jungle IC and nothing is changing at this rate. The ABL climbs just a
hair when it blanks, but if it were the cause it would be dropping. All
Vccs and inputs are normal.

I have already changed the jungle as well as the micro and it looks as
if the EPROM has already been changed.

If you turn the contrast all the way down and bring up enough
brightness to see something it does not happen. Something is resetting
the control to zero and it's coming back gradually. Sync is not
affected, but I already knew the Y input to the jungle wasn't it.

I have a close enough print, I have a scope and know how to use it, to
be at a dead end is unacceptable.

Let me ask this, possibly someone knows more about just how the data
are sturctured; Can I somehow stop the data from reaching the jungle IC
and have the set still run ? Seems like you would lose control of
everything but the symptom may stay or go. I can probably get the
details on every chip in there as to whether it's a pullup output or
whatever for the clock and data, but not the micro. If you know what
that costs you know why I really don't want to fry it. If you interrupt
the line, I figure the data has already loaded and the chip should
continue to operate. I wouldn't have to mess with the clock line (I
think). If it is feasible to run this test it would prove that it's a
data problem, such as the jungle IC getting reset when a certain pulse
train comes along. Even this is far fetched, but like I said I am at a
dead end.

I usually like a challenge, and I'm the third tech to work on this. I
have confidence in the others' confidence, I know them. They are good,
and nobody butchered anything. They don't work with me now, but one of
them just did happen by today and he's pretty out of ideas too.

This is another one of those cases wher we will end up changing a part
that probably costs less than fifteen cents and it's kinda got me up a
wall. I walked into the bosses office making the "hair pulling out"
motion.

Thanks in advance.

JURB

What kind of TV is it?

I've killed clock and data on a running chassis a couple of years ago
as a test, and the TV continued to run, but I don't remember which
jungle (I think it was a Sanyo).

I figured the model number would give you that, TP55G90 is a Toshiba
with a chassis in the TAC99XX series, built in the nineties.

If what you say holds true on this set, all I need to know now is the
method. Force source, sink or actually interrupt the signal. ???

I am not 100% sure, but pretty sure I have also disconnected the focus
from the fly, eliminating that arcing as a cause. I scoped the outputs
from the jungle and they were still doing it, even though you could'nt
see it on the screen. Just how did you kill clock and data ? If it
helps, this set uses a TA1222 jungle and a TMPA8700 series micro (orig
was a -111CN, replacement is -121CN)

Can you recommend a method to do this that is chip friendly and not
prone to cause damage or flag some other fault mode, thus rendering
confusion ? Others are starting to tell me to get out of the digital
domain and look elsewhere, but the timing is just too perfect and
steady. At the very least I would like to run one test to prove whether
it's in the digital domain or not. Killing clock and data is the only
way I can see. It is the only way to isolate it and get a valid yes or
no.

Incedentally, since the jungle has been changed, I think just killing
the data line should yield the results I need. What say you ? This is
however a Toshiba chipset, not Sanyo.

I've noticed that it is constantly busy, unlike some other sets.
Perhaps one of the other chips in the system is giving an improper
handshake and causing a partial systyem reset. What if one is
responding to the address of the jungle, but in gibberish. ?

Thank you, I think my next step is to do it, isolate, kill or shunt the
data somehow.

Sidestepping myself here, why would the bus be active continuously ?
There shouldn't be a valid reason for that. Quite a few chipsets
address the needed parameters when you adjust the controls and then
pretty much shutup, except maybe or a BLIP-BLIP, ,,,,,,, BLIP-BLIP.

Why would the bus have to be so busy when you are not chaging anything,
nor even addressing any functions ? XDS maybe ?

I guess it is possible, but I'm not sure if this set even has XDS.
Might be too old.

I see no bus expander or MUX/DEMUX chip around, maybe that's why there
is always activity ? Now we're back to why I put a $120 micro in it.
Could this be one of those rare times I should go into the options
mane, write down the settings and start turning things off ? Perhaps
someone has been in there.

It looks like the EPROM has been changed, maybe the guy who did it
threw the "special instructions" in the trash which said "Make sure you
set option code CS02 to 0F0 before attempting to autoprogram the set.
Failure to do so will make it nessecary to replace the EPROM and
perform this function as described herein.

Failure to do so may result in a blanking of the video every 8.37341
seconds."

That would floor me, and I don't think it's likely, but it is entirely
possible.

If this is what the game has become so be it.

Thanks again.

JURB

I figured the model number would give you that, TP55G90 is a Toshiba
with a chassis in the TAC99XX series, built in the nineties.

Hehe...my bad. I looked at the post, not the title.

Just how did you kill clock and data ?
Can you recommend a method to do this that is chip friendly and not
prone to cause damage or flag some other fault mode, thus rendering
confusion ?

I did it by unsoldering the SDL and SCL lands at the IC, leaving the 5v
pull up resistors intact on the board. I temporarily reconnected them
with a couple of common sewing pins, and pulled them out once the TV
was up and running. As for whether it would be chip friendly, I can
only say that it didn't do any harm to the one I tried. Your mileage
may vary.

It looks like the EPROM has been changed, maybe the guy who did it
threw the "special instructions" in the trash which said "Make sure
you
set option code CS02 to 0F0 before attempting to autoprogram the set.
Failure to do so will make it nessecary to replace the EPROM and
perform this function as described herein

Oh boy, don't you love tackling something that's already been futzed
with? I've had several TVs with bad eeproms that I could restore
partial or even full operation by temporarily removing the eeprom from
the circuit (RCAs obviously are the glaring exception) as a test. I'd
try it in your case. If the flashing goes away, there may be an option
bit that may need to be set.

John

Oh boy, don't you love tackling something that's already been futzed
with?

I'm lucky thus far, everybody who worked on it was competent. I know
them. Nobody has any more ideas. They didn't give up easily, and
neither will I, but I'm here now and it's in my lap.

I did say the EPROM looks like it's been changed, or at least the
solder does. Not bad but it's shinier. I wonder just how many sets can
run with no EPROM. Last one I can be sure of is a CTC140. Maybe a
CTC169.

It's very interesting you bring this up, here's a true anectode for ya:
One day I got your typical tuner grounds and EPROM job on an RCA.
However it happened I changed the EPROM with the set plugged in. Fired
the set up and it was exactly like it was before. I expected the H freq
to be out etc., until I realized that I hadn't unplugged the set.

I'm getting close to thirty years in this gig, and that has happened
more than once. More than half of the times no damage ocurred (though
I'll never be able to explain why for sure)

It's got to be a combination of luck and my soldering technique. I can
change a 64+ pin IC maybe ten times without collateral damage, but I
don't think that's special. I think most techs should be able to do it.
In some cases maybe the thing was dead shorted anyway so nothing I
could do could zap anything, except me of course.

This is what happens when you get called away from the bench for other
matters.

I will figure out a way to stop data from getting to the jungle IC, I
need to prove I'm on the right track now, or back up.

Of course at this point I have eliminated or checked so many things I
really don't know what exactly I should back up to !

Even if interrupting data to the jungle stops the symptom, now could it
possibly be any chip on the bus ? Micro, jungle and EPROM ruled out,
then what, take the tuner out ? Find the audio processor, closed
caption and possibly even XDS ?

What a game. In coming years I can see we are going to need drastically
better methods.

I need to know for sure if it's digital, but I'm not going to attack
the EPROM yet because it has no problem storing parameters.

Hmmmmmmmmmmmmmmmmmmmm

Just thought of something. What if it's set to 50Hz sweep ? Could it be
triggering the vertical alright but runs out of range and blanks when
it THINKS it's resetting the sync countdown ? It is not though, the OSD
is perfectly stable and remains interlaced, but maybe it THINKS it's
out of sync ?

I will try what we have discussed, but first I think I'll have one more
look at the service menu.

I might have to temporarily turn this job away, but I am by no means
scared of it. Remember I'm the one who had to adjust vertical centering
to fix a problem with greyscale, and had to reconnect a speaker to get
high voltage.

While I like the challenge, there is a customer out there waiting.

Thanks again, I'll let you know how the results of what I do next turn
out.

JURB

Aha ! ;

Disconnection the SDA line to the jungle stops the problem.

I have reconnected it and thusfar have disconnected everything I could
find on those lines (SDA1 and SCL1) to no avail. Neither print that I
have matches, but between the two of them I got enough on the chipset
to proceed. There is some kind of "level shifter" circuit between
SDA/SCL1 and 2 so I copmpletely isolated them. All of this didn't
affect the problem. I even disconnected the tuners and sure enough, the
snow was blinking out every eight seconds.

There is a rather large "OSD processing IC" something 90091 (MB ?)
which I DLed the datasheet for but was having a hard time IDing the
SCA/SDL, I think it's processed partly somewhere else, but I did lift
the pins of all the Vccs to it but it still didn't fix it.

I think on my next runin with this dog I'll actually disconnect the
SDA1 pin from the micro. The reason that I didn't head for the EPROM is
that it does not share the SDA/SCL and there is no constant activity on
the bus. Of course it could be telling the micro to do something wrong,
so if the SDA from the micro interrupted stops it, it probably is the
EPROM.

Next time around it'll be another thread, we're going to get some money
made the reat of the week if possible.

Thanks again.

JURB

The fix is to initialize the eprom. Follow the proceedure that is
outlined in the service manual for replacement of QA02

Cheers

Jim