Support IR in the simulator with FLIRC #93

DDRBoxman · 2024-12-17T03:53:57Z

This allows the simulator to send and receive ir remote codes by leveraging a relatively cheap off the shelf USB device.

https://flirc.tv/products/flirc-usb-receiver
https://www.amazon.com/dp/B01NBRBWS6

Simulator continues to work as expected without a device

Todo:

Clean up sending the rest of the codes other than NEC (mostly requires testing)
Add a check for the FLIRC firmware version and log if too old
Currently the msys2 package repo doesn't have a i686 build available of libusb https://packages.msys2.org/base/mingw-w64-libusb

This allows the simulator to send and receive ir remote codes by leveraging a relatively cheap off the shelf USB device. https://flirc.tv/products/flirc-usb-receiver https://www.amazon.com/dp/B01NBRBWS6 Currently the msys2 package repo doesn't have a i686 build available of libusb https://packages.msys2.org/base/mingw-w64-libusb

DDRBoxman · 2024-12-17T03:54:24Z

Opened as a draft as it needs a little more cleanup, but I wanted to judge interest before I finished it up.

DDRBoxman · 2024-12-17T03:57:48Z

Platformio/hardware/windows_linux/util.cpp

@@ -0,0 +1,11 @@
+unsigned long reverseBits(unsigned long n) {


for some wild reason the remote codes in the flirc sdk are backwards from the arudino library

KlausMu · 2024-12-17T06:17:46Z

Do I understand correctly: you are using the FLIRC for sending IR codes, and the FLIRC needs to be connected to the PC where the simulator is running on?

So this is a little bit different to the way this device is intended to be used. Normally it will be connected e.g. to a Fire TV and receives IR codes.

Correct?

Edit: according to the code and your very first message, the PR is both for sending and receiving IR codes. Cool.

KlausMu · 2024-12-21T08:34:24Z

I ordered a FLIRC. Sounds interesting. Didn't know of this device before.
Could also be helpful for other things.
So please give me some more days until I can provide feedback to this PR.

KlausMu · 2024-12-21T09:05:57Z

For me the file .gitmodules does not work. url seems to be wrong.
What it is:

[submodule "Platformio/hardware/windows_linux/lib/flirc_sdk"]
	path = Platformio/hardware/windows_linux/lib/flirc_sdk
	url = [email protected]:flirc/sdk.git

What it probably should be:

[submodule "Platformio/hardware/windows_linux/lib/flirc_sdk"]
	path = Platformio/hardware/windows_linux/lib/flirc_sdk
	url = https://github.com/flirc/sdk

Otherwise the submodule will not be cloned.

KlausMu · 2024-12-21T09:55:33Z

I have a problem compiling with Windows 64 bit. Maybe you can help out.

...
Linking .pio\build\windows_64bit\program.exe
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: hardware\windows_linux\lib\flirc_sdk\libs\Win64/libflirc.a: error adding symbols: archive has no index; run ranlib to add one
collect2.exe: error: ld returned 1 exit status

BTW: Although not listed here https://packages.msys2.org/base/mingw-w64-libusb , I succesfully could install libusb on MINGW32 with pacman -S mingw-w64-i686-libusb

Edit: the problem was the missing index. Deleting the stamp files fixed the error.
I started with MinGW32. The 32 bit ar does nothing at all. But both stamp files have been created, for 32 bit and 64 bit.
Switching to MinGW64, the index was not created because the two stamp files already existed.

Edit 2: The underlying problem is something different. It is fine that ar s is doing nothing to the 32 bit libflirc.a
The problem is a missing build_unflags in platformio.ini

[env:windows_32bit]
build_unflags =
	-Lhardware/windows_linux/lib/flirc_sdk/libs/Win64

Isn't the .stamp file dangerous? If you pull a new version of flirc/sdk, ar s will not be called again, right?

KlausMu · 2024-12-24T08:11:55Z

I think

unsigned long reverseBits(unsigned long n)

should be

uint64_t reverseBits(uint64_t n)

Otherwise you get

execute: will send IR NEC, data 0x5EA158A7 (1587632295)
test: (58650)

instead of

execute: will send IR NEC, data 0x5EA158A7 (1587632295)
test: (3843720570)

KlausMu · 2024-12-24T08:45:35Z

When turning on the IR receiver, the FLIRC seems to get into trouble when sending. If you try to send after the receiver was on, you often get

execute: will send IR NEC, data 0x5EA158A7 (1587632295)
test: (3843720570)
[E] lib/libtransport/hid.c hid_recv_packet(223): Wrong report exp: 5 != 7
[E] lib/libtransport/hid.c hid_recv_packet(224): 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
[E] lib/libtransport/transport.c _dev_send_cmd(225): Wrong response: 'irtranset' != 'irtransraw'
[E] lib/libflirc/firmware/fw_4.10.c _fl_transmit_raw(101): error sending data, check device log
[E] lib/libtransport/transport.c _dev_send_cmd(225): Wrong response: 'irtransraw' != 'irtranset'
[E] lib/libtransport/transport.c _dev_send_cmd(225): Wrong response: 'irtranset' != 'irtransraw'

After that, the FLIRC seems to stay in a broken state or at least in the wrong state. You have to unplug it to get it working again.

Maybe you explicitely have to leave the receive modus?
Currently, shutdown_infraredReceiver_HAL is empty:

void shutdown_infraredReceiver_HAL() {
}

KlausMu · 2024-12-24T08:50:38Z

When sending with FLIRC, there always seems to be one additional (empty?) message to be sent.

I changed fl_transmit_fake to

static int fl_transmit_fake(uint16_t *buf, uint16_t len, uint16_t ik, uint8_t repeat)
{
  printf("Flirc device not connected. Will only print what we would transmit.\n");
---

With that, sending looks like this. fl_transmit_fake is called twice.

execute: will send IR NEC, data 0x5EA158A7 (1587632295)
test: (3843720570)
Flirc device not connected. Will only print what we would transmit.
+9000 -4500 +560 -560 +560 -1690 +560 -560 +560 -1690 +560 -1690 +560 -1690 +560 -1690 +560 -560 +560 -1690 +560 -560 +560 -1690 +560 -560 +560 -560 +560 -560 +560 -560 +560 -1690 +560 -560 +560 -1690 +560 -560 +560 -1690 +560 -1690 +560 -560 +560 -560 +560 -560 +560 -1690 +560 -560 +560 -1690 +560 -560 +560 -560 +560 -1690 +560 -1690 +560 -1690 +560 
-40000
Flirc device not connected. Will only print what we would transmit.

This is what OMOTE receives. Do you know why this happens?

DDRBoxman · 2024-12-29T21:09:46Z

I suppose we can just remove the .stamp file if running the index on that archive every build is fine.

I'm using the ir library that flirc provides to generate the waveform data from the scan codes and I wonder if it's doing something slightly different than what the arudino library is doing.

DDRBoxman · 2024-12-29T21:15:47Z

Also that git module thing just depends on how you have git setup, but yeah the http will work in more environments

DDRBoxman · 2024-12-29T21:28:02Z

https://github.com/DDRBoxman/OMOTE/actions/runs/12538772245/job/34964259865#step:5:226

Looks like the msys2 installer step can't find that libusb package. Do you know if pacman -S mingw-w64-i686-libusb is doing anything different?

KlausMu · 2024-12-30T16:55:15Z

https://github.com/DDRBoxman/OMOTE/actions/runs/12538772245/job/34964259865#step:5:226

Looks like the msys2 installer step can't find that libusb package. Do you know if pacman -S mingw-w64-i686-libusb is doing anything different?

Ok, mingw-w64-i686-libusb was only available in older versions of MSYS2. And I had one.
But you can still install it with

pacman -U https://repo.msys2.org/mingw/mingw32/mingw-w64-i686-libusb-1.0.26-1-any.pkg.tar.zst

To get it running in the workflow, I did not find a better solution than this:

Replace (delete the last two lines)

      - name: Install MSYS2 MINGW64/32, SDL2, SDL2_image, hidapi, libusb
        if: ${{matrix.sys != 'xtensa'}}
        uses: msys2/setup-msys2@v2
        with:
          update: true
          msystem: ${{matrix.sys}}
          install: >-
            mingw-w64-${{matrix.env}}-gcc
            mingw-w64-${{matrix.env}}-SDL2
            mingw-w64-${{matrix.env}}-SDL2_image
            mingw-w64-${{matrix.env}}-hidapi
            mingw-w64-${{matrix.env}}-libusb

with

      - name: Install MSYS2 MINGW64/32, SDL2 and SDL2_image
        if: ${{matrix.sys != 'xtensa'}}
        uses: msys2/setup-msys2@v2
        with:
          update: true
          msystem: ${{matrix.sys}}
          install: >-
            mingw-w64-${{matrix.env}}-gcc
            mingw-w64-${{matrix.env}}-SDL2
            mingw-w64-${{matrix.env}}-SDL2_image

      - name: Install MSYS2 MINGW64 hidapi and libusb
        if: ${{matrix.sys == 'mingw64'}}
        uses: msys2/setup-msys2@v2
        with:
          msystem: ${{matrix.sys}}
          install: >-
            mingw-w64-${{matrix.env}}-hidapi
            mingw-w64-${{matrix.env}}-libusb
      
      - name: Install MSYS2 MINGW32 hidapi and libusb
        if: ${{matrix.sys == 'mingw32'}}
        shell: msys2 {0}
        run: |
          pacman --noconfirm -S mingw-w64-${{matrix.env}}-hidapi
          pacman --noconfirm -U https://repo.msys2.org/mingw/mingw32/mingw-w64-i686-libusb-1.0.26-1-any.pkg.tar.zst

On https://packages.msys2.org/base/mingw-w64-libusb they reference the new https://packages.msys2.org/base/mingw-w64-libusb-win32, but it seems it cannot simply be replaced. Do you know more about it?

References:
https://wiki.archlinux.org/title/Pacman#Additional_commands
https://github.com/msys2/setup-msys2
https://repo.msys2.org/mingw/mingw32/

DDRBoxman · 2024-12-31T03:12:36Z

I think https://packages.msys2.org/base/mingw-w64-libusb-win32 is for the libusb 0.1 api but we want the 1.0+ api

KlausMu · 2025-01-15T16:59:56Z

@DDRBoxman are you waiting for more feedback from my side?
Did you see my comment about unsigned long reverseBits(unsigned long n)?

And I think the first two todos from your list in the first post are still open, right?

DDRBoxman · 2025-01-20T04:08:48Z

Yeah, still working on this one hopefully I'll have some time soon to clean it up some more.

DDRBoxman commented Dec 17, 2024

View reviewed changes

Build fixes

c603700

KlausMu marked this pull request as ready for review January 15, 2025 16:55

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Support IR in the simulator with FLIRC #93

Support IR in the simulator with FLIRC #93

DDRBoxman commented Dec 17, 2024 •

edited

Loading

DDRBoxman commented Dec 17, 2024

DDRBoxman Dec 17, 2024

KlausMu commented Dec 17, 2024 •

edited

Loading

KlausMu commented Dec 21, 2024

KlausMu commented Dec 21, 2024

KlausMu commented Dec 21, 2024 •

edited

Loading

KlausMu commented Dec 24, 2024

KlausMu commented Dec 24, 2024

KlausMu commented Dec 24, 2024

DDRBoxman commented Dec 29, 2024

DDRBoxman commented Dec 29, 2024

DDRBoxman commented Dec 29, 2024

KlausMu commented Dec 30, 2024 •

edited

Loading

DDRBoxman commented Dec 31, 2024

KlausMu commented Jan 15, 2025

DDRBoxman commented Jan 20, 2025

		@@ -0,0 +1,11 @@
		unsigned long reverseBits(unsigned long n) {

Support IR in the simulator with FLIRC #93

Are you sure you want to change the base?

Support IR in the simulator with FLIRC #93

Conversation

DDRBoxman commented Dec 17, 2024 • edited Loading

DDRBoxman commented Dec 17, 2024

DDRBoxman Dec 17, 2024

Choose a reason for hiding this comment

KlausMu commented Dec 17, 2024 • edited Loading

KlausMu commented Dec 21, 2024

KlausMu commented Dec 21, 2024

KlausMu commented Dec 21, 2024 • edited Loading

KlausMu commented Dec 24, 2024

KlausMu commented Dec 24, 2024

KlausMu commented Dec 24, 2024

DDRBoxman commented Dec 29, 2024

DDRBoxman commented Dec 29, 2024

DDRBoxman commented Dec 29, 2024

KlausMu commented Dec 30, 2024 • edited Loading

DDRBoxman commented Dec 31, 2024

KlausMu commented Jan 15, 2025

DDRBoxman commented Jan 20, 2025

DDRBoxman commented Dec 17, 2024 •

edited

Loading

KlausMu commented Dec 17, 2024 •

edited

Loading

KlausMu commented Dec 21, 2024 •

edited

Loading

KlausMu commented Dec 30, 2024 •

edited

Loading