Philips 32PF9731D LCD TV

[joedaring]

Hellò all,
I've been working on this for the past two days but no joy so far... I'm sorry to say I need to grab some of your time again with an issue

Recently changed my TV set with a new Philips LCD TV mod. 32PF9371D, and thought it would have been trivial to include a new upgrade on my 9960 B01 and put the original remote in the bottom drawer... well... I must be doing something wrong since I still can't...

So, here is the template:

1. Device: Philips 32PF9371D LCD TV (Remote is RC4401/01)
2. Type of device: LCD TV
3. Year: 2006
4. UEI Remote model: 9960 B01
5. Do you have a JP1 cable? Yes!
6. Still have original remote? Yes!
7. Checked the file section? Yes! There is one that, at first sight, seems very similar to what I need: link
...but it simply doesn't work... when I push any button, the IR emitter flashes, but the LED on the TV doesn't blink at all for almost any of the commands.

8. Checked Pronto file section (at R/C)? Yes! There is something that looks quite similar to what I need: link
Also the remote depicted in this .ccf resembles somehow the one I have...
But the codes in it are, as far as I can see, the same that are already in the TV 1556 RC6 Upgrade I linked above, plus they are almost all NOT learned codes and, anyhow, they can't be decoded by IRTool

9. Partially working setup code? Actually, I had limited success with this Upgrade file from the Files Section: link
...which is an RC5 upgrade and is the one I used as a template for my old TV. With this upgrade the numbers work, plus some other keys like the TXT key...

10. Learning remote question? Yes, I tried to learn some of the keys from the original remote, of course, but the decodes I see in IR are ordinary-looking RC6 Dev. 0 learns... BTW the learnt keys DO work, while any attempt to put the same codes as the decoded leans into an RC6 upgrade yeld no appreciable result...

Finally, I posted a file in the diagnosis area: link

This file has some keys learnt from the original remote (...and learns DO work!), as well as a TV1556 RC6 Upgrade with some of the codes taken from the learns... this upgrade doesn't work!

Whew! This was quite a writing! Hope I have given enough details but, if I didn't, please bear with me and let me know what is missing...

Just want to say thank you in advance, and sincerely hope it is something stupid I did, instead of this bing an issue requiring too much of your time!

My regards,
Joe

[Capn Trips]

Although you've provided a vast amount of info (thanks!) I think one missing piece would be your actual KM or RM file for the TV. This is easier to compare to your learns than the code in IR's Devices Tab.

Having said that, a few observations:

(1) How is it that your remote has TWO signals learned to the Vol+, Vol-, and Mute buttons in VCR mode? That SHOULD be impossible!
(2) Many of your learns do not decode, but since SOME decode, they all should. Are you sure your technique is good? (See some of the pointers in THIS LINK)

Also, You should annotate the Notes in your learned signals tab with the actual function you are learning, so that one can tell what one is decoding.

(3) Now this is a wild speculation, and I may be able to see better from the above-mentioned KM/RM file, but your TV/1556 upgrade in IR has fixed data of 80 00 for PID 00 58 (RC 6). If I enter RC 6 protocol, device 0 in KM, I get different fixed data 95 30 55 55 which leads me to believe you have incorrectly built the upgrade, but without seeing it, I'm not smart enough to comment. Others are capable of reverse-engineering from your IR upgrade data what parameters you entered in KM/RM, but I am not.

[johnsfine]

8. Checked Pronto file section (at R/C)? Yes! There is something that looks quite similar to what I need: link
Also the remote depicted in this .ccf resembles somehow the one I have...
But the codes in it are, as far as I can see, the same that are already in the TV 1556 RC6 Upgrade I linked above, plus they are almost all NOT learned codes and, anyhow, they can't be decoded by IRTool

You should decode a CCF file with the DecodeCCF program, not with IRTool.
http://john.fine.home.comcast.net/ir/decodeCCF.zip

Finally, I posted a file in the diagnosis area: link

This file has some keys learnt from the original remote (...and learns DO work!), as well as a TV1556 RC6 Upgrade with some of the codes taken from the learns... this upgrade doesn't work!

How did you fill in the functions sheet for that upgrade? The EFC numbers in that upgrade don't match the ones you've specified from every other source (learned signals, that CCF, etc.).

Edit: I should have read Capn Trips's reply more carefully before I replied, because this is a bigger issue than the things I mentioned:

(3) Now this is a wild speculation, and I may be able to see better from the above-mentioned KM/RM file, but your TV/1556 upgrade in IR has fixed data of 80 00 for PID 00 58 (RC 6). If I enter RC 6 protocol, device 0 in KM, I get different fixed data 95 30 55 55 which leads me to believe you have incorrectly built the upgrade, but without seeing it, I'm not smart enough to comment. Others are capable of reverse-engineering from your IR upgrade data what parameters you entered in KM/RM, but I am not.

