Format of IR data from USB UIRT Reader?

[rcohen]

I have a USB -UIRT reader and I am sending it data from a microcontroller. I am using NEC and Sony protocols. The data I am getting is very inconsistent. Does EventGhost format the data in any way?

For example
irsend 0
Sending string over IR: 0
> INFO: nxp: IR trans done

Result for reader is

12:00:13 AM USB_UIRT.47BD540651BC

I don't see a hex 30 or it complement (NEC Protocol)

Thank you
Rob

[Bitmonster]

EG simply pipes the data from the USB-UIRT driver for the events. So there is no modification. You can proof it with a little utility from Jon Rhees that is also able to receive events from the USB-UIRT:
http://www.usbuirt.com/lrnhelper_0_0_2.zip

[rcohen]

I am using a programmable remote control that is transmitting the NEC protocol. The data received from EventGhost shows data but I see no evidence of the complement of the Command and the Address.

Any ideas why I don't see the complements?

Thank you

Rob

[Bitmonster]

Why do you think, there should be any evidence visible of the complements?

The algorithm used by the USB-UIRT seams to be nearly the same as the one used by the UIRT2. It will simply compare the current pulse (or current pause) with the previous one and then shifts in a "1" bit if they significantly differ or a "0" bit if not.

[rcohen]

I am a hardware guy and I read the NEC data format. It said

It is always a 32-bit code. Which consists of 16 bits of data and 16 bits of error checking. The code is divided into four 8-bit fields.

A device code will be in the range of 0 to 255 or 256 discrete device codes. The same is true of the function code. The compliment fields are the 1ÔÇÖs compliment of the code they represent. The device code and the device code compliment must add up to 255 or else there is an error. The same is true of the function code and the function code compliment.

I expected to see the device code and function code and there 1's complement in the data.

Is there a bit shift that I do not know about? I just want to validate the data. The prototype I am working with might be unstable so I need to check every byte is sends.

Am I missing something? If I had an Digital O-scope I could get right to the source of this issue, but I don't.

Thank you

Rob

[rcohen]

I tried teh prgram and it worked great.

Using Event Ghost and Cendron remote. I got the following when I pressed the first button.

4:23:53 PM USB_UIRT.1900020000E0


Using the USB-UIRT Learn Helper Utility I got the same data.

1900020000E0.

I have confidence in Event Ghost. I think it is a great tool and
I plan on using to automate testing of my project.

Once I get a handle on the data I will move on to testing.



Thank you for the link to the program.

Rob

[Bitmonster]

You misinterpret the abilities of the UIRT. It does no real decoding of any IR format when it generates events. The purpose of the events is only to be consistent for one button, but different to any other button. Thats why such devices generally use a simple approach to achieve this for all (or at least most) IR formats. As said above it only looks if a pulse or pause is different from the previous one and then shifts-in the result into a buffer. What you see as an event is simply this buffer. But this appraoch is lossy. You can't get the real IR code back from it.

[Bitmonster]

BTW: If you want to analyze IR codes on the deepest level, you can use your soundcard as a digital scope. Get an IR receiver component like a TSOP1738 and source it with a 5V supply. Then connect the data pin to your soundcard through a 1k (or bigger) resisitor (just for safety). Now you can monitor and store the signals you get. There are millions of audio recorder softwares out there and even some programs that are especially made for this purpose like this one:
http://www.zeitnitz.de/Christian/Scope/Scope_en.html

This works with the same principle (more advanced schematic), but was intended for a linux machine:
http://people.inf.ethz.ch/mringwal/lirc/index.html