DEV Community: Marius Gjerd

What 4-20mA actually means (and why your zero is at 4)

Marius Gjerd — Sun, 26 Jul 2026 10:00:18 +0000

The temperature in your database was, at some point, a current in a wire. Not as a metaphor. Actual milliamps through copper. Almost everything your code knows about a physical process traveled as an electrical current through a cable before it became a number, and the rules for that journey were written in the 1950s.

The standard is called 4-20mA. It is old, it is analog, and it still carries most of the world’s industrial sensor data. I have pulled the cables for it as an electrician and consumed the numbers from it as a developer, and the two jobs taught me very different things about the same signal. This post is what I wish the developer side knew.

Words in this post, in plain language

Transmitter: the measurement converter mounted on or near the sensor. It turns the sensor’s raw signal (the resistance of a PT100, for example) into a standardized 4-20 mA current.
PLC (programmable logic controller): the industrial computer that runs the control logic of a plant. It reads inputs, executes its program and sets outputs, over and over, in real time. In this post we care about its analog inputs.
Span: the measuring range the transmitter is configured with, meaning which physical values 4 and 20 mA correspond to. For example 0-200°C.
Frequency drive: power electronics that control the speed of a motor by varying the frequency and voltage it is fed. Found on everything from fans to pumps, and it returns in the noise section below.

Why your zero is at 4

A 4-20mA sensor maps its measuring range onto a current. 4 mA means the bottom of the range, 20 mA means the top. If the sensor measures 0-200°C, then 4 mA is 0 degrees and 20 mA is 200 degrees. Whatever sits between is your value, scaled linearly.

The first question everyone asks: why does zero sit at 4 and not at 0? The answer is the smartest part of the whole standard. 0 mA is reserved for failure. A healthy loop always carries at least 4 mA, so if the current drops to zero, something is wrong. Broken wire, dead transmitter, loop lost its power. The fault detection is built into the physics itself, which means a dead sensor cannot pretend to be a cold pipe.

There is a convention that makes this precise, NAMUR NE43. Normal measurement information lives between 3.8 and 20.5 mA. Anything below 3.6 mA or above 21.0 mA is a failure signal. Transmitters are configured to drive the current high or low when the sensor itself fails (this is called burnout direction), and your code needs to know which way your transmitters are set. A sensor failing upwards looks exactly like a process that is overheating, if you insist on treating it as a measurement.

So read the sensor documentation and know what to expect. A value below 3.6 mA is not a very cold pipe. It is a broken wire telling you about itself, in the only language it has.

