Shorton,

Can you post the hex codes here when you have finished so as to help others?


Cheers
Jason

Understood, thank you.

I did encounter an issue today though.  I have not had time to create/load/test the hex yet, and today I got an email from my contact at DPI who said he heard back from HQ. They said "Protocol=NEC, CustomCode=06F9"  06F9 woudl be 1785 I think.

So their Custom code does not appear to jive with what I decoded.  Does it?  Would not surprise me if they are wrong, but since the first byte matched at 6, I wondered.  06F9 would seem more plausible as far as being unique though, vs just "6".  Could it be 06F9 based on the ir decode I gave?

Note:  I also noticed the command part of the ir decode included "609F" in its prefix, which is suspiciously close to the DPI provided 06F9.  Bit order is just reversed maybe. 

Could the IR decoder be missing telling me about the 9F part?  Or am I missing it all on my own? :)

Jason:  I will definately post the info once I finish and clean it up.

Thanks,
Scott

Everything is consistent. The NEC standard originally was to send the device number followed by the binary complement of the device number. Now many companies use the second byte as a subdevice number, ignoring the complement rule. However, for IR signals in which the second byte is the complement, the convention is to refer to just the device number.

So NEC1 device 6 is the same as device 6 subdevice 249, or 6.249. The 6 and 249 are the complement of each other (0000 0110 versus 1111 1001). You can also see that in hexadecimal notation the numbers are 06 and F9.

There is no standard on the bit order. Of course the actual IR signal has to have a fixed order of bit transmision, but when writing the numbers, the design engineers (or folks trying to divine their intentions) can choose to write the bits with the earliest on the left or on the right. Note that the bytes are invariably shown with the earliest on the left.

Excellent.  I should be on the way then.  Thanks 3FG, VERY much for the help.

James, I'll post back when I get it cleaned up.  I'm going to spot check for the possibility of some IR commands that are not documented (becasue there is no physical button on the stock remote).  Should take a couple days to fit the work in my schedule.  I've got a URC I need to get programmed so I should have it done by Monday.

Best,
Scott

Having some trouble withthe codes.  Some buttons working, others aren't.  Will do some more careful checking with the irwidget tomorrow.  Any suggestions on what to look for? 

I am generating the hex with the make hex gui, entering the hex into the remote.  I tried with and without the 249.  Arrows worked, but power buttons did not. 

Back tomorrow....

OK.  Back at it today.  Yesterday's problem had to do withthe way the Makehex gui opens a notepad window and pasting issues.  Worked that out, redid all the codes in hex on the remote.

But My remote (URC MX-980) will not send a single command,  It apparently sends them in bursts.  The left-right controls for example are used to control sliders that move in increments of 1. 

When using the stock remote, I have no trouble getting the control slider to move by 1.  But, with the MX980 using my programmed codes, left moves by 4's, no matter how quick or lightly I press the button.

In IR Scope the identical pressing results in a capture that says zero dittons for the stock, but oddly for the MX980 is shows 2 dittos.  I expected to see 4.  Same thing, no matter how lightly I press the IRwidget and IRScope combo report 2 dittos.

Is there any way to help the 980 avoid this behavior? Can I add a "Space" to the end of the IR code?

Is there anything I can provide so you can help me debug?

Thanks again.

Scott

I don't know anything about URC remotes and how they are programmed. However, many remotes routinely send more than one IR signal because most equipment ignores immediate repeats. BTW, 2 dittoes means the original NEC1 signals, plus two additional repeat frames, so I would have guessed that you would get 3 steps rather than 4.

Anyway, could you check the learns carefully? It is not uncommon for equipment to be set up so that NEC1 signals are used for functions which don't naturally need repeats, and NEC2 for things like sliders. or volume controls.

NEC2 is very similar to NEC1, and perhaps the MX-980 will respect your desire to only send 1 burst if it is programmed with NEC2. You would only do that on buttons like the slider.

 3FG:  Thanks.  I will check the slider controls via IR scope carefully and see if they report NEC2.   And presuming I understand you correctly, I will try to program them as NEC2 either way to see what happens.  Will report back tomorrow...

Thank you.
Scott

3FG:

I double checked the codes being send with the NEC1 version of the slider controls (Left-Right).  IRScope reports it as NEC1 for the stock remote.  I am able, with quick clicks on the stock remote to get "no repeats" listed in IRScope.
  This identical quick press gets a move of 1 increment on the projector's control.

