Hey All,

I just purchased a Sharp Blu Ray player, but I'm having trouble learning the codes onto my Pronto TSU-3000 and I have been unable to find any discrete codes yet. In looking through the forums I discovered the makehex program, but am confused about how to configure the .irp file. Below is the improperly learned code for the power toggle. Could someone please explain how I can extract the needed info to properly configure .irp file?

0000 006C 0000 0031 0081 0010 0010 0031 0010 0010 0010 0031 0010 0010 0010 0031 0010 0010 0010 0031 0010 0010 0010 0031 0010 0010 0010 0031 0010 0031 0010 0010 0010 0031 0010 0010 0010 0031 0010 0031 0010 0031 0010 0031 0010 0010 0010 0010 0010 0010 0010 0031 0010 0010 0010 0010 0010 0010 0010 0010 0010 0031 0010 0031 0010 0010 0010 0010 0010 0031 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0031 0010 0010 0010 0031 0010 0010 0010 0010 0010 0010 0010 0031 0010 0031 0010 0031 0010 0031 0010 031E

OK, after further searching I found another thread that contained the .irp file I needed. After testing all of the 256 codes, I have mapped all the keys on the remote and have found a discrete pwr on code, but no discrete off. Is it possible that a device would have one without the other? Is 256 the maximum number of codes, or can I edit the function line in the .irp file to return more codes?

For those that are interested, below is the discrete pwr on hex code. Also, if anyone is interested in the functions I mapped to the other makehex codes I can post those as well.

0000 0071 0000 0032 007F 0040 0010 0010 0010 0030 0010 0010 0010 0030 0010 0010 0010 0030 0010 0010 0010 0030 0010 0010 0010 0030 0010 0010 0010 0030 0010 0030 0010 0010 0010 0030 0010 0010 0010 0030 0010 0030 0010 0030 0010 0030 0010 0010 0010 0010 0010 0010 0010 0030 0010 0010 0010 0010 0010 0010 0010 0010 0010 0030 0010 0030 0010 0010 0010 0010 0010 0030 0010 0010 0010 0010 0010 0010 0010 0030 0010 0010 0010 0010 0010 0030 0010 0030 0010 0010 0010 0010 0010 0010 0010 0010 0010 0030 0010 0010 0010 0010 0010 0AAB

Just editing the function line wouldn't give you new codes. MakeHex can process higher function numbers, but this protocol only uses eight bits of the function number, so if you caused MakeHex to generate functions 256 through 511 their Pronto Hex would be identical to that for 0 through 255.

Probably there are only the 256 functions you already tested. If there are more functions:
1) Maybe they use Sharp protocol rather than Kaseikyo.
2) Maybe they use a different value of E in the .irp file. Values from 0 to 15 are valid. The signal you posted uses the value 1.
3) Maybe they use a different subdevice value (the 48 on the device line) but values 0 to 255 are possible, so it would be very hard to guess which other value they might use.

Could you please post a few more of the working mapped codes as well?

I am working with the cryptic sharp documentation for this unit which is not entirely clear. A few of the working codes would help me decifer the info.

The code set you are working with is not limited to 256 codes as far as I know. I will try and confirm this with the documentation.

The kaseikyo codes I have worked with are 48 bit codes that can produce up to 4096 possible function codes within each device number (1024 x 4).

I am having an issue decoding the code you posted using IRtool. It is returning the protocol Kaseikyo 170.90 with a device number of 8.48 both which seem strange to me but I am likely too green in the gills to figure out the issue if there is any.

Can you send me a copy of that cryptic documentation. Maybe I can figure it out from one sample.


Different manufacturers use different fields within Kaseikyo in different ways. I don't know (or maybe just don't remember) how Sharp uses the four bits directly after the eight-bit function code. Those are represented by the E line in the .irp file I think bbarz used.

If E is part of the function number, then (as you said below) there are 4096 possible function numbers.


But if E is part of the function number then the ordinary functions are all in the range 256 to 511, rather than 0 to 255. That is counterintuitive. So I think E is something else for Sharp.

My software interprets Kaseikyo as having more than eight function bits only for Denon, where both the documentation and the values of working functions clearly show that the function number is more than eight bits.


