Any guess at the difference between "now" and before?

I'm pretty sure the commands 7E and 7F that I emailed are the same as the two that I posted.

Wow, I didn't realize that. - I couldn't get them to work at all before, and they are the exact same IR code.

This may have been an AMX software issue, because when I actually made the IR file for the system, the file itself wouldn't upload to the AMX controller, so I even took that same hex code and pasted it into an existing IR file, and the file would only upload to the pasted code, and then it would lock up. It was really frustrating... but I don't know what changed, because I've been doing this the same way the whole time, but now it's working great, uploading and functioning the way it's supposed to.

Thanks again for all your time,
Jeff

Bump.

I have the whole sheet for these commands, but they are in the same format as the power commands listed in post 1.

I have tried to use the IRCode Generator utility, but the codes that it creates seem to be off.

As an example, the code 40 BF 22 BC (discrete Video 3) generates the following:
0000 006D 0010 0020 000A 001D 000A 001D 000A 001D 000A 001D 000A 001D 000A 001D 000A 001D 000A 001D 000A 06d6 000A 001D 000A 001D 000A 001D 000A 001D 000A 001D 000A 001D 000A 001D 000A 001D 000A 0685 000A 001D 000A 001D 000A 001D 000A 001D 000A 001D 000A 001D 000A 001D 000A 001D 000A 0685

RTI Theater Touch software will not allow this, stating that there are an "invalid total number of tokens detected".

I have been searching and reading hex converter threads all day, but I have to admit that much of what John Fine has posted has gone past me...

Any idea what is going wrong with this conversion, and/or a layman's explanation of the file given vs. a ProntoHex?? I don't even know what this command style is called.

I cannot use the MakeHex utility on my office machine, and I do not have my laptop with me right now.

Where is that utility available? I'm surprised it would generate the crap you quoted, so I might want to test to see what it is doing.


Wrong in so many ways I can't even see the connection between it and the desired code.


They are correct about that.


Sorry. I try to explain as simply as the topic and my guesses about the readers' backgrounds permit.


Everything.


I'm sure you can. You just haven't read its readme file. It is not started the way a typical Windows program is started. It doesn't contain any code for displaying a window.

Well, it definitely respopnsible for the code that I posted...

I got it here: [Link: remotecentral.com]

Going back and looking at it, it was assuming Sharp codes. I can't believe that it generated anything. I was sent on a wild goose chase with that one...

