Why Your Flow Sensor Lies About Thick Oil (and How to Read the Right Meter with an ESP32)

TheTechLover — Sat, 07 Nov 2026 03:07:05 +0000

If you have built anything that measures liquid flow with a microcontroller, you have probably used one of those little hall-effect paddle-wheel sensors. You count pulses, divide by a number from the datasheet and get litres per minute. For water, it works nicely.

Then someone asks you to log gear oil going into a gearbox, hydraulic fluid in a test rig or glycerin in a mixing line. You wire up the same sensor, and the readings drift low, stall at low flow or stop altogether. Nothing is wrong with your code. The physics changed.

This post covers why viscosity breaks small turbine-style sensors, which kind of meter to use instead, and how to read it properly with an ESP32: interrupts, low-flow handling, temperature and a calibration you can trust.

Why thick fluids fool paddle wheels and turbines

A paddle-wheel or turbine sensor works because moving liquid pushes a rotor round, and the rotor speed follows the flow velocity. Its calibration constant, the K-factor in pulses per litre, assumes the fluid behaves like water: low viscosity, turbulent flow and very little drag on the blades.

Thick fluids break those assumptions in three ways:

Drag. A viscous fluid grips the rotor and its bearings, so the rotor turns slower than the flow suggests, especially at low flow rates. The sensor reads low.
Laminar flow. As viscosity rises, the Reynolds number falls and the flow turns laminar. The velocity profile changes from fairly flat to a parabola, so the blades see a different average velocity than they did during calibration, and the K-factor shifts.
Temperature. Oil viscosity changes dramatically with temperature. The same sensor can be close on a warm afternoon and several percent off on a cold morning.

Industrial turbine meters deal with this through calibration curves for different viscosities. A hobby sensor has one number on its datasheet, measured with water.

Use a meter that likes viscosity

For oils, syrups, resins and similar liquids, the usual answer is a positive displacement (PD) meter, most often the oval gear type. Two meshing oval gears trap a fixed volume of liquid on every turn and pass it through. Count the turns and you have counted the volume.

The main error source in a PD meter is slip: liquid leaking through the small clearances between the gears and the housing. The thicker the fluid, the less it slips, so accuracy often improves as viscosity rises. The trade-off is pressure drop, which also rises with viscosity, which is why manufacturers derate the maximum flow for very thick fluids. Coriolis meters are the other common choice when you need mass flow directly and the budget allows it.

When you choose hardware, a purpose-built high viscosity oil flow meter states its viscosity range, pressure drop and pulse output on the datasheet, and those are exactly the numbers your firmware needs.

What the meter gives your microcontroller

Most meters offer one or more of these outputs:

Pulses: a reed switch, a hall sensor or an open-collector (NPN) transistor. Each pulse stands for a fixed volume.
4-20 mA: an analog current proportional to flow, read through a shunt resistor and an ADC.
Modbus RTU over RS-485: registers that hold the flow rate and the totals.

Pulses are the simplest and the most accurate for totals, so that is what we will use.

A few wiring notes for an ESP32:

An NPN open-collector output can only pull the line low, so add an external pull-up of 4.7 to 10 kΩ to 3.3 V. The internal pull-up is too weak for a long cable.
A PNP output, or anything that drives 12 or 24 V, needs a voltage divider or, better, an optocoupler. Never connect 24 V to a GPIO.
Reed switches bounce. Add a small RC filter, for example 10 kΩ and 100 nF, plus a short software lockout.

The firmware: count in an interrupt, compute in the loop

#include <Arduino.h>
#include <Preferences.h>

constexpr int      PULSE_PIN        = 27;
constexpr float    PULSES_PER_LITRE = 100.0f;  // K-factor: use the value on your meter's calibration sheet
constexpr uint32_t MIN_GAP_US       = 2000;    // ignore edges closer than 2 ms (contact bounce)

volatile uint32_t pulseCount   = 0;
volatile uint32_t lastPulseUs  = 0;
volatile uint32_t lastPeriodUs = 0;
portMUX_TYPE mux = portMUX_INITIALIZER_UNLOCKED;

void IRAM_ATTR onPulse() {
  uint32_t now = micros();
  portENTER_CRITICAL_ISR(&mux);
  uint32_t gap = now - lastPulseUs;
  if (gap >= MIN_GAP_US) {
    pulseCount++;
    lastPeriodUs = gap;
    lastPulseUs  = now;
  }
  portEXIT_CRITICAL_ISR(&mux);
}

