We feed the same synthetic bytes into two model definitions in the published ErdiLRF 0.1.1 Arduino library, then corrupt the checksum to check that invalid input does not become a measurement. No sensor, target or module UART is needed.

Disclosure: We are the ERDILRF team at ERDI TECH LTD, the manufacturer associated with the library. The examples use generated bytes. They are software checks, not physical range, accuracy or compatibility tests.

What the check covers

The library accepts an Arduino Stream. A small in-memory stream can therefore supply input bytes without connecting a rangefinder. Writes from the driver are consumed by the test helper and do not reach a module.

We use the library's ERDI_LRF50H and ERDI_LRF50VB definitions. In version 0.1.1, their distance conversion divides the raw count by 100 and 1,000 respectively. This is a comparison of the published software definitions; use the delivered unit's controlled manual to confirm a real integration.

The chosen input is 5C 02 11 EC. The two distance bytes represent the synthetic raw count 4,354. The helper erdiCheckSumB() produces EC from 02 11. Changing that last byte leaves the input without a valid frame.

Install the published library

In Arduino IDE, open Library Manager, search for ErdiLRF, and select 0.1.1. The same version is listed in the Arduino library index and PlatformIO Registry.

For Arduino CLI:

arduino-cli lib update-index
arduino-cli lib install "ErdiLRF@0.1.1"

The version number matters: these checks describe 0.1.1. A later library release may change its implementation or documented limits.

Add an in-memory input stream

Create a sketch named SyntheticUARTChecks. Add a tab/file named SyntheticFrame.h with the following code:

#ifndef ERDI_SYNTHETIC_FRAME_H
#define ERDI_SYNTHETIC_FRAME_H

#include <ErdiLRF.h>

// MIT. Synthetic test helper; no module UART is opened.
class SyntheticStream : public Stream {
 public:
  SyntheticStream(const uint8_t *data, size_t size)
      : data_(data), size_(size), position_(0) {}

  int available() override { return (int)(size_ - position_); }
  int read() override {
    return position_ < size_ ? data_[position_++] : -1;
  }
  int peek() override {
    return position_ < size_ ? data_[position_] : -1;
  }
  void flush() override {}
  size_t write(uint8_t) override { return 1; }

 private:
  const uint8_t *data_;
  size_t size_;
  size_t position_;
};

inline ErdiStatus decodeSynthetic(ErdiModel model, const uint8_t frame[4],
                                ErdiMeasurement *measurement) {
  SyntheticStream stream(frame, 4);
  ErdiLRF driver(stream, model);
  driver.setTimeout(10);
  return driver.measure(measurement);
}

#endif

The helper implements only a finite input buffer and an output sink. Its timeout keeps a corrupt or incomplete input from waiting indefinitely. It does not simulate electrical levels, UART timing or a real device's response to commands.

Run the three cases

Put this in SyntheticUARTChecks.ino:

#include "SyntheticFrame.h"

void showSynthetic(const char *label, ErdiModel model, const uint8_t frame[4]) {
  ErdiMeasurement measurement;
  ErdiStatus status = decodeSynthetic(model, frame, &measurement);
  Serial.print(label);
  Serial.print(" status=");
  Serial.print((int)status);
  if (status == ERDI_OK && measurement.valid) {
    Serial.print(" raw=");
    Serial.print(measurement.raw);
    Serial.print(" metres=");
    Serial.print(measurement.metres, 3);
  }
  Serial.println();
}

void setup() {
  Serial.begin(115200);
  delay(1000);
  Serial.println("SYNTHETIC INPUT - no sensor measurement");

  uint8_t frame[4] = {0x5C, 0x02, 0x11, 0x00};
  frame[3] = erdiCheckSumB(&frame[1], 2);
  showSynthetic("LRF50H", ERDI_LRF50H, frame);
  showSynthetic("LRF50VB", ERDI_LRF50VB, frame);

  frame[3] ^= 0x01;
  showSynthetic("CORRUPT", ERDI_LRF50H, frame);
}

void loop() {}

The sketch uses Serial only for its console output at 115200. That is the console setting, not a statement about either sensor's delivered UART setting. Keep rangefinder hardware disconnected for this test.

To compile for an Arduino Uno with its AVR core installed:

arduino-cli compile --fqbn arduino:avr:uno SyntheticUARTChecks

Our verification build used Arduino CLI 1.5.1, AVR core 1.8.8 and a native ARM64 AVR-GCC 14.2.0 toolchain on macOS. It used 6,724 bytes of program storage and 308 bytes of static RAM. The sketch was compiled, not uploaded to a board.

Select the board you actually use when building a different target. A successful compile establishes that source/compiler/target combination; it does not establish electrical or hardware compatibility with a module.

Read the result correctly

Our host-side execution of decodeSynthetic() with the exact published 0.1.1 C++ source produced:

SYNTHETIC LRF50H status=0 raw=4354 metres=43.540
SYNTHETIC LRF50VB status=0 raw=4354 metres=4.354
SYNTHETIC CORRUPT status=1 valid=0

These numbers came from generated bytes, not measurements. The valid cases demonstrate the model-specific conversion. In the corrupt case, the driver discards the invalid frame and waits for another one. Because the finite stream contains no valid replacement, it returns ERDI_ERR_TIMEOUT, whose value in this release is 1.

Check the returned status before using measurement.metres. A timeout does not by itself distinguish a disconnected wire, a baud mismatch, incomplete input or discarded bad frames.

What remains to check on real hardware

Before replacing the synthetic stream with a board UART, confirm the exact model, controlled manual revision, delivered interface, supply, TX/RX logic levels, baud setting and grounding. Retain raw receive bytes and the model/configuration used to interpret them.

The library documents unresolved source discrepancies, including an LRF50VB command-table/checksum mismatch. This in-memory exercise neither sends those commands to hardware nor resolves that discrepancy. It also does not establish ROS 2, PX4, ArduPilot, all-board or all-model compatibility.

The source and examples are available in ErdiTech/ErdiLRF. The library is MIT licensed; keep its license when redistributing it. The small test helper and sketch in this article are also provided under MIT.

For model documents or configuration questions, use the ERDILRF catalog or contact page. Technical contact: tommy@erdimail.com.

rangefinder or LiDAR into something. Single-point DToF modules, 2D scanners, flight stacks, and the

message standards that connect them.

**Every link in this file was checked and returns HTTP 200** before publication. An earlier draft of

this list contained three repositories that did not exist — plausible-looking names I had

misremembered. They were removed. A list that sends you to a 404 wastes the only thing you were

going to give it, which is thirty seconds of trust.

**Disclosure:** I maintain entry 1.1. It is marked as such. Everything else here is other people's

work and none of it is affiliated with me.

---

## 1. Single-point DToF ranging modules

These are the closest cousins of an industrial 905 nm ranging module: one beam, one distance, a

serial or I²C interface.

### 1.1 `erdilrf/erdilrf-drivers` — *maintained by the author of this list*

https://github.com/erdilrf/erdilrf-drivers

Host driver (Python, zero dependencies) and a header-only Arduino/C++ driver for the **LR1000E2 8-byte

UART protocol family**, plus a full protocol reference and a `decode` CLI that parses a captured frame

with no hardware attached. 50 tests, none requiring a serial port.

