Sensor unreliable when using long wires

[Aaroneisele55]

Hello, I have two LD2450 Sensors on the same ESP32 board. Both detect presence well, but one of them (S2 or ld2450_external in the config) doesn't allow me to switch on the Bluetooth or the Multi-Target mode. When I flip the switch to ON, it resets to OFF after approximately 2 seconds. Power cycling the sensor and/or ESP32 doesn't help. It could be a similar problem to this Issue: https://github.com/TillFleisch/ESPHome-HLK-LD2450/issues/5

I also get this message in the logs after startup:

[14:52:31][W][LD2450:119]: Entering config mode failed, clearing command queue.
[14:52:31][W][LD2450:126]: Sending command timed out! Is the sensor connected?
[14:52:33][D][LD2450:271]: Clearing RX buffer.

Here's my config:

esphome:
  name: mmwavetest-d1mini32-02
  friendly_name: mmwavetest_d1mini32-02

esp32:
  board: esp32dev
  framework:
    type: arduino

# Enable logging
logger:
  logs:
    sensor: ERROR
    binary_sensor: ERROR

# Enable Home Assistant API
api:
  encryption:
    key: "8a/INyAsUXFGEf/4HuU2oXGTLKI0m+ddBEOYJbH4Cqw="

ota:
  password: "bf09a8dda9090dbe7040bed6da345672"

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Mmwavetest-D1Mini32-02"
    password: "xxeHosZcLSnu"

captive_portal:

#begin customisation (non-default things)
external_components:
  - source: github://TillFleisch/ESPHome-HLK-LD2450@main
    refresh: always

uart:
  - id: uart_bus_internal
    rx_pin: GPIO19
    tx_pin: GPIO18
    baud_rate: 256000
    parity: NONE
    stop_bits: 1
    data_bits: 8
    rx_buffer_size: 1024
  - id: uart_bus_external
    rx_pin: GPIO21 
    tx_pin:  GPIO22
    baud_rate: 256000
    parity: NONE
    stop_bits: 1
    rx_buffer_size: 1024
LD2450:
  - id: ld2410_internal
    uart_id: uart_bus_internal
    targets:
      - target:
          name: "S1 T1"
          x_position:
            id: t1_xpos_s1
          y_position:
            id: t1_ypos_s1
          distance: 
            id: t1_dist_s1
      - target:
          name: "S1 T2"
          x_position:
            id: t2_xpos_s1
          y_position:
            id: t2_ypos_s1
          distance: 
            id: t2_dist_s1
      - target:
          name: "S1 T3"
          x_position:
            id: t3_xpos_s1
          y_position:
            id: t3_ypos_s1
          distance: 
            id: t3_dist_s1
    flip_x_axis: false
    fast_off_detection: false
    max_detection_distance:
      name: "Max Distance S1"
      initial_value: "6m"
    restart_button:
      name: "Restart Sensor S1"
    tracking_mode_switch:
      name: "Multiple Target Tracking S1"
      restore_mode: ALWAYS_ON
    bluetooth_switch:
      name: "Sensor Bluetooth S1"
      restore_mode: ALWAYS_ON
    occupancy:
      name: "Occupancy S1"
      id: occupancy_s1
    target_count:
      name: "Target Count S1"
    zones:
      - zone:
          name: "Tür aussen"
          margin: 10cm
          target_timeout: 0s
          polygon:
            - point: 
                x: 1.42m
                y: 3m
            - point:
                x: 0.66m
                y: 3m
            - point:
                x: 0.66m
                y: 3.2m
            - point: 
                x: 1.42m
                y: 3.2m

          occupancy:
            id: tuer_aussen
            name: Occupancy Tür aussen
      - zone:
          name: "Tür innen"
          margin: 10cm
          target_timeout: 0s
          polygon:
            - point:
                x: 0.6m
                y: 2.6m
            - point:
                x: 0.66m
                y: 3.1m
            - point:
                x: 1.42m
                y: 3.1m
            - point:
                x: 1.42m
                y: 2.6m
          occupancy:
            id: tuer_innen
            name: Occupancy Tür innen
  - id: ld2410_external
    uart_id: uart_bus_external
    targets:
      - target:
          name: "S2 T1"
          x_position:
            id: t1_xpos_s2
          y_position:
            id: t1_ypos_s2
          distance: 
            id: t1_dist_s2
      - target:
          name: "S2 T2"
          x_position:
            id: t2_xpos_s2
          y_position:
            id: t2_ypos_s2
          distance: 
            id: t2_dist_s2
      - target:
          name: "S2 T3"
          x_position:
            id: t3_xpos_s2
          y_position:
            id: t3_ypos_s2
          distance: 
            id: t3_dist_s2
    flip_x_axis: false
    fast_off_detection: false
    max_detection_distance:
      name: "Max Distance S2"
      initial_value: "6m"
    restart_button:
      name: "Restart Sensor S2"
    tracking_mode_switch:
      name: "Multiple Target Tracking S2"
      restore_mode: ALWAYS_ON
    bluetooth_switch:
      name: "Sensor Bluetooth S2"
      restore_mode: ALWAYS_ON
    occupancy:
      id: occupancy_s2
      name: "Occupancy S2"
    target_count:
      name: "Target Count S2"
