frangipan

There is a thread about this issue (different application) on the Raspberry Pi forums: https://forums.raspberrypi.com/viewtopic.php?t=358453

@jason ok thank you.

@jason Just to clarify, the loop is running on the host computer, driving the Flirc sendir process.

@jason let me know if you need any further information.

@jason Yes, that is correct. I can reproduce both with a Linux host and Windows host per the scripts above. Many thanks.

@jason GIven what you were looking at recently with recording the 'k' key, do you know if this limitation still exists?

@cableffm The Flirc device is quite sensitive. I've not heard of phones emitting IR but then again, my LCD TV does so why not a phone screen? My solution was to cover the Flirc window with some opaque material (eg. card) to reduce its sensitivity. This stops wayward IR signals from triggering events but still allows remote controls to work with Flirc.

@HoochWindgrass This is certainly possible with flirc_settings, it now has the --pronto switch (this is what the format you've quoted looks like although every sequence should be 4 characters and be separated by a comma, not a space).

Is there any way to do the equivalent of flirc_settings record_lp using the record_api command? If it's not possible today, is it technically possible within the hardware, just not exposed to flirc_settings?

That's great, thanks for the information.

This is fixed in flirc_util version: 3.27.16

This is fixed in flirc_util version: 3.27.16

Hi, Will Flirc Gen2 work in a USB 1.1 port? Are there any downsides to using with this version of USB? Thank you.

@jason Can I do anything else here to assist in tracking down the issue?

I've also noticed that when Flirc gets into this state, it seems to repeatedly dispatch a key event (type = 1, value = 2) in an infinite loop.

@jason whilst you are in that area, it might be an easy fix to correct the help text for the buttons that are supposed to have an underscore in them. Eg print_screen, fast_forward etc.

Are you binding using flirc_util? Can you show the output of: flirc_util settings after performing the binding?

I can also reproduce this in Windows with the following script which should rule out the Linux USB implementation: @echo off set countfiles=100 :loop set /a countfiles -= 1 "c:\Program Files (x86)\Flirc\flirc_util.exe" sendir --ik=28000 --repeat=1 --csv=0,8953,4415,539,539,568,508,566,510,500,576,569,503,538,542,565,508,569,507,534,541,533,541,568,508,561,515,568,1628,501,576,566,506,538,539,537,1659,569,508,566,510,589,485,536,1663,569,504,538,538,567,509,567,510,566,1630,566,1631,501,1693,504,576,534,1659,569,1628,569,1629,569 echo %countfiles% if %countfiles% GTR 0 goto loop Whilst the script is running, press the remote key as described in the previous post. You will notice that eventually the batch file hangs. If you then kill the batch script and attempt to re-run it, you'll see that it can't even execute the first sendir command.

Some further information on this. Recreation steps Run the following bash script (Linux) i=0; while true; do flirc_util sendir --ik=28000 --repeat=1 --csv=0,8953,4415,539,539,568,508,566,510,500,576,569,503,538,542,565,508,569,507,534,541,533,541,568,508,561,515,568,1628,501,576,566,506,538,539,537,1659,569,508,566,510,589,485,536,1663,569,504,538,538,567,509,567,510,566,1630,566,1631,501,1693,504,576,534,1659,569,1628,569,1629,569; echo $i; i=$((i+1)); done Whilst this script is running, use a remote that you have previously programmed into Flirc and repeatedly press one of the remote buttons repeatedly as quickly as possible (not held down). Within about 10-20 iterations of the bash script, you will eventually get this error message: [E] lib/libtransport/hid.c hid_recv_packet(217): Wrong response length = 0 [E] lib/libtransport/hid.c hid_recv_packet(218): hidapi: Success [E] lib/libtransport/transport.c _recv_packet(127): _recv_packet: recv packet error = -1 [E] lib/libtransport/transport.c _dev_send_cmd(202): recv timeout Error getting version device disconnected, can't run command I'd say this normally takes around 10-20seconds for me. Once this has happened, Flirc is unresponsive. Following calls to flirc_util result in: [E] lib/libtransport/hid.c hid_send_packet(150): hidapi: Connection timed out [E] util/flirc_util/src/cmds/ir_transmit.c sendir(260): Error: could not transmit data You will see errors like this in the dmesg output: [Sat Sep 21 11:09:01 2024] usb 1-1.4: usbfs: USBDEVFS_CONTROL failed cmd arp-scan rqt 128 rq 6 len 40 ret -110 [Sat Sep 21 11:09:07 2024] usb 1-1.4: usbfs: USBDEVFS_CONTROL failed cmd arp-scan rqt 128 rq 6 len 40 ret -110 I've also seen this error: [Thu Sep 19 20:47:07 2024] usb 1-1.4: device descriptor read/64, error -110 Once Flirc has got into this state, it needs to be power cycled to start working again. @jason Can I provide any further information to help diagnose this?

@V_J Sorry, I should have tried to reproduce on my setup first before offering advice :) I can confirm that under Linux, I get identical behavior: # flirc_util record k Press any button on the remote to link it with 'k' [E] lib/libflirc/translate_v2.c translate_v2(297): not a valid keyboard key: k usage: flirc record 'word'Available Options: escape, return, enter, escape, backspace, delete, tab, space, F[1-12], printscreen, scroll, pause, insert, home, pageup, pagedown, end, right, left, down, up, wake, media keys: eject, vol_up, vol_down, mute, play/pause, stop, fastforward, rewind [E] lib/libflirc/firmware/fw_4.0.c fl_ver4_set_record(474): Key does not exist Error, button exists Settings info: 3.27.15+ FW Version: v4.10.5 SKU: Flirc 2.0 [dori] Branch: release Config: release Hash: 0xF7261C8C @jason any chance of taking a look at this one? Thank you.