On the URC MX-980, I get "4 dittos" pretty consistently in IRScope.  And on the PJ, I get a move of 4 increments.  It may be ignoring the first repeat but does the next 3 (if there are a total of 5, 1+ 4 dittos).

I tried NEC2 as suggested.  With that I see a difference.  On IR scope it reports "2 copies" (vs. 4 "dittos").  On the PJ, I get a move of 3 increments, which is more what is expected for the 1+2 copies but does not jive withthe NEC1 behavior.

If the remote is set to send repeats on hex, you woudl think it would send the same number of repeats regardless of the format (NEC1 or 2).  Unless it's a time thing and it's sending hex for a specified time insteal of quantity, and the NEC2 takes longer so it only "fits" 3 instead of 5?

So I'm back to wondering if there is a way to "pad" the hex with blanks, so it cannot repeat the bursts withtout a longer gap hard coded between them.  Is that possible?

Woudl IR scope show it if that was happening on the stock remote?

Thanks,
Scott

I tried adding some extraneous characters to the end of the hex string.  FOund tha tif I add "1111" at the end end, I can get a single keypress.  But I figure it's becasue the rest of the dittos being sent are hosed at that point.  Not a good solution.  And I get a 70% "hit" rate on the projector.

Guess I'll have to call URC tomorrow and ask them why their device is sending 5 set bursts of hex code.  The stock remote works flawlessly.

Any other ideas of anything I can do to debug/fix/workaround?

Thanks, Scott

Sometimes Nevo remotes have a similar problem but they only repeat twice. To fix this you can edited the hex code like this,

Example of a standard NEC1 code.
Device Code: 6 Function: 0
0000 006D 0022 0002 0157 00AC 0015 0016 0015 0041 0015 0041 0015 0016 0015 0016 0015 0016 0015 0016 0015 0016 0015 0041 0015 0016 0015 0016 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 0041 0015 0041 0015 0041 0015 0041 0015 0041 0015 0041 0015 0041 0015 0689 0157 0056 0015 0E94

Edit the fourth word to 0000 (green above) and delete the last four words (red above).

E.G.
Device Code: 6 Function: 0
0000 006D 0022 0000 0157 00AC 0015 0016 0015 0041 0015 0041 0015 0016 0015 0016 0015 0016 0015 0016 0015 0016 0015 0041 0015 0016 0015 0016 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 0041 0015 0041 0015 0041 0015 0041 0015 0041 0015 0041 0015 0041 0015 0689

Jason:  Great, thanks.  I will give that a try as soon as I get home. 

Jason:  Also, I think earlier you asked for the sheet I had from DPI.  They got it posted (finally) in the manual on the website.  It's near the back.  Link is:

www.digitalprojection.com/Portals/0/Documents/HIGHlite%20Cine/HIGHlite_Cine_260_User_Manual_Rev_A.pdf

It maps the function numbers to the buttons which helps instead of having to figure them out.  I will post the hex, too once I have it working, or as close as possible, for others to have access to it.

OK guys I believe I have the solution.  I only tested it on 2 buttons but they worked perfectly.  Jasons comment about the repeats got me looking today before I could get back to the remote to try his suggestion.  I found a post by Mr. Fines regarding NEC protocol and repeats.  As I understood it, remove everythign past the ";" in "form" line becasue that was the repeat info.  I did just that so my makehex looked like:

Device=6.249
Function=1..255

Protocol=NEC
Frequency=38000
Time Base=564
One=1,-3
Zero=1,-1
Prefix=16,-8
Suffix=1,-78
R-Prefix=16,-4
R-Suffix=1,-174
Default S=~D
Form=*,D:8,S:8,F:8,~F:8,_

The original key looked like this:

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

The code after removing the repeat info looked like this:

0000 006D 0022 0000 0157 00AC 0015 0015 0015 0040 0015 0040 0015 0015 0015 0015 0015 0015 0015 0015 0015 0015 0015 0040 0015 0015 0015 0015 0015 0040 0015 0040 0015 0040 0015 0040 0015 0040 0015 0040 0015 0015 0015 0040 0015 0040 0015 0040 0015 0015 0015 0015 0015 0015 0015 0015 0015 0040 0015 0015 0015 0015 0015 0015 0015 0040 0015 0040 0015 0040 0015 0689

Which equalls just what Jason advised to do manually.

This worked perfectly.  It decodes to no repeat, it does not casue a repeat on the device (slider moves by ones), it imports as no repeat.

Thanks Jason!

Next I'll redo the whole thing without repeats, and retest.  Presuming that all works, will post back here.

Best, Scott

 

Glad to here it worked for you.