DEV Community: Tommy Yu

Three 1535 nm rangefinders, three ranges: the sentence that makes them comparable

Tommy Yu — Mon, 26 Oct 2026 05:42:53 +0000

Three datasheets, three ranges: 23 km, 15 km, 8 km. All three call themselves "1535 nm laser rangefinder modules". None of those numbers can be compared, because none of them says what the laser was pointed at.

Here are three figures from our own catalogue, with the sentence that ships next to each one:

Model	Published range	Condition, as published
LRF1829C	23,000 m	line of sight, visibility not less than 26 km, humidity not greater than 50 % at 30 °C
LRF0610C	6,000 m	≥6,000 m against a 2.3 × 2.3 m reference target; ≥1,500 m against a human-size 0.5 × 1.7 m target
LRF0105C	3,000 m	≥3,000 m against 2.3 × 2.3 m at 30 % reflectance and ≥5 km visibility

Look at the third row. Against the same reference target it claims 3 km; the 23 km row claims 23 km. Both are 1535 nm, both carry the same eye-safety argument, both talk over a serial link. What separates them is aperture, pulse energy, mass — and the condition each figure was measured under.

Why the condition is the only thing worth comparing first

At 1535 nm the transmitter is erbium glass and the receiver is InGaAs. Because the light is absorbed in the cornea before it reaches the retina, the allowable pulse energy is far higher than at 905 nm — which is exactly why 1535 nm modules exist at all in the kilometre range.

But "high pulse energy" does not mean "long range". Range depends on the target's reflectivity, its size, and how much daylight is in the receiver. A 23 km module against a 10 % reflective target in bad visibility is not a 23 km module. That is not a marketing problem, it is arithmetic.

Three questions resolve it faster than any datasheet:

What target size and reflectance was the figure measured against?
What visibility?
Is the accuracy figure absolute (metres) or proportional (a percentage above some distance)?

What we did about it

We put the whole 1535 nm band on one page — every model, every published range, and the condition sitting next to it, unedited:

1535 nm laser rangefinder module — the band in one page

And the raw rows, if you would rather run your own filter:

JSON / CSV: specs.erdilrf.com/data
Versioned mirror: github.com/erdilrf-afk/erdi-lrf-specs
Citable copy with a DOI: 10.5281/zenodo.23655337

If you have a datasheet in front of you that quotes a range with no condition, that is the first thing worth asking about — before the price, before the lead time.

A rangefinder dataset you can diff: 59 models, with the test condition attached

Tommy Yu — Mon, 26 Oct 2026 03:42:56 +0000

A datasheet that says "20 km" is not telling you 20 km. It is telling you 20 km against some target, at some reflectance, in some visibility — and those three numbers are usually left out or buried in a footnote.

That omission is why two suppliers can both quote "20 km" and mean completely different things, and why procurement arguments about range so often end with nobody able to prove anything.

So we published the table we use internally, with the footnote kept.

What is in it

59 records, one per model, 29 fields. 38 rangefinder modules, 12 laser sources, 9 single-point lidar sensors. Wavelengths 905 nm, 940 nm and 1535 nm; ranges from 9 m to 23,000 m.

The field that matters is range_condition. It holds the manufacturer's own sentence — target size, reflectance, visibility — copied verbatim, not normalised and not extrapolated:

{
  "model": "LRF0815C",
  "wavelength_nm": 1535,
  "range_max_m": 8000.0,
  "range_min_m": 15,
  "range_condition": ">=8,000 m to a 2.3 m x 2.3 m target, 30% reflectance, visibility >23 km"
}

Where no condition is published, the field is empty. It is not filled with a guess, because a guessed condition is worse than a missing one: it looks like data.

Three things it will not do

It will not give you a "typical range". Averaging a 23 km row against a 12 km row produces a number that describes no product. Compare conditions, then compare ranges.

It will not normalise accuracy. Some models publish a fixed figure in metres, some publish a proportional one (D > 100 m, or a percentage). Where that happens the raw string ships alongside the scalar, and the raw string is authoritative.

It will not price anything. No prices anywhere in the dataset. Commercial terms are quoted per inquiry, because the right price depends on the interface, the housing and the volume, not on a table.

Why publish it at all

Two reasons, neither of them charitable.

First, a specification you can only get by emailing a sales address is a specification nobody checks. If the numbers are public, they can be diffed — including our own numbers, against our own earlier versions.

