I have a remote I'm trying to get the proper hex for.  I've used IR Scope and makehex to build the HEX for importing into a URC remote.

Originally, I ran into an issue with the left and right buttons where they would cause a slider control to move more than one increment at a time.  I checked the factory remote and it showed only one "ditto" in IR Scope, but when I programmed that hex into the URC remote, I got at least 4 "dittos".  From reading here I figured out how to remove the repeats by removing everything past the ";" in the Form= line of the IRP file. That took care of the left-right slider controls, they started workign properly.  So I re-did all the buttons with the non-repeating hex codes. I incorrectly presumed it was all fixed.

Yesterday I discovered a problem.  There is another control which uses the up-down buttons in a "repeat" fashion.  I missed testign these previously.  These controls are for lens adjustments (focus, zoom, shift) on a projector.  They required the button to be held so it repeats the commands.  Again, the stock remote decodes to 1 ditto, and works.  But the current hex with no ditto will not work at all.

Holding down the URC button withthe "no ditto" hex does not cause a repeat.  You have to press and release the button get it to sent the single burst.  No matter how fast I press and release, the control does not respond.

So, I went back and programmed the hex using the standard NEC1 repeat pattern fron the stock IRP file:   ";*,_"

That makes the up-down control respond now, and the URC will repeat the command as long as I hold the button in this form.  BUT, I and getting moves that are more than the stock remote casues.  And I have places where the right-left button apparently needs the single repeat (one ditto) and it those will nto work where the repeats are needed.  The presumption is it's sending too many repeats.

Is there a way I can limit/control the number of "dittos"/repeats to one?  

Also, my frequency reported from IR Scope is consistently very close to 37700.  The stock NEC IRP file shows 38000.  I didn't know how close these need to be, and I don't see how to determine the timebase from IR Scope, is that possible?  And should I try to tweak those?

Mainly I think I need help with repeats.

Thanks,
Scott

Have you read this document? It may help to understand Pronto Hex in more detail than Barry Gordon's document here.

NEC1 signals have a lead-in, a main body that describes the device and function numbers, and a lead-out.  If the signal is to repeat, the remote should send dittos, which are just a lead-in and lead-out with no body.  The ditto has somewhat different timing than the leadin/out of the "once" signal.

MakeHex is giving you the correct form for the Pronto Hex, but it appears that your controller is unable to provide the correct number of repeats for both of the situations you describe.

So I would try making one custom "NEC1" signal that has no separately defined dittos.  Here's a typical NEC1 signal (device 4 function 1) formatted to suit this discussion.

0000 006D 0022 0002   [Raw, 38KHz, 34 burst pairs in once, 2 burst pairs in repeat]

0157 00AC  [lead in]

0015 0016 0015 0016 0015 0041 0015 0016 0015 0016 0015 0016 0015 0016 0015 0016 0015 0041 0015 0041 0015 0016 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 0041 0015 0041 0015 0041 0015 0041 0015 0041 0015 0041  [body]

0015 0689  [lead out]
0157 0056 0015 0E94  [ditto, which is the repeat signal]

Instead try no repeats and include the ditto as part of the once signal.
0000 006D 0024 0000 [raw, 38KHz, 36 burst pairs in once, no repeat signal] 

0157 00AC 0015 0016 0015 0016 0015 0041 0015 0016 0015 0016 0015 0016 0015 0016 0015 0016 0015 0041 0015 0041 0015 0016 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 0041 0015 0041 0015 0041 0015 0041 0015 0041 0015 0041 0015 0689 0157 0056 0015 0E94

Here it is one block:

0000 006D 0024 0000 0157 00AC 0015 0016 0015 0016 0015 0041 0015 0016 0015 0016 0015 0016 0015 0016 0015 0016 0015 0041 0015 0041 0015 0016 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 0041 0015 0041 0015 0041 0015 0041 0015 0041 0015 0041 0015 0689 0157 0056 0015 0E94

I would start just with the signals that seem to require just one repeat.

I've seen other post's about URC remotes having this problem and apparently URC know their is a problem but can't or won't fix it.

3FG:

I tried to read the document linked.  I got the about half way before it lost me.  The english made it tough to follow along at my understanding level.  I looked hard at your examples though, they were helpful, however after looking closely they appear to be almost the same.  the "ditto part" is still listed at the end, after the lead out. 

The only difference I see are the 3rd and 4th words:
0000 006D 0022 0002 changed to
 0000 006D 0024 0000 [raw, 38KHz, 36 burst pairs in once, no repeat signal]

Is that want you meant?  I was expecting to see the ditto part inside the lead in and lead out, from your description.

Here's one of my actual codes with and without the repeats as I described originally:

1. Without repeat:
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 0015 0015 0040 0015 0015 0015 0040 0015 0040 0015 0015 0015 0015 0015 0015 0015 0040 0015 0015 0015 0040 0015 0015 0015 0015 0015 0040 0015 0040 0015 0040
0015 0689 (lead out?)
(no ditto)

2. With repeat (default NEC1 irp)
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 0015 0015 0040 0015 0015 0015 0040 0015 0040 0015 0015 0015 0015 0015 0015 0015 0040 0015 0015 0015 0040 0015 0015 0015 0015 0015 0040 0015 0040 0015 0040
0015 0689 (lead out)
0157 0056 0015 0E94 (ditto)