That's how it decodes. Why strange? I'm sure I've seen those values for Sharp a lot before (though I forget where).

sent... you have mail.

I think your statements above and below will make more sense to me once I have some time to decifer the documentation.

This only puzzled me because I have not seen kaseikyo codes decode with a device number containing more than one digit to the right of the decimal. I also had not seen the specific 170.90 protocol designation (only "kaseikyo" not "kaseikyo 190.70") so I did not know if this was correct or a glitch in IRTool... thus the green around the gills comment.

The following won't mean much to anyone who doesn't have that document tgrugett mentioned.

1) Each binary field is backwards (you must reverse the right to left sequence within the field before converting the binary to decimal). That applies to every number below where I give a number in binary and then in decimal.

2) Company code: That is two numbers. Binary 01010101 and 01011010. Decimal 170 and 90.
Those form the "manufacturer code" reported/used by DecodeIr/MakeHex

3) Division code: Binary 0001 Decimal 8. That is the device number reported/used by DecodeIr/MakeHex.

4) Category code: Binary 00001100 Decimal 48. That is the subdevice number reported/used by DecodeIr/MakeHex. I see they also document value 49 as "DVD2" and value 50 as "kazu0895" in one place and as "DVD3" in another. I expect you know much better than I do, what the choice DVD1, DVD2 or DVD3 means. I hope it means there is some way to adjust the device to which "Category code" it responds to, in order to control three of the same device in the same room. But I don't have any specific knowledge of that.

5) b0-b7 of Control DATA: That is the function number. Notice that for that field, they gave you the decimal value in the "No." column. I only checked a few for accuracy (found no errors). In other documents, they made a few errors in the binary to decimal translation, so I'm not sure you should trust the "No." column.
Notice that they do not document function number 145, so bbarz either found an undocumented signal or is talking about a different model than you are.

6) b8-b11 of Control Data: Binary 1000 Decimal 1. That is the E number reported/used by DecodeIr/MakeHex. Notice how they show it as seperate from the 8 bit function number and notice how the value is always 1. So while they call both function and E parts of "Control DATA", they seem to treat them as seperate kinds of information.

7) "Parity of Company code" and "DATA Parity". DecodeIR and MakeHex treat those as fundamental aspects of the Kaseikyo protocol. Their values are determined by computations from the other fields. The user of DecodeIR and MakeHex is intentionally left out of that process. The "Kaseikyo-170.90" decode assures you those two fields were correct. It doesn't tell you what those correct values were. The Kaseikyo.irp file with MakeHex computes the correct values. It doesn't ask you to provide them. Denon usually gives incorrect values for those in their Kaseikyo documentation, but builds the correct values into their remotes and the devices receiving the signals. Sharp is very similar to Denon in the way they use and document IR signals. I didn't bother to even check whether they documented these parity fields incorrectly. There is no reason we should care.

I hope, with the above explanation, you can now see the complete relationship between the codes as Sharp documented them and the codes as DecodeIR decoded them.

Most versions of IrTool.exe don't show you the value of E that DecodeIR.dll gives to them. So you may need to take my word for that part of the decode. DecodeCCF does show you that information, so if you had these signals in a CCF file you could see the value of E in the decode.

Thank you both for your replies. While most of what your talking about is well over my head. I will contribute as best I can.

I used the kaseikyo.irp posted by johnsfine here,

[Link: remotecentral.com]\-hp20

After creating the .ccf with irpanels, I was able to map the following to buttons on the remote

25 - function
27 - pop up menu
28 - enter
29 - return
32 - up
33 - down
34 - left
35 - right
38 - play
39 - stop
42 - pause
44 - slow
45 - skip back
46 - skip fwd
47 - rewind
48 - ffwd
53 - repeat
56 - top menu
57 - angle
59 - subtitle
60 - audio
65 - power on/off
66 - open/close
67 - display
117 - light
120 - zoom +
138 - skip search
145 - discrete power on
163 - top menu
165 - setup
167 - exit
176 - replay

There are some buttons that I have not found yet such as zoom -. Also here are a few misc. ones that I found.

