EZO-EC
Notice: This page is an original repo-authored summary informed by Atlas Scientific documentation. It is not an official Atlas Scientific manual.
Purpose
This page captures the repo-relevant behavior of the EZO conductivity family.
Product Summary
- default transport mode is UART
- default I2C address is
100(0x64) - typical one-shot read timing is about
600 ms - supports temperature compensation
- supports multi-point calibration
- supports configurable probe characteristics and output fields
Measurement Model
EC is the clearest example of why the repo should not pretend every EZO product returns one number.
The device can report multiple related values, including:
- conductivity
- total dissolved solids
- salinity
- specific gravity
When more than one field is enabled, vendor documentation defines a fixed output order. The current EC helper therefore parses an explicit CSV schema rather than calling ezo_parse_double() on the whole payload.
Shared Command Families Present
The EC family includes the common acquisition, calibration, identity, control, and protocol-switching families, plus calibration export and import.
Product-Specific Features
Probe Configuration
The EC product exposes probe K configuration. That configuration changes how the device should be interpreted in an application and belongs in the current typed helper layer.
Temperature Compensation
Temperature input directly affects readings and should be modeled as part of the product workflow, not as an afterthought.
TDS Conversion Factor
The device can change its TDS conversion factor. That is not a transport concern; it is product behavior with application-level impact.
Output Selection
The device can enable or disable its output fields independently. This changes the payload shape and is the strongest reason not to treat EC as a generic “read one value” device.
Vendor output-config replies also use an alternate query prefix shape: the documented response is ?,O,... rather than the more common ?Prefix,... form used by many other commands. The typed EC parser accepts that vendor-shaped response directly.
Calibration Procedure
Calibration Model
EC calibration is staged and order-sensitive:
- dry calibration must happen first
- dry plus one wet point gives a narrower-band calibration
- dry plus low and high wet points gives the broadest supported range
The command surface is:
Cal,dryCal,nCal,low,nCal,high,nCal,clearCal,?
Cal,? reports:
?CAL,0= not calibrated?CAL,1= dry plus one wet point?CAL,2= dry plus low and high wet points
Plan on about 600 ms for Cal,dry, Cal,n, Cal,low,n, and Cal,high,n, and about 300 ms for Cal,clear and Cal,?.
Before You Begin
- Perform the dry calibration first, even if the probe already reads
0.00in air. - Set the probe
Kvalue before calibration if you are not using the defaultK 1.0. - Leave temperature compensation at the default
25 Cduring calibration. - If the solution temperature is about
5 Cor more away from25 C, calibrate to the bottle-corrected conductivity value for that temperature instead of the nominal25 Cvalue. - Use fresh solution in a separate cup rather than in the bottle.
- Shake the probe gently to remove trapped air before each wet calibration point.
- If the probe reads
0.00in solution, stop and inspect the connection. The vendor guidance is explicit that you cannot calibrate EC to zero conductivity.
Recommended Point Sets
The vendor recommendation depends on the probe K value:
K 0.1: low84 uS, high1413 uSK 1.0: low12880 uS, high80000 uSK 10: low12880 uS, high150000 uS
You can use other certified values, but the maintained examples and the vendor guidance are built around the standard points above.
Step-By-Step Procedure
Step 1: Set Probe Type
If the hardware is not K 1.0, set the correct K value before calibrating. Calibration data is only meaningful relative to the configured probe type.
Step 2: Dry Calibration
- Keep the probe dry and in air.
- Issue
Cal,dry. - Treat this as mandatory even if the pre-calibration reading already looks like zero.
Step 3A: Narrower-Band Calibration
Use this when the operating range is narrow and well known:
- Complete
Cal,dry. - Place the probe in a known conductivity solution.
- Remove trapped air and wait until the reading stabilizes.
- Issue
Cal,nusing the conductivity value of that solution. - Confirm that the reading moves onto the target value.
Step 3B: Broad-Range Calibration
Use this when you need the broadest supported range:
- Complete
Cal,dry. - Place the probe in the low-point solution, remove trapped air, wait for stabilization, and issue
Cal,low,n. - Do not expect the reading to jump immediately after the low-point command; the vendor material explicitly shows this point as an internal anchor rather than an immediate visible correction.
- Rinse the probe.
- Place the probe in the high-point solution, remove trapped air, wait for stabilization, and issue
Cal,high,n. - Confirm that the reading now moves onto the high-point target.
What “Stabilized” Means
EC must not be calibrated on a moving value. The vendor guidance explicitly warns that blind calibration produces drifting post-calibration readings. Stabilized means the value has flattened and is no longer materially walking toward the final number.
Recalibration Expectations
The vendor position here is stronger than for most sensor types: a properly calibrated conductivity probe usually does not need routine recalibration. Recalibration is more likely after things that change the electrical characteristics of the system, such as changing cable length or moving the probe and circuit into a different machine or electrical environment.
Timing Notes
The current repo read fallback of 1000 ms is conservative for EC reads. Product-aware callers can usually wait less than that, but exact timing should still be treated as command-specific for calibration and control operations.
Code Implications
The current typed EC module owns:
- a typed output parser
- output-enable configuration
- probe
Kconfiguration - temperature-compensation helpers
- calibration query/set/clear helpers
The EC calibration-status query is vendor-quirky in current materials: examples use ?CAL,... uppercase. The parser accepts that documented form rather than assuming only ?Cal,....
That layer sits above the transport APIs rather than complicating src/ezo_i2c.* or src/ezo_uart.*.
Repo Entry Points
- Linux staged examples:
examples/linux/i2c/advanced/ec_calibration.candexamples/linux/uart/advanced/ec_calibration.c - Arduino staged example:
examples/arduino/i2c/advanced/ec_calibration/ec_calibration.ino - Cross-device compensation examples:
examples/linux/i2c/advanced/ec_temp_comp_from_rtd.c,examples/linux/uart/advanced/ec_temp_comp_from_rtd.c, and the matching Arduino I2C example - Calibration transfer helpers:
src/ezo_calibration_transfer.h