Second, it changes the conversation. Most supplier comparisons collapse because the two sides are quoting different measurements. When both sides publish the condition, the argument becomes about the actual decision: whether a 1535 nm module at this mass and this interface does the job.

Getting it

Interactive page, with the field list and the known limits: specs.erdilrf.com/data
JSON and CSV, same rows, mirrored and versioned: github.com/erdilrf-afk/erdi-lrf-specs
Archived copy with a DOI, so it can be cited in a purchasing document or a paper: 10.5281/zenodo.23655337

Licence is CC BY 4.0. Use it, quote it, build on it.

If you find a row that is wrong, the errata address is on the dataset page. We would rather correct a row than defend it.

What a first article inspection for a rangefinder actually contains

Tommy Yu — Mon, 26 Oct 2026 02:21:42 +0000

Two suppliers quote the same range. One of them can prove it; the other has a PDF. The difference shows up six months later, when the first batch arrives and nobody agrees what "conforming" means.

First article inspection is the moment that ambiguity gets closed. Most buyers have never seen one for a rangefinder, so here is what it should contain.

Why a sample test is not enough

A sample tells you one unit worked once. A first article tells you both sides agreed what the part is, which is what makes later disagreements mechanical instead of emotional. Once signed, a returned unit is compared against a document rather than argued about.

The twelve records

1. Identity. Serial number, firmware version, hardware revision, recorded against the drawing revision. Without the revision this document is worthless six months later.

2. Dimensional. Housing, mounting holes, optical window position — measured, with the instrument named.

3. Mass. Measured against the declared value, tolerance stated. Sounds trivial; it is the number that quietly breaks gimbal designs.

4. Optical axis. Boresight offset between transmit and receive axes relative to the mechanical datum, in mrad. For an integrated sight this is the number that decides whether the reticle and the beam agree at 2 km.

5. Range verification. Measured range against a stated target at a stated distance in stated visibility — with the reference instrument named. "16 km" alone is not a record.

6. Accuracy. Constant and proportional error, measured at three or more distances. A ±2 m figure with an unstated per-kilometre term is not a specification.

7. Repetition rate. Achieved rate in continuous mode, plus the missed-return count over a fixed number of shots. The second number is the one that predicts field behaviour.

8. Interface. Every command in the protocol document exercised once, replies recorded. This is where an integration either starts clean or starts with a two-week debug.

9. Power. Current draw at idle, single-shot and continuous, at both supply limits.

10. Environmental. Temperature cycling result, and whether the unit was operated at both extremes or merely stored there.

11. Sealing. IP test method and result — or an explicit statement that it was not performed. An omission stated is information; an omission hidden is a surprise.

12. Safety. Accessible emission measured at the aperture, with instrument and standard cited. Note this classifies that build, not your product.

What to do with it

Make it a line item in the quotation, not a favour. If it cannot be priced, it cannot be delivered.
Ask for it once, on the first article, and keep it. Later units are judged against it.
If a supplier cannot produce one, that is a data point about how the next twelve months will go — not a reason to negotiate harder.

The twelve fields, as a checklist you can send directly, are here. The range test report template that pairs with it is here.

I keep an open dataset of 59 rangefinder and single-point lidar modules at specs.erdilrf.com — every range figure carrying the manufacturer's own test condition, plus interface and optics tables. JSON and CSV, CC BY 4.0, no signup.

If you have a first-article horror story — a dimension that was "measured" without an instrument, a firmware revision nobody wrote down — I would like to hear it. Those are the ones worth writing about.

Why "eye safe" is a wavelength argument, not a marketing claim

Tommy Yu — Sun, 25 Oct 2026 15:58:57 +0000

"Eye safe" is not a property of a laser. It is a property of a number of joules at a given wavelength reaching a given aperture — and the wavelength decides how many joules that is.

This matters when you are choosing a rangefinder for something that points at people: a drone payload, a handheld sight, a perimeter scanner.

The physical reason

At 905 nm and 940 nm the eye focuses the beam onto the retina. The hazard is retinal, and the allowed exposure is tiny: a few hundred nanojoules for a nanosecond-class pulse.

At 1535 nm the beam is absorbed by water in the cornea and lens before it reaches the retina. The hazard becomes corneal, and the allowed exposure is roughly five orders of magnitude higher for the same tissue effect.

