Is remote receiver supposed to work on the libretiny platform (remote_receiver_libretiny.cpp)?

olivluca commented 2 months ago

The problem

I'm trying to implement a component for the rf part of a tuya rf and ir bridge and I mostly copied the implementation of remote_receiver and remote_transmitter. The transmitter part is working but the receiver is either dumping nothing or gibberish, so, in order to check if it's a problem with my implementation, I disabled my component and only implemented the standard remote_transmitter and remote_receiver with the ir part of the bridge. Again, the transmitter works (using a camera I see the ir leds flashing when I press the button in the web interface) but the receiver doesn't (it doesn't dump anything or it dumps gibberish). I checked with a logic analyzer that there are pulses on the P8 pin when I point a remote at the sensor. I tried also dump: raw instead of dump: all

Which version of ESPHome has the issue?

2024.7.3

What type of installation are you using?

pip

What platform are you using?

BK72XX

Board

CBU

Component causing the issue

remote_receiver

Example YAML snippet

external_components:
 - source:
    type: local
    path: components
   components: [ tuya_rf ] 
esphome:
  name: tuya

bk72xx:
  board: cbu
  framework:
    version: latest

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password
# Enable logging
logger:
web_server:
  version: 3
# Enable Home Assistant API
api:
  reboot_timeout: 0s
ota:
  platform: esphome
  password: !secret ota_password
#status_led:
#  pin: P9  
output:
  platform: gpio
  id: status
  pin: P9
#tuya_rf:
#  id: rf
#  dump: raw
#  receiver_disabled: true
remote_transmitter:
  id: ir
  pin: P7
  carrier_duty_percent: 50%
remote_receiver:
  pin:
   number: P8
   inverted: true
  dump: all

button:
  - platform: template
    name: irtest
    web_server_sorting_weight: 1000
    on_press:
       - remote_transmitter.transmit_nec:
          transmitter_id: ir
          address: 0x1234
          command: 0x78AB
          command_repeats: 1

Anything in the logs that might be useful for us?

No response

Additional information

imatge

(I'm not sure it's a nec remote, but pulseview decodes something)

I used inverted: true because esphome warned about it in the log, but even with inverted:falsethe result doesn't change.

[13:30:08][C][remote_receiver.libretiny:060]: Remote Receiver:
[13:30:08][C][remote_receiver.libretiny:061]:   Pin: 8
[13:30:08][W][remote_receiver.libretiny:063]: Remote Receiver Signal starts with a HIGH value. Usually this means you have to invert the signal using 'inverted: True' in the pin schema!
[13:30:08][C][remote_receiver.libretiny:066]:   Buffer Size: 1000
[13:30:08][C][remote_receiver.libretiny:067]:   Tolerance: 25%
[13:30:08][C][remote_receiver.libretiny:069]:   Filter out pulses shorter than: 50 us
[13:30:08][C][remote_receiver.libretiny:070]:   Signal is done after 10000 us of no changes

olivluca commented 2 months ago

Just to check if the micros() function is reliable, I put this in a platformio sketch

        unsigned long pippo=micros();
        int level=LOW;
            while (true) {
            while (micros()-pippo<10) {

            }
            pippo=micros();
            level=1-level;
            digitalWrite(CMT2300A_GPIO1_PIN,level);
        }

first with 10 and then with 100. With 10 I get 15us pulses, with 100 I get 105us pulses, so the 5us are the rest of the instructions in the loop, meaning the micros() function is fairly accurate. The problem lies somewhere else.

olivluca commented 2 months ago

The problem was in the libretiny's implementation of the CHANGE interrupt. Fix here

esphome / issues