Some repeated keys are not working

[Sill1000]

Hi,

Thanks a lot for this great library. 👍

With a continue press on the key volume down you get:
beo4_task: 0164 audio vol--
beo4_task: 0164 audio vol--
beo4_task: 0164 audio vol--
beo4_task: 0164 audio vol--

with vol up:
you receive
beo4_task: 0160 audio vol++
but only once !

Same for green, red, blue, audio up:
beo4_task: 01d5 audio green
beo4_task: 0176 audio green++
but yellow is working perfectly as audio down !

you have already writed a Tx code writed. Do you have some example ?

Thanks

[aanban]

I've noticed this before, but I don't have a solution for it. I could imagine that the TSOP7000 replicas can no longer keep up, or something similar. Do you perhaps have a recording with the oscilloscope and a screenshot of the output of these “repeat” key sequences? Maybe you can see something.

I've only prepared the transmitter routine once and couldn't test it because I don't have any transmitter hardware or would first have to set it up with a suitable IR transmitter LED. Have you ever tried this?

[Sill1000]

Thanks for your answer.

It's not a TSOP problem, because I'm using "real" TSOP.
I found this document about the timing.

This link: https://github.com/Arduino-IRremote/Arduino-IRremote/discussions/1181

I will connect a scope and send you some screenshots.

Compiling with Tx routines gives errors.
From what I understand you can generate the 455kHz. We just need to add FET and an
IR diode ?

hope it help ! Thanks

[aanban]

1. repeated-button press
That is interesting, it is possible that perhaps the gap between a short and long command is small and perhaps falls within the range of the debounce routine. Since you are lucky enough to be using an original TSOP7000 from Vishay, you could do a quick test and dispense with debouncing, i.e. set t_debounce=0 within IrBeo.h.

IrBeo4.h(34)

// TSOP7000 noise debounce-time 
constexpr int64_t t_debounce=0;      ///< turn off debouncing

If it works for your setup, then I can think about how I could solve this situation for the TSOP7000 replicas. So maybe something like an additional state in the state machine that handles the end of the frame and then does not debounce for the next falling edge (the next start of the frame). In order to catch the short gap between two repeat frames.

2. beo4_tx_task()
What exactly does not work when compiling the TX routine?
As far as I remember, I looked at the result on the oscilloscope, i.e. the 455khz bursts and the pauses between them. But as I said, I haven't tested it with IR transmit LED yet. The beo4_tx_task() works like the receiver task, i.e. you create a queue and fill it in the main program.

[aanban]

New insight, it looks like the repeat buttons are sent without a pause between the individual frames. I have to think about it, I'm afraid the statemachine RxFsm() is not prepared for this and can't recognize the beginning of the following frames.
(1) = 12.5ms --> Pulscode=4 --> Stop-Code
(2) = new Frame without gap

[Sill1000]

1. Same problem with "real" TSOP (I can send you 2 TSOP if you want)

One document more. To be correct to for long command:

2 beo4_tx_task must be removed otherwise:

`Arduino\libraries\esp32_beo4-main\src\IrBeo4.cpp: In function 'void beo4_tx_task(void*)':

Arduino\libraries\esp32_beo4-main\src\IrBeo4.cpp:49:5: error: 'ledcSetup' was not declared in this scope

   49 |     ledcSetup(beo4->m_tx_pwm,455000,4);  // pCarrier=455kHz,duty_range=[0..15]

Arduino\libraries\esp32_beo4-main\src\IrBeo4.cpp:50:5: error: 'ledcAttachPin' was not declared in this scope; did you mean 'ledcAttach'?

   50 |     ledcAttachPin(beo4->m_tx_pin,beo4->m_tx_pwm); // attach to transmit pin
`

How do you send an IR command (ex: beo4_tx(BEO_SRC_AUDIO,BEO_CMD_VOL_DOWN)) ?

[Sill1000]

New insight, it looks like the repeat buttons are sent without a pause between the individual frames. I have to think about it, I'm afraid the statemachine RxFsm() is not prepared for this and can't recognize the beginning of the following frames.

I just saw that we answered at the sample time !

But why does vol down and yellow work ?

[aanban]

ooops I pressed the wrong button

[aanban]

How do you send an IR command (ex: beo4_tx(BEO_SRC_AUDIO,BEO_CMD_VOL_DOWN)) ?

Just a quick answer, I will add a main.cpp example later.

In principle you have to add these lines in main.cpp

1. declaration section

add a transmit GPIO, e.g. 33, add a queue, call Constructor with rx, tx and channel

#define IR_RX_PIN 34                  // IR receive pin
#define IR_TX_PIN 33                  // IR transmit pin 
xQueueHandle beo4_rx_queue;           // queue for beo4codes from receiver
xQueueHandle beo4_tx_queue;           // queue for beo4codes from transmitter
IrBeo4 beo4(IR_RX_PIN,IR_TX_PIN,0);   // receive, transmit, channel=0

2. the setup()

within the setup() function the beo4.Begin() member function gets both queues

beo4_ok=beo4.Begin(beo4_rx_queue,beo4_tx_queue);  // start both tasks

3. your my_send_function()

generate the beoCode from source-code and command-code, and push to the beo_tx_queue

    uint32_t beoCode=((uint32_t)BEO_SRC_AUDIO << 8) + (uint32_t)BEO_CMD_VOL_DOWN;
    Serial.printf_P(PSTR("sending (%s, %s) = 0x%x --> beo4_tx_queue \n"),beo_src_tbl(beoCode), beo_cmd_tbl(beoCode),beoCode);
    xQueueSend(beo4_tx_queue,&beoCode,0);

I just saw that we answered at the sample time !
But why does vol down and yellow work ?