21 - when unit is off, it powers on, v-up is flashed on the display and after a few minutes, v -err is displayed and the tray ejects
108 - seems to be a 2nd code for enter
242 - displays read errors on screen

John... Thanks very much for your time and expertise on this.

bbarz... I will compare the documentation that I have with your mapped codes to see if there is another possible device number we can try.

I will post when I have the results.

Add these to your list of codes to test assuming the same protocol and device number...

1 - #1
2 - #2
3 - #3
4 - #4
5 - #5
6 - #6
7 - #7
8 - #8
9 - #9
10 - #0
31 - clear
53 - repeat ON
117 - light (this was struck out in red on the documentation sheet??? dimmer?)
120 - zoom+
164 - key mark (tamper proof) ???
170 - A (blue)
171 - B (red)
172 - C (green)
173 - D (yellow)
200 - HDMI (this was struck out in red on the documentation sheet???)
229 - zoom-
230 - repeat Off
231 - component reset (this was struck out in red on the documentation sheet???)

Of the codes you mapped these were not included in the documentation:

21 - status, config. or service mode???
108 - enter alternate
145 - discrete ON
163 - top menu
242 - read error display

I belive John must be correct about the three category codes ("DVD1", "DVD2" and "DVD3") in that there must be a feature to configure the units to respond to different codes sets corresponding to device 8.48, 8.49 or 8.50 accordingly.

The "E" portion of the code did throw me because of my work with Denon codes. I thought at first that it might be used to designate various function ranges for a total of 2048 function codes but given that the hex equivalent for each 8 bit binary data documentation is given for each function number it does not seem that it plays in to the determination of the function number at all.

I see no indication of other device numbers or any other variation in the code to generate any more possibilities than the 256 that have been tested.

Does any other command turn the unit on besides functions 65, 145 or 21?

tgrugett, thanks for filling in the missing pieces. With the exception of 164, 200 and 231, I tested and confirmed all of the additional codes to be functional. These other ones require the key to be pressed for a few seconds to have an effect.


yes, I missed this in John's post, but according to the user manual, 3 sets of codes can operate the player (rc-1, rc-2, and rc-3)


66 (eject) also turns on the player. Additionally 243, 248 and 249 all turn the player on, but have no apparent effect when the player is on. I guess these are potentially other discrete on codes. Interestingly, after the unit has been turned on with the 248 code, the only way to turn it off is to hold in the power button on the player for ~ 5 sec.

I also found 2 more codes that both do something when the player is off

154 - flashes 'hold' on the display for about 2 sec
198 - 'E000:51' appears on the display, pressing again causes it to disappear.

I'm going to go through the codes 1 more time to see if I can find that elusive discrete off code.

Thanks for the effort.

I do not have a unit to test but I will let you know if I find out anything else.

I will start a nice excel chart of these documented codes.

I am curious about the three new codes you found that turn the player on and if they have some other intended function.

What did you mean exactly when you said, "These other ones require the key to be pressed for a few seconds to have an effect"? Which ones exactly?

164, 200 and 231 require that the key be pressed for ~5 sec (according to the user manual) on the original remote. To test them I could edit the duration of the signal on the pronto. I don't really have a use for any of these so i just assumed that since all of the others were as you specified that these would be as well.

I have all of the functioning codes in a .ccf with labeled buttons that I could upload. Are there any rules regarding the format that this should be in?

I am not quite sure what you are asking.

The codes from makehex are already in a format recognized by pronto.

I expect he meant the formatting of other aspects (not the Pronto Hex) of the CCF to make it understandable by others who might download it.

Somewhere, long ago, I saw a set of suggestions for preparing CCF files for sharing through remote central.

It included a standard way of embedding info in the CCF files identifying the brands and models of the controlled devices.

It also included the more common suggestion to seperate the panels with the signals from the panels that should be used and them connect them with aliases. So the visible panels contain no learned signals, only aliases to signals on invisible panels. The invisible panels contain learned signals with meaningful function names, so understanding which function does what (while editing the CCF) isn't dependant on the GUI layout.

Almost no one sharing CCF files via remote central follows any of those suggestions. The collection of CCF files would be much better if they did.

I don't recall where I saw those good suggestions for structiong a CCF file to share.