Anyway, now I have the MakeHex working on my laptop, and I have the 255 codes from Device 64 (from the first hex #40 of the yet un-named file type).

I also have the decimal numbers for each of the codes I need from taking the third hex and converting it to decimal...

When I use MakeHex and change the device to 64, the converted hex is slightly off from what you posted above for the only known commands (power on = 7E and P-off = 7F)

This is what I got for the 7F conversion (function 127)

nec1.hex
Device Code: 64 Function: 127
0000 006D 0022 0002 0157 00AC 0015 0015 0015 0015 0015 0015 0015 0015 0015 0015 0015 0015 0015 0040 0015 0015 0015 0040 0015 0040 0015 0040 0015 0040 0015 0040 0015 0040 0015 0015 0015 0040 0015 0040 0015 0040 0015 0040 0015 0040 0015 0040 0015 0040 0015 0040 0015 0015 0015 0015 0015 0015 0015 0015 0015 0015 0015 0015 0015 0015 0015 0015 0015 0040 0015 0689 0157 0056 0015 0E94

vs. your command posted above for the same function number...

0000 006D 0022 0002 0157 00AC 0015 0016 0015 0016 0015 0016 0015 0016 0015 0016 0015 0016 0015 0041 0015 0016 0015 0041 0015 0041 0015 0041 0015 0041 0015 0041 0015 0041 0015 0016 0015 0041 0015 0041 0015 0041 0015 0041 0015 0041 0015 0041 0015 0041 0015 0041 0015 0016 0015 0016 0015 0016 0015 0016 0015 0016 0015 0016 0015 0016 0015 0016 0015 0041 0015 0689 0157 0056 0015 0E94

I see a lot of 0015 bytes in mine which are 0016 bytes ion yours... as well as 0040 bytes in my conversion which are 0041 bytes in your command...

John, any ideas on what went wrong??

Thanks in advance for your assistance.
Once I get the hang of MakeHex, I can convert and test the following commands...

Discrete inputs should respond to the following:
Vid 1 = 20 (32)
Vid 2 = 21 (33)
Vid 3 = 22 (34)
Vid 4 = 23 (35)
Vid 5 = 24 (36)
Vid 6 = 25 (37)
Vid 7 = 39 (57)
Vid 8 = 3A (58)
Vid 9 = 3B (59)
Vid 10 = 3C (60)
Ant 1 = 3D (61)
Ant 2 = 3E (62)

Discrete aspect controls should respond to the following:
Natural = C0 (192)
TheaterWide 1 = C1 (193)
TheaterWide 2 = C2 (194)
TheaterWide 3 = C3 (195)
Full = C4 (196)

Discrete video setting memories should respond to the following:
Sports = CD (205)
Standard = CE (206)
Movie = CF (207)
Preference = D0 (208)

John, what is the significance of the second and last hex numbers?? I saw your post relaying that this is a check byte inversely related to the third byte, and that was my first guess as well... but what is the second byte??

Please lighten up a little on the bashing. I don't get this kind of data very often, so I haven't invested a lot of time learning to interpret it.

I have shown you respect in every post....

I'll try that later and see what results I get.


Good.


The values that differ are approximate durations. That tiny difference is totally insignificant.

I think you used an older version of MakeHex, probably the one I posted long ago at RemoteCentral. I used the current one posted on my own web space. In between those versions I made some changes to MakeHex to be more precise about approximate durations, because I came across an obscure protocol where that mattered. It doesn't matter to this protocol, so the change is neither better nor worse.


For NEC1 nothing. For future use of MakeHex with other protocols, the newer version may be better.


Sounds like you already know enough for that.


You are asking about the four bytes encoded inside an NEC signal (and documented as such by some of the manufacturers using NEC protocol).

1'st byte is the device number.

2'nd byte is one of two different things, depending on how that manufacturer uses NEC protocol. It may be a subdevice number or it may be a check byte on the device number. If the 1'st and second bytes add up to FF then the second was a check byte and there is no subdevice.

3'rd byte is the function number.

4'th byte is a check byte. 3'rd byte plus 4'th byte add up to FF.


Sorry. Sometime the only concise way to give the information sounds like bashing. My intent was to inform, not to insult. (But I always read the readme file on anything I download before saying it doesn't work. Most people posting that MakeHex didn't work didn't read its readme and I do get slightly annoyed and less polite when that appears to have happened).

I followed that link. The description makes fairly clear that the program generates only the IR protocol used by Sharp and Denon.

To use that program you need to input the four parts of a Sharp/Denon signal in binary with the division of bits (5 bits, 6 bits, 2 bits and 2 bits) that Denon normally uses for documenting their signals. If you use non binary characters or the wrong number of bits, that program gives no error message, it just produces garbage output (not just not correct Sharp/Denon signals, but something that isn't any kind of an IR signal because it isn't structurally correct Pronto Hex).

Anyway, if you want anything other than creating a Sharp/Denon signal from documentation in binary, it's the wrong program.

OK. You are absolutely correct that I was using the 4.0 version from the files section here at RC.
How can I get the newer version?? (2ndrick at gmail)


I didn't mean to imply that there was an issue with the software, I simply missed the step of pasting the .irc back onto Notepad after it was re-created with the correct Device number. I printed off the Read Me, I just didn't rewad it as closely as I needed to until I got home where it is a little quieter...

Besides, at my office, they have everything clamped down to require some sort of admin permission... So I stopped trying.

Oh, and to clarify something from above...
All '05-'06 LCD flat panels and DLP rear pros have full discretes including power, but the newest plasmas (42HP66 and 50HP66) will not respond to the discrete power on and power off.

I think I have the same document that mdnitehk sent to you back in March...

A colleague sent me to that one... It probably worked on the last Denon or Sharp issue we had to deal with!!


I guess I didn't know that I was dealing with NEC until reading these threads...

On that note, is there a guide or thread somewhere on how to ID the raw IR data that these manufacturers publish so that we know which .irc to choose in your program??

BTW, sorry I was cranky and defensive earlier...
Discrete hunter isn't my regular arena here at RC, and you have been a lot of help.

Last time I crossed your path, you lit me up a little bit because I hadn't searched for the 48 bit Denon commands using the term "kaseiyko" or whatever obscure name that they gave it.

Ultimately, you helped me at that time as well.

MakeHex
[Link: hifi-remote.com]

DecodeCCF: Used with DecodeIr to decode all the Pronto Hex in a CCF file. Understands the basic modulated form of Pronto Hex, the unmodulated form and almost all the condensed forms. Runs non-GUI, same ways as MakeHex.
[Link: hifi-remote.com]

The JP1 group's modified version of IrTool: Used with DecodeIr to decode one sample at a time of Pronto Hex pasted into its GUI. Understands only the basic modulated form of Pronto Hex, not unmodulated nor any of the condensed forms.
[Link: remotecentral.com]

DecodeIr: Used by DecodeCCF and IrTool and several other programs to do most of the work of decoding an IR signal.
[Link: hifi-remote.com]


So maybe you can't install .reg files to get more convenient access to MakeHex and DecodeCCF via context menues. But the basic function of those programs is so self contained, that if they let you download/run anything you can run those.


No. Half the time even I can't guess the protocol and/or device code from the manufacturers' documentation of function numbers. When I can guess, there are lots of things that might be hints, but I wouldn't know how to collect or explain most of those.

The only robust way to find that information is to learn a few ordinary signals from the original remote. Decode those with DecodeCCF or IrTool. Then assume the other signals documented by the manufacturer use the same protocol and device code as the one you can learn.

Of course even that isn't perfect. You already know about exceptions such as Denon systems where ordinary signals may be Denon protocol (Denon's version of Sharp protocol) while the documented special signals are Denon's version of Kaseikyo protocol. Marantz devices that use RC5 protocol for ordinary signals typically use RC5x protocol for special signals. Sony has a "Control-A1" protocol for special signals that is much more complicated than Sony's ordinary protocols (MakeHex doesn't have support yet for Control-A1).

Unrelated question, but I have a hunch that you know how to do this...

Do you know the formula to convert Hex to Dec automatically in Excel??

That function is hex2dec. For example, if cell A1 has a hex number, some other cell could have the formula =hex2dec(A1)


I don't know whether that is enabled by default or is part of the Add-In named "Analysis Toolpak". I always have Analysis Toolpak enabled because the JP1 spreadsheets require that. The JP1 spreadsheets are the only place I've used hex2dec

Hi John,
I am working on the same Toshiba TV as mdnitehk. I also received the codes from Toshiba, but cant get the conversion to Pronto to work. I've tried using the makehex with nec.irp, nec2.irp and some others and then testing the codes with the Pronto TSU3500 with no luck. Reading your posts with mdnitehk it souds like you were able to get the conversion to work. I am currently using a macro for on/offs , but would like to get the discreets working. I thank everyone in advance.

Reread posts 5, 16, and 17 of this thread. The codes he got to work are the ones from post 5.

I believe a TSU3500 doesn't need the long form of these codes. It should work equally well with the "900A" form (see post 2 of this thread).

I assume you've tried some of those codes and failed. Without more info I can't tell what went wrong.

When testing a discrete code, you should program it as the only action on a button and test it with an long press of that button.

I understand it makes no sense to use a discrete that way. You want to use it in a macro. But that introduces lots of timing and other complicating factors. First find out whether it is the right discrete code. Only if it passes that, try to use it in a macro and tweak whatever timing must be tweaked to get it to work.

Hey guys,

I think I have a similar problem.
I have a Loewe Individual TV. I have the ir code of the handset, what is this type of code: 5000 0000 0000 0001 0000 0016 (on)
I used it with a Marantz remote. This is working.
Now I have a AMX controller and need another hex code. I downloaded the programm makehex. What is the device numver in this case?