PIR Sensor Library for Proteus

Hello friends! Today, we will install the PIR Sensor Library for Proteus and build a motion-detection demonstration with Arduino. We will first understand the sensor's output, then install the library, connect the circuit and write a program that reports when a motion event starts and ends.

The original PIR model uses a TestPin to represent motion in the simulation. That input lets us exercise the receiving circuit without trying to reproduce a person walking through an infrared detection pattern. It is a simulation control, not an extra connection found on a typical three-pin PIR module.

We will also improve the timing explanation. A sensor output going LOW and an application declaring an area inactive are different events. Our Arduino example waits for five continuous seconds of LOW before ending an event, while remaining responsive to a new HIGH during that interval.

What Is a PIR Motion Sensor?

PIR means passive infrared. A PIR detector responds to changes in infrared radiation reaching its sensing elements. In a module, the sensing element, optical arrangement and signal-conditioning electronics work together to produce an output that a microcontroller can read.

The word passive means that this sensing method does not illuminate the target with an emitted measurement beam. A changing thermal scene can create a detection, but the output does not identify the object, count people or measure their exact distance.

Panasonic's PIR motion-sensor FAQ explains the importance of the detection area and stable mounting. Moving a sensor can change the thermal scene it observes. Consequently, a PIR module is normally mounted in a fixed position and evaluated in the environment where it will operate.

For our first project, we only need a digital interpretation: HIGH means the module is asserting its detection output, and LOW means it is not asserting that output. Neither state is a complete description of room occupancy. A stationary person can remain present without producing the changes needed for another detection.

What This Original Proteus Model Supports

This library provides four differently colored PIR components with the same basic behavior for the demonstration. Select whichever appearance suits the schematic. Their color does not create a different detection range, sensitivity or output protocol.

Set TestPin HIGH to exercise detection and LOW to remove the simulated motion condition. This arrangement is useful for checking logic, messages and application timers. It does not model a moving person's thermal signature, a Fresnel lens pattern or the effects of sunlight and air movement on a physical installation.

If you need a more detailed model, see the PIR Sensor Library for Proteus V4.0, which documents its own HC-SR501 controls and startup behavior. Earlier alternatives include V3.0 and the V2.0 library. Follow the instructions for the version actually installed rather than mixing its controls with this original TestPin example.

Download and Install the PIR Library

Download the original package below and extract it. The files used in this tutorial are PIRSensorTEP.LIB, PIRSensorTEP.IDX and PIRSensorTEP.HEX. Keep the original package available so that you can distinguish these files from similarly named files belonging to a newer release.

1. Close Proteus.
2. Find the library directory configured for your installation.
3. Copy the LIB and IDX files into that directory.
4. Keep the HEX file in a stable project folder.
5. Restart Proteus and search for the PIR sensor in Pick Devices.
6. Place one sensor on the schematic.
7. Open its properties and assign PIRSensorTEP.HEX as the sensor's Program File.

The library files make the symbol available, while the support HEX supplies its simulated behavior. If the symbol appears but does not operate, inspect the Program File path before reinstalling the library. A path pointing into a temporary extraction folder may stop working after that folder is removed.

Do not confuse the sensor support file with your Arduino program. The PIR component receives PIRSensorTEP.HEX; the Arduino receives the HEX compiled from the sketch below. Each program belongs to a different simulated device.

Connect the PIR Sensor to Arduino

We will use an Arduino UNO and read the sensor output on digital pin D2. Add a logic-state control to TestPin so that you can change the input while the simulation runs. Add a Virtual Terminal to observe the Arduino's event messages.

Keep TestPin LOW when starting the first run. This gives the program a clear inactive state before you create an event. Check the OUT signal directly if necessary; it helps distinguish a sensor-control problem from a problem in the Arduino's event logic.

A physical module may have a different supply range and output voltage from another module sold under the same general PIR description. Check the specific board documentation before connecting real hardware. The 5 V supply used here is a statement about this demonstration, not a universal rating for every PIR sensing element.

Arduino Program for Motion Events

The following sketch reports one message when detection begins and one message after the sensor has remained LOW for five seconds. It avoids a five-second blocking delay, so a new HIGH can cancel the pending end of the event immediately.

