HEX->IRedit->Not working

Garret

I have downloaded the the .ccf file with the ir codes from Audio Request. I'm interested in the zone1, zone2...zone4 codes. I have confirmed the codes work from the pronto to the Request, I also confirmed they are in RAW format using IR code doctor.

0000 006a 0009 0000 0040 0021 00c0 0061 0080 0041 0060 0061 0020 0021 0060 00e1 0020 0041 0020 0021 0020 00c1

I then entered the hex codes into IREdit where they cease to function. Any ideas of things to try at this point? I do not have the AMX IR learner. Is their a way to change the amplitude of the IR ports on a NI controller? I have looked in the AMX-PI and did not see anything. Most of the IR codes work in the IRL file that I obtained from the AMX website a few of them did not and using the method I mentioned above i was able to get them to work. I just have these last 4 hold outs.

This also seems like as good of time as any to ask a few academic questions that have been on my mind regarding IR and AMX

DATA_EVENT 		[dvREQUEST_IR]
{
ONLINE:																			
	{
		SEND_COMMAND dvREQUEST_IR,"'SET MODE IR'"	//SET IT TO IR
		SEND_COMMAND dvREQUEST_IR,"'CAROFF'"		
		SEND_COMMAND dvREQUEST_IR,"'XCHM-0'"		
		SEND_COMMAND dvREQUEST_IR,"'CTON',3"		
		SEND_COMMAND dvREQUEST_IR,"'CTOF',2"		
	}
}

It is my understanding from reading the AMX-PI that CTON and CTOF commands only affect the timing of codes sent using the XCHM method... or does it govern all IR sent through that port? Ok i guess its only one question:) and BTW the CTOFF I am aware of that and don't believe its my issue i have tried both ways both wired and with an emitter.


Thank you for any help you have to offer in this department.

Joe Hebert

Garret wrote: »

It is my understanding from reading the AMX-PI that CTON and CTOF commands only affect the timing of codes sent using the XCHM method... or does it govern all IR sent through that port?

CTON and CTOF govern the pulse width when sending IR codes with the XCH or SP commands.

If you PULSE and IR code the pulse width is the global value set by SET_PULSE_TIME (by default it’s .5 sec)

I rarely ever use PULSE when dealing with IR. I stick with SP for almost everything except for volume which I normally use a TO.

The IR code you posted looks pretty short. Are the working IR codes that short also?

Garret

Yes the working ones are quite short. Since the hex loaded into a pronto remote works, and just for grins i loaded the hex code into a URC remote it works. After all the mucking about I have done today I'm reasonably sure that the hex is fine. Is it possible that IREdit is mistranslating the codes when it saves them to an .IRL? I am running Vista... I was going to try running IREdit on a virtual XP machine but when it came time to install it wanted .net greater then 1.0 and 3.x is installed. Yar, revert to a previous version of .net to install IREdit for such a long shot... It may come to that i guess.

On the bright side a second look at the AMX-PI reviled those SP commands you mentioned, they should come in handy

Garret

Well, to leave no stone left unturned. I entered the hex on a computer running XP with the same results. I wish there was a way to capture the IR coming out of the control system but none of the capture devices i have access to seem to be able to pickup the IR from an emitter, I'm sure its too weak.

DHawthorne

For what it's worth, I regularly paste hex codes from other remote files or IR Doctor into IREdit, and they work fine. IREdit is a bit flaky (at least in Vista, I don't remember ever having trouble in XP) though; I have had better success getting files to work if I took an existing file and overwrote individual channels than if I start from scratch. Save frequently too, it crashes a lot.

And yes, the output of an AMX IR port is a bit weaker than many other IR devices, and no, there is no way to turn it up higher. If you have a very long wire run on very small gauge wire, that could be your issue; but I have successfully run over a hundred feet on 22 ga. ... not sure you could pull that off on CAT 5 though. What I would do is hook an emitter directly to the back of your controller and temporarily get the device right there to test. That would rule out malformed IR right away. If you are already in the same cabinet, try an new emitter before you go too nuts. I've had that solve the problem many times and save me a lot of chasing after gremlins that didn't really exist.

Garret

I have had good luck with this method before, just this time something seems wrong. I put 9 hours into trying to rule out that it's not my fault... and well it prolly still is. After things cool down a bit I'll revisit the issue, I was able to just write the 232 for the ARQ witch was the better way to go in this case. I just hope it doesn't come up again with some IR only device.

Thank you all for the replies and ideas!