HC-SR501 PIR Motion Sensor with Arduino: Wiring, Trimpots and the H/L Jumper

How a PIR sensor actually detects motion

"PIR" stands for passive infrared. Passive is the important word: unlike an ultrasonic sensor, which emits a pulse and listens for the echo, a PIR sensor emits nothing at all. It only listens.

Every object above absolute zero radiates infrared energy, and a human body radiates strongly in the range this sensor is tuned to. Underneath the white dome sit two (sometimes four) pyroelectric elements wired in opposition. When both elements see the same amount of infrared, their signals cancel and the output is zero. When something warm moves across the field of view, it crosses one element before the other, the balance breaks, and the difference produces a measurable signal.

That differential arrangement is a deliberate design choice, and it explains the sensor's single most misunderstood behaviour: it detects change, not presence. Ambient room temperature rising slowly affects both elements equally and produces nothing. A person walking across the beam produces a strong signal. A person standing perfectly still produces nothing after a second or two, and the output drops back to LOW.

What the white dome is for

The dome is a Fresnel lens, and it is not decorative. Look closely at the moulded facets — each one focuses infrared from a different narrow slice of the room onto the sensing elements. This slices the detection area into a fan of alternating sensitive and blind zones.

The result is that a warm body crossing the field passes through zone, gap, zone, gap, producing a sharp alternating signal that is easy to distinguish from a slow ambient drift. Without the lens, the sensor would have a single wide undifferentiated view and would be far worse at telling motion apart from background change. It is also why walking across the sensor triggers it much more reliably than walking directly towards it — moving straight at the sensor crosses far fewer zone boundaries.

Board tour: what each component does

Lens side. The faceted dome divides the field of view into alternating detection zones.

Component side. The BISS0001 controller is the large chip at left; the two black trimpots and the yellow jumper are the only user adjustments.

The board is built around the BISS0001, a dedicated PIR controller chip that handles the entire analogue signal chain. The raw output from a pyroelectric element is tiny and noisy, so the BISS0001 provides a two-stage amplifier, a comparator with a fixed threshold, and the retriggerable timing logic that holds the output HIGH for the configured delay. The chip in the photo above is marked BISS0001 with a date code below it.

The BISS0001 controller and its supporting components. The three-pin header is at the left edge, the yellow mode jumper at lower right, and the electrolytic capacitors that decouple the supply rail sit at the corners.

Everything else on the board supports that chip. The onboard voltage regulator lets the module accept a wide supply range and feed the BISS0001 a clean rail. The electrolytic capacitors decouple that rail — PIR front-end gain is high enough that supply ripple would otherwise show up as false detections. The three-pin header carries VCC, OUT and GND.

The two trimpots: sensitivity and time delay

The two black adjusters are the module's only tuning controls, and getting them right is most of the work.

Sensitivity

Sets the comparator threshold, which effectively controls detection range — roughly 3 metres at minimum, roughly 7 metres at maximum. Turning it up does not just extend range; it also makes the module more willing to act on weaker signals, which means more false triggers from heat sources at the edge of the field.

The practical approach is to start at minimum, then increase until the sensor reliably catches motion at the distance you actually care about, and stop there. Resist the urge to max it out — a sensor covering a 3-metre doorway set to 7-metre sensitivity will pick up movement through the doorway from the next room.

Time delay

Sets how long the output stays HIGH after a detection, from well under a second at minimum to several minutes at maximum. This is done in hardware by the BISS0001, not in your code — the pin genuinely stays HIGH for that whole period regardless of what your sketch does.

For testing and for reading the sensor in software, set this to minimum. A long hardware delay makes debugging miserable, because every test requires waiting out the timer before the sensor will respond again. If your application needs a light to stay on for two minutes, it is almost always better to keep the hardware delay short and handle the timing in your sketch, where you can change it without a screwdriver.

The H/L jumper: repeatable vs single trigger

The small yellow jumper — visible at the left edge of the component-side photo above — selects between two genuinely different output behaviours. This is the setting that most tutorials skip, and it causes a disproportionate share of confusion.

