[urgent] RAW IR codes gt 50, limitations of UIRT2?

[Snow]

I'm working on a thesis where I develop an application that works with infrared and Luc's UIRT2 module. At the moment I can receive, learn and resend RC5 infrared remote codes via RAW receive and transmit.

The problem resides in infrared codes of NEC, Sanyo, Pioneer and related Japanese remote controls. Their codes are much longer then RC5 codes.

For example:

Philips remote: 28 bytes received, 31 resend (dotxraw).
02e2 130f
130f
240f 130f 130f 130f 130f 130f 130f 120f 130f 1320 13ff

Sanyo remote: 70 bytes received, 73 resend (dotxraw).
8232 b156
0c08 0d08 0c09 0c1e 0c1e 0d1e 0c08 0d08
0c1e 0d1e 0c1e 0c09 0c08 0d08 0c1e 0d1e
0c1e 0c09 0c08 0d08 0c09 0c08 0d08 0c09
0c08 0d1e 0c1e 0c1e 0d1e 0c1e 0c1e 0d1e
0cff

The UIRT2 Command protocol limits transmitting to 50 bytes and I think this is the reason why I receive error code 81 (timeout) when I try to send the Sanyo code.

I have a very tight deadline to catch, so I would be very thankful to anyone who can confirm my theorem or anyone who can find a workaround for this vexing problem.

Best regards,
Snow

Edit: I tried this with Girder and learning in RAW-modus from the Sanyo remote control doesn't work. Structured-modus does, but that's no help since I'm working with RAW and I have to stick to this. The good old Philips device works fine in both ways...

[jon_rhees]

This is indeed a memory limitation on the UIRT2 design. Since it is serially driver, the code must be cached in the UIRT's memory before transmitting.

-Jon

[Snow]

Thanks Jon.

From the UIRT2 Command Protocol:

It is recommended that host interfaces utilize RAW mode for learning IR commands and UIR mode for normal event reception. This allows the host to use a more sophisticated algorithm to translate RAW IR data to a REMSTRUCT structure suitable for re-transmission.

A solution would be to receive in RAW mode and to convert this to a REMSTRUCT for re-transmission using a sophisticated algorithm?

When I look at this REMSTRUCT it is first of all quite complex, but one expects that you know exactly how every bit of the RAW code corresponds with a 0/pulse, 1/pulse, 0/pause, 0/pulse, number of data bits, etc. Since this differs pretty much in every remote code protocol, I would assume on first sight that you need a distinct algorithm for every type of remote code protocol?

If this is indeed the case, the cost of losing so much flexibility would be too high.

How does Girder handle these concerns?

[jon_rhees]

There is a very sophisticated algorithm in the UIRT plugin for learning in non-raw (STRUCT) mode. Unfortunately, if you're unsuccessful getting your IR code to learn without going to RAW mode, then there's a good chance that the code simply isn't compatible with STRUCT.

Struct is basically a method of compression which assumes that there are only two different pulse/space timings to toggle between. If your codes have more than 2 unique timings, the STRUCT mode will not accomodate them.

-Jon

[Snow]

Is there a possibility that this "very sophisticated algorithm" becomes public in the spirit of open source?