Linux Infrared Remote Control

Hi!

Adam Sampson "ats@..." wrote:
[...]
> If you've got any thoughts on the patch, I'd be interested to hear
> them... this seems like a simple enough bit of hardware to build that
> it'd be worth getting into upstream LIRC.

- s/4/sizeof(lirc_t)

- you probably can remove this set_nonblocking() stuff. I don't see why it  
should be required (there are systems where O_NONBLOCK is not defined?  
shiver ;))

- you are leaking the pipe file descriptors, close them

- fork instead of thread

Christoph

Hello Adam,
> I've been playing with your libftdi driver for LIRC. I've updated the
> patch [...]
>   
nice to hear that somebody actually managed to get it working ;-)

> I've left it using pthreads for now, but since all the other lircd
> backends that need concurrency use a separate, forked process, it might
> be worth changing that too at some point. 
There should be no problem to move to a forked process I think. But I'm 
not a hero when it comes to working with patchfiles etc. Could you give 
me a hint how to apply your patch to the CVS version? How does your 
patchfile refer to 'a' and 'b' paths?

while typing this reply a mail from Christoph came in with some 
additional hints too..
- s/4/sizeof(lirc_t)
eeh... this indeed is a bit of a hack, and not portable. I think best is 
to define 'rxctr' to be of type lirc_t and use 'sizeof(lirc_t)' as the 
record length in the pipe.

- you probably can remove this set_nonblocking() stuff. I don't see why 
it  should be required (there are systems where O_NONBLOCK is not 
defined?  shiver ;))
I just copied it somewhere from the net, didn't pay much attention to 
it. So a simple 'fnct()' call in place is more elegant then.

- you are leaking the pipe file descriptors, close them
oops

- fork instead of thread
I'd like to try to implement this, but I can't get Adam's patches to 
compile for me right now.

> It all seems to work happily.
> [..] it'd be worth getting into upstream LIRC.
>   
Note that the transmitting part doesn't perform well. I've done some 
further testing, and there are really big 'gaps' in between the 
continous stream. This causes the transmitted carrier to contain 
unwanted pulses :-(
When supporting reception only, the bitrate (and therefore the USB 
traffic) can be descreased significantly.

> I'm using the FT232R chip on an Arduino NG board (since I had a few of
> [...]  http://offog.org/stuff/irduino.jpeg
>   
:-) cool


-- 

 __________________________________________________________________
|                           _______                                |
| *Albert Huitsing*          |       |     *Huitsing Embedded Systems* |
| System Design            |    /|___|\            Dr. Mondenweg 5 |
| albert@...       |   /       \    7831 JA  Nw. Weerdinge |
|                          |   \  ___  /  Phone: +31-(0)591-521222 |
|                          \    \| | |/     Fax: +31-(0)591-522113 |
|                           \______|        http://www.huitsing.nl |
|                                                                  |
|      "/conformity is the uncomfortable feeling of wearing/         |
|       /somebody else's clothes; even when they don't fit/"         |
|__________________________________________________________________|

On Mon, Dec 29, 2008 at 10:23:34PM +0100, Albert Huitsing wrote:
> There should be no problem to move to a forked process I think.

OK -- here's an updated version of the patch that uses a forked process,
and fixes the other problems Christoph spotted (thanks!):

  http://offog.org/stuff/lirc-ftdi-20081229a.diff

> Could you give  me a hint how to apply your patch to the CVS version?
> How does your  patchfile refer to 'a' and 'b' paths?

It's the same as with your patch: change into the source directory, and
do "patch -p1 <whatever.diff", where -p1 means to strip the first
directory component off all the paths. The reason my patch looks a bit
funny ("a/...") is because I used git to generate it, rather than using
diff by hand.

> Note that the transmitting part doesn't perform well. I've done some  
> further testing, and there are really big 'gaps' in between the  
> continous stream.

Hm, that's a shame -- I guess building a 38kHz oscillator onto the end
of the cable would somewhat defeat the point of it being simple. ;)
I haven't tried transmitting yet...

Thanks,

-- 
Adam Sampson <ats@...>                         <http://offog.org/>

Hi!

Albert Huitsing "albert@..." wrote:
[...]
> - you probably can remove this set_nonblocking() stuff. I don't see why
> it  should be required (there are systems where O_NONBLOCK is not
> defined?  shiver ;))
> I just copied it somewhere from the net, didn't pay much attention to
> it. So a simple 'fnct()' call in place is more elegant then.

No, please remove it altogether. There's no need to make the read end of  
the pipe non-blocking.
Adam's latest patch looks fine otherwise.

[...]
>> It all seems to work happily.
>> [..] it'd be worth getting into upstream LIRC.
>>
> Note that the transmitting part doesn't perform well. I've done some
> further testing, and there are really big 'gaps' in between the
> continous stream. This causes the transmitted carrier to contain
> unwanted pulses :-(
> When supporting reception only, the bitrate (and therefore the USB
> traffic) can be descreased significantly.

How about switching bitrate on demand?

Christoph

On Mon, Dec 29, 2008 at 5:42 PM, Adam Sampson <ats@...> wrote:
>> Note that the transmitting part doesn't perform well. I've done some
>> further testing, and there are really big 'gaps' in between the
>> continous stream.
>
> Hm, that's a shame -- I guess building a 38kHz oscillator onto the end
> of the cable would somewhat defeat the point of it being simple. ;)
> I haven't tried transmitting yet...

Toggling a GPIO off/on at 38Khz over a USB link is never going to work
accurately; the latencies are too high.