That is the whole trick. It is not marketing, and it is not that 1535 nm is "safer light" — it is that the energy stops at the front of the eye instead of the back.

What it buys you

For a rangefinder, range scales with pulse energy (among other things). If the allowed energy is far higher at 1535 nm, the same Class 1 limit permits:

more joules per pulse → longer range against the same target
and, just as importantly, the same range with a narrower beam, which concentrates energy and makes the return stronger

This is why the long-range end of the market is almost entirely 1535 nm, and why the 905 nm parts are the short-range, high-rate, low-mass ends of the same catalogue.

What it does not buy you

It does not make the module Class 1 by itself. A 1535 nm source at high energy can still exceed the corneal limit. The class is a measurement of the assembled product at its aperture, not a property of the wavelength.

It does not transfer to your product. The module's label applies to the module as supplied. Add a lens, a window, a different housing, or a second emitter, and the accessible emission changes. The finished product needs its own assessment and its own label. This is the part that integrators most often get wrong — and the part that a customer's safety officer will ask about first.

It does not mean invisible. 1535 nm is well outside the visible band, which is convenient operationally, but "invisible" is not "harmless"; the classification exists precisely because it is not.

What to ask a supplier

Which wavelength, and is the class statement made at the module aperture or at the source?
Under which standard and revision was the class determined?
What is the pulse energy, pulse width and repetition rate at the stated class?
Does the class statement survive the intended optical configuration, or does it need re-assessment?

A supplier who answers these four precisely is telling you they have been through a customer's safety review before.

I keep an open dataset of rangefinder and single-point lidar modules at specs.erdilrf.com — 59 modules, 905 / 940 / 1535 nm, every range figure carrying the manufacturer's own test condition, plus an interface table and the safety guide for integrators. JSON and CSV, CC BY 4.0.

If you have had a class statement fail at the product level, I would like to hear how it happened — it is the most useful kind of anecdote in this field.

Five things in a rangefinder protocol document that cost two weeks each

Tommy Yu — Sun, 25 Oct 2026 15:55:37 +0000

Two weeks of field debugging, then a one-line fix in the protocol document. That is the usual ratio when a rangefinder integration goes wrong. The laser is rarely the problem — the bytes around it are.

Here are the five things that break integrations, in the order they usually bite.

1. Endianness, and the number that is silently wrong

A range value spans two or four bytes. If the document says "distance, 2 bytes" and stops, the host and the module can disagree about byte order and still produce a number — just a wrong one. 0x0B B8 is 3000 in big-endian and 0xB80B (47115) in little-endian. Both are legal integers. One is 3 metres, the other is 47 kilometres.

Symptom: ranges that jump by a factor of ~15.6 when the low byte happens to be large.

Fix: demand the byte order in writing, and test with a known short distance where the two readings differ.

2. Checksum coverage: which bytes, exactly

"Checksum over the message" is not a specification. It has to state:

the algorithm (sum, XOR, CRC-8/16, which polynomial)
the seed / initial value
whether the checksum byte itself and the start bytes are covered
whether it is computed before or after byte-stuffing, if stuffing exists

Off-by-one in coverage produces a link that works for one command length and fails for another — the worst kind of bug, because it looks like an intermittent hardware fault.

3. What happens mid-measurement

A command that arrives while the module is still integrating has three plausible behaviours: it is queued, it is dropped, or it aborts the measurement and replies with something. If the document does not say which, the host software will be written against the wrong one.

Related: the minimum interval between commands. Modules that need 200 ms of integration will not answer faster than that, and sending faster does not produce errors — it produces stale or missing answers.

4. Resynchronisation after a dropped byte

A UART link loses bytes. What does the host do when a frame arrives short? If the protocol has no reliable frame boundary (a start byte pair, or a length field plus terminator), the parser cannot tell a truncated frame from a valid short one, and the stream stays misaligned until the host is restarted.

The document must state the resync rule explicitly: flush until the next start marker, discard the partial frame, resume.

5. Error codes that nobody can act on

"Error 0x03" with no cause attached is not an error code, it is a puzzle. Useful error sets distinguish at least:

no return detected
return detected but ambiguous (two echoes, e.g. through glass or vegetation)
target too close
target too far
supply out of range
internal temperature out of range

