Skip to main content

Before connecting UART, keep three separate records

Updated 3 min readMarkdown
Before connecting UART, keep three separate records

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

No comments yet. Be the first to comment.