const byte pirPin = 2;
const unsigned long quietTimeMs = 5000UL;

bool motionActive = false;
bool timingLow = false;
unsigned long lowStartedAt = 0;

void setup() {
  pinMode(pirPin, INPUT);
  Serial.begin(9600);
  Serial.println("PIR demonstration ready");
}

void loop() {
  const unsigned long now = millis();
  const bool detected = digitalRead(pirPin) == HIGH;

  if (detected) {
    timingLow = false;
    if (!motionActive) {
      motionActive = true;
      Serial.print("Motion detected at ");
      Serial.print(now / 1000UL);
      Serial.println(" s");
    }
  } else if (motionActive) {
    if (!timingLow) {
      lowStartedAt = now;
      timingLow = true;
    }
    if (now - lowStartedAt >= quietTimeMs) {
      motionActive = false;
      timingLow = false;
      Serial.print("Motion event ended at ");
      Serial.print(now / 1000UL);
      Serial.println(" s");
    }
  }
}

Compile the sketch for the UNO, export the compiled binary and assign the resulting application HEX to the simulated Arduino. Match the simulated processor clock to the board configuration. A clock mismatch affects serial communication and timing, so correct it before judging the five-second behavior.

How the state variables work

motionActive records whether the application currently considers an event active. It does not simply mirror the input. Once HIGH begins an event, the event remains active through short LOW intervals until the quiet-time requirement has been satisfied.

timingLow records whether a continuous LOW interval is being measured. The first LOW sample stores the current time. Further LOW samples leave that starting time unchanged, allowing the interval to accumulate. Any HIGH clears this timing state, so the next LOW starts a fresh interval.

The elapsed-time calculation uses unsigned subtraction: now - lowStartedAt. This is the usual approach for short intervals measured with a wrapping unsigned millisecond counter. It is preferable to comparing against a future absolute timestamp that may wrap across the counter boundary.

The startup state deliberately avoids printing an event-ended message before any detection has occurred. This makes the serial log describe actual application transitions rather than repeatedly announcing that an initially inactive input is still inactive.

Why the original calibration variable was misleading

The older sketch declared a calibration-time variable but did not use it to implement a startup wait. Declaring a number does not delay execution or calibrate the sensor. The revised demonstration therefore makes no claim that an unused variable performs calibration.

Physical PIR modules can need a settling interval after power is applied. Use the interval specified for the actual module and implement an explicit startup state if your application needs to ignore readings during that period. This original TestPin model does not establish a universal warm-up time for hardware.

Run the Simulation Step by Step

1. Start with TestPin LOW and run the simulation.
2. Confirm that the terminal displays the ready message.
3. Set TestPin HIGH and observe a single motion-detected message.
4. Leave it HIGH and confirm that the program does not print the same event repeatedly.
5. Set TestPin LOW and wait less than five seconds.
6. Set it HIGH again; the pending end should be canceled.
7. Finally, set it LOW and leave it there for at least five seconds.
8. Observe the event-ended message and then create another HIGH to begin a new event.

The detected-state screenshot shows the purpose of the terminal output: a readable event record that can be compared with your input changes. Exact wording and timestamps may differ from the archived sketch because the revised code makes the state transitions more explicit.

The ended-state screenshot illustrates the second transition. In the revised example, its timestamp is when the application declares the event ended, after the quiet interval. If you also need the time of the last falling edge, record and label that separately.

Work through a timing example

Suppose the input goes HIGH at 2 seconds and LOW at 4 seconds. The event starts at 2 seconds, and the LOW timer begins at 4 seconds. If no further detection occurs, the application ends the event at approximately 9 seconds.

Now suppose another HIGH occurs at 7 seconds. Only three seconds of LOW have elapsed, so the event remains active and the quiet timer is canceled. If the input next becomes LOW at 8 seconds, the earliest end becomes approximately 13 seconds.

Event-end time = start of the final uninterrupted LOW interval + quiet-time setting

This timing belongs to the Arduino application. A real module may already hold its output HIGH for its own configured delay. If that module releases its output three seconds after its last detection, and your application then adds five seconds of LOW qualification, the combined release behavior can be about eight seconds after that detection under those assumptions.

