IR Widget

[BeyondPlatinum]

Hey Guys,
Sorry if this has been explained already but I cant seem to find the best way to do this:
I have a USB ir widget that I got from Tommy and would like to be able to learn IR codes from original remote controls.
I would then like to copy these codes and add them to other devices like universal remotes and home automation products.

Is this possible and if so, what would be the best way?

PS: I have used irscope to capture some info from the remotes but if i'm correct then that info isnt what i need for what i'm trying to do.

Thanks

[vickyg2003]

I would then like to copy these codes and add them to other devices like universal remotes and home automation products.

We have the tools here to add these codes to UEI remotes. That's what we call a device upgrade.

RemoteMaster (RM) or KeyMaster (KM) is used to assign the data to the buttons. If the signal isn't a recognized protocol, we might need to create a customized protocol with ProtocolBuilder(PB).

[johnsfine]

I would then like to copy these codes and add them to other devices like universal remotes and home automation products.

Most of those expect to import IR signals in a format called Pronto Hex.

So far as I understand, irscope does not have an option to export to Pronto Hex and if it did have such an option the results would likely be inferior to what you can get with just a bit more effort as described below:

So far as I understand, irscope can use decodeir.dll to display decoded signals including:
Protocol name,
Device number
Where appropriate subdevice number
Function number (AKA OBC number).

You can use the MakeHex program with Protocol name, Device number and (where appropriate) subdevice number and generate Pronto Hex for all possible function numbers.

Depending on the universal remote or automation product you are targeting, you may then want to convert the entire output of MakeHex to a CCF file (with buttons numbered by function number) using either IrPanels.exe or Hex2CCF.exe. Then you can import that CCF file, then use the function numbers from the original decodes to tell you which numbered button to rename, alias, or move (whatever the target supports) for each named function.

For example, the editor for MX universal remotes has a drag/drop interface that lets you drag from the numbered button in the CCF file and drop onto the named button in the MX configuration.

