RCA ColorTrak TV (20 years old)

jon_armstrong · Post by **jon_armstrong** » Sun Dec 07, 2003 8:32 pm

Steve,

I am surprised that it doesn't work. But, I have seen stranger cases. Let me start with the basics. Did you upload my IR image in your 8810w directly? If you did the upgrade to your current configuration, did you select TV_1999 in the "General" tab?

usblipitor · Post by **usblipitor** » Sun Dec 07, 2003 8:53 pm

Small Problem:

Pressing 3-3 gives channel 31
Pressing 7-7 gives channel 75
Pressing Power gives Power then LastChannel

It is very close. As it is now I can use the upgrade to turn on and off the TV

usblipitor · Post by **usblipitor** » Sun Dec 07, 2003 9:00 pm

jon_armstrong wrote:Steve, I am surprised that it doesn't work.

It almost works! I am very impressed with that Jon! You really know your stuff!

jon_armstrong wrote:But, I have seen stranger cases. Let me start with the basics. Did you upload my IR image in your 8810w directly?

Yes, I sure did!

jon_armstrong wrote:If you did the upgrade to your current configuration, did you select TV_1999 in the "General" tab?

It was already selected when I got there!

BTW I have a side question: when I took your work and changed from 2 device bits/8 function bits to 3 device bits/7 function bits (I did this since the first 3 bits are always zero) the thing no longer worked. Is there somewhere else I need to change also?

Any idea why the numbers keep changing what they send (always send one of two numbers, like the 3 sends either 3 or 1 I think)

jon_armstrong · Post by **jon_armstrong** » Mon Dec 08, 2003 7:57 am

Steve,

Try learning with the OEM remote and learn two succesive button pushes of the same command. Learn the Zero button to zero on your 8810. Then learn the Zero button again to the 1 button on the 8810. Repeat the process from OEM buttons 1 through 4. Those should then be on numerals 2 through 9 on the 8810.

Steve on the 2/8 or 3/7 arrangement -- and the reason I choose 2/8 -- is that UEIC protocols always start at the top bit when using less than 8 bits. If you take the function values calculated in 2/8 and multipy by 2 then it would work. Basically you are moving everything over one bit to the left and placing a zero in the bottom bit that is ignored.

The reason is that most protocols use LSB first and the bits are "backwards" 10000000 is ONE (not 128) in LSB first. So in that case ONE will always be correct in any byte width>0.

usblipitor · Post by **usblipitor** » Tue Dec 09, 2003 12:37 am

Hi Jon,

You and Jason (and John) are excellent teachers. Words cannot express my thanks for explaining LI, LO, one, zero, etc, and pointing me at the protocol_builder_spreadsheet. It is interesting and fun to learn more and more about JP1.

jon_armstrong wrote:Try learning with the OEM remote and learn two succesive button pushes of the same command. Learn the Zero button to zero on your 8810. Then learn the Zero button again to the 1 button on the 8810. Repeat the process from OEM buttons 1 through 4. Those should then be on numerals 2 through 9 on the 8810.

OK, I did this, and the learned signals are identical on 0,1 ("0"); 2,3 ("1"); 4,5 ("2"); 6,7 ("3"), and 8,9 ("4"), so not much help to us in this case, but it was a good thought and worth a try.
I discovered that sometimes the 8810w remote will work properly, but after a few minutes of channel changing with the number keys, the problem starts in again. Once the problem begins, even the OEM remote does not change channels correctly. After several minutes of the TV being off, or waiting for afew minutes, or maybe it is the phase of the moon

, things are working again. When using the OEM remote and having things working ok, the weird problem never starts. But using the 8810w and pressing channel digits, eventually the problem starts. My theory, which is probably wrong, is that somehow having the correct LI burst pair keeps the IR receiver happy. Since the original remote sends the LI, it never causes the problem to start. The 8810w does not send the LI, so my theory is that without the LI, the IR receiver eventually becomes unhappy and goes into a corrupt mode where it does not interpret the signal correctly. My theories are usually wrong, BTW

Happy Holidays,

johnsfine · Post by **johnsfine** » Tue Dec 09, 2003 7:52 am

That theory sounds exactly right to me.

Jon usually does better than I do at making PB alone generate the right thing, so he might still think of some trick I've forgotten. But I'm pretty sure PB alone can't do this right.

I was hoping to find time for the following approach (but don't know when I will):

Use PB to create the protocol for just the first frame, without leadout.

Hand patch the output of PB adding ASM code to:
1) Call the ROM routine to transmit just one frame.
2) Patch the parameters to change the Lead in
3) Maybe it is OK to just jump to the normal routine at that point.
or maybe the first patch needs to set the new lead in as both lead in and lead out, then call single frame once more, then patch the new lead in to be lead out only and finally jump.

usblipitor · Post by **usblipitor** » Tue Dec 09, 2003 8:43 am

any readme files out there that talk about how to do this? For me, the best way to learn about something is to have a project and do it, but in this case I am not sure where to start. I used to be able to write small fast code in assembler and call it from (haha) GWBASIC, and do cool things on 8086 machines way back before I chose a different path in life. I should be glad. Knowing my curiousity about things, I probably would have gotten into some trouble. I would imagine that there were orders of magnitude more buffer overflow errors to be exploited in the early 1980s than there are today.