It's definitely worth running: flirc_util.exe device_log --ir -p and checking if there is any spurious IR coming from any of your equipment. This one confused me initially. However, this affected all keys for me, not just a single key. It might also be worth formatting the device (to remove all keys) and then trying just the 'k' on its own to see if that sheds any further light on this.

@Atelier Anna is your Flirc plugged directly into the host or via an extension cable? If you can, try running the following command at a command prompt and see what comes back: flirc_util device_log The output of flirc_util settings will also show version information and the status of any mapped keys.

It would be work monitoring the device log with: flirc_util device_log --ir -p to see if events are being generated when not pressing any remote keys. If they are, gradually turn off all electrical devices in the room until you stop seeing events. Plasma TVs produce spurious IR and I have an LCD TV which does the same. The solution in my case was to put a piece of cardboard over the Flirc IR window. It could still see the remote IR, but blocked out the spurious IR. That all said, this is an odd error which might suggest that the firmware needs reflashing: B table CRC Mismatch: 0x32EF6B1C != 0xFFFFFFFF

3.27.15+ FW Version: v4.10.5 SKU: Flirc 2.0 [dori] Branch: release Config: release Hash: 0xF7261C8C Hi, I have written a tool which is based on flirc_repeater (https://github.com/andrewfraley/flirc_repeater). This tool waits for an incoming key which is recognised by Flirc and then re-transmitts a different key using flirc_util sendir based on some routing rules. If you are slow and methodical about pressing the remote buttons, this system works well. However, if you "spam" one of the remote keys with a cadence of approximately 0.5seconds it looks like the Flirc code that dispatches keys to the host and the functions that allow sendir to work deadlock within the Flirc USB device. Flirc then becomes totally non-responsive and requires an unplug and replug to resolve. I have tried workaround such as mutexes in the calling code to try and avoid reading from the /dev/input/eventX at the same time as dispatching IR codes via sendir but this has not helped because I cannot control how quickly the user presses the button on the remote. I am open to workarounds for this including some way to cut and restore power to the USB port to "reboot" the Flirc but so far attempts using for example /sys/bus/usb/drivers/usb/unbind and /sys/bus/usb/drivers/usb/bind have been unsuccessful.

I see the same result with flirc_util 3.27.15+ and the following Flirc 2.0 USB firmwares: v4.9.6 v4.10.5 The workaround is to transform the "raw" codes into CSV, this can be done with the following command (Linux): raw="+9014 -4405 +535 ..... <rest of raw string>" csv=$(echo 0"$raw" | sed 's/ \?[+-]/,/g') flirc_util sendir --raw="$csv" Note the prefixed '0'.