S2-Mini UART is dropping the first 129 bytes.

[protectivedad]

To me this is very strange. I'm trying to figure out why my LD2402 driver is not working on an S2-Min. I think I've isolated all the variables. I've compiled code with the following lines:

yield();
LD2402Serial->setReadChunkMode(1);
avail = LD2402Serial->readBytes(LD2402.buffer, LD2402_BUFFER_SIZE);
DEBUG_SENSOR_LOG(PSTR(D_LD2402_LOG_PREFIX "Engineering: %*_H"), avail, LD2402.buffer);

I've created it for:

tasmota
tasmota32
tasmota32s2

On the ESP8266:

10:45:09.562 LD2: Engineering: F4F3F2F183000000000000000000000000AB0F00005203000009020000890200003F020000E5010000D90100008E010000D10100000202000021020000F5010000EF010000FE0100003C0100003C0100004D1200008D020000F501000085020000590100006C01000076010000320100004B01000032010000F4000000C3000000E70000001E010000F8F7F6F5

On the ESP32:

10:42:42.284 LD2: Engineering: F4F3F2F18300019400000000000000000010370000310E0000390C00002C0500009D030000320500008F0500001D050000C103000012030000460300009E030000F6020000240300000000000000000000E030000089150000A41800001B0F0000C9060000C6040000830400005E03000032030000D7010000FE0100009801000030020000FA000000F8F7F6F5

Which are what I expect header section data footer section.
On the ESP32S2:

10:47:17.345 LD2: Engineering: FB00000070010000F8F7F6F5E5010000E4000000F8F7F6F5390100002D010000F8F7F6F56901000098010000F8F7F6F5CB0100006B010000F8F7F6F58801000024010000F8F7F6F53A02000084010000F8F7F6F535010000AF010000F8F7F6F51101000054020000F8F7F6F5930100003C010000F8F7F6F534020000CC010000F8F7F6F5A7000000E6010000F8

Only the last 12 bytes comes in. Consistently.

I've used the same wires and sensor on the ESP32/ESP32S2 because I thought it might be a wiring issue. I've attached the sensor to three different S2-Mini boards. Soldered it a dozen times. I'm stumped, any ideas of how to track this down.

[Jason2866]

@arendst Since this is device specific i fear this is an Arduino / IDF issue. I wonder why UART is affected.
Known troublemaker is when CDC is used as serial port, but UART should work.

[arendst]

I'll have as look using my Wemos S2 mini which BTW needs flow control (RTS/CTS) to communicate serial using the USB connector.

[arendst]

Pls provide your S2 mini GPIO configuration.

[protectivedad]

This is how I have all my test devices connected. The "engineering" mode of the ld2402 sends 141 characters and the first 129 are dropped leaving only 12 characters. If I put it in normal mode it will work with 15 characters.

[protectivedad]

Here are the connections I thought maybe the USB connection was interfering with the uart so this is plugged into a charger not the computer..

[arendst]

Thx.

Current status: I verified with SerialBridge that the S2 (= single core) fails to receive full serial data when the message is larger than the S2 hardware serial receive buffer (128 bytes). It works fine on an ESP32 (= dual core) having the same size serial hardware receive buffer.

I'll dive further into ArduinoEspressif framework and IDF to find where it fails.

Nice exercise ;-)

[Jason2866]

@arendst Maybe this is similar and helps? espressif/arduino-esp32#10420 (comment)

[arendst]

It did help!

The fix is using (not yet implemented in Tasmota but testing now) command setRxFIFOFull(80). This is default set to 120 which is probably too high at high speed baudrates. If I add it and set to 80 it fixes both ESP32-S2 and ESP32-C3 serial reception of messages longer than 128 bytes.

Further testing....

[protectivedad]

Well that definitely does it. Changing:

  if (m_speed < 115200) {
    // At 76800 the timeout is ~1ms
    uart_set_rx_timeout(m_uart, 6);
  }

to

  if (m_speed < 115200) {
    // At 76800 the timeout is ~1ms
    uart_set_rx_timeout(m_uart, 6);
  } else {
    TSerial->setRxFIFOFull(80);
  }

in Esp32Begin fixes the issue for me.

Thanks.

[arendst]

Fixed with latest change fb6640b

[protectivedad]

There are still issues with dropping data. Every minute the S2-Mini will loose characters (or gain them). So the system will find the header grab 2 bytes for the length and then pull 131 bytes for the data. About once a minute the footer will be garbage, I don't know how much it looses. The driver will get back on track with the next header and it seems to work for up to a minute and then it will hiccup again. This is not experienced with the ESP82366 or ESP32.

I am not sure if you would consider that amount of interference "good enough". If you have any thoughts with how I can tune the parameters, I'm willing to see if I can get it to become more solid.

[protectivedad]

After a successful header the code I'm using to get the rest of the line is:

    static uint32_t length;
    if (byte_counter < 6) {
      while (LD2402Serial->available() < 2) {
        yield();
      }
      length = LD2402Serial->read();
      LD2402Serial->read();
      if (length > LD2402_BUFFER_SIZE) {
        data_type = 0;
        byte_counter = 0;
        break;
      }
      byte_counter = 6;
    }

    yield();
    byte_counter = LD2402Serial->readBytes(LD2402.buffer, length);
    if (byte_counter < length) {
      DEBUG_SENSOR_LOG(PSTR(D_LD2402_LOG_PREFIX "Wasn't able to get whole line!"));
      data_type = 0;
      byte_counter = 0;
      break;
    }

    while (LD2402Serial->available() < 4) {
      yield();
    }
    for (uint32_t i = 4; i; i--) {
      footer.buffer_32<<=8;
      footer.buffer[LD2402.is_big*3] = LD2402Serial->read();
    }

when it fails it burbs out:

12:52:22.196 LD2: Head F1F2F3F4
12:52:22.197 LD2: Eng 01730000000000D7190000EB190000BC050000BE02000017030000280300005502000032020000660200001C0200009902000046020000FC010000C801000039020000000000003D4C0000835B0000D42A00008E0D00004D070000D9010000350300000D0300004604000026010000F30200000000AC030000E3020000F80000008800
12:52:22.199 LD2: byte_counter: 131, avail: 275, length 131
12:52:22.200 LD2: Foot 00B20000
12:52:22.202 LD2: Found engineering footer but have no header!
12:52:22.205 LD2: Found engineering footer but have no header!

[arendst]

I guess you're stumbling on the single core of the esp32-s2. What happens on the console when it fails every minute? Is it a teleperiod message then change the interval from 60 to 300.

Otherwise accept the lack of dual core.

[protectivedad]

It seems strange to me that it works flawlessly with the esp8266. It gets better if I adjust the uart_set_rx_full_threshold(m_uart, 120); to uart_set_rx_full_threshold(m_uart, 100);. Not sure the trade offs. It just skips a little. But it still 'skips' a little. Thanks for the help.