From the bench

MAX31820 Troubleshooting: Why Your 1-Wire Temperature Sensor Isn't Working

August 12, 2026 · AI-generated from the datasheet, fact-checked by two independent LLM critics

The most common MAX31820 failure looks like this: the device answers a reset with a presence pulse, the ROM reads back fine, and then every temperature conversion returns garbage or 85.0 °C forever. Nine times out of ten the root cause is power delivery, not the sensor — the part draws up to 1.5 mA during a conversion, which a weak 1-Wire pull-up simply cannot supply in parasite-power mode. This post works through that failure and the rest of the real-world problems in the order you'll hit them: what the part is, how to wire it, the traps to avoid, how to verify it on the bench, and how to diagnose the failures that still get through.

Next step
Start building with MAX31820 → This guide comes from the same grounded, cited datasheet answers — ask the assistant your own MAX31820 questions.

What the MAX31820 is (and what it's for)

The MAX31820 is a 1-Wire digital ambient temperature sensor in a 3-pin TO-92 package, measuring −55 °C to +125 °C with ±0.5 °C accuracy from +10 °C to +45 °C and ±2.0 °C over the full range. It communicates over a single data line (DQ) plus ground, carries a unique 64-bit ROM serial code for multidrop operation, and can be powered either from a local VDD pin or parasitically off the data line itself — no external supply components required. The datasheet positions it for HVAC environmental controls, thermostatic controls, temperature monitoring in buildings, equipment, and machinery, process monitoring, industrial systems, thermometers, and consumer products. The TO-92 form factor is a feature, not a leftover: the sensor sits above the board on its leads, so it reads system ambient temperature rather than PCB temperature the way a surface-mount part would. Long-term drift is ±0.2 °C, and resolution is configurable from 9 to 12 bits (0.5 °C down to 0.0625 °C LSB).

Wiring the MAX31820 correctly (How do I integrate the MAX31820 into a design?)

Most "broken" MAX31820 circuits were wired wrong from the start. Get these right and you eliminate the majority of failures before they happen.

Supply voltage: 3.0–3.7 V, full stop. All DC and AC specs are qualified at VDD = 3.0–3.7 V. Do not wire the part to a 5 V rail. Absolute maximum on any pin is −0.5 V to +6.0 V, so 5 V won't instantly destroy it — but behavior outside 3.0–3.7 V is unspecified, and unspecified is where intermittent bugs live. One datasheet quirk to be aware of: the Active Current spec row lists VDD = 5 V as its test condition. That's a characterization artifact, not permission to run at 5 V.

Pull-up resistor and pull-up supply. The datasheet's reference application circuit uses a 4.7 kΩ pull-up between the DQ bus and the pull-up supply, with DQ shared between the microprocessor and any other 1-Wire devices. The pull-up supply VPU must be 3.0–3.7 V in parasite-power mode, or anywhere from 3.0 V up to VDD in local-power mode — so a 5 V pull-up is out even if your sensor is locally powered at 3.3 V. The logic thresholds tell you why the value matters: VIL ≤ 0.8 V, VIH ≥ 2.2 V (local power) or ≥ 3.0 V (parasite power), and the device guarantees sinking at least 4.0 mA at VI/O = 0.4 V. Your pull-up must let the master pull DQ below 0.8 V and let the bus rise well above the relevant VIH when released. The 4.7 kΩ reference from 3.3 V does both with margin.

Decoupling on VDD. The reference circuit includes a decoupling capacitor between VDD and GND. The datasheet doesn't state a value.

Design practice (not a datasheet spec): a few hundred nF to ~1 µF ceramic placed close to the pin is standard practice and keeps a 3.6 V rail with a few hundred mV of ripple safely inside the 3.0–3.7 V window.

Strong pull-up (parasite mode only). If you use parasite power, the reference circuit adds a PMOS strong pull-up on the bus — source to VPU, drain to DQ, gate driven by the master — enabled during conversions and EEPROM writes. If you'd rather not build that, the simpler and more robust option is to give the device a real VDD. The datasheet explicitly calls local power the alternative, and it removes the entire class of strong-pull-up timing bugs described below.

Long or externally routed buses. The datasheet rates every pin at −0.5 V to +6.0 V absolute max.

Datasheet absence caveat: the datasheet does not publish an ESD-withstand level or a maximum bus length. For a bus that leaves the board, series resistance and a TVS on DQ are common practice, but they're design choices beyond what the datasheet guarantees.

What to watch out for (What are the MAX31820's gotchas?)

These are the behaviors that cause field failures even in correctly wired circuits.

The 1.5 mA spike vs. the weak pull-up. Standby current is tiny — 750 nA typ, 1000 nA max — but during a temperature conversion or a scratchpad-to-EEPROM copy, active current reaches 1.5 mA (1.0 mA typ). That's too much for the weak 1-Wire pull-up to supply in parasite mode, and more than the internal charge pump can source. The voltage on DQ sags, the device browns out mid-conversion, and you get failed or corrupted readings. This is the single most common MAX31820 implementation failure.

The 10 µs strong pull-up rule. In parasite mode, you must enable the strong pull-up within 10 µs (max) of issuing Convert T [44h] or Copy Scratchpad [48h], and hold it for the full conversion time or the full EEPROM write time (tWR is 2 ms typ, 10 ms max). No other bus activity is allowed while it's enabled. Ten microseconds after the last bit of the command leaves the bus is not a lot of firmware slack — if your master does anything between sending the command and asserting the MOSFET gate, you've already missed the window.

Conversion-complete polling doesn't work in parasite mode. On external power, you can issue read time slots after Convert T and the device returns 0 while converting, 1 when done. In parasite mode you cannot use that technique, because the bus is held high by the strong pull-up during the conversion — you must simply wait out tCONV. Firmware that assumes polling will misbehave in exactly one power topology, which makes this bug easy to miss on a bench that happens to be locally powered.

Conversion time scales with resolution. 9-bit ≈ 93.75 ms, 10-bit ≈ 187.5 ms, 11-bit ≈ 375 ms, 12-bit = 750 ms max. If your poll loop or strong-pull-up hold time is shorter than the configured resolution's maximum, you read stale or partial data. The power-up default is 12-bit (R1=1, R0=1), so a lost or corrupted config write silently changes both resolution and timing.

The device does no error checking for you. Scratchpad byte 8 is a CRC over bytes 7:0, and the ROM carries its own CRC — but the datasheet is explicit that there is no internal circuitry that stops a command sequence on a CRC mismatch. Error checking is entirely the bus master's job. Skip CRC validation and a marginal bus read silently becomes a bad temperature.

Alarm semantics lag by one conversion. The alarm flag updates only after every temperature conversion — if the over-temperature condition clears, the flag deasserts on the next conversion, not instantly. Comparison against TH/TL uses only bits 11:4 of the temperature register (TH/TL are 8-bit), so alarm granularity is coarser than your 12-bit reading. If you change TH/TL while an alarm exists, you must run another conversion to validate the new limits. And after every Alarm Search [ECh] cycle you must return to initialization (Step 1) before the next transaction — no other sensor forces this polling-loop shape.

Testing and verification (How do I verify my MAX31820 circuit works?)

There is no self-test or built-in diagnostic command — verification means exercising behaviors the datasheet defines and checking their defined results. This sequence isolates problems layer by layer.

  1. Confirm bus presence. Issue Search ROM or Read ROM and verify the unique 64-bit ROM code, including a valid ROM CRC. A corrupted ROM read here points at bus wiring or signal integrity before you ever touch temperature code.

  2. Verify the power topology with Read Power Supply. Issue Skip ROM [CCh] → Read Power Supply [B4h] → read time slot. Parasite-powered devices pull the bus low during the slot; externally powered devices let it stay high. This is a genuine, datasheet-defined probe that tells you whether your power design behaves as intended and whether the strong pull-up is required.

  3. Check the power-on-reset value. Before any conversion, the temperature register should read +85 °C — the datasheet-specified power-on-reset value. A clean +85 °C read proves the read path, register access, and sign handling all work before you trust a live measurement.

  4. Run a conversion and check completion semantics. Issue Convert T [44h]. On external power, poll read time slots (0 = converting, 1 = done). In parasite mode, hold the strong pull-up for the whole tCONV and then read. Budget 750 ms max for a 12-bit conversion.

  5. Validate the decode math. The result is a 16-bit sign-extended two's-complement value calibrated in °C (convert to °F in software). Check your scaling against the datasheet's worked 12-bit examples, and mask the undefined LSBs at reduced resolutions: 9-bit leaves bits 2:0 undefined, 10-bit leaves bits 1:0, 11-bit leaves bit 0. Verify the scratchpad CRC (byte 8 over bytes 7:0) on every read.

  6. Check accuracy against a calibrated reference. There's no internal way to test accuracy — compare readings against a known reference and hold them to ±0.5 °C from +10 °C to +45 °C and ±2.0 °C over −55 °C to +125 °C. Note there is no intermediate accuracy band and no published typical-error curve, so outside the comfort band ±2.0 °C is all the datasheet guarantees.

Datasheet absence caveat: the datasheet gives no self-heating magnitude. Place the sensor so its own dissipation and the board's heat don't skew an ambient reading — this is a placement judgment, not a calculation.

  1. Exercise alarms if you use them. Confirm the flag clears one conversion after the condition clears (not instantly), that your TH/TL math accounts for the bits 11:4 compare granularity, and that your loop re-initializes after every Alarm Search cycle.

Troubleshooting (Why is my MAX31820 circuit misbehaving?)

Work these symptoms in order — each points at a specific cause.

Device doesn't respond, or reads garbage at power-up. Measure the rail first: everything is qualified at VDD = 3.0–3.7 V. A drifted rail or a 5 V pull-up puts you in unspecified territory. Then check for DQ transients — absolute max on any pin is −0.5 V to +6.0 V, and an over-voltaged DQ may have damaged the part.

First read after power-up looks wrong. The power-on-reset value is +85 °C. If a fresh boot returns anything else, suspect the read path or the power-up itself. If you see +85 °C forever after conversions, the conversions aren't completing — move to the next symptom.

Temperature stuck or wrong after conversions. Check the resolution/config register: the power-up default is 12-bit, and a lost config write changes both resolution and conversion time. Then check your timing against the configured maximum: 750 ms at 12-bit, 375 ms at 11-bit, 187.5 ms at 10-bit, 93.75 ms at 9-bit. A poll loop shorter than the max reads stale or partial data.

Parasite-power design misses conversions or browns out. This is the classic failure. The 1.5 mA active-current spike exceeds what the weak pull-up can supply. Verify the strong pull-up engages within 10 µs of Convert T [44h] or Copy Scratchpad [48h] and holds for the full tCONV or the full 10 ms worst-case tWR. Also confirm your firmware isn't trying to poll for conversion completion — that only works on external power. If this keeps biting, switch to local VDD power; it removes the strong pull-up requirement entirely.

Intermittent wrong data on a real bus. You're probably skipping CRC validation. Byte 8 of the scratchpad is a read-only CRC over bytes 7:0, and the device will not flag or stop on a mismatch — a marginal bus read silently becomes a bad temperature unless the master checks it.

Alarm fires late or won't clear. Remember the flag only updates after a conversion, so allow one conversion of lag in both directions. Re-check that your thresholds account for the 8-bit (bits 11:4) compare granularity, and that you ran a conversion after changing TH/TL to validate the new limits.

Recommended diagnostic order: (1) confirm the rail is inside 3.0–3.7 V, (2) read the +85 °C power-on-reset value to prove the read path, (3) confirm conversion-time budget matches the configured resolution, (4) verify strong pull-up timing and hold for your power mode, and (5) CRC-check every scratchpad read.

Part page: MAX31820.