frangipan

@jason perfect, many thanks.

@jason Sorry, I presume I can work through the firmware revisions by using the builds on flirc.io?

@jason thanks, I should check the SDK out.

@Benjamin1971 another alternative to @parkerlreed's excellent solution is to use the "shell" mode of flirc_util. Here is a project which uses this approach with Python: flirc_repeater/flirc_repeater.py at main · andrewfraley/flirc_repeater · GitHub Look at the "wait_loop" function.

@jason In my efforts to get this resolved I have purchased a new Flirc which is on an earlier firmware (v4.6.5) and it doesn't suffer the same problem. I can continuously send IR commands using sendir of flirc_util whilst sending IR codes to the device and no crash occurs. Could you make available to me all the firmwares so that I can upgrade one by one until I encounter the issue? This would then hopefully point us in the right direction for a fix.

@jason does the current firmware automatically disable the receiver? I'm wondering if this is related to the issue I am seeing (posted in another thread).

@ffwema is there an "unofficial" command to disable the receiver?

@jason I'm on the latest firmware and version of irtools and this is still easy to reproduce. Run the Windows BAT file (swapping out flirc_util.exe with irtools.exe) and whilst it's running, point a remote at Flirc and tap a button (paired or unpaired makes no difference) and Flirc will lock up. Errors from irtools: [E] hid_recv_packet(166): hid_recv_packet: wrong report id [E] hid_recv_packet(167): hidapi: Success [E] _recv_packet(126): _recv_packet: recv packet error = -1 [E] _dev_send_cmd(208): recv timeout [E] flirc_init(77): could not set iface

@jason thanks, I will try this other tool. If I can still reproduce the problem, I will create a video showing the issue.

@jason have you had a chance to take a look at this?

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.