For now, the only thing I can think of is perhaps the length of the complete frame. It's a bit tricky with the “BEO_SAME” pulse code. The idea is probably to create frames of approximately the same length. But it doesn't work for everyone, so there are longer and shorter frames. Maybe the statemachine can still keep up with the "yellow" and "down" key. I'll have to have a look at this at my leisure. Maybe I can improve the statemachine further. The evaluation of long codes from the lintronic source is helpful. I'll see what I can do.

A nice idea, by the way, if you could send me an original Vishay TSOP7000 Receiver.

[Sill1000]

Thanks!
2. Set into setup() but error: beo4_ok was not declared.
Sorry... I'm not on the top about programming!

I also discover this library but using timer on arduino (probably not easy to transpose it on ESP);
https://github.com/christianlykke9/Beomote/blob/master/Beomote.cpp

If you have access to my email address, please send me an email with your address to send you TSOP7000

[aanban]

OK here the complete setup()

// prepares queue, starts beo4_task and the internal beo4 receiver tasks 
void setup_beo4(void) {
  static int beo4_ok=-1; 
  Serial.printf(PSTR("===> start beo4... ")); 
  beo4_rx_queue = xQueueCreate(50, sizeof(uint32_t));
  beo4_tx_queue = xQueueCreate(50, sizeof(uint32_t));
  xTaskCreatePinnedToCore(beo4_task,"beo4_task",10000,NULL,0,&beo4_task_h,0);
  beo4_ok=beo4.Begin(beo4_rx_queue,beo4_tx_queue);  // start beo4 receiver only
  Serial.printf(PSTR("%s\n"),beo4_ok==0? "OK":"failed");
}

Q: what is your development environment? Are you running Arduino or platformio + VScode?

to help your compiler errors from above, you could try to add esp32-hal-ledc.h" like so within IrBeo4.h. It seems that platformio finds all dependences, maybe for Arduino you have to add the header-file.

#ifndef IRBEO4_H_
#define IRBEO4_H_

#include "Arduino.h"
#include "esp32-hal-ledc.h"

2. further investigations

I made some tests with the transmit routine, I think the signal at GPIO33 itself seems to look OK, the burst has 455khz the length of the different pulsewith codes is OK. these are the screen shots from the [audio, +vol--] Button.

the complete frame

the stop pulsecode has about 12,6 ms

the 455khz bursts are about 200µs

the frequency of the bursts is about 455khz

3. an idea how to add a sender IR LED

have a look at this website
It is where I found the idea how to generate the output signal for the IR Sender Led.

[Sill1000]

Thanks.

1. I'm using Arduino IDE.
   Arduino\libraries\esp32_beo4-main\src\IrBeo4.cpp: In function 'void beo4_tx_task(void*)':

\Arduino\libraries\esp32_beo4-main\src\IrBeo4.cpp:49:5: error: 'ledcSetup' was not declared in this scope

49 | ledcSetup(beo4->m_tx_pwm,455000,4); // pCarrier=455kHz,duty_range=[0..15]

Arduino\libraries\esp32_beo4-main\src\IrBeo4.cpp:50:5: error: 'ledcAttachPin' was not declared in this scope; did you mean 'ledcAttach'?

50 | ledcAttachPin(beo4->m_tx_pin,beo4->m_tx_pwm); // attach to transmit pin

2. Looks nice. 458kHz should works fine with a TSOP receiver. The range will be shorter with Beo systems. Because they are using very sharp filter on 455kHz. Is the fine tuning possible ?

3. Send me your adress on my email to send you some TSOP.

[aanban]

1. Arduino IDE, Arduino ESP32 got a migration from 2.x to 3.0

As far as I see, there was a change within the Arduino ESP32 package. And these two functions where affacted, that why it's broken. I guess your Arduino IDE Version is a newer one right? Here was a discussion about the same Problem.

I will check how this can be fixed. It might be a little tricky because the platformio IDE somehow does not support the newer Version. It's a shame that the espressif people let platformio down like this. Propably I have to switch to the pioarduino repository to get the mirgration to 3.0. I will see.

2. Fine-Tuning of the 455kHz carrier

As far as I see it should be possible with ledcSetup(), as well as the new api funktion ledcAttach The function got an argument for the frequency.

3. long code handling

I just thinking about how to extend the statemachine for the long codes.

[aanban]

Sometimes it's easier than you think. The RxFsm() state machine determines the start sequence rxST::S0 --> rxST::S1 --> rxST::Start With the "repeated" codes there is easily the condition that one of the first two states can be skipped. To solve this problem, there is now an additional check within the concerned states rxST::S0 and rxST::S1. If the pulse code snaps to bStart, the system jumps directly to the rxST::Data state.

    case rxSt::S0: {
      if(bZero==m_pCode) {
        m_rxFSM=rxSt::S1;      // next state -->  continue start sequence
      } else if(bStart==m_pCode) {
        m_rxFSM=rxSt::Data;    // next state -->  collect data
      } else {                 // frame corrupt
        resetRxFsm("ERR: FSM_S_0 state failed "); 
      }
      break; 
    } 
    case rxSt::S1: {
      if(bZero==m_pCode) {
        m_rxFSM=rxSt::Start;   //  next state -->  continue start sequence
      } else if(bStart==m_pCode) {
        m_rxFSM=rxSt::Data;    // next state -->  collect data
      } else {                 // frame corrupt
        resetRxFsm("ERR: S1 state failed ");
      }
      break; 
    } 
    case rxSt::Start: {
      if(bStart==m_pCode) {
        m_rxFSM=rxSt::Data;    // next state -->  collect data
      } else {                 // frame corrupt
        resetRxFsm("ERR: Start state failed ");
      }
      break; 
    } 

The Bugfix included in the Release 1.2.1