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
Linux driver
Moderator: jrhees
46 posts
• Page 1 of 4 • 1, 2, 3, 4
by jrhees » Mon Mar 03, 2003 11:07 am
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
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
- jrhees
- Site Admin
- Posts: 1652
- Joined: Tue Jan 28, 2003 11:49 pm
Preliminary Spec.
by jrhees » Mon Mar 03, 2003 4:44 pm
- jrhees
- Site Admin
- Posts: 1652
- Joined: Tue Jan 28, 2003 11:49 pm
by Guest » Tue Mar 04, 2003 9:14 pm
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!!
It was a real pleasure to plug it in, load the driver, and see it work so well.
Thanks Jon!!
- Guest
OpenBSD at it too?
by brockgr » Thu Mar 06, 2003 2:18 pm
- brockgr
- Posts: 5
- Joined: Mon Feb 03, 2003 4:47 am
by jrhees » Sun Apr 20, 2003 11:55 pm
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
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
- jrhees
- Site Admin
- Posts: 1652
- Joined: Tue Jan 28, 2003 11:49 pm
by Guest » Tue Apr 22, 2003 6:15 pm
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
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
- Guest
by jrhees » Tue Apr 22, 2003 6:25 pm
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
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
- jrhees
- Site Admin
- Posts: 1652
- Joined: Tue Jan 28, 2003 11:49 pm
by Guest » Thu May 08, 2003 12:28 am
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?
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?
- Guest
by judapeno » Thu May 08, 2003 12:52 am
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
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
- judapeno
46 posts
• Page 1 of 4 • 1, 2, 3, 4
Who is online
Users browsing this forum: Bing [Bot] and 108 guests