Linux driver

[Guest]

The usb-uirt does send something. I can see the ir-led flash in my video camera. Raw just doesnt get recognized by my receiver.

Whats strange as well is that when I send the structured code that is learned from Girder plugin, it works about 25% of the time. When using "test" in girder it gets 100% accuracy.

Jon, is there some sort of other initialization of the uirt before you xmit codes to it? I notice you have fine tune controls in the plugin and was wondering how that affects commands.

[jrhees]

There shouldn't be any needed initialization. The 'Fine tune' controls are to make *alterations* to the codes themselves. If you don't use them (leave them at center) no alterations are made.

Some things to make sure of are:

1. What is your repeat count? Is your success rate low because of too few repeats?

2. Are you getting the expected ACK's etc. from the USB-UIRT?

3. Are you allowing the IR transmission to complete before sending other stuff to the USB-UIRT?

-Jon

[Guest]

1.
Repeat counts were set to 4 on both Girder and being sent in the struct command in linux.

Repeat, Girder, linux
4, 100% , 5%
15, 100% , 25%
30, 100% , 15%

Seems to be not recognizable as much after 15 + repeats.

2.
Ill have to check the ACK.

3.
Nothing is being sent after the initial command.


So as far as you can tell, the protocol command we are using is correct
for the Raw code given? I wonder if something is funky with the 56Khz carrier frequency calculation or how the device handles it in RAW mode. Wish I had a digital scope (can I rent one? )

Thanks!
-J

[jrhees]

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

There's an error in this format, it should read:

36352d0400372f1681641680a214621680a214621680a21480a21680a21680a21480a21680a21480a21680a21480a21680a21680a2143

(the seventh byte in was changed from 2e to 2f, to indicate the correct number of burst/space bytes). You may also want to try:

36352c0400372f1681641680a214621680a214621680a21480a21680a21680a21480a21680a21480a21680a21480a21680a21680a2143

(Here the frequency is upped to 56.8KHz...but I think either of these should work fine)

-Jon

[Guest]

Jon: Thank you for finding that!

David: I hacked your USB-UIRT.pm to add one to the 7th byte of the code in the uirt_send_ir(). I wasnt quite able to find out where you were calculating this at first glance, so I just threw that code right before you calc the checksum and does the job.

This fix coupled with bumping the frequency to 58Khz (read specs saying echostar has a 57.6Khz bandpass) and now everything seems to be working great!! Near 100% accuracy (glitches once and a while, but ill live with that).

Now on to making a poor-mans tivo with MisterHouse.

-J

[jrhees]

You should be able to get 100% accuracy by upping the repeat_count.

-Jon

[Guest]

My hopes arent too high for 100%. My OFA remotes with the 0775 code dont get 100% either. I give partial blame to the Xantec system all of my IR is going through. I have a friend with a TIVO and it has problems with its IR blaster as well on the Echostar receiver.

For every channel change I am just going to have to repeat the whole sequence of commands a few times to make sure the channel is changed As long as its all automatic behind the schenes I will be happy.

[Guest]

One more thing.

While trying to get the RAW commands to work and changing some things around, I did manage to "lock-up" the USB-UIRT. I had to cycle the power on the USB port to get it to come around again. During its fuge, the IR LED was constantly on and a code was being sent out every 5 or so seconds. Nothing being sent to it was being responded to.. I was doing some of this testing remotely and had to wait several hours before I could get home to see what was going on and it was still hung at that point.

Just an FYI. Not that we should be sending invalid commands and expecting it to work

[jrhees]

Sounds likely that you sent something bogus to it. Things such as zero repeat counts and 0 durations can have interesting effects...

-Jon

[tbdombrosky]

So does the USB-UIRT work with lirc? I'm interested in using Linux instead but I don't feel like formatting and installing Linux if the USB-UIRT won't work with lirc. Thanks.

Tom

[hadees]

so how is development going?

[judapeno]

I have submitted a patch to the ftdi_sio linux driver to support the USB-UIRT. Unfortunately, there hasn't been a new release of the driver yet, and it may be a while. The next release will probably be 1.3.4 and you can check for it here:

http://ftdi-usb-sio.sourceforge.net/

This driver allows you to talk to the USB-UIRT as if it was a serial device. Use the communication protocol doc Jon posted here to figure out how to operate it.

[Guest]

Don't use MisterHouse for a poor man's tivo use http://www.Mythtv.org for a better than tivo front end/ record that won't cost you anything, btw if your working on the driver might i suggest making it compatiable with lirc because so many programs right now have support for it, doesn't have to be lirc but alteast emulate it

[Carl F.]

There's a patch on the lirc sourceforge site to provide UIRT2 support. With a minor change in the initialization routine, it works fine with the USB-UIRT. It's just a matter of getting the baud rate set up correctly.

Feel free to contact me at kf0yn@mchsi.com if you need more information.

[htpc_linux]

Did you manage to get USB UIRT working on Linux ?

If yes, and if you don't mind can you share the driver with us ?

Thanks You