binary_sensor:
    - id: occupancy_combined
      platform: template
      name: "Occupancy combined"
      lambda: |-
        return (id(occupancy_s1).state || id(occupancy_s2).state);
      filters:
        - delayed_off: 10s
    - name: Tuer innen korrigiert
      platform: template
      lambda: |-
        return (id(tuer_innen).state);
      filters:
        - delayed_off: 2s
    - name: Tuer aussen korrigiert
      platform: template
      lambda: |-
        return (id(tuer_aussen).state);
      filters:
        - delayed_off: 2s

button:
  - platform: restart
    name: Restart

How could I fix this issue?

Best regards Aaron Eisele

[TillFleisch]

[14:52:31][W][LD2450:119]: Entering config mode failed, clearing command queue.
[14:52:31][W][LD2450:126]: Sending command timed out! Is the sensor connected?
[14:52:33][D][LD2450:271]: Clearing RX buffer.

This may be due to a loose TX wire. Make sure the that both RX and TX are connected properly. Increasing the size of the rx buffer on the uart component may also help with this issue. The Clearing RX buffer. message hint's at an overflowing RX buffer. Thus, the sensors response may not be processed.

Please try the sensors one at a time (using a minimal configuration (with switches)), to verify they are working properly. Depending on the firmware version of the sensor, the Bluetooth/Target switches may not be supported.

Which firmware versions do the logs show for both sensors (when connecting wirelessly for logging)? I am referring to the following log output:

[19:24:26][I][LD2450:367]: Sensor Firmware-Version: V2.04.23101915
[19:24:26][C][ota:096]: Over-The-Air Updates:
[19:24:26][C][ota:097]:   Addr [...]

[Aaroneisele55]

[14:52:31][W][LD2450:119]: Entering config mode failed, clearing command queue.
[14:52:31][W][LD2450:126]: Sending command timed out! Is the sensor connected?
[14:52:33][D][LD2450:271]: Clearing RX buffer.

This may be due to a loose TX wire. Make sure the that both RX and TX are connected properly. Increasing the size of the rx buffer on the uart component may also help with this issue. The Clearing RX buffer. message hint's at an overflowing RX buffer. Thus, the sensors response may not be processed.

Please try the sensors one at a time (using a minimal configuration (with switches)), to verify they are working properly. Depending on the firmware version of the sensor, the Bluetooth/Target switches may not be supported.

Which firmware versions do the logs show for both sensors (when connecting wirelessly for logging)? I am referring to the following log output:

[19:24:26][I][LD2450:367]: Sensor Firmware-Version: V2.04.23101915
[19:24:26][C][ota:096]: Over-The-Air Updates:
[19:24:26][C][ota:097]:   Addr [...]

1. What value should I use for rx_buffer_size?

2. The Firmware version and MAC are only printed for the first sensor (the one that fully works). I can see from the App that they are both on V2.04.23101915.

[TillFleisch]

What value should I use for rx_buffer_size?

This depends on your hardware and configuration (available memory). According to the ESPHome UART documentation, the default size is 256 bytes. You can try doubling this value.

The Firmware version and MAC are only printed for the first sensor (the one that fully works). I can see from the App that they are both on V2.04.23101915.

Is the firmware version reported properly, when using only one sensor in the configuration / with only one connected sensor/ after switching them around? Try using only a single sensor to verify they are working properly one at a time (or to rule out wiring issues).

If I find the time, I will try to replicate this.

[Aaroneisele55]