The last two matter more than they look: a module that quietly returns garbage below −20 °C will be blamed for a positioning bug months later.

An example exchange, and why it belongs in the document

Nothing in a protocol document saves as much integration time as one complete transcript:

TX  55 AA 04 01 00 05          start, len, cmd=measure, arg=0, checksum
RX  55 AA 07 81 0B B8 00 12     start, len, cmd|0x80, distance=0x0BB8, status=0x00, checksum

Nine bytes of example explain more than three pages of prose, because it forces the author to state the frame layout unambiguously.

I put the full list of twelve items a protocol document must state into a checklist. Send it to any supplier before you write a driver — the ones who can answer all twelve have shipped to integrators before.

The general rule

Every ambiguity in a protocol document becomes an experiment in your lab. An experiment costs a day; a sentence in the document costs nothing. If a supplier cannot produce the sentence, treat that as information about how the rest of the project will go.

I keep an open dataset of rangefinder and single-point lidar modules at specs.erdilrf.com — 59 modules with the manufacturer's test conditions attached to every range figure, plus the interface and optics tables. JSON and CSV, CC BY 4.0, no signup. The answers section covers the buyer questions that keep coming up.

If any of the five above has bitten you with a specific module, I would like to hear which one — the failure modes are the interesting part.

Your lidar says 40 m and reaches 9 m: the four numbers that decide a real range

Tommy Yu — Sun, 25 Oct 2026 15:53:52 +0000

Your lidar says 40 m. Outdoors it stops at 9 m. Nothing is broken — the datasheet was measured under conditions nobody wrote down.

I maintain an open dataset of laser rangefinder and single-point lidar modules (specs.erdilrf.com), and the most common support question is some variant of "why is my range so much worse than the datasheet?" It is almost always one of four numbers, and the datasheet usually gives you one of them.

The four numbers

1. Target reflectance. Most modules quote a range against a 90 % reflective target — a retro-reflector or a white board. Real targets are not that. A matte grey wall is around 10–20 %; black anodised aluminium is under 5 %; foliage is worse and it moves. Returned power falls with reflectance, and range falls with the fourth root of returned power, so a 10× drop in reflectance costs you a meaningful fraction of your range before anything else goes wrong.

2. Background illumination. Indoor compatibility is often quoted in klx. Direct sun on a white target is on the order of 100 klx. If the module's stated ambient immunity is 10 klx, outdoor daylight is outside its specification. Narrowband filtering helps — one reason 905 nm and 940 nm parts behave differently in sunlight — but it does not perform miracles.

3. Atmosphere. Visibility in km is the usual figure. At 10 km visibility the atmosphere already eats a few percent per hundred metres; in fog or heavy rain the return can vanish entirely. Long-range modules quote their headline numbers at good visibility, which is a condition, not a guarantee.

4. Integration time and rate. A 200 Hz stream cannot integrate as long as a 1 Hz single shot. The same optics produce quite different ranges depending on how long they look. This is why the fastest modules and the longest-range modules are usually not the same product.

What to do about it

Ask for the condition behind every range figure. In the dataset I keep, each row carries the manufacturer's own sentence — target size, reflectance, visibility — verbatim, because paraphrasing it destroys the only comparable part of the number:

"Measuring range 12 km for target 5 × 15 m, reflectivity 0.3, visibility 23 km"

That is a completely different claim from "12 km", and the only form in which the number means anything. Two modules quoting the same headline range can differ by 3–4× in practice, simply because one condition says large vehicle at 23 km visibility and the other says small drone in haze.

A 20-minute test that settles it

You do not need a lab. You need to record the four numbers above, then take a few hundred shots at each distance:

Put the target at a measured distance; note material and size.
Note the light: direct sun, shade, or dark. Measure illuminance if you can.
Note the weather and roughly the visibility.
Take at least 100 shots per distance; record the median and the spread, and count the misses.
Report the distance at which you start losing returns. That is the honest range; everything before it is a nice-to-have.

The misses matter more than the hits: the failure boundary decides whether the product works on a bad day. If you want the full field list, I published a range test report template with the twelve fields that make a result checkable by someone else.

Two things to check before committing

Interface documentation. Framing, endianness and checksum coverage are where integrations die, and none of it is in a brochure. There is a protocol checklist of the twelve items a protocol document must state.
Update rate vs accuracy. A fast stream with centimetre resolution is a good control input and a poor measuring instrument. Decide which one you are building before comparing parts.

