From: Dick S. <di...@st...> - 2008-01-24 19:46:06
|
Here is a patch for the igorplugusb driver. Besides the original IgorPlugUSB device, this driver is also used for my USBtiny IR receiver (http://www.xs4all.nl/~dicks/avr/usbtiny/). The patch below changes two things: 1) Increase the sample rate to 100 times per second. Some IR protocols have a gap as low as 20ms between subsequent codes, which is further reduced by a timeout of about 10ms used to detect the end of the code. Since the USB device only has a single buffer, it must be polled at least every 10ms. 2) A bug fix, originally from Reinhard Max, that is required to get correct gap timings. Without the fix, the gap time is incorrect because it includes the duration of the IR code. diff -pu lirc-0.8.2/drivers/lirc_igorplugusb/lirc_igorplugusb.c.orig lirc-0.8.2/drivers/lirc_igorplugusb/lirc_igorplugusb.c --- lirc-0.8.2/drivers/lirc_igorplugusb/lirc_igorplugusb.c.orig 2007-02-13 08:28:38.000000000 +0100 +++ lirc-0.8.2/drivers/lirc_igorplugusb/lirc_igorplugusb.c 2008-01-15 14:47:04.000000000 +0100 @@ -110,7 +110,7 @@ #define ADDITIONAL_LIRC_BYTES 2 /* times to poll per second */ -#define SAMPLE_RATE 10 +#define SAMPLE_RATE 100 /**** Igor's USB Request Codes */ @@ -373,6 +373,7 @@ static int usb_remote_poll(void* data, s /* 1 Igor-tick = 85.333333 us */ code = (unsigned int)ir->buf_in[i] * 85 + (unsigned int)ir->buf_in[i]/3; + ir->last_time.tv_usec += code; if(ir->in_space) code |= PULSE_BIT; lirc_buffer_write_n(buf, (unsigned char*)&code, 1); -- Dick |
From: Dick S. <di...@st...> - 2008-01-16 23:24:53
|
Here is a patch for the igorplugusb driver. Besides the original IgorPlugUSB device, this driver is also used for my USBtiny IR receiver (http://www.xs4all.nl/~dicks/avr/usbtiny/). The patch below changes two things: 1) Increase the sample rate to 100 times per second. Some IR protocols have gaps as low as 20ms between subsequent codes. Since the USB device only has a single buffer, the device must be polled at least every 20ms. To be on the safe side, I increased the sample rate to once every 10ms. 2) A bug fix, originally from Reinhard Max, that is required to get correct gap timings. Without the fix, the gap time is incorrect because it includes the duration of the IR code. diff -pu lirc-0.8.2/drivers/lirc_igorplugusb/lirc_igorplugusb.c.orig lirc-0.8.2/drivers/lirc_igorplugusb/lirc_igorplugusb.c --- lirc-0.8.2/drivers/lirc_igorplugusb/lirc_igorplugusb.c.orig 2007-02-13 08:28:38.000000000 +0100 +++ lirc-0.8.2/drivers/lirc_igorplugusb/lirc_igorplugusb.c 2008-01-15 14:47:04.000000000 +0100 @@ -110,7 +110,7 @@ #define ADDITIONAL_LIRC_BYTES 2 /* times to poll per second */ -#define SAMPLE_RATE 10 +#define SAMPLE_RATE 100 /**** Igor's USB Request Codes */ @@ -373,6 +373,7 @@ static int usb_remote_poll(void* data, s /* 1 Igor-tick = 85.333333 us */ code = (unsigned int)ir->buf_in[i] * 85 + (unsigned int)ir->buf_in[i]/3; + ir->last_time.tv_usec += code; if(ir->in_space) code |= PULSE_BIT; lirc_buffer_write_n(buf, (unsigned char*)&code, 1); -- Dick |
From: Dick S. <di...@st...> - 2008-01-27 22:21:25
|
On Thursday 2008-01-17 00:24, Dick Streefland wrote: | Here is a patch for the igorplugusb driver. Besides the original | IgorPlugUSB device, this driver is also used for my USBtiny IR | receiver (http://www.xs4all.nl/~dicks/avr/usbtiny/). The patch | below changes two things: Nevermind. When I sent this message 10 days ago, I was not yet subscribed to the list, and the message got redirected to the moderator. In the meantime, I subscribed and resent the patch myself. -- Dick |
From: <li...@ba...> - 2008-01-24 20:59:39
|
Hi! Dick Streefland "di...@st..." wrote: [...] > 1) Increase the sample rate to 100 times per second. I'm a bit hesitant to include this part as it considerably increases the load on the USB bus. Could you explain a bit how the buffering is working in this device? What is the size of the buffer? Will the GET_INFRACODE command really always get the whole buffer? Or is it possible that you only get a part of a signal if you issue the command while the remote currently is transmitting? How about remote controls that have a gap <10 ms (yes, they exist)? Christoph |
From: Dick S. <di...@st...> - 2008-01-24 21:47:34
|
On Thursday 2008-01-24 21:55, Christoph Bartelmus wrote: | I'm a bit hesitant to include this part as it considerably increases the | load on the USB bus. | Could you explain a bit how the buffering is working in this device? | What is the size of the buffer? Will the GET_INFRACODE command really | always get the whole buffer? Or is it possible that you only get a part | of a signal if you issue the command while the remote currently is | transmitting? How about remote controls that have a gap <10 ms (yes, | they exist)? The device has a very limited amount of RAM space, so there is only room for a single buffer. In the original IgorPlugUSB implementation, the buffer is a 3-byte header plus 36 bytes mark/space data. In my USBtiny implementation, I use 35 bytes mark/space data. USBtiny supports longer IR codes by using the last 16 bytes as a circular buffer, instead of simply truncating the data. As the most significant bits tend to be at the end, this works well in practice. USBtiny uses a timeout of 10.5ms to detect the end of a code (IgorPlugUSB uses 12.8ms). When a remote control sends two codes with a smaller gap, they get interpreted as a single code. The GET_INFRACODE command always reads the complete buffer. When a command is received when the IR code is not yet finished, nothing is returned. When a new IR code starts while the previous code is not yet read by the host, the buffer is cleared, dropping the previous code. While the buffer is being read by the host, new IR codes are being ignored. All this means that you will always read complete codes, but when you don't poll fast enough, codes get lost. -- Dick |
From: <li...@ba...> - 2008-01-25 22:40:30
|
Hi! Dick Streefland "di...@st..." wrote: > | I'm a bit hesitant to include this part as it considerably increases the > | load on the USB bus. [...] > being ignored. All this means that you will always read complete > codes, but when you don't poll fast enough, codes get lost. Do you think the sample rate could be a module parameter. I can see that your proposed change is valid and I also don't see any other way to make the device work with all remotes, but a poll rate of 100/s still is really high... Christoph |
From: Dick S. <di...@st...> - 2008-01-25 22:59:59
|
On Friday 2008-01-25 23:39, Christoph Bartelmus wrote: | Do you think the sample rate could be a module parameter. I can see that | your proposed change is valid and I also don't see any other way to make | the device work with all remotes, but a poll rate of 100/s still is | really high... A module parameter is an interesting option, as it will make it easy to experiment with different sample rates, and optimize it for a particular situation. However, it will complicate the installation a little bit. -- Dick |
From: <li...@ba...> - 2008-01-26 08:39:12
|
Hi! Dick Streefland "di...@st..." wrote: > On Friday 2008-01-25 23:39, Christoph Bartelmus wrote: > | Do you think the sample rate could be a module parameter. I can see that > | your proposed change is valid and I also don't see any other way to make > | the device work with all remotes, but a poll rate of 100/s still is > | really high... > > A module parameter is an interesting option, as it will make it easy to > experiment with different sample rates, and optimize it for a particular > situation. However, it will complicate the installation a little bit. Depends on which default configuration we choose. If it turns out that poll rate of 100 Hz makes a problem, then the user should at least have the possibility to reduce the poll rate without recompiling the module. Could you please post a patch? The second change is in CVS already. Christoph |
From: Dick S. <di...@st...> - 2008-01-26 09:55:34
|
On Saturday 2008-01-26 09:38, Christoph Bartelmus wrote: | Depends on which default configuration we choose. | If it turns out that poll rate of 100 Hz makes a problem, then the user | should at least have the possibility to reduce the poll rate without | recompiling the module. | | Could you please post a patch? The second change is in CVS already. OK, here it is: diff -pu lirc-0.8.2/drivers/lirc_igorplugusb/lirc_igorplugusb.c.orig lirc-0.8.2/drivers/lirc_igorplugusb/lirc_igorplugusb.c --- lirc-0.8.2/drivers/lirc_igorplugusb/lirc_igorplugusb.c.orig 2008-01-26 10:42:14.000000000 +0100 +++ lirc-0.8.2/drivers/lirc_igorplugusb/lirc_igorplugusb.c 2008-01-26 10:41:14.000000000 +0100 @@ -110,8 +110,9 @@ #define ADDITIONAL_LIRC_BYTES 2 /* times to poll per second */ -#define SAMPLE_RATE 10 +#define SAMPLE_RATE 100 +static int sample_rate = SAMPLE_RATE; /**** Igor's USB Request Codes */ @@ -503,7 +505,7 @@ static void *usb_remote_probe(struct usb plugin->rbuf = rbuf; plugin->set_use_inc = &set_use_inc; plugin->set_use_dec = &set_use_dec; - plugin->sample_rate = sample_rate; /* per second */ + plugin->sample_rate = SAMPLE_RATE; /* per second */ plugin->add_to_buf = &usb_remote_poll; #ifdef LIRC_HAVE_SYSFS plugin->dev = &dev->dev; @@ -661,6 +663,9 @@ MODULE_AUTHOR(DRIVER_AUTHOR); MODULE_LICENSE("GPL"); MODULE_DEVICE_TABLE(usb, usb_remote_id_table); +module_param(sample_rate, int, 0644); +MODULE_PARM_DESC(sample_rate, "Sampling rate in Hz"); + EXPORT_NO_SYMBOLS; /* -- Dick |
From: <li...@ba...> - 2008-01-26 14:25:16
|
Hi! Dick Streefland "di...@st..." wrote: [...] > | Could you please post a patch? The second change is in CVS already. > > OK, here it is: Applied (corrected version). Christoph |