The problem is (I guess) that the problematical sensor is connected to the ESP32 over ~2m of cable. What could I do to enhance data transmission without changing the placement of the sensor?

Till @.***> schrieb am Mi., 28. Feb. 2024, 20:57:

What value should I use for rx_buffer_size?

This depends on your hardware and configuration (available memory). According to the ESPHome UART documentation https://esphome.io/components/uart.html, the default size is 256 bytes. You can try doubling this value.

The Firmware version and MAC are only printed for the first sensor (the one that fully works). I can see from the App that they are both on V2.04.23101915.

Is the firmware version reported properly, when using only one sensor in the configuration / with only one connected sensor/ after switching them around? Try using only a single sensor to verify they are working properly one at a time (or to rule out wiring issues).

If I find the time, I will try to replicate this.

— Reply to this email directly, view it on GitHub https://github.com/TillFleisch/ESPHome-HLK-LD2450/issues/9#issuecomment-1969747340, or unsubscribe https://github.com/notifications/unsubscribe-auth/AU44A45AJKSZ3BLCCJGCNJTYV6DZNAVCNFSM6AAAAABD2HTHM6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRZG42DOMZUGA . You are receiving this because you authored the thread.Message ID: @.***>

[TillFleisch]

What could I do to enhance data transmission without changing the placement of the sensor?

You can use shielded cabling (ideally RX and TX shielded separately) and/or try lowering the baud rate. Note than after changing the sensors baud rate you also need to update your ESPHome configuration.

[Aaroneisele55]

I already use a recycled Ethernet cable, but it's voltage drop (ESP I/O: 3.3v) is really huge and I guess that prevents it from working. Could I use 5v logic (via bidirectional levelshifters) to the sensor to resolve the issue?

Till @.***> schrieb am Do., 29. Feb. 2024, 08:45:

What could I do to enhance data transmission without changing the placement of the sensor?

You can use shielded cabling (ideally RX and TX shielded separately) and/or try lowering the baud rate. Note than after changing the sensors baud rate you also need to update your ESPHome configuration.

— Reply to this email directly, view it on GitHub https://github.com/TillFleisch/ESPHome-HLK-LD2450/issues/9#issuecomment-1970584027, or unsubscribe https://github.com/notifications/unsubscribe-auth/AU44A44XQQZ7FNAQNFQALB3YV3OBZAVCNFSM6AAAAABD2HTHM6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNZQGU4DIMBSG4 . You are receiving this because you authored the thread.Message ID: @.***>

[TillFleisch]

via bidirectional levelshifters