The dataset

If it is useful: specs.erdilrf.com/data — 59 modules, 905 / 940 / 1535 nm, with the manufacturer's range condition attached to every row, plus interface, optics and selection-by-application tables. JSON and CSV, CC BY 4.0, no signup.

If a row is wrong, tell me and it gets fixed. An errata is cheaper than a design review built on a bad number.

What a laser rangefinder module actually costs: 59 published prices

Tommy Yu — Thu, 22 Oct 2026 03:59:53 +0000

What a laser rangefinder module actually costs: 59 published prices

Every laser rangefinder supplier answers a price question with a form. We published the unit price for
all 59 modules in our catalogue instead — $70 to $5,000, on the model page, before anyone asks for
an email address.

This post is the engineering reading of that price list: what the money buys, where the discontinuities
are, and how to compare a quote that arrives with a much lower number than the one you budgeted.

Nothing below is a quotation. These are catalogue values, captured from the datasheet each model ships
with, and they are the same numbers a buyer can check on any model page.

1. The price bands, and what changes as you climb

Band	Representative models	What you are buying
Under $100	ER100 $70 · LR1000E2 / LR1000E4 $80 · LRF10VB $80 · LR1200E2 / E4 $90 · LRF1200A1 $90 · LRF22VB $90 · SPD1200N3 $94.5	Short-range DToF, 1 km UART modules, first integration
$100 – $200	LR1000D23 $110 · LR2000E2 / E4 $120 · LR1200D23 $130 · LR1500D23 $140 · LRF50VB $140 · LRF50H $160 · LRF3000A1 $200 · SPD1200ZG $200	1–2 km ranging, 50 m industrial sensing, 3 km long range
$200 – $400	ER400 $230 · LRF100H $230 · LRF200H $250 · LRF300H $280 · LRF0105C / 0305C / 0306C / 0310C $300 · LRF600H $350 · LRF1500H $400	200–600 m industrial, entry into 1535 nm
$800 and up	LRF0609C / 0610C $800 · LRF0815C / 0818C $900 · ER800 $1,050 · LRF0816C $1,200 · LRF1017C $1,300 · ER2000 $1,500 · ER8000 $3,000 · LRF1525C $3,000 · LRF1830C $3,500 · ER10000 $5,000	Multi-kilometre eye-safe ranging, 1.54 µm sources

Two things are visible in that table that a per-unit quote never shows you.

The 905 nm line is not uniformly cheaper. A 3 km 905 nm module sits at $200; the cheapest long-range
1535 nm module starts at $300. The cheap end of the spectrum is short range, not short wavelength.

The step function is at the detector, not at the range. Between $300 and $900 you are no longer
paying for metres. You are paying for indium gallium arsenide instead of silicon, and for an
erbium-doped source instead of a diode stack.

2. Why 1535 nm costs 4× for the same aperture

At 905 nm the light focuses on the retina. That caps the energy you may emit per pulse, and the cap
caps your range: hundreds of metres to about three kilometres in a small aperture.

At 1535 nm the water in the cornea and lens absorbs the light before it reaches the retina. The permitted
energy is far higher, so the same aperture reaches 8, 12, 18 km — and the returns that come with it:

an InGaAs detector instead of silicon,
a 1.54 µm source,
a thermal path that is no longer optional at high pulse energy.

That is the whole $300 → $900+ jump. There is no version of this where the longer-range module is cheap.

The comparison I would actually put in a design review:

Question	905 nm	1535 nm / 1.54 µm
Entry price	From $80	From $300
Range in a small aperture	Hundreds of m to ~3 km	Kilometres to 18 km
Detector	Silicon	InGaAs
Eye-safety budget	Tight	Far larger
Visible to a silicon camera at night	Faintly	Effectively no

If your requirement is under a few hundred metres, 905 nm is not the budget option — it is the correct
option. People over-specify wavelength for the same reason they over-specify range: the datasheet's
largest number is the easiest thing to compare and the least informative.

3. The two numbers per model that decide the outcome

Every module publishes two range figures: one at 90 % target reflectivity, one at 10 %. The gap
is often 3×.

A warehouse floor is not a white wall. Neither is wet asphalt, dark rubber, black shrink-wrap, or a
person in a dark jacket. On those surfaces the module behaves like the second number, and the first
number was never a lie — it just described a laboratory target.