But, a FTDI chip can send serial streams at up to 6Mb. You can use the
serial stream to create 36-40Khz by sending patterns of 1/0.


>
> Thanks,
>
> --
> Adam Sampson <ats@...>                         <http://offog.org/>
>
> ------------------------------------------------------------------------------
>



-- 
Jon Smirl
jonsmirl@...

On Mon, Dec 29, 2008 at 06:30:28PM -0500, Jon Smirl wrote:
> But, a FTDI chip can send serial streams at up to 6Mb. You can use the
> serial stream to create 36-40Khz by sending patterns of 1/0.

Yes, that's what Albert's doing:
  http://www.huitsing.com/irftdi/

-- 
Adam Sampson <ats@...>                         <http://offog.org/>

Hello all,
> No, please remove it altogether. There's no need to make the read end of  
> the pipe non-blocking.
> Adam's latest patch looks fine otherwise.
>   
Adam's latest patch works fine here with my hardware. I've removed the 
non-blocking code and it still works. So the reader process is doing a 
select() then? or simply blocks until data available? Christoph: I'll 
take a look in your code and learn further. Adam: you really tweaked 
those last steps quickly, wow! Nice solution by the way using the 
'usecs' variable, this way it is platform and type safe.

> How about switching bitrate on demand?
>   
the 'demand' being a static command line argument, or do you mean 
dynamically:
*) waiting for initial starting edge with low bitrate
*) dynamically switching to high bitrate for decoding
I think the I/O buffers will ruin this idea, because decoding always 
lags behind realtime and it's too late in time to switch bitrate when 
the start-edge was detected.
A static commandline argument on the other hand will be feasible though.

Albert
-- 

 __________________________________________________________________
|                           _______                                |
| *Albert Huitsing*          |       |     *Huitsing Embedded Systems* |
| System Design            |    /|___|\            Dr. Mondenweg 5 |
| albert@...       |   /       \    7831 JA  Nw. Weerdinge |
|                          |   \  ___  /  Phone: +31-(0)591-521222 |
|                          \    \| | |/     Fax: +31-(0)591-522113 |
|                           \______|        http://www.huitsing.nl |
|                                                                  |
|      "/conformity is the uncomfortable feeling of wearing/         |
|       /somebody else's clothes; even when they don't fit/"         |
|__________________________________________________________________|

Hi!

Albert Huitsing "albert@..." wrote:
[...]
> Hello all,
>> No, please remove it altogether. There's no need to make the read end of
>> the pipe non-blocking.
>> Adam's latest patch looks fine otherwise.
>>
> Adam's latest patch works fine here with my hardware. I've removed the
> non-blocking code and it still works. So the reader process is doing a
> select() then? or simply blocks until data available?

Your problem probably was caused by the missing waitfordata() in the  
initial code.

[...]
>> How about switching bitrate on demand?
>>
> the 'demand' being a static command line argument, or do you mean
> dynamically:

Change to a high bitrate if you are planning to transmit something and  
switch back once done.

Christoph

On Tue, Dec 30, 2008 at 12:19:00AM +0100, Christoph Bartelmus wrote:
> No, please remove it altogether. There's no need to make the read end
> of  the pipe non-blocking.

OK; here's another version:
  http://offog.org/stuff/lirc-ftdi-20081230.diff

Changes since the last one:

- The pipe's no longer made non-blocking. (Looking at the other drivers,
  hw_commandir is the other one that does this; presumably that should
  be fixed too?)

- Fixed the sample rate computation, having checked the FT232 datasheet:
  it should be 16 times the baud rate, not 32. (Albert, you'll need to
  double the time values in your lircd config -- but it now works with
  the config files out of the lirc distribution.)

- Made the baud rate configurable, and made the default 4800 rather than
  4500 since the FT232 can't do 4500 exactly.

- Some minor cleanups.

Thanks,

-- 
Adam Sampson <ats@...>                         <http://offog.org/>

Hi!

Adam Sampson "ats@..." wrote:

> On Tue, Dec 30, 2008 at 12:19:00AM +0100, Christoph Bartelmus wrote:
>> No, please remove it altogether. There's no need to make the read end
>> of  the pipe non-blocking.

> OK; here's another version:
>   http://offog.org/stuff/lirc-ftdi-20081230.diff

I've put this into CVS.

[...]
> - The pipe's no longer made non-blocking. (Looking at the other drivers,
>   hw_commandir is the other one that does this; presumably that should
>   be fixed too?)

No, this is the child's read pipe, not the parent's.

Christoph

Hello,
>> OK; here's another version:
>>   http://offog.org/stuff/lirc-ftdi-20081230.diff
>>     
Adam: nice work, thanks for all your efforts!
> I've put this into CVS.
>
> [...]
>   
Christoph: thanks too!

I've update my page at http://www.huitsing.nl/irftdi to reflect the changes.

Albert
-- 

 __________________________________________________________________
|                           _______                                |
| *Albert Huitsing*          |       |     *Huitsing Embedded Systems* |
| System Design            |    /|___|\            Dr. Mondenweg 5 |
| albert@...       |   /       \    7831 JA  Nw. Weerdinge |
|                          |   \  ___  /  Phone: +31-(0)591-521222 |
|                          \    \| | |/     Fax: +31-(0)591-522113 |
|                           \______|        http://www.huitsing.nl |
|                                                                  |
|      "/conformity is the uncomfortable feeling of wearing/         |
|       /somebody else's clothes; even when they don't fit/"         |
|__________________________________________________________________|