This may help. I did not have the opportunity yet, to play around with them. Also, make sure the sensor is powered properly. Using 3.3V (or lower, I don't know how big the voltage drop is under load) for power the LD2450 sensor can cause reliability issues. I would recommend measuring the voltage (drop) to verify this is the issue and to ensure the LD2450 Sensor is powered properly.

Did lowering the baud rate help with the issue?

Sidenote: Some ethernet cables only use outer shielding. Since the sensors' RX line is quite busy it may induce a voltage into the TX/GND line (inside of the outer shielding), thus messing with the sensor.

[Aaroneisele55]

I have now implemented sn74ahct125 as a level shifter for the TX line from the ESP (to prevent issues with signals being lost due to voltage drop ) and the sensor actually works now, but freezes after ~4h. I need to powercycle the ESP and the sensor then, which isn't really good. How could I diagnose a sensor related (freezing/not responding) issue? The affected sensors isn't visible in HLKradartools either when the bug occurs.

Best regards Aaron Eisele

[TillFleisch]

The affected sensors isn't visible in HLKradartools either when the bug occurs.

To me this sounds like the sensor is not powered properly. The voltage drop across the wire may cause to the sensor to not work properly. The readme's troubleshooting section contains more information about power related issues. Make sure you're using a reliable 5V power source and that the sensor is connected properly.

[Aaroneisele55]

The affected sensors isn't visible in HLKradartools either when the bug occurs.

To me this sounds like the sensor is not powered properly. The voltage drop across the wire may cause to the sensor to not work properly. The readme's troubleshooting section contains more information about power related issues. Make sure you're using a reliable 5V power source and that the sensor is connected properly.

I did measure the voltage with the sensor not in place (I can't measure under load, would need to redo my wiring for that) and it was 5.11V, so I personally doubt it's a power issue, but I'm not an expert. What also makes a pow issue less probable is the fact that it works fine for like 5 hours, but then "freezes".

[TillFleisch]

I did measure the voltage with the sensor not in place (I can't measure under load, would need to redo my wiring for that) and it was 5.11V, so I personally doubt it's a power issue, but I'm not an expert.

The voltage drop is dependent on the load (current) applied to the circuit. Measuring the voltage under virtually no load (since the voltmeter your using probabaly has a very high resistance) will therefore give inaccurate measurements. I'm also no expert when it comes to electronics.

the fact that it works fine for like 5 hours, but then "freezes".

I have experienced a very similar issues when using 3.3v to power the sensor in combination with other components which cause the voltage to be a bit lower (and noisier). The sensor sometimes stopped and sometimes never recovered. In regards to the Bluetooth functionality I can't say much as I have it disabled. The Bluetooth functionality being unavailable can be caused by the sensor not being powered properly (the sensor may turn off intermittently).

I would recommend trying the following for troubleshooting:

• measure the voltage under load
• switch the 2 sensors you have around to rule out any issues with them
• unplugging the closer sensor (your power supply may not be sufficient enough to power both sensors properly (voltage drops under "high" load))
• try a two sensor set-up with short wires
• try to replicate this issue in a similar setup (long wire, same diameter) then increase the wire diameter or shorten the wire to reduce voltage drop
• Use a separate power supply for the far away sensors (with common ground)

When using a zone tagert count sensor, it should go Unavailable when the ld2450 sensor is not sending updates. When using an unreliable power supply, this sensor will intermittently go unavailable for short periods. This may help in finding the issue/to verify that the sensor is not sending updates regularly.

Anyhow, it seems like this not an issue with this component but rather with the wiring/sensor.

[Aaroneisele55]

Ok, so I did measure the voltage under load and it was exactly 5.1V, which is the same value as with no load. I did measure in both the "buggy/freezing" state and during normal operation. I will try switching the sensors around later, but what should I do if they both react the same?

My problem while testing your tips is that I have to wait everytime for the bug to reappear, which takes ~1 hour.

Is that

zone target count sensor

the one that is created for a specific zone or the general "target count" sensor for the whole detection area?

Thanks for your help

Aaron Eisele

[TillFleisch]

I will try switching the sensors around later, but what should I do if they both react the same?

In that case we can rule out that this is a problem with one particular sensor and more likely one with the setup(i.e. long wire).

specific zone or the general "target count"

I was referring to a zone (any zone) specific target sensor

[Aaroneisele55]

Ok, so I swapped the sensors and the one attached via the longer cable became unresponsive again.

What could I do now? The affected sensor is powered via a separate 5V USB power supply, it gets 5.1V, so no power issue. What could be the problem then? Should I try with a shorter (~0.75m) cable instead of the 2m one currently in use?

[TillFleisch]

Should I try with a shorter (~0.75m) cable instead of the 2m one currently in use?

This may help, it's certainly worth a try. You've also mentioned that you've used a logic-level-shifter for the TX (esp to sensor) wire. Maybe the RX wire is affected in the same way, causing similar problem. What do the logs say when this happens? Do the target debug statement stop?

[Aaroneisele55]

Maybe the RX wire is affected in the same way, causing similar problem.

How would I fix this ? Could I use the second channel on my shifter (located near the ESP) ? I don't have a spare logic level shifter, nor do I have the abilities to unsolder the current one if something goes wrong. Would the ESP32 even "survive" 5v on its input pin? I don't think so, but what should I do instead?

[TillFleisch]

Would the ESP32 even "survive" 5v on its input pin?

The ESPs input pins are not rated for 5 volts.

The specific wiring depends on you level shifter and setup. If I recall correctly, the sensors logic output is 3.3v even when powered using 5 volts. Assuming the long wires causes noise on Rx/tx a wiring solution could be: esp <--> (3.3v)level shifter (5v)<-->long wire <--> (5v)level shifter(3.3v) <-> sensor (for both Rx/tx) (Placing the RX/tx wires further apart from one another can also help)

My experience is limited when it comes to electronics, therefore I can't really help you in this situation.

Please try the second sensor using short wiring (like the first sensor) to verify that the two sensor set-up is working properly when not using the long connection.

[Aaroneisele55]

Ok, so I have now wired the second sensor the same way (no shifter, shorter wires) as the first one and the issues were resolved