by jrhees » Mon Oct 13, 2003 3:27 am
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