That says the KM version Capn Trips used believes that the 9960B01 has the new version of the RC6 executor built-in. It is probably correct.

The rdf file and protocols.ini that I have for RM generate an RC6 upgrade for the old version of the RC6 executor for the 9960B01. It sounds like we need to get a correction out for that.

[joedaring]

Hellò Can'Trips and Johnsfine... thanks a lot for your replies...

I believe you went right to the core of the trouble:

(3) Now this is a wild speculation, and I may be able to see better from the above-mentioned KM/RM file, but your TV/1556 upgrade in IR has fixed data of 80 00 for PID 00 58 (RC 6). If I enter RC 6 protocol, device 0 in KM, I get different fixed data 95 30 55 55 which

That says the KM version Capn Trips used believes that the 9960B01 has the new version of the RC6 executor built-in. It is probably correct.

I also had noticed that KM gave me those different numbers, and that rang a bell in my head, but I'm not that deep into JP1 to tell that was the problem... reading your comments now I realize this is the right clue!

Unfortunately, I'm not sure I can actually use KM reliably, because Excels complains that the names of some of the Analisys functions aren't found... I have the Italian version of Excel...

Johnsfine, you are right about the .ccfs... I didn't decode the full.ccf with IRtool... just tried to decode SOME of the codes INSIDE the .ccf, which I opened (actually imported) with ProntoProEdit NG...

Capn'Trips the learns you find in my IR file are probably the worst I've ever done... I was very tired and didn't feel like re-learning them! I saw some of them were OK and supposed these ones were enough to have something to compare...

BTW I have noticed that, with this new remote (The original one from the TV, I mean...) I have to be extra-careful during the learns, or I get some bad decodes very easily...

Anyway, there are a couple of key, which I still didn't tell you about, that I believe will need some extra knowledge from you to be implemented, since, when learnt, IR (Actually the decode dll I believe...) complains about not being able to decode them... they are two keys used to activate and modify the ambient lighting system this TV has on the back panel... it is called "Ambilight".

I'll pose a specific question when the basic upgrade is working... with your very valuable help...

So, do you still need something else from me, or the need to modify protocol.ini and .rdf for my remote is a matter-of-fact and doesn't need more info?

I'm very grateful for your help, guys... great team here!
Ciao
Joe

[johnsfine]

You still haven't explained where you got the EFC numbers (or OBC or Hex or whatever you used) for the functions sheet in RM. The EFC numbers in the upgrade inside your .ir file make no sense.

It make take us a while to fix this. Meanwhile you may want to get your upgrade working. It would be larger than the correct way, but other than size it should be fine:

I assume the RDF file you are using is
KASAKAS0 (URC-9960 B01 One For All Kameleon).rdf

Edit that file (open it in Notepad or similar program)

Near the bottom is a line that says
002D, 002F, 0034, 003F, 0045, 0046, 0058, 005A, 005C, 005D,
change it to say
002D, 002F, 0034, 003F, 0045, 0046, 0058:2, 005A, 005C, 005D,

That tells RM that the RC6 executor (PID 0058) in your remote is not the standard version, so RM will know that a standard RC6 upgrade won't work with the built-in executor, so RM will build the standard device upgrade but also include a protocol upgrade that will make the standard device upgrade work.

After we fix RM to do this right, it will instead generate a device upgrade that works with the built-in executor.

Of course none of that will work unless the EFC numbers in the functions sheet are also correct.

[Mark Pierson]

Unfortunately, I'm not sure I can actually use KM reliably, because Excels complains that the names of some of the Analisys functions aren't found... I have the Italian version of Excel...

Can you be a little more specific regarding the message you receive? KM does have support for the Italian version of the Analysis ToolPak, so it's likely another setting you need to change in the MS Office Language Settings. Try this:

Click the Start button on your taskbar.
Select All Programs
Select Microsoft Office
Select Microsoft Office Tools
Select Microsoft Office Language Settings
Set English (U.S.) as one of the Enabled Languages

[joedaring]

Hi all,

Since you asked for more... here we go!

To Johnsfine, Capn Trips, Mark Pierson...

About the EFC in the upgrade... with all the trials I did, I may have left in some EFC from some other Philips upgrade file I've found and tried... Or, more probably, I tried some OBC entering them in RM with the wrong RDF for my 9960B01... sorry if this added to the confusion... it is amazing that notwithstanding all the mess, you still can see the light! Sorry again...

I checked the IR file again, and the majority of the codes I see in there match what I get when I learn the keys...

But I did some steps forward...