The second trap is the minimum range. It is stated, and it is frequently ignored:

0.05 m floor on the H and VB series (useful for landing, close obstacle guard, precision docking),
3 m on SPD1200N3,
tens of metres on some long-range models.

Two suppliers can both quote "1,200 m" while one cannot measure anything closer than 15 m.

4. Four checks before you compare two quotes

The condition behind the range figure. Target size, reflectance, visibility, and whether the number is a maximum or a repeatable value.
The interface. UART-TTL, RS232, RS485, I²C — and the frame format with its checksum, not just "serial output".
The minimum range. See above.
What is in the box. Bare module, module with cable, module with housing, module with an acceptance report. This is where two quotes 30 % apart usually differ.

5. What volume changes

Published prices are single-unit values. Volume pricing is quoted per order and depends on the model,
the test coverage and the delivery schedule. Concretely:

Unit price changes with volume.
Acceptance documentation changes with volume, and for an integrator it is usually worth more than a few percent off the unit price — a batch that ships with a test record against the datasheet's own conditions removes a qualification step from your project.
Mechanical and firmware variants (connector, cable length, mounting, baud rate, output frame) are engineering changes, not discounts, and they cost lead time.
The specification does not change. A module specified against a 2.3 × 2.3 m target at 30 % reflectance is specified to that at any quantity.

6. Why publish this at all

Because a hidden price is a decision made for you. If the number is public, an engineer can tell in
thirty seconds whether a supplier is in the budget or three times over it, and spend the meeting on the
questions that actually decide the design: minimum range, beam divergence, thermal path, protocol.

All 59 model pages carry their own price, the measuring condition behind the range, and the interface:

Catalogue and model selector: https://erdilrf.com/models/
Price bands in one page: https://erdilrf.com/laser-rangefinder-module-wholesale/
The 1535 nm / 1.54 µm line: https://erdilrf.com/1535nm-laser-rangefinder-module/
Open drivers (Python, Arduino, ROS 2) and the verified UART protocol: https://github.com/erdilrf

If a quotation you received is materially below the figures above for the same specification, the
useful question is not who is cheaper. It is what condition that number was measured under.

Prices are captured catalogue values, not quotations, and can be revised as the catalogue changes.
A written quotation governs an order. Where two source documents conflict on a value — for example on
LRF1200A1, LRF3000A1, LRF50VB or LRF1500H — the model page states the conflict instead of choosing one,
and the current datasheet governs the order.

What a 905 nm rangefinder datasheet does not tell you

Tommy Yu — Thu, 08 Oct 2026 06:24:42 +0000

What a 905 nm rangefinder datasheet does not tell you

Four gaps I found while verifying the UART protocol of an LR1000E2-class 905 nm laser rangefinder
module — and how to work around each one.

This is not a complaint about the manual. It is what the manual says, what it deliberately leaves
out, and what that costs you at bring-up. Every claim below is reproducible from the published
document, which is cited at the end so you can check me.

0. Context: the frame format is 8 bytes, and the checksum is direction-dependent

offset   0     1     2      3    4    5     6      7
        0x55  0xAA  FUNC   D1   D2   D3    D4     SUM

host  -> module   SUM = (FUNC + D1 + D2 + D3 + D4) & 0xFF
module -> host    SUM = (0x55 + 0xAA + FUNC + D1 + D2 + D3 + D4) & 0xFF

Two different ranges. The manual states this in its own notes, and it is the single most common way
an integration stalls: if you build one checksum helper and use it for both directions, every
transmitted frame you validate looks corrupt, or every received frame does. You get a link that
appears dead while the bytes on the wire are perfectly fine.

A worked example with the ranging response 55 AA 88 01 FF 27 10 (1000.0 m):

bytes:  0x55 0xAA 0x88 0x01 0xFF 0x27 0x10   ->  85+170+136+1+255+39+16 = 702 = 0x2BE

response rule  SUM[1:7] = 0x2BE & 0xFF              = 0xBE   <- correct
command  rule  SUM[3:7] = 136+1+255+39+16 = 0x1BF & 0xFF = 0xBF   <- wrong, silently rejects

Verify it yourself before trusting me:

erdilrf decode "55 AA 88 01 FF 27 10 BE"
# checksum : 0xBE  (recomputed 0xBE) OK
# STA      : 0x01  measurement successful
# detail   : 1000.0 m

Distance decoding is ((DIS_H << 8) | DIS_L) / 10 — the register holds tenths of a metre, so the
16-bit field tops out at 6553.5 m and 1000 m arrives as 0x2710.

Now the four gaps.

Gap 1 — One response frame is printed incomplete, and it is the one that controls the laser

The manual documents the LD constant-on command, including both complete transmit frames:

55 AA 86 FF FF FF 01 84     enable LD constant-on
55 AA 86 FF FF FF 00 83     disable

The response row prints only:

That is one byte of an eight-byte frame. The remaining seven bytes are not in the published
document, as far as I can determine.

Why this matters more than it looks. LD constant-on is the command that turns the laser diode on
continuously. It is the one command where a failed write has a physical consequence rather than just
a wrong number — and it is the only command in the manual whose acknowledgment you cannot parse.

What to do. Do not invent the missing bytes. Send it fire-and-forget, and confirm the result
observably, not by reading a reply:

Issue the enable frame and do not block waiting for a well-formed acknowledgment.
Confirm from the physical side — the module draws measurably more current, and the emitter is live.
Prefer singleShot() / continuous for anything automated. Turn LD constant-on on only for alignment work, and turn it off when you are done. The manufacturer warns against leaving it enabled for extended periods, which is consistent with it being a service mode rather than an operating mode.

Gap 2 — Parity and stop bits are unstated

The manual gives you two of the four serial parameters:

Parameter	Documented?	Value
Baud rate	✅ yes	115200 default, plus nine selectable rates
Data bits	✅ yes	8
Frame length	✅ yes	8 bytes, fixed
Parity	❌ not stated	—
Stop bits	❌ not stated	—

Why this matters. Wrong parity does not produce garbled data — it produces silence. The UART
never frames a valid byte, so you see nothing at all. That symptom is indistinguishable from a
wiring fault, a dead module, or a power problem, and it sends people hunting through hardware when
the actual fix is one configuration byte.

How to narrow it down without a scope. Parity errors are not probabilistic; they are total. So:

Complete silence + correct TXD/RXD crossover + confirmed power → try 8E1, then 8O1. A parity mismatch is the single best explanation for absolutely nothing on the wire.
Occasional valid frames among garbage → parity is probably fine; suspect grounding or a noisy supply instead.
Frames arrive but the checksum fails → the link is fine. You are almost certainly validating with the wrong rule (see section 0).

erdilrf measure --port COM3 --parity E --count 1
erdilrf measure --port COM3 --parity O --count 1

The driver defaults to 8N1 because that is the near-universal default, and labels it an assumption in
PROTOCOL.md rather than a fact. An assumption that announces itself is worth more than a guess that
does not.

Gap 3 — TXD and RXD are named from the module's point of view

The pinout is documented clearly:

Pin	Signal	Description as printed
1	GND	power supply negative
2	VCC	power supply positive
3	I/O	reserved for expansion
4	TXD	transmit data: module → host
5	RXD	receive data: host → module
6	SW-SHOT	function enable

Those parenthetical directions are the whole story, and they are easy to read past. TXD on the
module means the module transmits — so it must land on your RX. A straight-through TXD-to-TXD
cable is the most common cause of a silent link, and it looks correct on a schematic.

What the manual does not give you: there is no mapping from pin number to cable colour.
Forum posts supply colour mappings confidently and inconsistently. Buzz the cable out with a
multimeter and write the mapping on the connector. This is five minutes against an afternoon.

Gap 4 — The enable pin's polarity is configuration-dependent

Pin 6, SW-SHOT, is described as:

Function enable (active high)

and, in the same table cell:

Compatible with active-low control requirements

Both statements are true, and together they mean the polarity you receive is decided by the
factory configuration, not by the datasheet. The manual does not tell you which unit you have.

What to do. Do not design around an assumed polarity. Tie pin 6 to the level that makes your
actual unit measure, confirm it against the power-on self-test frame, and record the finding in
your own BOM notes. If you are building a product around this module, get the polarity confirmed in
writing with your order.

Also worth knowing: the module emits a power-on self-test frame once, at power-on —
55 AA 80 STA 00 00 ErrCode SUM. STA = 0x01 means initialisation succeeded; STA = 0x00 means it
failed and ErrCode carries the reason. It is free diagnostics, and it is only available if you read
the port before sending anything else. Miss it and you have to power-cycle.

