Linux driver

[furry_fool]

If possible can you post some of the steps to make USB-UIRT to run on Linux?
Thanks.

[tbdombrosky]

I tried to get it set up in Redhat with the 2.4.22 kernel. I get it recognized and it's definitely at /dev/ttyUSB0 because when I do a cat the led doesn't blink anymore. It also is recognized as the USB-UIRT in /proc. I have the FTDI driver loaded but can't seem to get any commands recognized by Lirc. I could not get the uirt2 patch to compile in Lirc. Can anyone help with this? The patch doesn't seem to have the right files in the right places (or I may be doing the wrong command)? I issued the patch -i patch.diff but it just put them in the current directory. I've never patched anything before so I may be doing something wrong. Any help would be greatly appreciated. Thanks.

Tom

[jrhees]

Boy, wish I could help, but this [linux] is all greek to me! Sorry!

-Jon

[Guest]

I believe the driver is just generic/raw gateway to talk to the chip inside usb-uirt but someone needs to write software which would know protocol to send/recieve signal. And the protocol depends on firmware which seems to be not finished, and author still works on it. If you are going to write/read that RAW device under Linux, I think you are risking to corrupt firmware and might not be able to fix it yourself, so be carefull.

[jrhees]

The firmware *is* pretty well baked -- especially for the feature set you'd probably use for Lirc. IIRC, Lirc, basically does most of the thinking inside the host PC, so only some basic functionality would actually be used inside the USB-UIRT firmware.

I *do* make periodica changes to the firmware, but most of the time it is bug and compatibility fixes or enhancements.

The processor *is* field-flash-upgradable, but the architecture is such that you cannot really 'accidentally' mess up the part. So, the risk is low. And, even if somehow you overwrote the firmware, the design is such that a 'dead' unit can still be field-programmed by the host PC.

I wish I knew more about the Lirc project, but I'm not a Linux-head and really am out of my element with it. If someone needs help with the internal workings of the Lirc USB-UIRT driver, I can certainly help there...

-Jon

[Guest]

If firmware has stable protocol specs then I guess its matter of time until someone gets it to work. Some guy on LIRC list says he got it to work with UIRT2 driver and small change in source, he refered to baud rate. The LIRC must be compiled from current CVS sources.

[Scott]

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

is there an updated source for the protocol spec that reflects the recent changes? this document (above) appears to be out of date. if not, can i get access to past firmware versions? i'm using non-girder software (misterhouse) that someone wrote a driver for earlier in the year. looks like the protocol change in march broke the driver...

Scott

[jrhees]

The firmware changes should have no effect on this -- unless I'm mistaken, Misterhouse does *not* talk directly to the USB-UIRT, but rather accesses the API driver. The protocol specification you refer to describes the low-level comm between the device itself and the API driver, and should be invisible to any app using the API interface.

-Jon

[Scott]

thanks for the clarification...

you are correct (at least on the windows side - i think the linux version of Misterhouse talks directly to the UIRT). has there been a change in the API with the recent fimware/protocol changes?

scott

[jrhees]

I'm not aware of any [intentional] change in the protocol. Do you have any specifics on what broke?

-Jon

[Guest]

Can anyone kindly post what needs to be done in lirc? It seems ftdi_sio driver locks baud rate at 312500 and/or maps it to 38400 but changing baud rate in lircs hw_uirt2_raw does not seem to help at all.

[kRutOn]

Okay, I must be missing something. I've made some modifications to LIRC to support the USB-UIRT, but so far I've had limited succses in getting it to transmit. I used Girder to receive a IR code and transmit it back to a device and it works fine.

Girder uses this at 4 repeat, 56KHz, zone all:

Code: Select all

R00371781651780A41780A41780A41780A41780A41780A41780A41780A41780A41780A41780A41780A41780A41780A41780A417

I created a LIRC profile that is similar to what Girder thinks it is, and the output to the USB-UIRT is:

Code: Select all

lircd 0.7.0pre7:  36 36 2c 04 00 37 30 17  80 a7 17 80 a7 17 80 a7  17 80 a7 17 63 17 80 a7  17 80 a7 17 80 a7 17 80  a7 17 80 a7 17 80 a7 17  80 a7 17 80 a7 17 80 a7  17 80 a7 17 80 a7 17 ca
lircd 0.7.0pre7: wrote 56
lircd 0.7.0pre7: cmd res 1:
lircd 0.7.0pre7:  21

However, the device doesn't respond to the LIRC command. The only difference is that I chopped off the beginning 178165 code from LIRC because I thought it was spurious.

[jrhees]

kRutOn,

For the USB-UIRT to respond, you must conform to the low-level protocol specification (located earlier in this thread).

-Jon

[Guest]

For the USB-UIRT to respond, you must conform to the low-level protocol specification (located earlier in this thread).

Sorry, I think I spoke ambiguously. When I said the device doesn't respond, I meant the Dish Network receiver I was trying to control with the infrared code. The USB-UIRT responds with CMDOK (0x21) and the red light comes on momentarily while it transmits.

I can receive commands fine as well. So I was hoping there was something fundamentally flawed with how I translate the R0037... string to an actual command.

[jrhees]

Well,

two comments -- 1) You *dont* want to remove the 178165 header. This is *not* spurious but is the typical IR preamble most IR devices use to set their AGC.

2) What repeat value are you using? Make sure its four or so for starters.

If you email me at support@usbuirt.com, we can work on this a bit more if needed. I can feed commands through the API driver and give you the binary back of what is being sent to the device if needed.

-Jon