Release 1.5.0

1. handling of repeated codes (issue #8 )

1.1 cut frames into usable chunks

Improvement for repeatable codes, e.g., BEO_CMD_UP. The RMT recording stops when the pause exceeds signal_range_max_ns. In the previous version, this meant that evaluation could only begin after the last repeated code, resulting in a long delay, i.e., only when the button was released.

In the new version, signal_range_max_ns=10ms has been set, that is shorter than the stop symbol, i.e. beoCodes are cut into two parts, two dummy symbols ( = the rest of start sequence 1,1,5) followed by 17 symbols ( = the payload data). Long repeat codes are treated the same way. Since the dummy frames with two symbols only are filtered out anyway, the interesting actual payload appear in bite-sized 17-symbols chunks for the decoder, which now works without a state machine and instead uses a simple for() loop. With the new method, the repeat codes are transmitted immediately as can be seen below:

           delta   hex   beoCode
---------- ------- ----- ---------           
beo4_task: 14062ms 0011e audio-up
beo4_task:   279ms 00172 audio-up++
beo4_task:   138ms 00172 audio-up++
beo4_task:   138ms 00172 audio-up++
beo4_task:   137ms 00172 audio-up++
beo4_task:   138ms 00172 audio-up++

1.2 new parameter lc_mode

The constructor got a new parameter: lc_mode controls the behavior for long repeat codes.

• lc_mode=0
  Activates the lintronic behavior, i.e., the pilot code is discarded and only the repeated codes are delivered. E.g., pressing the [Right Arrow] button on the beo4 remote results in: BEO_CMD_RIGHT_REPEAT,...BEO_CMD_RIGHT_REPEAT

• lc_mode=1
  All codes are send, including the pilot code. E.g., pressing the [Right Arrow] button on the beo4 remote results in: BEO_CMD_RIGHT, BEO_CMD_RIGHT_REPEAT,...BEO_CMD_RIGHT_REPEAT

2. handling of beoLink bit (issue #9)

The previous release just skipped the beoLink Bit. In the new release the beoLink bit is extracted from the payload data and stored in the result data.

Release 1.4.1

The available RMT buffer varies between the ESP32 and the ESP32-S3. The previous value of mem_block_symbols=512 causes a crash on the ESP32-S3. The value 128 works on both ESP32 variants.

See issue: #6

Release 1.4.0

The RMT-based approach was chosen for sending and receiving. The timing is done in hardware now and therefore no more interference, i.e. interrupts of the application or the Wifi module is expected.

Transmitting:
The output signal is only very accurate, there is no more jitter in the carrier and low pulses.

Receiving:
Unlike the interrupt-based approach, no more codes are lost when there is WLAN traffic.

Note:
There is a delay with repeat codes that follow each other in quick succession because all the codes have to be recorded first. The “partial-receive-done” variant does not seem to work or is dependent on the ESP32 module

Release 1.3.1

1.) handling of repeatable BeoCodes

It turned out that repeatable BeoCodes should be skipped if a successor BeoCode has arrived. Repeatable BeoCodes, i.e. codes with
BeoCmd value of following list:

• BEO_CMD_LEFT
• BEO_CMD_RIGHT
• BEO_CMD_UP
• BEO_CMD_DOWN,
• BEO_CMD_GO,
• BEO_CMD_GREEN,
• BEO_CMD_YELLOW,
• BEO_CMD_BLUE,
• BEO_CMD_RED

Within the RxFsm() state machine repeatable beoCodes are now first sent to a quarantine queue, where they wait until a.) a time out or b.) a successor repeat BeoCode has arrived.

• Case a.)
  no successor BeoCode has arrived, so let the waiting BeoCode pass as a normal single BeoCode. There is a small disadvantage because these codes are slightly delayed due to the check. However, this cannot be avoided
• Case b.)
  the waiting BeoCode it is deleted, i.e. only the successor repeat BeoCodes are passed on.

See lintronic workflow --> #2

2.) breaking changes

Furthermore, the source code has been cleaned up a bit and the header IrBeo4Info.h was removed in this release. It is integrated within IrBeo4.h now. In existing main.cpp the #include "IrBeo4Info.h" statements must be deleted.

Release 1.3.0

• indicator LED handling added to transmit task as well. If the beo_led_cb() callback function is set in main.cpp the LED will be turned on at frame start and turned off at frame end within the beo4_tx_task()
• README.md updated
• Transmitter schematic for the IR diode TSHA6500 added. See Details --> esp32_beo4_tx

Release 1.2.3

tidy up unused code

• beo_code_cb() removed, this callback may disturb the receiver task and lead to unreadable codes. The better solution is the queue based aproach
• one shot timer routines, e.g. EventGroupHandle_t g_eg_handle, esp_timer_create(&OneShotTimer_args, &beo4->m_OneShotTimer_h); removed, the timing is done with delayMicroseconds() and a mutex taskENTER_CRITICAL(&beo4_tx_mutex);
• more info can be found in this discussion : #3

other changes

• example for a transmit task only device can be found under /examples/esp32_beo4_tx
• LED handling updated, the LED is only switched on when the start sequence has been validated. It therefore no longer flashes when TSOP7000 hickups occur.

readme updated

• changes made to match readme to sources

Release 1.2.2

The pioarduino based arduino-esp32 platform is used, in order to support newer boards like ESP32-C6.

arduino-esp32 migration 2.x to 3.0
https://docs.espressif.com/projects/arduino-esp32/en/latest/migration_guides/2.x_to_3.0.html#ledc

arduino-esp32 for platformio
https://github.com/pioarduino/platform-espressif32

breaking changes

The migration has affected these functions within the beo4_tx_task() .

• ledcSetup() is omitted
• ledcAttachPin() is replaced by ledcAttach()
• ledcWrite() has changed

Release 1.2.1

Bugfix for issue #2 , e.g. the Buttons BEO_CMD_LEFT_REPEAT, BEO_CMD_RIGHT_REPEAT and so on, are working now.

Release 1.2.0

• added example with Home Assistant MQTT auto discovery
• readme updated

Release v1.1.0

• use SW debouncing instead of HW monoflop
  --> see 2.1.2. Software solution
• updated readme