Thanks to Mark, that suggested the workaround of the edited RDF, now I have a partially working RM Upgrade...

The new upgrade uses the additional RC6 protocol and has almost ALL the keys working... unfortunately ALL of the number keys don't work!

These are the only keys that don't work so far, but bear in mind that there are still some EFCs I will try to add later, once I'm sure the upgrade works fine.

To help with this new challenge, I have upload the following .zip file:
https://www.hifi-remote.com/forums/dload ... le_id=3826

This archive contains the RM Upgrade built wth the RDF modified as per Mark's suggestions, and the IR dump of my 9960 B01 setup with the generated upgrade and protocol added...

Please note that on TV Keys 7 & 8 I have learnt keys 7 & 8 from the original remote, to give you something to compare with the non-working number keys generated by the upgrade.

Finally, to answer Mark's question about the KM 9.05 that complains about being used in an Italian Excel environment, I uploaded the following file:
https://www.hifi-remote.com/forums/dload ... le_id=3827

It is actually a screen hardcopy composition of the error I get upon startup and the additional Tools dialog open to show what's enabled.

OK, all for now... hope to get some other hints and workarounds to progress toward a complete solution... sorry for giving so much troubles!

BTW, the way this thread has evolved doesn't look very in-topic anymore to me... it is more belonging to the "Software" category than to the "Code Search" one... if one of the moderators feels appropiate to move it, please do so... it is fine with me, of course!

My regards, guys!

Joe

[Mark Pierson]

Finally, to answer Mark's question about the KM 9.05 that complains about being used in an Italian Excel environment, I uploaded the following file:
https://www.hifi-remote.com/forums/dload ... le_id=3827

It is actually a screen hardcopy composition of the error I get upon startup and the additional Tools dialog open to show what's enabled.

Did you try what I suggested above? That should solve the problem.

[johnsfine]

About the EFC in the upgrade...

I checked the IR file again, and the majority of the codes I see in there match what I get when I learn the keys...

The new upgrade uses the additional RC6 protocol and has almost ALL the keys working... unfortunately ALL of the number keys don't work!

I looked first at the digits when I concluded that most of the EFC numbers are wrong. And I was only able to look at them in IR, because you hadn't yet posted the .rmdu file.

Now it looks like we have another software problem. The digit EFC numbers are correct in RM but incorrect in IR.

Both RM and IR have built-in knowledge of the digit table structure, but they seem to disagree. Since the digits don't work, I can conclude RM is wrong (which doesn't necessarily mean IR is right).

Hopefully Greg can sort that out soon.

Edit: As I look at this more carefully, maybe Greg (or someone) already did sort it out and you have an obsolete version of something.

In your .ir file the second byte of the upgrade is 18. It should be 19. You can see/change that by going to the Devices tab and clicking on TV:1556 in the left panel, then click the edit button. See that the upgrade begins with 58 18. It should be 58 19.

