I decoded them with IrTool and DecodeIr. Those are

Off = Sony12:1:21

Options = Sony15:151:54

Return = Sony15:151:35

Then I looked up the list of Sony15:151 codes here:
[Link: hifi-remote.com]

It says 54 is "Tools" and 35 is "Return". So that list looks like it would be pretty compatible with your TV. You can generate all those codes with MakeHex if there are any you don't have yet that you want to test.

In the connected set of Sony12:1 codes (top of that page) it says command 21 is power toggle. You say it is "Off". You mean discrete off? Are you sure?

BTW, there is no important difference between starting with 0000 0066 vs. 0000 0067. If you changed a 0066 to 0067 or vice versa, the signal would still work. In signals with larger values, when you change that second value you need compensating changes in other values to keep the timing correct. But in these signals, the random capture variations are bigger than the size of that minor compensation.

Also, your learned signals for Options and Return decode as the same IR signals as the ones posted earlier by Tom Light, which didn't work for you. Perhaps there is a problem in uploading Pronto Hex to your remote?

Well i decoded them again. But why should i use makehex as i have all the codes working. And 0000 0066 in stead of 0000 0067 or 0000 0068 works for me; only the off is is 0000 0067.
On the origional sony remote the off key works discrete, it is not a toggle.
It sets the tv in standby modus. To get it out of standby you have to use one of the channel keys.
I copied the ir codes from Tom Light (copy and paste) into mydatabase in the appropriate functions. Asigned them to buttons off the tsu9600 and downloaded them to the device.
I got no errors after downloading in the logfile, but they didn't work.
So i don't see why there might be a problem uploading to my remote.

I was searching the sony website, and the X4500 TV's have the same remote.
I have three or four customers with that in combination with pronto, and no problems.....

What editor you use, and what firmware ?
Did you try them without extender ?

sometimes the way the hex code 'looks' doesn't matter, you have to decode it with IRTool.
still, both Jans and Toms codes decode the same, both should work.
this is another version of the 'options' hex code and it looks very different from the others, it should however still work.
0000 006C 0000 0010 005C 0017 0017 0017 002E 0017 002E 0017 0017 0017 002E 0017 002E 0017 0017 0017 002E 0017 002E 0017 002E 0017 0017 0017 002E 0017 0017 0017 0017 0017 002E 02E1

I'm using PEP 2.4.18.0, the firmware version is 4.0.20 and it's a TSU9600 v2.2.
I do use it without an extender (yet).

Has anyone actually tried my codes, the ones with the 0000 0066 on other sony's?

generally the people who offer help here don't own the products in question.
your codes should work just as well as Toms codes, why Toms don't work for you is the real question.

Could be the problem.
I have had configurations with the 5.0.6 and 6.0.21 FW, worked great until i updated my PEP2 to the 2.4.18

So you could try to upgrade FW 7.2.22 (the last one if the number is incorrect)
If you have FW4.0.20 you normally can go back.

Well oke; i didn't know you were seeing it from a rather theoratical side.
Forgive me, but i'm from a more practical side: when it works, it works.

But then i'm also interested in the theoratical working of the rc devices.
So. i'm going to follow Tom's advice to downgrade (?) the firmware, if i can find it.

Meanwhile i'm doing something very practical: learning the codes of a dvd/hdr also from sony and i get only 0000 0067 codes sofar.

I intend to put al the codes (good and bad) in a database for future analysis.

I also think like that, but when it stopped working, the firmware upgrade to 7.2.22 solved the problem.

Firmware can be found here:
[Link: remotecentral.com]

We often refer to "hex codes", but learned hex codes aren't codes at all. Instead they are measurments of time durations. The 0067 (103 in ordinary decimal notation) is simple a measure of the frequency of modulation of the IR beam. 67 means that the frequency is 1/(103*0.24125 microseconds) or 40.24KHz. 66 means 40.64KHz. Neither the sending remote or the learning remote have accurate frequency control, and either or both could be responsible for this 1% variance. Most electronic components handle 10% variation in frequency easily.

If the 0067 were actually a code, it might mean something very different from 0066. But in fact, it is just a measure of frequency, and isn't important at all.

Yes, that's clear. Thank you for elaborating.

But how can MakeHex compute the values; is it because the algorithem computes the mean value ?

I remember i have seen a site where there is an explanation of all the words in the sequence; i have a ict background with programming as the main discipline, so i am curious.

And to Tom Light: i have the 7.2.22 FW and it is stil working good. I wonder now if there is a difference between European and American rc's or tv's.

Each IR protocol has a design specification. The Sony protocol specification says the the intended modulation frequency is 40.0KHz. So if both remotes (teaching and learning) had a completely accurate timebase, then the learned Pronto Hex would start 0068. Of course MakeHex sends 0068, since it is calculating the duration from the specification rather than measuring it.