thanks for your info and suggestions.
An External serial device: this is not a good option as a usb-2-serial
costs about the same as the keyspan usb device. (that comes with mac os
I also just bought a TV card, so I will try to see if I can watch TV
and how I can control the TV, too.
thanks also for the souce code. I doing pretty much the same in my
Using a pipe would be ok, too, besides I can't create and use a fifo in
/dev/... as its a dynamic device tree on mac os x/darwin.
For the communication between a lircd hw_driver and the audio part, it
also doens't matter which one to use: socket, pty, pipe
as its under my control anyway.
Using sox instead of /dev/dsp is better but doesn't help on other
platforms, so I'm in favour of the portable audio library.
If sound card support finds its way into the lircd sources, I would
suggest using this library to make porting easier (as it is for me
Also a 44100 sample rate give 22 uS per sample. this should be good
The interface from an application to lircd matters. So a named pipe
outside of /dev/... is a good choice in addition to the
tcp/ip interface. A /dev/lircd is possible but would require a kernel
extension which looks like much more work.
Some thoughts and facts about the
Keyspan USB Remote:
I just downloaded the mac os x software for it and had a look at it.
I got :
Text files with raw ir codes for their supported remotes
Text file with mapping of remote buttons to application events (key,
mouse, scripts, launch, ..)
A GUI tool for to configure the button mapping
And a mapper appliation.
They don't install a special kernel exension a.k.a driver so my guess
is that the mapper application includes everything(= lircd + irxevent +
is talking directly to the usb device, which is pretty simple on the
mac (using their example projects only.. :).
I already dumped pcl files to hp printers so they can print them.
I would argue, that as keyspan supports mac os classic, mac os x and
windows, the easiest way would be to make the protocol like any other
serial device. Then one could hope that it just gives back pulse/pause
values. (why not ?)
Anyone out there with a keyspan usb remote to give it a try?
Concerning my port, I wonder why lirdc works but irrecord fails when I
try to lern a button. It just tells "something went wrong".
Did someone had the same problems ? I using a sony remote with 12,15,20
bit codes. It fails also if I only use the 12 bit code buttons... :(
On Donnerstag, Dezember 5, 2002, at 10:37 Uhr, Karl Bongers wrote:
> Hey Matthias,
> Thats a neat idea using the sensor IC to the sound card.
> I experimented with the diode input on the sound card.
> There are a few points that I consider weak about hw_dsp.c,
> one is the sample rate it uses which I believe works out to
> 200us, a bit coarse. Also opening my /dev/dsp would
> fail due to the odd hard-coded sample rate(47999).
> I have some alternate code that uses a pipe from sox program.
> Then I don't have to deal with the oddities of sound card IOCTL
> interface so much. Also I can compile my driver stand alone
> where it outputs something the same as lirc_serial. This I route
> to a fifo. This has the advantage for debugging, I can use
> mode2/xmode2 on it. Since it has the same output format as lirc_serial
> it can use the stock lirc code as is(point lircd at the fifo).
> Heres my code if you want to take a look -
> I think you could get some hardware working on a USB serial port.
> A USB/serial port should work with some of the commercial IR
> gadgets. A number of them output a decoded 1200 baud, so the
> stock serial ports work. I picked up a Silitek reciever and
> discovered the way it works is that the remote control outputs
> RS232 signals at 1200 baud. So the reciever is similiar to the
> home brew but routes the data to the rs232 RX pin.
> The IRMAN looks neat. It has a PIC micro decode the signal
> and send it as normal rs232 data. It attempts to use a "universal"
> decode algorithm. From what I can gather it uses some generic
> formula base on pulse/space widths to generate a 6 byte key which it
> sends back to the PC on button press. My rough understanding is that
> it determines if a pulse/space is short or long, and sets a bit
> on or off to form the 6-byte key. This normally generates unique
> keys, and
> is supposed to work with most remotes. Someone did some neat stuff
> with a new version of IRMAN, expanding its capability, for example
> tying it into wake-on signals on the motherboard. One drawback
> to IRMAN is the PIC micro source code is not open. I haven't actually
> tried one either, so I don't know how well they work.
> Keyspan had a USB remote/reciever that I noticed in a local ad for a
> price, and I enquired about it to see if they had interest in getting
> it working with LIRC. They replied with some interest, but then I
> didn't hear back from them.