Pronto TSU3000 / IRTool Code Conversion Questions

[spowell]

Hello,

I have spent a few hours searching the forums and haven't found any posts relating to my problems, so I'm hoping some one can help me out.

I have 2 ReplayTV remotes that came with the early Panasonic Replays. I have successfully programmed them in the past with TiVo, DVD and TV codes. Recently I bought a Philips 17PF9936 Flat LCD TV and am trying to reprogram the TV functions. I haven't found codes that successfully work for the PC, HD and TV input selection buttons for the TV's remote. I do have a Philips TSU3000 which has successfully learned all the codes. However, when I try to get the information from IRTool on the learned codes IRTool tells me the codes aren't learned codes. The codes look like this ...
PC ... 5000 0000 0000 0001 0003 007B
HD ... 5000 0000 0000 0001 0003 0039

Can some one tell me what I'm doing wrong and point me in the right direction on how to decode these?

Thanks for any help you can provide.

Sean

[johnsfine]

If that format is in a CCF file DecodeCCF will decode them, but IrTool doesn't.

They are the easiest form to decode by hand. You just need to change two numbers from hex to decimal.

The leading 5000 tells you that the protocol is RC5 and that the device is the 5'th value and the OBC is the 6'th.

So PC = RC5:3:123 and HD = RC5:3:57

[Wheelie4]

The Pronto TSU3000 uses PCF's instead of CCF's. A PCF can be unzipped (using winzip, IZArc etc.) and contains the cofiguration bitmaps and an XML file with the pronto hex codes amog other config info. It would be kewl if there was a DecodePCF that decoded PCF's like decodeccf does with CCF's.

[johnsfine]

an XML file with the pronto hex codes amog other config info.

Actually it doesn't contain Pronto Hex. It contains something we nearly (but not totally) understand, which is similar to (maybe the same as) Pronto NEO Hex (which we also only nearly understand).

The ProntoEdit for NG models translates (with some bugs) the Neo Hex to Pronto Hex whenever you ask for it to be displayed and translates (with some more bugs) from Pronto Hex to Neo Hex whenever you change a learned signal.

So you never see or use Neo Hex in the UI.

It would be kewl if there was a DecodePCF that decoded PCF's like decodeccf does with CCF's.

Sure would be, but I don't have time to write it.

[Wheelie4]

Actually it doesn't contain Pronto Hex. It contains something we nearly (but not totally) understand, which is similar to (maybe the same as) Pronto NEO Hex (which we also only nearly understand).

Ok, that explains why the what looked like pronto hex was so short.

Sure would be, but I don't have time to write it.

Ohhh, I didn't realize you wrote decodeccf. Very kewl program.

[The Robman]

Actually it doesn't contain Pronto Hex. It contains something we nearly (but not totally) understand, which is similar to (maybe the same as) Pronto NEO Hex (which we also only nearly understand).

Ok, that explains why the what looked like pronto hex was so short.

Not really. When the Pronto stored the learned signal as raw data, the first word is all zeroes and the complete string is alot longer. However, when the Pronto recognises that the signal is RC-5 (which is a Philips signal) the first word is "5000" and the raw data is much shorter (as is the case here). If this had been an NEC signal (for example) the data would have been more like what you would have expected.

[Wheelie4]

ok, I just looked farther down the XML file and see more pronto hex codes the length I'm more use to pasting into Prontoedit. I do remember reading at RemoteCentral something about ProntoEditNG cleaning up and shorting the hex codes to save file size or something like that. I'm not to clear on the subject.

[johnsfine]

ok, I just looked farther down the XML file and see more pronto hex codes the length I'm more use to pasting into Prontoedit.

I thought the hex in the XML file was all formatted as two digits per value. Pronto Hex is always formatted as four digits per value. So nothing in the XML file should look very much like Pronto Hex.

I do remember reading at RemoteCentral something about ProntoEditNG cleaning up and shorting the hex codes to save file size or something like that. I'm not to clear on the subject.

There are a whole lot of interacting processes involved in that.

1) There are formats for Pronto Hex (such as the 5000 format you posted) which are very dense, because they represent the logical content of the signal rather than a detailed recording of the signal.

For all models of Pronto there is logic somewhere in the handling of IR signals to match the detailed recording of a signal against one of the known patterns and store it the dense way if it matches.

So far as I know, the Neo Hex lacks those dense formats, so Pronto Hex in a dense format must be translated back to detailed format and the pattern matching to get to dense format must be recomputed every time you display the Pronto Hex. Because the pattern matching is done at a different stage and more often, there are cases where an NG model will apparently convert to dense format when an older model wouldn't.

2) There are various generic rules about the structure of IR signals and most IR signals that don't fit those rules are that way because they were badly learned. So, in theory, you can "clean" an IR signal by fixing the places where it doesn't fit generic rules. In practice it doesn't work very well. The newer models do more signal cleaning, so there are more cases of signals destroyed by the cleaning process. (I think that to get good clean signals, you need to pattern match the dirty signal against a large library of known structures, with a tool like DecodeIR and then reconstruct the signal with a tool like MakeHex),

3) There are limits (often inconveniently small) on the maximum length of Pronto Hex strings. Apparently those limits are even smaller in the newer models. Given Pronto Hex of a length that's OK in an older model but too long in a newer model, ProntoEdit applies rules that would fix a signal that was too long because of some simple failure to see the repeat pattern during the original recording process, but totally trashes the signal if it was too long for other reasons.

[spowell]

Thanks guys, that's exactly what I was looking for. I was hoping there would an easy solution. I have to confess, I'm a scripter/programmer by day, and this stuff still easily confuses me even after reading all f the documentation.

My Replay Remotes (though I love them to death) are a bit limited, so I think I may go out and buy a JP1 remote with more advanced capabilities. Is there a current list of available remotes some where? I looked at Robman's page but the remotes look like the same ones from last summer when I originally started programming the Replay remote. Has the list really not changed, or is there a newer list I haven't founs somewhere yet?

Robman ... I saw in many posts that you are the Replay Remote expert ... is it true that the Replay Remote can't learn, do macros or do 'shift' codes?

Thanks again guys ...

[spowell]

Ok, I should have looked harder. I see that Robman's remotes for sale post seems to have all the current versions.