Alternately (for targets that can't take their Pronto Hex through CCF files) you would use a text editor on the output of Makehex to select the Pronto Hex for each named function (based on the function number from the decode) and paste it into the Pronto Hex import tool of the target.

For targets, supporting both CCF and direct Pronto Hex, the CCF is usually easier unless you are importing very few signals per device.

PS: I have used irscope to capture some info from the remotes but if i'm correct then that info isnt what i need for what i'm trying to do.

So you should already have the protocol names and device numbers.

Post that info. There are a number of exceptional cases in which you would need some extra advice on how to use the decode info. If you post protocol names and device numbers someone here can tell you whether the use of Makehex will be as simple as I described above or whether something extra is needed.

[ElizabethD]

So far as I understand, irscope can use decodeir.dll to display decoded signals including:
Protocol name,
Device number
Where appropriate subdevice number
Function number (AKA OBC number).

Also puts out HEX codes, and OBC number is in the KEY column.

[johnsfine]

Also puts out HEX codes

I assume those "HEX codes" are UEI Hex codes, which are the internal values hiding behind UEI EFC numbers (which most of our tools also display).

UEI Hex codes and EFC numbers are useless if the target remote or automation system is not UEI.

In most IR contexts outside this forum, "Hex codes" usually means "Pronto Hex". I haven't used irscope, so I'm mainly guessing that it does not generate Pronto Hex and you did not mean Pronto Hex. If I'm wrong (if you meant Pronto Hex) please say so, because in this forum "Hex codes" almost never means "Pronto Hex".

I'm also guessing, rather than sure, that the OP wants Pronto Hex. But anyway, I'm pretty sure he doesn't want UEI Hex.

OBC number is in the KEY column.

That's important to know.

I'm not very happy about that. It is confusing enough that the same value is "OBC" in most of our tools and "function number" in others and a few more strange names in some Pronto or other contexts. It didn't need yet another name.

But the important thing is that you told the OP where to find the function number.

[ElizabethD]

Also puts out HEX codes

I assume those "HEX codes" are UEI Hex codes,
...
I'm mainly guessing that it does not generate Pronto Hex and you did not mean Pronto Hex.

IRscope uses DecodeIR. so I guess puts out UEI Hex codes. And, correct, I did not mean Pronto Hex.

BeyondPlatinum's specs aren't clear to me, and the title is about widget, and I assumed the 'universal remotes' meant UEI. Sorry.

[BeyondPlatinum]

Hey guys,

Sorry for the late thanks but I've been away on business and just got back.
I appreciate all the info and will give it a try.

Been working on a project over the last few months that everyone here may find quite interesting and as soon as its completed I will post some info.

Hoping to have things completed within 2 weeks or so.

Thanks again for all the advice.

PS: By Hex, I meant codes that could be added to a number of different devices and universal remotes so my guess, if I am correct is that pronto hex codes would be what I need.

[BeyondPlatinum]

Sorry about this but I'm a little confused here.
Using IRscope and IRwidget, this is what I end up with after pressing the volume up button on my remote.



How exactly do I use this info to get the hex codes to add to a programable universal remote.
If i'm correct then I need to somehow generate the pronto Hex codes?

I attempted to use makehex but wasnt to sure on exactly what info to add and where exactly to add it.

Thank again for the advice

[johnsfine]

I'm at the wrong computer for checking any of this. But I think MakeHex.zip includes an xmp.irp file:

Edit xmp.irp to change the device line to
Device=71.17

Drag/Drop xmp.irp onto MakeHex.exe, which will create xmp.hex

Edit xmp.hex and copy the Pronto Hex for function 131.

That will include both parts of the signal, which are labeled XMP and XMP-R by your combination of IR Scope and DecodeIr. DecodeIr was designed for use with learning systems that do more preprocessing of the IR signal than IR Scope does. As a result, two part signals are more likely to be reported by IR Scope as two separate decodes. Even with the learned signals DecodeIR was designed for, it is possible for a two part signal to be reported as two separate signals, so you need to know that an XMP-R signals is part of an XMP signal.

Also, is the universal remote you want to program available in the same location as your IR Scope? If it is, you should capture the signal from that universal remote after programming with the Pronto Hex and see whether the process worked well.

XMP is a difficult protocol for universal remotes. The editing software for universal remotes is not designed to expect imported Pronto Hex to be perfect, so it usually runs some "clean up" operation on the imported Pronto Hex. For most perfect Pronto Hex strings the clean up makes no difference. But for a perfect (or imperfect) XMP string, the clean up often changes the meaning of the signal.

If a few cases (at RemoteCentral) I helped someone capture the output from a cleaned up XMP signal that had become wrong and figured out what the clean up was doing to that signal, then pre distorted the Pronto Hex before import, so the import software would fix the signal instead of breaking it. IR Scope is a much better tool for looking at the results of a bad clean up. It can see exactly what happened, where other tools can only see approximately what happened. I haven't used IR Scope myself, so if you do need to look at the timing details of a badly cleaned up signal, either that should be obvious from the IR Scope UI, or someone else here can tell you how. I can tell you the significance of those timing details if you post them.

[ElizabethD]

Just FYI, in case it's not obvious: IRscope puts out a text file. The display is a summary. Default file location is the irscope directory. File extension is .ICT and the filename is a timestamp of the capture.
File contains exact timings for every bit coming at it. So it might be useful for whatever conversions are planned here.

[johnsfine]

Just FYI, in case it's not obvious: IRscope puts out a text file. The display is a summary. Default file location is the irscope directory. File extension is .ICT and the filename is a timestamp of the capture.
File contains exact timings for every bit coming at it. So it might be useful for whatever conversions are planned here.

Good.

Hopefully the detailed timing won't be needed for converting the original signals to Pronto Hex. The decode should be enough.

But, if there is a problem in the import of Pronto Hex to the other universal remote (as there often is for XMP), that file of exact timings (from testing that universal remote) is what we would need to understand the import problem and devise a work around for it.

BTW, I checked xmp.irp in MakeHex.zip and it is correct for the instructions I posted above (that I wasn't sure of when I was at the wrong computer to check).