USB-UIRT Forum

I've had some partial success getting the USB-UIRT working on Linux. It turns out Linux includes a driver for the usb-serial chip (FTDI) used in the USB-UIRT. I had to modify the driver source slightly to recognize the vendor and product IDs.

Now, I can receive incoming IR codes, but none of the UIRT2 commands I send seem to work.

Jon, please post a protocol spec for the USB-UIRT!

David

Dave,

Thanks for your work on this! I will post a low-level protocol spec. for this purpose. *However*, it should be kept in mind that this protocol will change and migrate over time as the firmware is enhanced.

-Jon

David,

Here's a preliminary spec:

http://home.earthlink.net/~jrhees/USBUI ... otocol.doc

-Jon

FYI: I just installed one of Jon's USB UIRT last night, and I wanted to let everyone know that this thing works great!! I previously experimented with other IR rs232 devices from Actisys and they were nothing but trouble.

It was a real pleasure to plug it in, load the driver, and see it work so well.

Thanks Jon!!

Thanks for the good news, 'Guest'!

-Jon

Thanks for the good news, 'Guest'!

-Jon

http://archives.neohapsis.com/archives/ ... /0463.html

Jon,

Would you update the protocol spec to reflect the new firmware release? I would like to implement the new learning capability (with carrier recognition) in my Linux application.

David

Judapeno,

I'll try to update the low-level protocol soon. But to tide you over, here's the changes:

1. The baud rate has changed from 125000 to 312500. This was to further reduce latency and to widen the pipe for the new RAW mode.

2. Added another RAW mode. Unlike the normal raw mode (which is entered via command 0x21), the new RAW mode is entered via command 0x24 and works like this:

a. Like the regular RAW mode, the first two bytes sent to the host are the Inter-space delay. This is in units of 51.2 uS. The Inter-space delay's accuracy has been improved, however.

b. The new RAW mode will send 3 or 4 bytes for each pulse from the remote. This is in the form:
Ph Pl Cl -or- Ph Pl Ch Cl
...where Ph and Pl represent the Pulse Time high byte and low byte, respectively. These are now in 400nS units.
...where Ch, Cl represent the *number of carrier cycles* which occurred during the pulse time. If count<0x80, only Cl will be sent. If count>=0x80, Ch will be sent with the msb set followed by Cl. For example, a count of 0x85 would be sent as 0x80 followed by 0x85.
...To compute the carrier for the pulse, use the formula:
pulseFreq = ((1000000/((PhPl*0.4) / (ChCl-0.5)))

c. The new RAW mode will send two bytes for each space from the remote. This is in the form Sh Sl, where Sl and Sl represent the Space Time high byte and low byte, respectively. These are now in 400nS units.

To compute carrier frequency, it is suggested that some form of running average be maintained. This is because the circuitry may not see a full cycle count if the remote is too close or far away during learning. If the remote is detected to be too close, the USB-UIRT will send 0 for the cycle count.

-Jon

Hi Jon,

Couple of questions

Where is the new firmware located and how is that updated?

Is there a way to determine the firmware version via a protocol command? I didnt see anything in your protocol doc.

Does the new firmware support the 125000 baudrate anymore(doesnt sound like it)? Do you foresee the baudrate changing again any time soon?

I would like to work with the maintainers of the ftdi driver module in getting the usb-uirt supported in the official linux code tree. Dave sent me his patch and everything appears to be working fine at a driver level, just would like to get it included for a more plug-n-play experience

-J

From the protocol doc:

GETVERSION = 0x23 + checksum
On this command, the USB-UIRT will send 7 bytes of version info followed by a checksum byte, as follows:
Byte 0: Firmware MinorVersion
Byte 1: Firmware MajorVersion
Byte 2: ProtocolCompatibility MinorVersion
Byte 3: ProtocolCompatibility MajorVersion
Byte 4: FirmwareDate Day
Byte 5: FirmwareDate Month
Byte 6: FirmwareDate Year
For the USB-UIRT protocol described here, the versions are currently:
Firmware Version = 5.0
ProtocolCompatibility Version = 0.0
Note: ProtocolCompatibility specifies the ‘minimum required’ protocol version support on the host for proper operation. A value of 0.0 indicates no compatibility requirements.

The new firmware will report back version 5.3 and protocol compatibility of 1.1

Also, the new firmware will no longer support 125000 baud. I believe the 312500 baud rate is here to stay!

If you email me at uirtsupport@earthlink.net and request the prerelease firmware I can send it to you.

-Jon

Doh! My Bad. I just happened on that part of the doc before comming here to see you already responded to me. :Z

Thanks for the answers! I send an email.

-J

I obtained the following raw code from girder (which xmits fine in girder) with the new firmware: 56Khz 4 repeat.

R00371681641680A214621680A214621680A21480A21680A21680A21480A21680A21480A21680A21480A21680A21680A214

Sent this as the command to the usb-uirt from David's program:

36352d0400372e1681641680a214621680a214621680a21480a21680a21680a21480a21680a21480a21680a21480a21680a21680a2143

Im just guessing at the format as:

Extend command: 0x36
Freq: 0x352d
Repeat: 0x04
Interspace: 0x0037
Pulse Count: 0x2e
Data: 0x16 81 64 16 80 a2 14 62 ......

Does anyone see whats wrong?

A couple corrections to Jason's post above, based on MY understanding of the protocol spec:


Extend command: 0x36
Command length: 0x35
Freq: 0x2d (2500000/56000)
Repeat: 0x04
Interspace: 0x0037
Byte Count: 0x2e
Data: 0x16 81 64 16 80 a2 14 62 ......
Checksum: 0x34 (I think Jason left off the 4 when he copy and pasted)


Did I calculate frequency right? Did I do the byte count right?

David

Your right..

Missed the 4 in the 0x34 checksum in the cut 'n paste. I verified this is being sent correctly to the usb-uirt.