Add an Indicator or an Application Output

Once the serial example is clear, an LED can show the application state. Set the LED according to motionActive, not merely the raw input, if you want it to remain illuminated during the quiet interval. This makes the difference between the sensor output and the event state visible.

For an external red LED on a 5 V logic output, an illustrative resistor calculation is R = (5 - 2) / 0.005 = 600 ohms, assuming a 2 V forward drop and a 5 mA target current. A nearby standard value such as 680 ohms reduces the current slightly. Check the actual LED and processor limits before building the circuit.

A motor, relay coil or lamp requires a suitable driver rather than a direct connection to a microcontroller pin. Keep that power stage separate from the sensor-reading logic. For an inductive DC load, the driver design must also account for the voltage generated when coil current is interrupted.

Useful Test Cases

Use these cases to check behavior rather than relying on one successful detection. A program can appear correct when you hold the input HIGH, yet still mishandle a short LOW gap or print an ended message continuously once the interval expires.

Polling is sufficient for this slow demonstration because the loop performs very little work. If you later add long display updates or blocking communication, check the shortest pulse you must observe and the longest interval between input samples. An interrupt is not automatically necessary, but unbounded delays can make polling miss important transitions.

Separate a detection event from an alarm policy

A finished motion event is a useful input to another part of the program, but it should not decide every output by itself. A lighting application might illuminate a room while the event is active. A logger might record the start time and duration. An alarm application might additionally require an armed state and a deliberate reset policy.

Keep those decisions outside the code that reads D2. Otherwise, adding a manual override or changing the quiet interval can unexpectedly change unrelated behavior. A small set of named states is easier to inspect than several timers and output writes distributed throughout the loop.

Also decide what happens after a processor reset. The sketch begins inactive and treats a HIGH input as a new event. That is appropriate for this demonstration, but an application that restores persistent state may need a different startup rule. Document the choice so that a restart does not silently appear to be a continuous observation.

If you record event duration, calculate it from timestamps rather than counting serial messages. The program intentionally prints only state changes, and printing can be delayed by other work. Store the start time when the event begins and subtract it from the declared end time; label that result as the application event duration, including its five-second quiet interval.

Keep a short event log during these experiments so you can compare input transitions with the application's decisions after the run has finished.

Troubleshooting and Library Review

If the PIR symbol is missing, check the LIB and IDX installation. If it is visible but OUT does not change, check the support HEX and TestPin connection. If OUT changes but no messages appear, inspect D2, the Arduino program file and the terminal's connection to D1/TX.

Unreadable text usually points to serial settings or processor-clock configuration. A motion event that never ends usually means the input is still HIGH or keeps returning HIGH before the quiet interval completes. Observe the input directly before modifying the timing code.

This original library is a useful introduction to digital sensor inputs and timed event handling. Its simple TestPin makes edge cases easy to reproduce. Its limits are equally important: it does not validate detection coverage, immunity to environmental disturbances or the suitability of a particular physical PIR module for an installation.

For distance measurements, explore a different sensing method, such as the ultrasonic sensor library or VL53L0X library. A distance sensor and a PIR detector answer different questions, so choose according to the information your application actually needs.

The original Arduino project download and video are retained below. They provide the historical simulation files; the revised code above explains the event logic without the unused calibration variable or unnecessary blocking delay.

Frequently Asked Questions

Is TestPin available on a real PIR module?

It is a control provided by this simulation model. A typical digital PIR module exposes power, ground and output, although the exact connections depend on the board.

Why does the program wait five seconds after LOW?

That is an application choice to combine detections separated by short quiet gaps. Change quietTimeMs if your project requires another release interval.

Does LOW prove that nobody is present?

No. It means the module is not currently asserting its detection output. A PIR detector cannot by itself prove that a space contains no stationary person.

Why are there four sensor colors?

They provide alternative appearances in this original library. The basic TestPin demonstration described here is the same for all four.

Can I reuse the sketch with a physical module?

The state-machine approach is reusable. First verify supply and logic levels, output behavior, startup settling and any hardware delay or retrigger settings for the actual module.