USB-UIRT & GIRDER: I/R butons work like toggles?

[gduprey]

Howdy,

I have the latest USB-UIRT driver and Girder 3.3 installed and am trying to teach USB-UIRT/Girder a series of RC5 I/R codes I've programmed into my ProntoProNG remote control.

The problem is that after learning, the buttons on the remote are acted on only on every other push (like the button is a toggle or something).

When I look at the girder status bar, pressing the button once displays one hex code (next to the LED) and pressing it again displays an alternate code. Repeated presses consistantly cycle between those two codes. When I have Girder learn, it picks up one code but not the other.

I've confirmed the remote is sending only a single RC5 compatible I/R code on each button press. In fact, the RC5 hex code string is:

5000 0000 0000 0001 0008 0001

which is RC5 8 1

Actually, all my buttons are like this (variations of the RC5 codes, though each is unique in the last 4 digits).

I have tried all sorts of learning situations and am sure there is no extraneous light (I/R, flourescent, etc) around. I have the sensor at about 3" from the remote and have tried moving it closer and further with no different result.

Any thoughts/suggestions?

I have tested this with a stock/standard remote control and USB-UIRT seems to learn some codes from them OK (i.e. responds each time the button is pressed, not every other time). So I don't think the unit is bad, but it definetly does not seem to get along with either the RC5 command set or my ProntoProNG unit very well.

Any thoughts, pointers or suggestions would be very much appreciated.

Gerry

[jrhees]

Gerry,

This is typical for RC5 codes. When a remote *transmits* an RC5 code, it intentionally toggles a 'parity' bit in the IR stream. This causes the remote to actually transmit two versions of the same code. The RC5 protocol used this feature to help receiving equipment determine if a button-press was 'missed'.

Because the USB-UIRT is a universal receiver, it does not attempt to decode RC5 (because the received IR could be any protocol). Therefore, you will see two alternating codes.

There are two ways to deal with this:

1. Some people simply avoid using RC5 if they're putting codes into a programmable remote control. Unsing a simpler protocol eliminates the dual codes and also gives faster response time.

2. Others simply learn two Girder events for each button.

-Jon

[gduprey]

Howdy,

The RC5 codes I'm sending are from a ProntoPro which basically really has no idea it's an RC5 control signal (I don't think it does) and as such, is just the short sequence of hex codes I included above. As such, I'd image the remote doesn't know enough to send it one way and then another (who knows though -- perhaps it senses the code pattern).

Are there any other "simpler" code patterns you can suggest? I don't have any particular affinity for RC5 -- just seemed like an easy code that I could type in and easily modify (so I didn't have to learn many codes from a remote (which seems to cause it's own problems)).

Thanks!

Gerry

[gduprey]

Argh!

I just spent 2 hours teaching my remote to use a differnt code set (a Sony DVD player as the source -- I have no Sony equipment) and it's still happens.

In fact, it's worse now -- pressing a button on the remote now cycles through 3 or 4 different event codes (the hex codes displayed on the bottom of the Girder status bar). These buttons are programmed directly from the remotes built in code list and should be as clean as I/R can be.

Is it possible my USB-UIRT unit is bad? Any help here would be appreciated. I've been working on this, off and on, for 4 months and have yet to get a stable, reliable I/R control. I know it can be done, but something in the mix is not working.

Thanks for any help,

Gerry

[jrhees]

gduprey,

I'm sorry you're having so many issues! Before you go further with the Pronto, try grabbing a few remotes you have lying around for some pieces of equipment you own and test them out on the USB-UIRT. You definitely should find many remotes which produce repeatable, reliable codes.

Some possible complications could be excessive IR noise (fluorescent lights, plasma displays, etc.) but even these should affect the code reliability at shorter range.

-Jon