The general lesson, which is not specific to this module

Every one of these four gaps is invisible in a specification table and expensive at bring-up. Three
of them (parity, wire colours, enable polarity) fail as silence, and silence has a dozen possible
causes. Only one of them (the checksum split) fails as garbage, which at least points at the
protocol.

So when a link is dead, order your diagnosis by what the symptom can distinguish, not by what is
easiest to check:

Symptom	Most likely cause	Next
Nothing at all	parity unstated (gap 2), TXD/RXD crossed (gap 3), enable pin (gap 4)	try `8E1`, swap TX/RX, toggle pin 6
Frames, checksum fails	wrong checksum range (section 0)	use the response rule for received bytes
Intermittent bad shots	supply sag, shared ground with motors	≥ 100 µF bulk at the module; separate returns
Works, then resets	inrush current vs. undersized regulator	module draws < 350 mA inrush

Where this came from

The protocol in this article is implemented, tested and published here:

github.com/erdilrf/erdilrf-drivers

protocol/PROTOCOL.md — every documented command, both checksum ranges, STA semantics per command
protocol/verification.md — the checksum arithmetic re-derived independently. All six transmit frames printed in the manual reproduce byte for byte, and that file also records an arithmetic slip I made and corrected rather than quietly fixing
python/ — zero-dependency host driver, 50 tests, no hardware required
arduino/ — header-only C++ driver, compile-verified on AVR (uno + nanoatmega328, zero warnings from the driver under -Wall -Wextra; arduino-build/ reproduces the build with pio run). Behaviour on real hardware is still unverified — no board, no module, and nothing above claims otherwise

Primary source: LR1000E2 User Manual v1.2, 2025.10, ERDI TECH LTD, section 8
(SHA-256 ab396d61a08d1d4d3e89ced7f77156096250697dc296d6fefffce16b010701a9).

If your module disagrees with anything above, open an issue with the raw bytes. A capture from real
hardware outranks this article.

Scope note: this covers a civilian industrial optical distance-measurement sensor module
(IEC 60825-1 Class 1, 905 ± 5 nm). The manufacturer restricts the product to civilian applications
and excludes defence use.

A note on how this was written

This article was drafted by an AI agent working on the ERDI 905 nm rangefinder module line,
then checked line by line against the manufacturer's manual. That is stated here rather than
buried, because you should know what you are reading.

The verification is the point, and you do not have to take any of it on trust:

every transmit frame in the table is reproducible from the stated checksum rule, and the arithmetic is written out in protocol/verification.md
the 50-test suite runs with no serial port and no hardware attached
the Arduino driver is compile-verified on ATmega328P (16-bit int, 2 KB RAM) with -Wall -Wextra and zero warnings from the driver itself
where the primary source is silent — parity, wire colours, the enable pin — the article says unknown instead of filling the gap with something plausible

Article history: an earlier revision of this piece listed the Arduino driver as not compiled,
because the machine that wrote it had no C++ toolchain. That limitation has since been closed — the
driver now builds for uno and nanoatmega328, and arduino-build/ in the repository reproduces
it. The line is updated rather than deleted, so you can see what changed. Behaviour on real
hardware remains unverified, which is still the more important caveat.

Using it from Arduino

If you want this on a microcontroller rather than a host PC, the same protocol is implemented as a
header-only Arduino library with no dependencies beyond Stream:

Arduino IDE — Tools → Manage Libraries… and search ERDILRF_LRF
PlatformIO — lib_deps = erdilrf/ERDILRF_LRF

Both are verified by actually resolving and installing: PlatformIO reports
ERDILRF_LRF@0.2.2 has been installed!, and the driver compiles for AVR (ATmega328P, 16-bit int,
2 KB RAM, no FPU) under -Wall -Wextra with no warnings of its own. The example sketch compiles too,
including SoftwareSerial on an Uno.

Source, the PlatformIO build used for that verification, and the example sketch:
erdilrf/erdilrf-lrf-arduino

It carries the same caveat as everything above: compile-verified, not verified on real hardware.

If a claim here does not hold up against your module, open an issue on the repository. A capture
from real hardware outranks this article, and that is not a formality — it is how the protocol
reference is intended to improve.