Hi, On Wed, Oct 09, 2024 at 07:03:57AM +0000, 金超-软件项目部 wrote: > NORMAL: The kukong apk control remote control sends codes for other buttons > 10-09 11:20:18.219 1023 1023 D ConsumerIrHal: pattern[0]: 4500, 4500, 560, 560, 560, 1680, 560, 1680 > 10-09 11:20:18.219 1023 1023 D ConsumerIrHal: pattern[8]: 560, 1680, 560, 560, 560, 560, 560, 560 > 10-09 11:20:18.219 1023 1023 D ConsumerIrHal: pattern[16]: 560, 560, 560, 560, 560, 1680, 560, 1680 > 10-09 11:20:18.219 1023 1023 D ConsumerIrHal: pattern[24]: 560, 1680, 560, 560, 560, 560, 560, 560 > 10-09 11:20:18.219 1023 1023 D ConsumerIrHal: pattern[32]: 560, 560, 560, 1680, 560, 560, 560, 1680 > 10-09 11:20:18.219 1023 1023 D ConsumerIrHal: pattern[40]: 560, 1680, 560, 560, 560, 560, 560, 560 > 10-09 11:20:18.219 1023 1023 D ConsumerIrHal: pattern[48]: 560, 560, 560, 560, 560, 1680, 560, 560 > 10-09 11:20:18.219 1023 1023 D ConsumerIrHal: pattern[56]: 560, 560, 560, 1680, 560, 1680, 560, 1680 > 10-09 11:20:18.219 1023 1023 D ConsumerIrHal: pattern[64]: 560, 1680, 560, 46920, 4500, 4500, 560, 1680 > 10-09 11:20:18.219 1023 1023 D ConsumerIrHal: 0x560, > 10-09 11:20:18.219 1023 1023 D ConsumerIrHal: 0x96200, If I sum all these lengths, I get 216000 microseconds. That's well clear of IR_MAX_DURATION (500ms). Note that the last two values 0x560 and 0x96200 look really weird, they are not hex values are all, and there is no "pattern[...]: " prefix. > 10-09 11:20:18.219 1023 1023 D ConsumerIrHal: > 10-09 11:20:18.220 1023 1023 D ConsumerIrHal: IRTX: Send to driver > 10-09 11:20:18.469 1023 1023 D ConsumerIrHal: Done, Turn OFF IRTX > > SPECIAL :Sending the power button on the remote control of the kukong app may result in additional lines of coding, leading to transmission failure (72-88 extra) > 10-09 11:19:53.973 1023 1023 D ConsumerIrHal: pattern[0]: 4500, 4500, 560, 560, 560, 1680, 560, 1680 > 10-09 11:19:53.973 1023 1023 D ConsumerIrHal: pattern[8]: 560, 1680, 560, 560, 560, 560, 560, 560 > 10-09 11:19:53.973 1023 1023 D ConsumerIrHal: pattern[16]: 560, 560, 560, 560, 560, 1680, 560, 1680 > 10-09 11:19:53.973 1023 1023 D ConsumerIrHal: pattern[24]: 560, 1680, 560, 560, 560, 560, 560, 560 > 10-09 11:19:53.973 1023 1023 D ConsumerIrHal: pattern[32]: 560, 560, 560, 560, 560, 560, 560, 1680 > 10-09 11:19:53.973 1023 1023 D ConsumerIrHal: pattern[40]: 560, 1680, 560, 560, 560, 560, 560, 560 > 10-09 11:19:53.973 1023 1023 D ConsumerIrHal: pattern[48]: 560, 560, 560, 1680, 560, 1680, 560, 560 > 10-09 11:19:53.973 1023 1023 D ConsumerIrHal: pattern[56]: 560, 560, 560, 1680, 560, 1680, 560, 1680 > 10-09 11:19:53.973 1023 1023 D ConsumerIrHal: pattern[64]: 560, 1680, 560, 46920, 4500, 4500, 560, 1680 > 10-09 11:19:53.973 1023 1023 D ConsumerIrHal: pattern[72]: 560, 96200, 4500, 4500, 560, 1680, 560, 96200 > 10-09 11:19:53.973 1023 1023 D ConsumerIrHal: pattern[80]: 4500, 4500, 560, 1680, 560, 96200, 4500, 4500 > 10-09 11:19:53.973 1023 1023 D ConsumerIrHal: pattern[88]: 560, 1680, 560, 96200, 4500, 4500, 560, 1680 > 10-09 11:19:53.973 1023 1023 D ConsumerIrHal: 0x560, > 10-09 11:19:53.973 1023 1023 D ConsumerIrHal: 0x96200, If I sum all these lengths I get 648000 microseconds, so quit a bit more than IR_MAX_DURATION, which is why the send fails. Again the last two values are printed like garbage. The signal looks like NECx1: http://hifi-remote.com/wiki/index.php/NECx1 So there is the main signal, follow by a bunch of repeats. Each repeat looks like +4500 -4500 +560 -1680 +560 -96200; the -96200 is the trailing gap. To avoid going over IR_MAX_DURATION, don't include the -96200 gap but replaced with a usleep(96200), i.e. in psuedo code: int i, fd = open("/dev/lirc0", O_RDWR); write(fd, [4500 4500 560 560 560 1680 560 1680 560 1680 560 560 560 560 560 560 560 560 560 560 560 1680 560 1680 560 1680 560 560 560 560 560 560 560 560 560 560 560 560 560 1680 560 1680 560 560 560 560 560 560 560 560 560 1680 560 1680 560 560 560 560 560 1680 560 1680 560 1680 560 1680 560]); usleep(46920); for (i=0; i<4; i++) { write(fd, [4500 4500 560 1680 560]); usleep(96200); } Note that this what the lirc daemon also does for transmits; it's a well established way of sending. The write() to a lirc chardev won't return until the transmit has been successful. It might be interruptted by a signal, so you should disable signals during write (I don't think lirc daemon bothers though). Hope this helps Sean
