Questions about UIRT protocol

[frdfsnlght]

I have a few questions about the protocol used between the PC and the UIRT. I've been reading Danijel Pticar's most excelent protocol page (http://free-zg.hinet.hr/DPM/protocol.txt), but I still have a few questions.

1) When the UIRT is in "normal" use, what mode is being used, GRAB or DEBUG? I would expect GRAB, but maybe I'm wrong.

2) When in GRAB mode, I assume the UIRT internally converts between DEBUG like data and GRAB format. What's the algorythm used? How do you get from pulse times to GRAB format?

3) I've looked at Danijel's protocol page, but I don't understand parts of his description of the GRAB data format. For example, he states:


P1=First puls length
P2=Length of puls that length is different than P1 length
( |P1-P2|>6 )


I understand P1, but what does he mean for P2, and what does the following expression mean? I mean, I understand the syntax, but what's the symantic?

Any help would be appreciated. Thanks.

-Tab

[kari]

Hi.

1) Actually I think it is the UIR mode. In this mode the GRAB data is further codified into standard 6-byte strings. These strings cannot be used to regenerate the original IR signal, hence the need for a seperate GRAB mode. They have however the advantage that they are repeatable, i.e. successive presses of the same button should always produce the exact same UIR code. In the GRAB mode variations in timing can produce minor variations in the code returned.

2) I don't have the algorithm, but it should be possible to work it out from the description of the codes returned.

3) Perhaps this is slightly clearer:
P1= length of first pulse from remote.
P2= length of first pulse from remote that is more than 6 units longer or shorter than P1.
The reason for this is that remotes usually indicate '1' and '0' by varying the mark to space ratio: '1' might for instance be indicated by a 10 msec pulse (mark) followed by a 5 msec pause (space), while '0' might be indicated by a 5 msec pulse followed by 5 msec pause.

Hope this helps

-Kári.

PS: Note that Danijel uses a protocol that is different from Ruud van Gessel's (the original creator of the UIRT).

[frdfsnlght]

OK. So UIR mode is the "normal" mode. I also now understand the conversion from DEBUG data to GRAB data (thanks kari, for clarifying that bit of the mystery; your description of P2 is much better than Danijel's). So I guess I now have these questions:

1) In GRAB mode, are the B1-B13 bytes just packed bits? That would mean that they represent 96 bits of data, where each 1 and 0 is represented by the pulse/space lengths in P1, P2, S1, and S2. Correct?

2) How do you get from GRAB mode data to UIR mode data? What's the algorithm used to condense 22 bytes to just the 6 bytes in UIR mode (producing a "reliable" code)?

3) Why isn't the data in GRAB mode "reliable"? If you just look at the B1-B13 bytes, shouldn't that produce a "reliable" code? Why reduce it to 6 bytes in UIR mode?

Thanks for the help so far.

-Tab

[kari]

1) Yes.

2) Sorry, I don't have that algorithm.

3) I'm afraid I hadn't thought this possibility right through :oops: You are quite right, bytes B1-B13 are constants. It is just HP through S2 that vary slightly on successive keypresses (due to equally slight variations in timing). One curious thing I noticed though while testing this just now. My TV remote seems to send out alternating codes for the same key (first keypress produces code A, a second keypress code B, a third code A again, and so on). This is in GRAB mode. in UIR mode however all keypresses produce the same code, so the algorithm must compensate for this somehow. There may be other pitfalls of a similar kind to using the GRAB mode for event starting.
Another reason for using UIR mode in some applications may be compatibility. The UIR protocol is compatible with the protocol of the original UIR device and all its spinoffs (IRman et al.)

-Kári.

[frdfsnlght]

Again, thanks for the help.

I wonder if anyone else will be able to chime in with the algorithm for GRAB to UIR data. I might be able to figure it out from the disassembly of the PIC code, but reading uncommented, unlabled assembly that you haven't written yourself is a daunting task. I haven't yet been able to find a source willing to give me a copy of the source assembly. Oh well.

I understand about the toggling codes, but I tought that the windows side driver handled this, so I didn't think it would get fixed in the hardware.

Anyway, the reason I'm asking all these questions is that I'm building myself a PIC based UIRT of sorts. It's my own design, inspired by the UIRT threads. I'm building it to satisfy my own needs, but I expect it may be useful for others. In a nutshell, this is what I'm building:

*) 20 MHz 16F877 based
*) IR reception
*) IR transmission
*) at least 8 button inputs
*) some outputs (not sure how many yet)
*) Ability to wake sleeping PC (WOR, WOL, power button)
*) Ability to turn on PC
*) Drives LCD/VFD panel
*) Powered by the PC PS, not the serial port
*) Uses proper RS232 drivers, so long distance/high speed won't be a problem
*) Interrupt driven serial IO
*) Command interpreter, of a sorts (none of the repetituous resetting like the UIRT)

On the host side, I'll be writing a Java daemon (platform independence) that will provide fancy LCD/VFD display options like scrolling, etc. The daemon will be a TCP server and multiple clients (e.g., Girder) will be able to connect and register to receive particular events, like button press/release, IR raw timing, and other events.

The Java side should be no problem since I do network server programming for a living. On the hardware side, I'm a computer engineer, so this is right up my alley. It's been a while since I've done hardware, but so far I have my PIC receiving IR and transmitting to the PC. The other functions should be easier than what I've done so far.

Anyway, thanks for the help, and please let me know if you learn anything else that may be useful with regards to my questions. Thanks.

-Tab

[kari]

Wow! This sounds impressive!

I hope you will let us know how it comes along.

Btw. I just rechecked; the toggling codes are definitely handled by the UIRT, not the Girder plugin.

-Kári.