I will try changing my header (022 0002) to (024 0000) per your example.

Let me know if something on the end (after or right before the lead out) is supposed to change, too.

Jason:  Thanks, I had read some similar posts, too.  Not sure if it was explicit to this case, I hope not.  I'll take it up with them if it is the case.  I have dealer access to them FWIW.

The 024 0000 change did not work.  It won't repeat.  Was there more I was to change?

Thanks,
Scott

I can't tell what you did. Why not post an example of th original and modified hex?

Also, what does the modified signal decode as?

3FG: Sorry for the delay, just now able to get to back to the remotes.  To answer your question, here are all the codes, the 2 originals and the one I edited trying to follow your example.  Not sure I did it right still.

These are the 2 originals:

First, with no repeats (removed all past the ";" in the irp to generate it).  This one decodes as NO ditto.:

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 0015 0015 0015 0015 0015 0015 0040 0015 0040 0015 0015 0015 0015 0015 0015 0015 0040 0015 0040 0015 0040 0015 0015 0015 0015 0015 0040 0015 0040 0015 0040 0015 0689

Second, built with standard NEC1 irp file, with repeats.  After loading on the URC remote via "Complete Control" program, this one consistently decodes as 4 dittos:

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 0015 0015 0015 0015 0015 0015 0040 0015 0040 0015 0015 0015 0015 0015 0015 0015 0040 0015 0040 0015 0040 0015 0015 0015 0015 0015 0040 0015 0040 0015 0040 0015 0689 0157 0056 0015 0E94

Finally, this is the one I edited, trying to follow your examples above.  I replaced words #3-4 (0022 0002) with 0024 0000.  This one decodes as one ditto, same as the stock remote's decode, but it will not repeat (by holdign down the key).  I get one burst per keystroke:

0000 006D 0024 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 0015 0015 0015 0015 0015 0015 0040 0015 0040 0015 0015 0015 0015 0015 0015 0015 0040 0015 0040 0015 0040 0015 0015 0015 0015 0015 0040 0015 0040 0015 0040 0015 0689 0157 0056 0015 0E94

I can think of one other thing to try:
For the functions that need a controllable repeat, try using the nec2 irp files with the usual device and function number. Maybe the URC will handle that differently. NEC2 doesn't send dittos; instead it repeats the entire IR signal.

I doubt you want to hear this, but a $20 RCA RCRP05B can send these signals, and just about any others. The repeats will work, IR signals with toggle bits will work, etc. Spend an additional $29 for a JP1 interface cable, and it will control any device which is controlled by IR.
Of course, there is no LCD screen.......

I tried the NEC2 already, it didn't work.  I understand a JP1 will work, I have a box full of new OFA's.  I used to use them for a device I make (unrelated) www.cineslide.com.  UEI canned the OA's so I finally designed and build my own small remote to sell with that device.  I programmed it to use a Sony protocol.  But the URC controls a MSC400 which is part of my control system.  I don't have it for the LED :) .

Somewhere I read someone got something to work by making a ccf first then importing it instead of the hex.  I can try that I guess.

So I was doing your suggestion correctly then? 

Yes, you did what I was suggesting, and I think you showed that it does provide the NEC1 signal with 1 ditto. That's what I thought you wanted to get.
Now I understand that you're still looking for a way to convince the URC to repeat properly.

Yes, I guess that's right.

Spoke to URC today.  Think I found the problem, and the solution.  Will test and report back here either way.  WIll help all those other URC users if it's right.

Best, Scott

I was mistaken.  Did not work.

What I found is in their Total Control software, once you enter a hex code, you can doubleclick on the learned data in the macro editor and it will give you a second dialog.  In that IR Settings dialog it gives the options to repeat if the button is held, and how many repeats to send (1+  Does not allow 0).  This looked like "it".

But after trying every conbination and permutation of the repeating and non-repeating code forms, with and without repeats set on in the dialog, the result was "better" but not fixed.  I got the dittos down to 2 on IRScope, but not to one.  And the commands still casued multiple moves on the device.

I did find that if I "learned" the code from the factory remote, via this IR Settings dialog, then ran that learned code back through IRScope, that IRScope showed 1 ditto.  Same as the factory remote.  HOWEVER, back on the actual device, a single keypress from the URC learned code still casued multiple moves. 

This points to a failure of IRScope to reflect what's really coming out of the remote, or my inability to see the difference.

Without consistency in the analized data from IRScope, it's hard to know wht's really going on.  Is there anything I can do with/to IRScope to see what's different about these 2 commands?  One from the learned data and and one from the factory remote, that decode the same, but behave differently?

Is there a better IR analizer out there?  I understand RTI has some sort of tool.

Thanks,
Scott

It woud be better to post questions about IRScope at www.hifi-remote.com/forums/viewforum.php.

I recommend that you capture two wave forms:
1) From your URC remote
2) From the original remote

Save these in an ict file, and post that file in the Diagnosis File Section, with a link to it in the question post.  That way others can see the actual waveforms rather than a decode.

Or you might want to take a peek yourself at the waveforms.  They will be different if the reaction from the component is different.

Will do.  Thanks.