Hi, Please send your emails in plain text only or they will be rejected by the list. On Fri, 2024-10-18 at 10:32 +0000, 金超-软件项目部 wrote: > 在 2024/10/17 15:57, Sean Young 写道: > > Hi, > > > > On Thu, Oct 17, 2024 at 07:15:21AM +0000, 金超-软件项目部 wrote: > > > Hi > > > May I ask if there has been any progress on this issue? It > > > affects the > > > user experience and could you please take a look as soon as > > > possible? > > > Thank you > > > > > > > > > 在 2024/10/12 11:09, quqiwanzi 写道: > > > > Hi > > > > > > > > 在 2024/10/11 22:34, Sean Young 写道: > > > > > 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. > > > > This is to iterate through the remaining parts that are less > > > > than > > > > eight digits and print them out. > > So why print the decimal value 560 as 0x560? > > The printing error here should be 560 > > > > 10-09 11:20:18.219 1023 1023 D ConsumerIrHal: 0x560, > > > > 10-09 11:20:18.219 1023 1023 D ConsumerIrHal: 0x96200, > > > > > > > > > > 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: > > > > > https://apc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhifi-remote.com%2Fwiki%2Findex.php%2FNECx1&data=05%7C02%7Cjinchao%40vivo.com%7Cccbe2b0c91d344e44d6408dcee815f75%7C923e42dc48d54cbeb5821a797a6412ed%7C0%7C0%7C638647486650784417%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=g442wKqtyI9uyQqq7iTcSB3ej4El39kd9Z51cI5mpa0%3D&reserved=0 > > > > > > > > > > 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); > > > > > } > > > > Thank you for your suggestion. The infrared code here is the > > > > power key > > > > code sent through the Kukong remote control, and there may be > > > > other > > > > infrared codes that exceed IR-MAX_DURATION. > > 1) If you send repeats separately then no known protocol exceeds > > 0.5 seconds > Now it is being sent separately and not duplicated. I have > confirmed with the remote control manufacturer that the code for > sending the power button will be over 500ms. The signal above is 61ms plus four repeats. If you add a ton of repeats yes, then sure, it becomes a lot longer. You haven't really engaged with the suggestion that you send signal plus repeats in separate calls to send. > The length of the power button code varies among different air > conditioning manufacturers. For example, the power button length of > Panasonic air conditioning is over 900ms, there may be codes over > 500ms I'm always interested to learn more about infrared protocols. Do you have any examples/documentation? > > 2) There are databases of protocols, and no protocol here exceeds > > 0.5 seconds > > (or even comes near). > > > > https://apc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhi > > fi- > > remote.com%2Fwiki%2Findex.php%2FDecodeIR&data=05%7C02%7Cjinchao%40v > > ivo.com%7Cccbe2b0c91d344e44d6408dcee815f75%7C923e42dc48d54cbeb5821a > > 797a6412ed%7C0%7C0%7C638647486650807965%7CUnknown%7CTWFpbGZsb3d8eyJ > > WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0 > > %7C%7C%7C&sdata=UQijcgNqYDRV48noNxXewkdKlEYHldrAvFiq5DD5Aeg%3D&rese > > rved=0 > > > > https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fg > > ithub.com%2Fbengtmartensson%2FIrpTransmogrifier%2Fblob%2Fmaster%2Fs > > rc%2Fmain%2Fresources%2FIrpProtocols.xml&data=05%7C02%7Cjinchao%40v > > ivo.com%7Cccbe2b0c91d344e44d6408dcee815f75%7C923e42dc48d54cbeb5821a > > 797a6412ed%7C0%7C0%7C638647486650821914%7CUnknown%7CTWFpbGZsb3d8eyJ > > WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0 > > %7C%7C%7C&sdata=eSnjJeKxIF37B9PKxiW4cFqNjeYEALXqx59A3Lu%2FKro%3D&re > > served=0 > > The longest protocols I know of are for air conditioning units > > and I've > > never seen one longer than 0.5 seconds. > > > > 3) If a button press on a remote would take more than 0.5 seconds > > the latency > > would be awful, so no manufacturer would do this. Also, the > > chance of > > signal being corrupted during transmit would be quite high. > There may be some air conditioning manufacturers who set the power > button code to more than 500ms, but we have not found any issues such > as delay in our testing > > > > 4) Some of the IR transmit hardware cannot handle such long > > transmits, e.g. > > mceusb, iguanair, redrat3 have limits on what can be sent due to > > usb > > packet limits. That means your software will never work with > > such hardware. > > > > 5) This limit has existed since the dawn of time in infrared. What > > has changed? > Our software only runs on Android 15 and sends infrared signals by > scanning the air conditioning remote control. Therefore, the length > of the infrared signal depends on the infrared remote control, There > are no relevant changes, some air conditioning manufacturers send > power button codes that exceed 500ms So you're "learning" the codes from the existing remote and then just repeat it. Rather than sending it in one go, you can replace large gaps with a call to usleep(), e.g. anything above 20ms or so. > > > > In order to ensure the > > > > universality of the code and adapt to different situations, it > > > > would > > > > be better to directly modify IR-MAX_DURATION. > > > I get the feeling you are trying to avoid the problem that you are > > sending > > the IR signal with the key repeats all at once. > Communicate > with the manufacturer that the length of the power key code sent > here cannot be modified and must maintain signal integrity for at > least 500 milliseconds. What is signal integrity? What problem are you describing? Why does usleep() not work? > Therefore, > we hope to modify the delay from 500ms to 1000ms, which is more > suitable to match more air conditioning manufacturers Sure, I think we need to understand more about the air condition infrared protocols. The example you've given so far is not really showing anything special. > > What driver are you using for transmit? > > Use the infrared remote control driver provided by MTK for > > transmission, and the interface called by the program comes from > > kernel-6.6 I am confused. The mtk driver in drivers/media/rc/mtk-cir.c is receive only and has no support for transmitting. Do you have a modified mtk- cir driver or are you using gpio-ir-tx or pwm-ir-tx? The reason I ask is that some drivers take more locks that others, and it might be possible to do something depending on the driver. Sean