Preferences prefs;
uint64_t totalPulses = 0;

void setup() {
  Serial.begin(115200);
  pinMode(PULSE_PIN, INPUT);                       // external pull-up on the board
  prefs.begin("flow", false);
  totalPulses = prefs.getULong64("total", 0);      // the total survives a reboot
  attachInterrupt(digitalPinToInterrupt(PULSE_PIN), onPulse, FALLING);
}

void loop() {
  static uint32_t lastReport = 0, lastSave = 0;
  if (millis() - lastReport < 1000) return;
  float seconds = (millis() - lastReport) / 1000.0f;
  lastReport = millis();

  portENTER_CRITICAL(&mux);
  uint32_t pulses    = pulseCount;
  pulseCount         = 0;
  uint32_t period    = lastPeriodUs;
  uint32_t sinceLast = micros() - lastPulseUs;
  portEXIT_CRITICAL(&mux);

  totalPulses += pulses;
  float litresPerMin;
  if (pulses >= 5) {
    litresPerMin = pulses / PULSES_PER_LITRE / seconds * 60.0f;   // plenty of pulses: count them
  } else if (period > 0 && sinceLast < 10000000UL) {
    litresPerMin = 60.0e6f / (period * PULSES_PER_LITRE);         // slow flow: time between pulses
  } else {
    litresPerMin = 0.0f;                                         // no pulse for 10 s: stopped
  }

  Serial.printf("{\"lpm\":%.3f,\"total_l\":%.3f}\n", litresPerMin, totalPulses / PULSES_PER_LITRE);

  if (millis() - lastSave > 60000) {               // save once a minute, not on every pulse
    prefs.putULong64("total", totalPulses);
    lastSave = millis();
  }
}

A few details are worth calling out.

The interrupt only counts. On the ESP32 the handler lives in IRAM, and the critical section stops the loop from reading a half-updated count. All the floating-point maths happens in the loop.

Two ways to get the rate. At normal flow there are plenty of pulses per second, so counting them is accurate. At low flow a viscous fluid may produce only one pulse every few seconds, and counting would make the reading jump between zero and a large number. Timing the gap between pulses gives a smooth value instead.

Choose the lockout from the maximum frequency. The highest pulse rate is the K-factor times the maximum flow in litres per second. With 100 pulses per litre at 60 L/min, that is 100 Hz, or 10 ms between pulses, so a 2 ms lockout filters bounce without dropping real pulses.

Save the total sparingly. Flash memory wears out with repeated writes, so store the running total once a minute and accept that a power cut may lose a few seconds of counting.

Temperature, density and a calibration you can trust

A PD meter measures volume at line conditions, and oil expands as it warms, roughly 0.07 % per °C for many mineral oils. A litre at 60 °C is therefore less oil than a litre at 15 °C. If you dose, sell or report quantities, log the temperature next to the pulses (a DS18B20 strapped to the pipe is enough for monitoring) and convert to a reference temperature, or to mass, with the fluid's density table.

Then calibrate in place. Dispense into a container on a scale, record the pulses and work out K = pulses / (mass / density). Repeat at low, medium and high flow and at the temperatures you actually run at. If the K values agree within your tolerance, use their average. If they do not, the meter is outside its range or something is slipping.

Test the logic before you touch the pipe

You can debug most of this without a drop of oil. A function generator, or a second microcontroller toggling a pin at a known frequency, shows whether the rate, low-flow and total calculations are right. If you prefer simulation, The Engineering Projects publishes a YF-S201 water flow sensor library for Proteus that produces the same kind of pulse train, so you can step through the interrupt and loop code on a virtual board first and drop in your real meter's K-factor later.

Wrapping up

Paddle-wheel sensors are calibrated with water. Viscosity adds drag and changes the flow profile, so they read low and drift with temperature.
Positive displacement (oval gear) meters suit thick fluids because slip falls as viscosity rises. Size them for pressure drop.
Count pulses in an interrupt, compute in the loop, switch to pulse timing at low flow and save totals sparingly.
Log temperature and calibrate by weight under your real operating conditions.

Get those right and your dashboard will tell you how much oil actually moved, not how hard it was to push.

DEV Community: TheTechLover