Worth reading even if you use a different module: [`protocol/verification.md`](https://github.com/erdilrf/erdilrf-drivers/blob/main/protocol/verification.md)

re-derives a manufacturer's checksums from the stated rule rather than trusting the printed values,

and [`docs/what-the-datasheet-does-not-say.md`](https://github.com/erdilrf/erdilrf-drivers/blob/main/docs/what-the-datasheet-does-not-say.md)

documents four gaps in a published datasheet. The method transfers; the constants do not.

### 1.2 `budryerson/TFMINI-Plus`

https://github.com/budryerson/TFMINI-Plus

Arduino library for the **Benewake TFMini-Plus and TFMini-S** LiDAR distance sensors. The de-facto

community library for these modules, and the reference for how to structure a driver that has to cope

with two firmware variants of the same product.

Also see [`budryerson/TFMini-Plus-I2C`](https://github.com/budryerson/TFMini-Plus-I2C) for the I²C

variant — useful because it shows the same device behind two different physical layers.

### 1.3 `garmin/LIDARLite_v3_Arduino_Library`

https://github.com/garmin/LIDARLite\_v3\_Arduino\_Library

First-party Arduino library for the **Garmin LIDAR-Lite v3**. A vendor publishing its own driver is

rarer than it should be, and this one is a decent model for what a vendor driver ought to contain.

### 1.4 VL53L0X / VL53L1X — the ST ToF family

Short-range ToF sensors with the widest ecosystem of any ranging part, which makes them the fastest

way to get *any* working distance pipeline before you commit to a long-range module.

| Repository | Note |

|---|---|

| https://github.com/stm32duino/VL53L1X | ST's own Arduino core library for VL53L1X |

| https://github.com/pololu/vl53l0x-arduino | Pololu's VL53L0X library — exceptionally clear register-level code |

| https://github.com/adafruit/Adafruit\_VL53L0X | Adafruit's, with the usual tutorial support |

| https://github.com/DFRobot/DFRobot\_VL53L0X | DFRobot's, for their breakout boards |

Range is centimetres to a few metres, not hundreds. Use them to validate your I²C plumbing and your

data path; do not use them to validate a long-range optical design.

---

## 2. 2D scanning LiDAR

If you need a scan plane rather than a point.

| Repository | What it is |

|---|---|

| https://github.com/Slamtec/rplidar\_sdk | Slamtec RPLIDAR SDK — the most widely deployed low-cost 2D LiDAR |

| https://github.com/ldrobotSensorTeam/ldlidar\_stl\_ros2 | LD06/LD19 ROS 2 driver — very common on small robots |

| https://github.com/YDLIDAR/ydlidar\_ros2\_driver | YDLIDAR ROS 2 driver |

These are scanning mechanisms: a spinning or rotating assembly producing a point cloud, not a single

range. If your problem is "how far to that one thing", a single-point module will be smaller, cheaper,

faster and far easier to power.

---

## 3. 3D and automotive-grade

Heavier, and mostly relevant if you are building perception rather than measurement.

| Repository | What it is |

|---|---|

| https://github.com/Livox-SDK/Livox-SDK2 | Livox non-repetitive-scanning LiDAR SDK |

| https://github.com/ouster-lidar/ouster-ros | Ouster ROS driver |

| https://github.com/ros-drivers/velodyne | Velodyne ROS driver — long-lived, still worth reading for ROS conventions |

---

## 4. Flight stacks — where rangefinders actually get used

If you are putting a ranging module on an aircraft, do not write the integration from scratch. Both

major open-source stacks already have a rangefinder abstraction, and both have absorbed years of

hardware-specific failure modes.

| Repository | Note |

|---|---|

| https://github.com/PX4/PX4-Autopilot | `src/drivers/distance_sensor/` — many modules, one interface |

| https://github.com/ArduPilot/ardupilot | `libraries/AP_RangeFinder/` — the same idea, different abstractions |

| https://github.com/mavlink/mavlink | The `DISTANCE_SENSOR` message — how a rangefinder's output reaches a ground station |

Reading two independent implementations of the same abstraction is a fast way to learn which parts of

*your* interface are real constraints and which are habits.

---

## 5. How to read a ranging module driver

Across all of the above, the same four questions decide whether a driver is usable:

1. **Does it distinguish "no answer" from "measurement failed"?** These have completely different

causes — a cable versus a target — and a driver that returns one error code for both costs you an

afternoon every time.

2. **Does it resynchronise on a corrupted frame, or does one bad byte poison the stream?** Look for a

header-scan or a rolling buffer.

3. **Does it state its physical-layer assumptions, or silently guess them?** Parity, stop bits and

logic levels are the usual silent guesses.

4. **Does it say what it does not know?** A driver whose documentation admits a gap is more reliable

than one that reads as complete, because completeness in a hardware driver is usually a sign that

something was assumed rather than measured.

Point 4 is the one that separates the good ones. Hardware documentation that never says "unknown" has

either tested everything or is hiding something, and in open source it is usually the latter.

---

## Contributing

Corrections are the most valuable contribution: if a link here has died, or a repository has been

superseded, open an issue on

[`erdilrf/erdilrf-drivers`](https://github.com/erdilrf/erdilrf-drivers/issues). Broken links and

wrong characterisations both count as bugs.