So I assumed RM got that second byte (the index into the digit table) wrong. But I loaded up your rmdu file and RM gets it right (so it doesn't match what you pasted into IR from your copy of RM). So either your RM or your copy of the RDF file has an error that my copy doesn't have.

It's probably simplest to first fix the 18 to be 19 in that edit dialog in IR and verify that works (that my copy of IR and the RDF agree with the actual 9960B01). Then later you can figure out what made your RM get that wrong.

[gfb107]

The problem with the digits is most likely an error in the DigitMaps section of the RDF. I'm not enough of an expert to know how to check those values.

[johnsfine]

Greg, I was typing an edit to my post above while you replied. That edit significantly changes theory.

[gfb107]

OK. Too bad that none of the standard notes that are included when importing a device upgrade from RM/KM into IR are present in his .ir file. At least we would then know what version of RM he is using.

I've just about got 0058:2 coded in protocols.ini and ready for a release. Took a bit to figure out that it uses bit-doubling to store the device number in the fixed data.

[joedaring]

Wow!
Quite some activity on my problem, I see! Guys, thanks a bunch! I could not have made any progress without your help...

It seems I have catalyzed the interest of almost all of the experts on the forum with this thread... thanks again!

OK, now for some comments to your posts...

Finally, to answer Mark's question about the KM 9.05 that complains about being used in an Italian Excel environment, I uploaded the following file:
https://www.hifi-remote.com/forums/dload ... le_id=3827

Did you try what I suggested above? That should solve the problem.

Yes, Mark, I follow EVERY advice I receive from experts... . English (US) is among the enabled languages in my Office Environment... it is not the preferred one, but I also tried to change the preferred language to English (US) (It is "Inglese (Stati Uniti)") in my Office 2003, to no avail...

To Greg and Johnsfine:

In your .ir file the second byte of the upgrade is 18. It should be 19. You can see/change that by going to the Devices tab and clicking on TV:1556 in the left panel, then click the edit button. See that the upgrade begins with 58 18. It should be 58 19.

So I assumed RM got that second byte (the index into the digit table) wrong. But I loaded up your rmdu file and RM gets it right (so it doesn't match what you pasted into IR from your copy of RM). So either your RM or your copy of the RDF file has an error that my copy doesn't have.

And:

The problem with the digits is most likely an error in the DigitMaps section of the RDF. I'm not enough of an expert to know how to check those values.

About the RDF... a while ago I edited it manually as per the following post found in another thread:

The curent URC-9960B01 RDF (KASAKAS0) has an incomplete DigitMaps section, left over from before we figured out how we were going to support the multiple-byte entries (the 9960B01 being the first one we found to have them). Here's an updated section:Code:
[DigitMaps]
072 048 053 094 092 003 302 090 044 046 086 087 010 187 188 058
083 147 011 126 023 081 016 001 127 034 032 021 075 033 030 029
295 301 064 013 091 270 199 209 145 170 131 093 141 208 212 278
This should be included in the next RDF release.
_________________
Mike England

I did it in an effort to keep files updated and before actually editing the RDF I placed a question in the same thread to ask if I run any risk of doing any harm to the RDF... May this editing be the cause of this trouble?

In your .ir file the second byte of the upgrade is 18. It should be 19. You can see/change that by going to the Devices tab and clicking on TV:1556 in the left panel, then click the edit button. See that the upgrade begins with 58 18. It should be 58 19.

So I assumed RM got that second byte (the index into the digit table) wrong. But I loaded up your rmdu file and RM gets it right (so it doesn't match what you pasted into IR from your copy of RM). So either your RM or your copy of the RDF file has an error that my copy doesn't have.

It's probably simplest to first fix the 18 to be 19 in that edit dialog in IR and verify that works (that my copy of IR and the RDF agree with the actual 9960B01). Then later you can figure out what made your RM get that wrong.

OK, John... did the edit in IR and Hey Presto! The numbers DO work now!

So, now I have an IR image that, when upload to the 9960 B01 makes for a working remote... it would be nice now to have all the corrections embedded in the RDF, the protocol.ini and any other file involved, but I'm sure you are already working on this!

OK. Too bad that none of the standard notes that are included when importing a device upgrade from RM/KM into IR are present in his .ir file. At least we would then know what version of RM he is using.

I've just about got 0058:2 coded in protocols.ini and ready for a release. Took a bit to figure out that it uses bit-doubling to store the device number in the fixed data.

Greg, what standard notes are missing in my files? Sorry if this is the case, but I can't remember deleting any notes from my files... is it something wrong I did???

Anyway, I'm using the latest version of all the involved software... at least the newest version made available to the public:
RM is V 1.68
IR is the V7 beta 2
The RDFs Maps and Image files are in the V 1.25 archive, with the exception of the edits I did to the KASAKAS0 RDF as per your kind suggestions...

Well... I hope it won't take long to finally close this thread, but thank you all for your efforts so far... as I said, great support team here!

Ciao!!! Joe

[gfb107]

The device upgrade generated by RM should look something like

Code: Select all

Upgrade code 0 = 16 14 (TV/1556) Philips TV 1556 (Custom for 32PF9731D/10) (RM v1.69)
 58 19 7E FC FE C1 95 30 55 55 10 11 0D 20 21 0C
 38 54 58 59 5A 5B 0A 0F 5C 5D 12 13 3C FB FC F5
 40 CC
KeyMoves
 2D F0 04 16 14 00 29«Red (Demo)»¦
 2E F0 04 16 14 00 41«Green»¦
 2F F0 04 16 14 00 39«Yellow»¦
 30 F0 04 16 14 00 91«Blue»
End

There's a significant portion of that upgrade that should be imported into IR as notes.
Specifically the text "Philips TV 1556 (Custom for 32PF9731D/10) (RM v1.69)" is attached as a note to the device upgrade. This note included the RM version.

In addition, the "Red (Demo)", "Green", "Yellow" and "Blue" will be attached as notes to the keymoves generated for those functions.

It may just be that you've turned off the "Include embedded notes in upgrades (requires IR 5.01 or later)" check box on RM's output tab.

[binky123]

The RDF digitmaps section should be updated to be:

Code: Select all

[DigitMaps]
072 048 053 094 092 003 302 303 090 044 046 086 087 010 187 188
058 083 147 011 126 023 081 016 001 127 034 032 021 075 033 030
029 295 301 064 013 091 270 271 199 200 209 210 145 170 131 093
141 208 212 278 279

Some of the 2-byte digitmaps were missing the second index entry.