Learning?

[MikeH]

Jon,

Could you explain a little about the learning process? Does USB-UIRT have it's own application, or do you rely on Girder to store the learned commands? In a previous post you mention that the learned Girder command is a 6-digit number. What device/process/applicaiton is responsible for the conversion between the raw IR data, and this 6-digit code? What data is actually stored? where?

Sorry, I'm a little confused here due to my previous experience with IRman and PCIRLinc.

thx

[jrhees]

Mike, Here's a shot at an explanation. I know this can get a bit confusing, 'cause there is a bunch of different things going on in this process:

For clarity, I'll first describe everything in the context of using Girder for control. At the end, I'll then outline what parts are Girder-specific.

1. First, we must understand that the USB-UIRT does three basic things:
- RECEIVE
- LEARN
- TRANSMIT
RECEIVE is what the USB-UIRT does when its not doing LEARN or TRANSMIT (basically in all of its idle time). When the USB-UIRT sees IR activity in the air, it deciphers it and 'condenses' it into a 6-byte HEX number. This is very similar to what the IrMan and other receiver-only devices do.

LEARN is a special process the USB-UIRT performs when requested and is very different than RECEIVE above. Where 'Receive' creates a condensed 6-byte code, LEARN, in contrast, creates a much longer code which contains *all* of the necessary information to fully recreate the IR signal. This often requires 50-300 bytes of information. So, LEARN is entirely dedicated to capturing all of the information needed so that TRANSMIT below can recreate an IR code.

TRANSMIT is the act of using the data in a LEARN to recreate an exact copy of the IR signal received during a LEARN above.

Now, onto your specific questions:

1. When the USB-UIRT is RECEIVing an IR code (not learning), the USB-UIRT internally condenses the raw IR information it is receiving into a 6-byte UIR-style code. Once this is complete, the 6-byte code is sent to the host PC where it is dispatched as an event in Girder.

2. When LEARNING an IR code for retransmission, the Girder plugin asks the USB-UIRT to learn a code, which when complete is sent to the host where it is stored by the USB-UIRT plugin in the Girder GML file.

Does this answer your questions?

Best Regards,

Jon

[MikeH]

Does this answer your questions?

Yes!! Very nice explanation.

So, I would assume that my IRMan and PCIRLinc "condense" their captured/received codes with a different "condensing algorithm" which makes them incompatible with USB-UIRT...?? Thus, your previous (another post) comment about having to re-learn codes if switching from IRMan..?

So.....

Would you mind explaining IR Passthru. If I plan to use NetRemote to send raw data (so that I don't have to learn a bunc of commands) to NRIRServ on my HTPC, then send these out thru USB-UIRT to my XBOX, this bypasses the "condensing" process....right? I should be able to simply find CCF files that contain XBOX IR codes and use them "as-is"...??

Sorry for so many tutorial questions....but I can't seem to find this anywhere.

thx

[jrhees]

MikeH,

The NetRemote passthru bypasses the learning process in Girder somewhat but is really designed to avoid the need to use Girder. This can be both good and bad. Without Girder in the loop, you will only be able to do things that NetRemote is designed to handle. However, if this is all you need, then it can simplify your setup.

The NetRemote passthru plugin is available in Beta because it is difficult to support. I have heard mixed user responses about it. So, you'll probably want to just try it to see how well it works for you. Some prefer to not use this approach and instead have NetRemote talk to Girder.

In both cases, the 'condensed' codes shouldn't apply, since you are not trying to initiate events with your standard IR remote control.

When using the passthru, NETREMOTE (instead of Girder) is responsible for storing the complete IR codes (the long ones needed to transmit). In this case, the IR format used is 'Pronto' format. In many cases these can be found in CCF's with one caveat: They must be 'Learned' pronto codes!

-Jon

[MikeH]

Jon,

thanks for the continued tutoring

I've just ordered my USB-UIRT. I guess I'll just have to play with each approach (passthru vs learned codes) to see which works best for my setup. I've just had such bad luck learning commands (IRLinc ) that I was hoping to avoid this process for a screenful of device commands (XBox).

BTW, I'll be happy to help you with the NetRemote IR Passthru plugin if you need an additional beta site.

[jrhees]

MikeH,

Another option you have if you *do* end up using Girder is that the Girder plugin *does* have the 'Pronto Import' feature, which allows you to import pronto commands.

-Jon

[MikeH]

Jon,

I downloaded the latest USB-UIRT plug-in (which IT says is 2.5.9) from the Girder site and copied the dll file to my Girder Plugins folder. However, when Girder starts it complains that it can't find the USB-UIRT driver. Do I need to wait for my USB-UIRT device before Girder will initialize the plug-in? I wanted to get a headstart looking at the Pronto Import feature while I was waiting for the device

[jrhees]

MikeH,

Yes, you'll need the USB-UIRT to get very far with the plugin. The Pronto Import basically is an option when trying to 'Learn' an IR code for retransmission. When you press the IMPORT button, you are given a dialog where you are allowed to paste a RAW pronto code into the box and hit OK.

-Jon