In H mode, every new detection resets the delay timer. Someone walking around the room keeps the output HIGH continuously and it only drops once the room has been still for the full delay period. This is what you want for a light that should stay on while a room is occupied.

In L mode, the timer is not restarted by further motion. The output goes HIGH, runs its delay, and drops — then a blocking interval passes, and only then can it trigger again. With continuous motion the output pulses on and off. This is occasionally useful if you want one discrete event per detection cycle, but it is rarely what a beginner intends.

If your symptom is "the light keeps turning off while I am standing right in front of it", check this jumper before anything else.

Wiring to an Arduino

Three wires, and the pin order is printed on the board underneath the header — worth checking, because it is not identical across all clones.

Pin 2 is a deliberate choice: on an Arduino Uno it is one of the two external interrupt pins. This sketch polls the pin rather than using an interrupt, but wiring it to pin 2 from the start means you can move to attachInterrupt() later without rewiring — useful once the sketch grows and polling every loop stops being practical.

Unlike a button, the OUT pin does not need INPUT_PULLUP. The module actively drives the line to about 3.3 V for HIGH and to ground for LOW, so a plain pinMode(pin, INPUT) is correct. Adding a pull-up would fight the module's LOW drive.

The 3.3V output and 5V logic thresholds

This deserves its own section because it is the source of the most frustrating class of HC-SR501 failure: the one that works on the bench and fails intermittently in the finished project.

The module's OUT pin goes to roughly 3.3 V when triggered, not 5 V. On a 5 V AVR Arduino, a digital input is guaranteed to read HIGH above about 0.6 × V_CC, which is 3.0 V. So 3.3 V is read as HIGH — with roughly 0.3 V of margin.

That margin is enough on a short jumper wire with a clean supply. It erodes quickly when you add a two-metre signal run, share a supply with motors, or run the Arduino from a slightly high regulator that pushes V_CC above 5 V — which raises the threshold and shrinks the margin further. The failure mode is not a dead sensor; it is a sensor that works most of the time and occasionally misses a detection, which is far harder to diagnose.

If you need real margin on a 5 V board, the clean fix is a small NPN transistor or a logic-level MOSFET as a level translator, or simply moving the sensor to a 3.3 V microcontroller. For a classroom exercise on a 30 cm jumper wire, direct connection is fine — just know why it is fine, so that when the same circuit misbehaves inside a two-metre enclosure you already know where to look.

Working code with state tracking

The naive sketch — digitalRead() and print — floods the Serial Monitor with hundreds of identical lines per second and tells you nothing about when things changed. This version tracks state transitions and reports only the edges, which is what you actually want when tuning the trimpots.

// HC-SR501 PIR motion sensor - edge-detecting test sketch
// OUT -> pin 2, LED -> pin 13
// Set the time-delay trimpot to MINIMUM while testing.

const int PIR_PIN = 2;
const int LED_PIN = 13;

const unsigned long WARMUP_MS = 60000UL;  // 60 s stabilisation

int  lastState = LOW;
unsigned long motionStartedAt = 0;

void setup() {
  Serial.begin(9600);
  pinMode(PIR_PIN, INPUT);     // module drives both levels; no pull-up
  pinMode(LED_PIN, OUTPUT);
  digitalWrite(LED_PIN, LOW);

  Serial.println(F("HC-SR501 warming up - ignore output for 60 s"));
  unsigned long start = millis();
  while (millis() - start < WARMUP_MS) {
    // blink slowly so it is obvious the board is alive, not frozen
    digitalWrite(LED_PIN, (millis() / 500) % 2);
    delay(10);
  }
  digitalWrite(LED_PIN, LOW);
  lastState = digitalRead(PIR_PIN);   // adopt whatever state it settled into
  Serial.println(F("Ready. Watching for motion."));
}