jon_armstrong · Post by **jon_armstrong** » Tue Dec 09, 2003 4:27 pm

johnsfine wrote: Jon usually does better than I do at making PB alone generate the right thing, so he might still think of some trick I've forgotten. But I'm pretty sure PB alone can't do this right.

The only reason that I could do better (which is doubtful) is that my assembly language skills are very thin, so I don't have another choice

I agree, I can't see any way for PB can't do this one.

Steve, as far as referneces Rob posted "Fully commented source code for the NEC/5A protocol" in the files|protocol notes at the JP1 group and the S3C80 manuals http://groups.yahoo.com/group/jp1/links ... 991179289/ have the instruction set.

NEC has nothing to do with the RCA(ancient) -- sorry we already have an RCA (old) -- protocol, but it may give you some idea of how they work.

johnsfine · Post by **johnsfine** » Fri Dec 12, 2003 12:16 pm

I took a fairly wild stab at this
Upgrade protocol 0 = 01 C1 (S3C8)
3E 87 11 8B 16 85 21 02 08 03 24 03 10 00 C9 05
6B 00 00 09 60 03 3E 0E 74 02 76 1C 22 F6 01 4C
8D 01 46
End

I tried a method I never tried before (plus I could have made other errors) so odds are it won't work. When I'm near a couple remotes again I'll learn from one to another and probably fine tune this.

jon_armstrong · Post by **jon_armstrong** » Fri Dec 12, 2003 1:08 pm

Looks right to me (meaning I tested it for numeral 1.) So what did you do differently?

johnsfine · Post by **johnsfine** » Fri Dec 12, 2003 1:17 pm

You already did a learn from one remote to another?

1) I used Lead-Out style 1 instead of the "Burst Mid-Frame" to create the Lead out. That just simplifies things a little, it shouldn't change the results of what you did.

2) I added an extra burst pair definition for the one-time lead in (manually inserted it after all the ones defined by PB and changed the initial JR to take it into accout).

3) I added two instructions
LD W1, #22
CALL 014C
which do a raw send of a single burst pair. The #22 identifies which burst pair definition to send and is the number for the one I added.

I wasn't sure that you could transition smoothly from sending a burst pair this raw way to sending the rest the ordinary way. I thought it might add some delay on that boundary (make the off time of that first burst longer than it should have been).

jon_armstrong · Post by **jon_armstrong** » Fri Dec 12, 2003 1:29 pm

Yes I did learn the commands, for numeral 1:

Once:
+7374 -1322 +400 -2814 +400 -2814 +400 -2814 +1600 -1614 +1600 -1614 +400 -2814 +400 -2814 +400 -2814 +1600 -1614 +1600 -1614 +4774 -1722

Repeat:
+400 -2814 +400 -2814 +400 -2814 +1600 -1614 +1600 -1614 +400 -2814 +400 -2814 +400 -2814 +1600 -1614 +1600 -1614 +4774 -1722

Maybe the off time is a little long I think it averaged about 1200 in the learned comands but that is from memory and I don't think I calculated it.

johnsfine · Post by **johnsfine** » Fri Dec 12, 2003 1:41 pm

-1322 is enough longer than what I tried for that I think it does show the transition isn't smooth. That could be hard to cover for in some faster protocols where I'd also like to try this trick. It also likely means that the old S3C80 remotes will show a timing difference vs. the new ones. I'll need to experiment a little to see if all that is real.

Meanwhile, the 02 76 near the middle of the protocol is that value. If we reduce that number a little it ought to average close enough to correct to satisfy the real device. (here I'm reducing it to 02 3A).
Upgrade protocol 0 = 01 C1 (S3C8)
3E 87 11 8B 16 85 21 02 08 03 24 03 10 00 C9 05
6B 00 00 09 60 03 3E 0E 74 02 3A 1C 22 F6 01 4C
8D 01 46
End

jon_armstrong · Post by **jon_armstrong** » Fri Dec 12, 2003 2:09 pm

I had actually tested the first ones in a 1994. Here are the results from the SECOND protocol upgrade in an 8811 for the one time lead-in:

+7410 -1170

I tested Numerals 1,2, and 3 and they were identical.

On the SECOND protocol upgrade using the 1994 Numerals 1 and 2 were:

+7386 -1188

and three was:

+7350 -1224

jon_armstrong · Post by **jon_armstrong** » Fri Dec 12, 2003 2:20 pm

BTW, I calculated the average time for the original learned commands:

7463 -1064

I tried 01 FA on the 8811 and got:

+7410 -1042

If you, John, think that is close enough I added 0xF for 02 09, then Steve it is:

Upgrade protocol 0 = 01 C1 (S3C8)
3E 87 11 8B 16 85 21 02 08 03 24 03 10 00 C9 05
6B 00 00 09 60 03 3E 0E 74 02 09 1C 22 F6 01 4C
8D 01 46
End