.lbl { font-family: ui-sans-serif, system-ui, sans-serif; font-size: 13px; fill: var(--content, #333); } .sub { font-family: ui-sans-serif, system-ui, sans-serif; font-size: 12px; fill: var(--secondary, #666); } .leg { font-family: ui-sans-serif, system-ui, sans-serif; font-size: 11px; fill: var(--content, #333); } .fault-lbl { font-family: ui-sans-serif, system-ui, sans-serif; font-size: 12px; font-weight: 600; fill: #d64545; } .sig-lbl { font-family: ui-sans-serif, system-ui, sans-serif; font-size: 13px; font-weight: 600; fill: #ffffff; } .tick { stroke: var(--secondary, #666); stroke-width: 1; } .map { stroke: var(--border, #bbb); stroke-width: 1; stroke-dasharray: 4 4; }

measurement range
fault: fail low
fault: fail high

0 mA

3.6

4

12

20

21

0 °C
100 °C
200 °C
what your code sees, after the span (here 0-200 °C) is applied

measurement range (4-20 mA)

NE43 margin (3.8-4/20-20.5)

dead band (3.6-3.8/20.5-21)

fault (<3.6/>21)

The whole scale in one picture: fault zones outside 3.6 and 21 mA, the NE43 margins in faint blue, dead bands in gray between them, and the linear mapping to engineering units underneath.

Why current and not voltage

Two reasons. First, current is the same everywhere in the loop. A voltage signal drops along the cable, and the longer the cable, the more you lose. Current does not have that problem. The loop can run through half a building and the milliamps arriving at the panel are the milliamps the transmitter set.

Second, a current loop shrugs off electrical noise far better than a voltage signal does. Industrial buildings are electrically loud places. More on that below, because I have a story.

The wiring itself is almost elegant. A typical loop is just two wires, and those same two wires carry both the power supply (usually 24 VDC) and the signal. The transmitter sits in the loop and regulates how much current it lets through. On the receiving end, the analog input card often just measures the current across a 250 ohm resistor, which turns 4-20 mA into 1-5 V that the card can read. Two wires, hundreds of meters, powered and talking at the same time.

.wire { stroke: var(--content, #333); stroke-width: 2; fill: none; } .box { fill: var(--entry, #f6f6f6); stroke: var(--content, #333); stroke-width: 1.5; } .lbl { font-family: ui-sans-serif, system-ui, sans-serif; font-size: 14px; fill: var(--content, #333); } .sub { font-family: ui-sans-serif, system-ui, sans-serif; font-size: 12px; fill: var(--secondary, #666); } .pol { font-family: ui-sans-serif, system-ui, sans-serif; font-size: 13px; font-weight: 700; fill: var(--content, #333); } .sig { font-family: ui-sans-serif, system-ui, sans-serif; font-size: 13px; font-weight: 600; fill: #2f6fdd; } .term { fill: var(--content, #333); } .arrow { fill: #2f6fdd; }

transmitter
+ sensor (2-wire)

+

−

24 VDC
power supply

+

−

PLC analog input
250 Ω → 1-5 V

AI+

AI−

4-20 mA

return

cable: 2 x 0.75 mm² shielded twisted pair, shield grounded at one end
series loop: the same 4-20 mA flows through every component

One loop, three components in series. The transmitter regulates the current, and the same milliamps flow through every point in the loop.

From current to a number

The current becomes a number through the transmitter’s span. The span is the configured measuring range, and the transmitter maps it onto 4-20 mA linearly. With a span of 0-200°C, 12 mA means 100 degrees. Simple.

Here is the danger: the span lives in the transmitter, not in your code. If someone reconfigures the range to 0-150°C and does not tell anyone downstream, every value in your pipeline is scaled wrong from that moment on. Silently. The numbers still look plausible, no error, no gap, just a temperature that is no longer the temperature. If a measurement setup changes, the configuration and the documentation have to move together, because the person consuming the data three systems away has no other way to know.

.lbl { font-family: ui-sans-serif, system-ui, sans-serif; font-size: 13px; fill: var(--content, #333); } .sub { font-family: ui-sans-serif, system-ui, sans-serif; font-size: 12px; fill: var(--secondary, #666); } .ok { font-family: ui-sans-serif, system-ui, sans-serif; font-size: 14px; font-weight: 700; fill: #2f6fdd; } .bad { font-family: ui-sans-serif, system-ui, sans-serif; font-size: 14px; font-weight: 700; fill: #d64545; } .track { fill: var(--border, #d8d8d8); opacity: 0.55; } .dash { stroke: var(--content, #333); stroke-width: 1.5; stroke-dasharray: 5 4; }

the same 12 mA

span in the transmitter: 0-150 °C

= 75 °C, what it sends
4 mA = 0 °C
20 mA = 150 °C

span your code assumes: 0-200 °C

= 100 °C, what you compute
4 mA = 0 °C
20 mA = 200 °C

same current, two different temperatures. The transmitter always wins, silently.

The span problem in one picture. The current is correct, the assumption is not, and nothing in the data tells you.

(Some loops also run HART, a digital signal on top of the same 4-20 mA wires, which can carry diagnostics and configuration. Worth knowing it exists.)

One honest note about the last step. Inside the PLC, the analog card converts the current into raw integer counts, and software scales those counts into engineering units. I have seen those raw counts in systems I integrate against, and I have learned not to assume I know which scaling sits behind a value. The converter layer itself is a part of the chain I have not worked hands-on with yet. I start my industrial automation degree this fall and that layer is high on my list. When I have measured it myself, it gets its own post.

Noise, or the days we spent chasing ghost data

From my electrician years. We were on a project in a large building, pulling cables from a huge number of sensors to local nodes, and from the nodes into a main panel where all the building’s sensor data came together. Lots of cable, lots of runs, everything landed and terminated. Our part was done.

Then the automation guys started commissioning, and the data was garbage. Not dead, which would have been easier, but wrong and weird and jumpy. They spent days troubleshooting before someone found it: the sensor cables were unshielded, and long stretches of them were lying on the same cable ladder as high voltage power cables. The power lines were inducing noise straight into the signal wires, and every reading arriving in that panel had a little bit of the building’s electrical activity mixed into it.

This is what electrical noise looks like from the data side: values that vibrate a few counts around the real reading, and sudden jumps that look like process changes but are actually a motor starting somewhere. Frequency drives are notorious for this. Shielding helps, grounding the shield correctly matters (grounding it at both ends can create its own problem, a ground loop), and physical distance from power cables is the cheapest fix of all. None of which your code can see. It just sees a temperature that trembles.

.lbl { font-family: ui-sans-serif, system-ui, sans-serif; font-size: 13px; fill: var(--content, #333); } .sub { font-family: ui-sans-serif, system-ui, sans-serif; font-size: 12px; fill: var(--secondary, #666); } .noise-lbl { font-family: ui-sans-serif, system-ui, sans-serif; font-size: 12px; font-weight: 600; fill: #d64545; } .ladder { stroke: var(--border, #bbb); stroke-width: 2; } .power { stroke: var(--content, #333); stroke-width: 9; stroke-linecap: round; } .signal { stroke: #2f6fdd; stroke-width: 2.5; fill: none; } .noise { stroke: #d64545; stroke-width: 1.8; fill: none; }

power cable (motors, frequency drives)

unshielded 4-20 mA signal pair, same ladder

induced noise

what the transmitter sent

what the PLC read

The project in one drawing: unshielded signal cable on the same ladder as power cables. The transmitter sends a clean signal, the PLC reads a trembling one.

What your code should assume

The practical takeaways, same spirit as the sensor data post:

Treat anything below 3.6 mA or above 21 mA as a fault, never as a measurement. Do not let fault currents sneak into averages and aggregates.
Know the burnout direction of your transmitters. A sensor that fails high should not page anyone about an overheating process.
Do not trust that the span in the documentation is the span in the transmitter. Verify when you can, and log loudly when values stop making physical sense.
Expect a few counts of noise. Alert thresholds tighter than the noise floor produce alerts about electricity, not about the process.
If you can, log the raw mA or counts alongside the scaled value. It is the only way to debug a scaling problem after the fact.

.box { fill: var(--entry, #f6f6f6); stroke: var(--content, #333); stroke-width: 1.5; } .fbox { fill: none; stroke: #d64545; stroke-width: 1.8; } .lbl { font-family: ui-sans-serif, system-ui, sans-serif; font-size: 13px; fill: var(--content, #333); } .sub { font-family: ui-sans-serif, system-ui, sans-serif; font-size: 11.5px; fill: var(--secondary, #666); } .yes { font-family: ui-sans-serif, system-ui, sans-serif; font-size: 12px; font-weight: 700; fill: #2f6fdd; } .no { font-family: ui-sans-serif, system-ui, sans-serif; font-size: 12px; font-weight: 700; fill: #d64545; } .fault { font-family: ui-sans-serif, system-ui, sans-serif; font-size: 13px; font-weight: 600; fill: #d64545; } .wire { stroke: var(--content, #333); stroke-width: 1.8; fill: none; } .head { fill: var(--content, #333); }

value arrives
mA or raw counts

inside 3.8-20.5 mA?
the zones from above

no

fault path
alarm it, keep it out of stats

yes

apply the span
validate range + rate

store scaled
+ raw value

The whole list as an ingestion flow: fault currents take the alarm path, everything else gets scaled, validated and stored with the raw value.

And the biggest one, the assumption behind all the others: assume that nobody has the full picture. The electrician who pulled the cable, the automation tech who commissioned the system, the project engineer sitting on the datasheets, and you, the developer consuming the number at the end. Every one of them knows their own layer. Nobody is checking yours against theirs unless you ask.

The current loop is honest. It is your assumptions about it that lie.

This post is step two in a chain. Step one, what happens to the value after it becomes a number, is here: Can you trust your sensor data?

Originally published at mariusgjerd.github.io, where I write about what happens when code touches the real world. New posts also go out by email: subscribe here.

Can you trust your sensor data? A developer's guide to the full stack

Marius Gjerd — Mon, 13 Jul 2026 20:30:19 +0000

Every data pipeline in industrial IoT starts the same way: something physical happens, a sensor detects it, and a number appears in your database.

The gap between “something physical happens” and “a number appears in your database” is where most data quality problems live. If you’ve only ever worked on the database side, that gap is invisible. This post is a map of it.

We’ll trace a single temperature reading from a heat exchanger through to a cloud application, step by step. At each stage I’ll show what the data looks like, what can go wrong, and what your code should account for.

Stage 1: The physical measurement

A PT100 resistance temperature detector is embedded in a pipe. Its resistance changes with temperature, predictably but not perfectly. Every PT100 has a tolerance class. Class B (the cheaper option) has an accuracy of ±0.3°C at 0°C, widening to ±1.3°C at 300°C.

Your sensor is already an approximation.

There’s also the installation to consider. Is the sensor mounted correctly in the flow? Is there air around it that might affect the reading? Has it been in service for 10 years without recalibration? Sensor drift, where a sensor’s output gradually deviates from the true value over time, is common and often undetected.

What to remember: The physical measurement has inherent uncertainty. Your data has error bars even before it leaves the sensor. ±1°C is normal. On an alert threshold of ±0.5°C, that matters.

Stage 2: Signal transmission (4-20mA)

The PT100’s resistance is converted to a 4-20mA current signal by a transmitter. This current travels over a cable to an input card in a PLC or remote I/O.

4-20mA is a very old standard and deliberately hard to break: it’s a current loop, so resistance in the cable doesn’t affect the reading, and a broken wire is detectable (0mA means fault, not zero). But it has limitations:

The 16mA range (4 to 20) maps to your full engineering range (say, 0-200°C). Your resolution is limited by how finely the analog-to-digital converter on the input card can divide that range.
Cable length and electromagnetic interference can introduce noise. A variable-frequency motor drive nearby can inject enough noise to make a reading jump by several counts.
The current-to-value conversion uses a calibrated span. If the transmitter is configured for 0-200°C but the range has changed to 0-150°C and nobody reconfigured it, every reading is scaled wrong.

What to remember: By the time the physical measurement has become a digital number in the PLC, it has already been scaled, quantised, and potentially affected by electrical noise.

Stage 3: The PLC scan cycle

The PLC reads its inputs, executes its logic, and updates its outputs, in a cycle that repeats every 10-100ms. When you request a value from the PLC, you get whatever was in memory from the last scan.

This introduces a latency of up to one scan cycle between the physical world and the PLC’s view of it. For slow processes (temperatures, pressures, levels) this is irrelevant. For fast events (a valve that opens for 20ms), you might miss it entirely.

The timestamp on a PLC value is usually the time it was read by the SCADA system, not the time the physical event occurred. These can differ by seconds depending on polling frequency.

What to remember: PLC values are samples, not a continuous stream. Events faster than the scan cycle are invisible. The timestamp is often “when we asked”, not “when it happened.”

Stage 4: SCADA / historian

The SCADA system polls the PLC and stores values in a historian, a time-series database built for industrial data. Historians use a technique called exception reporting or deadbanding: they only store a new value if the reading has changed by more than a configured threshold.

If your temperature is stable at 73.2°C, the historian might store that value once and then not again for an hour. This is efficient for storage, but it means:

Querying the historian for “the value at 14:32:17” returns the last recorded value before that time, which might be from 14:00. If you’re not aware of this, your trend looks flat because it is flat in the database, not necessarily flat in reality.
The threshold for “changed enough to store” is a configuration parameter. If someone set it to 5°C to save storage, you’ll never see small fluctuations.

What to remember: Historian data is not a complete record of what happened. It’s a compressed approximation. Flat lines in your data might mean “nothing changed” or “we stopped recording small changes.”

Stage 5: The cloud pipeline

The historian exports data to your cloud pipeline via an MQTT broker, OPC-UA server, or a bespoke API. Each of these adds its own considerations:

Buffering: If the connection drops, does the local system buffer unsent data? For how long? What happens at reconnect? Does it send a burst, or drop the gap?
Resampling: If your cloud pipeline expects data at 1-minute intervals but the historian sends on-change, you’ll need to resample. Forward-fill? Interpolate? The choice changes the data.
Time zones: Industrial systems often use local time. Your cloud pipeline probably expects UTC. If the historian is in Norway (CET/CEST), you have a seasonal 1-hour offset to handle.

What to remember: The cloud pipeline introduces its own latency, buffering behaviour, and resampling decisions. Each one is a transformation that should be explicit in your schema and documented.

Stage 6: Your application

By the time a temperature reading reaches your application, it has been:

Measured with inherent uncertainty (±1°C or more)
Transmitted as an analog signal and converted to digital
Sampled at the PLC scan cycle
Compressed by deadbanding in the historian
Transmitted over a network that may buffer or drop values
Resampled to fit your pipeline’s cadence

The number in your database is not “the temperature at that time.” It’s the best available approximation, given all of the above.

What to do about it

Document the uncertainty. Add metadata to your schema: sensor type, accuracy class, historian deadband, poll interval. Future you, or the developer debugging an anomaly at 2am, needs this.

Be conservative with alert thresholds. If your alert fires when temperature exceeds 95°C and your sensor accuracy is ±1.5°C at that range, your alert might be lying.

Don’t interpolate silently. If you resample sparse historian data, make it visible. A value filled from a reading that’s 30 minutes old is different from a value sampled 10 seconds ago.

Validate range and rate-of-change. A PT100 measuring a pipe temperature that jumps from 70°C to 500°C in one second is probably a sensor fault, not reality. Industrial processes have physical limits. Enforce them at ingestion.

Ask the operators. The people who run the plant know which sensors are reliable and which “always read a bit high.” That knowledge is rarely in the documentation.

The sensor data you’re working with is honest about what it is, if you know how to read it. The full stack is the context. Without it, you’re optimising code on top of uncertainty you haven’t accounted for.

Originally published at mariusgjerd.github.io, where I write about what happens when code touches the real world. New posts also go out by email: subscribe here.

Your uptime SLA means nothing when the physical process can't wait for your rollback

Marius Gjerd — Sun, 12 Jul 2026 20:52:59 +0000

There’s a conversation that happens when IT developers first encounter operational technology. It usually goes something like this:

“What’s your uptime requirement?”

“99.9%.”

“That’s about 8 hours of downtime per year. We can work with that.”

“No, 99.9% per shift. We run 24/7. And if the system goes down mid-batch, we lose the entire batch.”

The IT developer nods, makes a note, and quietly recalculates.

What uptime means in IT

In web services, uptime is a statistical measure. Your load balancer distributes traffic. A rolling deployment takes down one instance at a time. If a deploy goes wrong, you roll back. The user retries their request. Maybe they see an error page for a few seconds.

99.9% uptime means roughly 8.7 hours of downtime per year. For most web applications, that’s acceptable. For the unlucky users who hit those 8.7 hours, it’s annoying but not catastrophic.

The whole model assumes the system’s state is recoverable. A failed transaction gets retried. A dropped connection reconnects. Deployments are reversible.

What uptime means in OT

In industrial control systems, “the system” is not the software. It’s the physical process the software controls.

A water treatment plant doesn’t pause while you roll back a SCADA update. A cement kiln running at 1400°C doesn’t wait for your deployment pipeline. A paper machine running at 1000 meters per minute doesn’t retry when your historian goes offline.

The physical process continues whether the software is healthy or not. And if the software loses control of the process, even briefly, the consequences are measured in:

Batches scrapped
Equipment damaged by running outside safe parameters
Product out of spec that must be discarded
In the worst cases: fires, injuries, environmental incidents

Your 8.7 hours of acceptable downtime might span three production batches. That’s not an SLA problem. That’s a business continuity problem.

The rollback problem

Web developers treat rollbacks as a safety net. Something went wrong in production? Roll back to the last good version. Worst case, you lose a few minutes of data.

In industrial systems, rollback is often not an option mid-process.

If a PLC program update goes wrong mid-batch, you can’t simply restore the previous version and continue. The physical state of the process has changed. Temperatures, pressures, chemical compositions are now different from what the previous version expected. Restoring old software to a new physical state can be more dangerous than finishing the bad deploy.

This is why industrial systems have change management processes that look bureaucratic and slow to IT eyes: planned maintenance windows, tested rollback procedures, operator sign-offs. They’re not bureaucracy for its own sake. They’re built around the reality that the software controls something that doesn’t stop.

What to do about it

If you’re writing software that talks to industrial systems, a few things are worth internalising:

Graceful degradation looks different here. In web services, graceful degradation means showing a cached page or a friendly error. In OT, it means the control system continuing to operate safely in manual mode while your software is down. Design for that hand-off explicitly.

Test against the physical constraints, not just the software ones. What happens to your system when the network drops for 30 seconds? What does the PLC do? What does the operator see? What alarms trigger?

Understand the process before you touch it. The operators who run the plant know things about failure modes that aren’t in any documentation. Talk to them before you write a line of code.

The SLA number on the contract is the easy part. Understanding what it actually means for the thing being controlled is the hard part.

Originally published at mariusgjerd.github.io, where I write about what happens when code touches the real world. New posts also go out by email: subscribe here.

Why this blog exists

Marius Gjerd — Sun, 12 Jul 2026 20:49:06 +0000

Hi, I’m Marius Gjerd, a developer based in Bergen, Norway, working at the crossroads of code and physical infrastructure.

I started out as an electrician. Then I learned to write software, and for the past few years I’ve been building IoT solutions in the energy sector. This autumn I’m starting a three-year degree in Industrial Automation alongside my day job. It covers PLCs, instrumentation, industrial networks, and OT security.

That’s a deliberate move. The bridge between IT and OT, between the cloud-connected world of developers and the physical world of industrial control systems, is somewhere I find genuinely interesting, and a place where very few people are comfortable on both sides.

This blog is where I’ll write about what I learn along the way. Expect posts on:

The strange and useful corners where IT and OT meet
Industrial cybersecurity from a developer’s perspective
Hands-on experiments with PLCs, sensors, and home labs
Lessons from building IoT at scale in energy
Whatever else I find worth sharing as I work my way through the degree

I’ll write when I have something to say, not on a schedule. Some posts will be technical deep-dives; others will be shorter reflections. All of it will be in my own words, and the code behind the projects will be open source on my GitHub.

If any of this is interesting to you, stick around.

Originally published at mariusgjerd.github.io, where I write about what happens when code touches the real world. New posts also go out by email: subscribe here.