
A supply rating belongs in the power section of an integration note. It does not tell you what can be connected to TX/RX, or how received bytes should become a distance.
We are the ERDILRF technical resource team at ERDI TECH LTD. This note uses the published ErdiLRF 0.1.1 source and its documented limits to organize the information needed before wiring a module.
The library accepts an Arduino Stream. That describes its software transport; the host's UART capabilities and the delivered module interface still need checking. Start a connection record with the exact model, delivered configuration and controlled manual revision. Then keep the following entries separate.
| Record | Information to confirm | Evidence to keep |
|---|---|---|
| Supply | Operating supply and power pinout | The delivered model's power specification and connector drawing |
| Logic level | Delivered signal interface and TX/RX limits | The matching electrical-interface specification |
| Protocol | Baud, frame rules, commands and distance unit | The controlled protocol manual and driver version |
Supply
Identify the power pins from the correct connector drawing and record the documented operating supply. A supply value is not a TX/RX logic-level specification. Keep the pinout reference alongside it, so the voltage and the connector drawing refer to the same delivered configuration.
This worksheet deliberately supplies no voltage value. The available source says to confirm the selected configuration; it does not establish one electrical specification for every library model.
Logic level
Write down the delivered signal interface and the documented limits for its transmit and receive pins. Do the same for the host interface. If an adapter is part of the intended connection, record its interface and limits too. That is a documentation check to complete for the proposed connection, not evidence that an adapter has been tested here.
The library's model list cannot fill these fields for you. Its installation guide explicitly separates software model entries from supply voltage, TX/RX logic levels, connector pinout and available interface. Leave an unresolved field marked as unresolved until the matching documentation supplies it.
Protocol
Record the selected model, baud and frame rules before choosing commands or interpreting a distance field. The published README warns that a shared frame header does not establish common units, baud, checksum interpretation or electrical details.
Keep the driver version in this record. A repository's current branch and a published package can be different artifacts. Also check that the host serial implementation supports the documented configuration; accepting a Stream object is not a test of that host.
The known source gaps belong in the record as well. ErdiLRF 0.1.1 retains an LRF50VB command-table/checksum discrepancy, while SPD1200D03 has conflicting baud statements and undocumented distance scaling. A successful compile does not resolve those questions.
The result is a connection note whose fields have specific sources. When you later record a physical test, retain that configuration, the driver version, raw receive bytes and returned status with the result. This worksheet itself records no powered connection or hardware test.
The published 0.1.1 source archive includes the library and its MIT license. The ERDILRF software reference explains the installation scope and links to status handling and known limits.
About the author
- Tommy Yu at ERDI TECH LTD. I maintain ERDILRF's model documents and write about UART parsing and rangefinder integration. Generated-byte exercises are labelled; their output is not measured distance. Documents: https://erdilrf.com/ | Questions: tommy@erdimail.com
Comments
Join the discussionNo comments yet. Be the first to comment.

