Skip to content

MAX31865

Introduced in: rtd-acquire 0.1.0a1

The MAX31865 is the first concrete acquisition driver in rtd-acquire. The driver is platform-independent: it talks to a SpiDevice rather than containing Raspberry-Pi-specific code.

Configuration

from rtd_acquire.max31865 import MAX31865Config

config = MAX31865Config(
    reference_resistance_ohms=430.0,
    wire_count=3,
    filter_frequency_hz=60,
)

The configuration represents electrical facts needed by the acquisition path:

  • the actual reference resistance;
  • the physical 2-, 3-, or 4-wire RTD connection;
  • 50 or 60 Hz filter selection; and
  • optional low/high resistance fault thresholds.

It deliberately does not contain Pt100, Pt1000, nominal R0, or a temperature range. Those are RTD-model concepts, not MAX31865 acquisition configuration.

Use your board's actual reference resistor

430.0 is an example, not a universal default. Configure the value used by the physical acquisition circuit.

Reading

from rtd_acquire.max31865 import MAX31865

converter = MAX31865(spi, config)
measurement = converter.read()

A read performs the driver's fault-checked one-shot sequence and returns the normalized Measurement result.

SPI requirements

The driver validates the effective SPI connection. The MAX31865 path requires:

  • clock phase 1;
  • no more than 5 MHz;
  • MSB-first transfers;
  • 8-bit words; and
  • active-low chip select.

Timing

MAX31865Timing exposes the input-filter time constant used to calculate required settling delays. The default is 1 ms; hardware with a larger external RC time constant should supply the actual value.

Portable C implementation

Introduced in: rtd-acquire 0.2.0

The portable C implementation supports the same electrical configuration and threshold-register encoding rules as Python, decodes native RTD/fault registers into the shared caller-owned C result contract, and performs the fault-checked one-shot sequence through portable SPI and blocking-delay HALs. Public C MAX31865 operations use a discriminated result enum so caller/configuration/storage failures remain distinct from SPI and delay execution failures. Both current MAX31865 conformance-vector families run against Python and C. The portable C MAX31865 driver is complete for the 0.2 software scope.

High-scale conformance coverage introduced in: rtd-acquire 0.3.0

The shared measurement-decode and threshold-encoding vectors also cover a representative 4.3 kΩ reference network. This exercises the existing driver and portable C implementation near the Pt1000 upper resistance envelope and across its low/high envelope thresholds without adding RTD-model logic to the driver. Electrical-compatibility classification and physical validation remain separate 0.3 work.

Compatibility classification introduced in: rtd-acquire 0.3.0

The first compatibility record set now classifies conservative 4-wire reference-network configurations for all six current rtd-sensor parity families. Pt100, Pt500, and Pt1000 have explicit manufacturer-support evidence; Ni120, Ni1000 6180, and Ni1000 TK5000 are electrically compatible under the assessed reference networks but retain not_established manufacturer-support states because the datasheet does not explicitly name those nickel families. All six records remain physically not_validated. See the Compatibility matrix for the public status view and Compatibility data for the versioned machine-readable evidence.

Arduino AVR / HERO adapter introduced in: rtd-acquire 0.2.0

The first embedded adapter now supplies the driver's SPI and delay HALs on the Arduino AVR / UNO-class core used by the inventr.io HERO. CI compiles the example for arduino:avr:uno; physical cross-platform hardware validation remains pending after the 0.2.0 software release.

See the Portable C MAX31865 API and Arduino AVR / HERO adapter API.

Validation status

The Python and portable C software paths, emulator/host tests, and shared conformance vectors are implemented through 0.2.0. Formal physical Raspberry Pi/MAX31865 and HERO/MAX31865 validation remains pending; see Hardware validation.