void loop() {
  int state = digitalRead(PIR_PIN);

  if (state == HIGH && lastState == LOW) {
    motionStartedAt = millis();
    digitalWrite(LED_PIN, HIGH);
    Serial.print(F("MOTION START  at "));
    Serial.print(millis() / 1000.0, 1);
    Serial.println(F(" s"));
  }
  else if (state == LOW && lastState == HIGH) {
    unsigned long heldMs = millis() - motionStartedAt;
    digitalWrite(LED_PIN, LOW);
    Serial.print(F("MOTION END    held HIGH for "));
    Serial.print(heldMs / 1000.0, 1);
    Serial.println(F(" s"));
  }

  lastState = state;
}

Three things make this sketch more useful than the usual example:

• It enforces the warm-up rather than leaving it as a comment, and blinks the LED during it so the board does not look dead.
• It reports only transitions, so the Serial Monitor stays readable and you can see exactly when each detection began and ended.
• It measures how long the output stayed HIGH, which is the direct way to calibrate the time-delay trimpot. Turn the knob, trigger the sensor, read the number.

Typical output once running:

That repeated "held HIGH for 2.8 s" is the time-delay trimpot at its minimum setting on this particular module. Turn the knob clockwise and the number grows. If it never drops back to LOW while you keep moving, you are in H mode — which, as covered above, is usually the correct mode.

Diagnosing false triggers

Work down this list in order. The causes are roughly ordered by how often they turn out to be the answer.

The decoupling capacitor fix is worth emphasising. The PIR front end amplifies a very small signal by a large factor, so ripple on the supply that would be harmless to a digital circuit lands squarely in the sensor's signal band. Any project where the PIR shares a supply with motors, servos or relays should have that capacitor pair fitted as a default, not as a troubleshooting step. The same principle applies to the battery-sag problems documented in our four-generation robot car write-up — shared supplies are a recurring source of bugs that look like sensor faults.

What this sensor fundamentally cannot do

Choosing the right sensor matters more than tuning the wrong one. These are properties of the technology, not defects:

• It cannot detect a motionless person. The differential pyroelectric design responds to change. Someone sitting still at a desk will stop registering within seconds. If you need occupancy rather than motion, you need a different technology — a microwave or mmWave radar module, for example.
• It cannot measure distance. The output is a single digital HIGH or LOW. There is no distance value available, only "something moved within the configured range". For distance, use an ultrasonic sensor — see our HC-SR04 proximity alert build.
• It cannot tell you direction or count people. Two people or one produce the same output. Some projects approximate direction with two sensors and timing analysis, but the individual module gives you nothing.
• It cannot see through glass. Ordinary window glass blocks the infrared wavelengths involved. Pointing a PIR through a window at a garden will not work, and putting one inside a sealed clear enclosure usually will not either — the enclosure needs an IR-transparent window, typically HDPE.
• It struggles to distinguish humans from pets. A dog is also a moving warm body. Commercial alarm PIRs use shaped lenses to create a blind zone at floor level; the generic HC-SR501 lens does not. Mounting height and downward angle are your only real controls.
• Its performance drops as ambient temperature approaches body temperature. The sensor works on the contrast between a warm body and a cooler background. On a very hot day that contrast shrinks and effective range falls.

Where it fits in a project

A batch of HC-SR501 modules as they arrive — individually bagged in antistatic packaging. Buying in quantity is how these get used in a classroom, and it also means checking a few for consistency before handing them out.

Once the module is behaving, the HC-SR501 is a genuinely useful building block precisely because it does one thing and does it in hardware. A few directions worth taking it:

• Automatic lighting. The archetypal use. Keep the hardware delay short and manage the on-time in software so you can adjust it without a screwdriver.
• Battery-powered alerts. The module's current draw is low enough that a PIR plus a sleeping microcontroller can run a long time on batteries. Wire OUT to an interrupt-capable pin and let the detection wake the board.
• Robot wake-on-approach. A PIR on a robot lets it stay idle until a person is nearby, rather than driving its avoidance loop continuously and draining the pack.
• Data logging. Counting detection events over hours tells you about room usage patterns — and it is a good exercise in appreciating that what you are logging is motion events, not people.

Frequently asked questions