How to use 18B20 in Proteus ISIS

Hello friends! Today we will use the DS18B20 temperature sensor with Arduino Uno in Proteus and display its reading on a character LCD. The sensor is sometimes shortened to 18B20 in project descriptions, but DS18B20 is the part name we will use when selecting the device and checking its specifications.

We will begin with the sensor connections, add a 20-column by 4-row LCD, and write a sketch that requests a temperature conversion before displaying the result. We will also handle a missing sensor explicitly instead of presenting an error value as though it were a real temperature.

The Proteus model lets us change the simulated temperature using its controls. It does not measure the room around your computer. This makes it useful for checking the program and display workflow before building the physical circuit.

What Does the DS18B20 Measure?

The DS18B20 is a digital temperature sensor. Arduino communicates with it over a 1-Wire data connection, rather than measuring an analogue output voltage. The bus still needs a ground reference, and our recommended beginner circuit also provides a separate supply connection.

The DS18B20 datasheet specifies a measurement range of -55 to +125 degrees Celsius and an accuracy of plus or minus 0.5 degrees Celsius over -10 to +85 degrees Celsius. Its selectable resolution is 9 to 12 bits.

Resolution is the size of the numerical step, while accuracy concerns how closely the reading represents the actual temperature. Printing several decimal places cannot improve the sensor's physical accuracy.

The device also has an individual 64-bit ROM code, allowing sensors to share a bus while being addressed separately. We will begin with one sensor so that wiring, conversion and display behaviour remain easy to follow.

Select the Proteus Components

Open the component picker and locate a DS18B20 simulation model, Arduino Uno, a compatible 20x4 character LCD, resistors and a contrast potentiometer. The original component selection is shown below.

A schematic symbol alone is insufficient for this experiment. The selected temperature component must support simulation, and the Arduino model must be able to execute the compiled Uno firmware.

We use a parallel character LCD in four-bit mode, not an I2C backpack display. Those two arrangements use different connections and library interfaces. Choosing an I2C LCD while retaining the parallel constructor below will not produce the intended result.

Understand the Original Circuit

The original schematic keeps the 1-Wire data connection on Arduino D6 and connects the LCD through six Arduino outputs. We will retain that signal mapping in the revised sketch.

The historical drawing uses a 10-kilohm data pull-up and shows the sensor supply connection in a parasite-power arrangement. For a clearer first hardware build, use the separately powered connection described below instead. An ideal simulator accepting the older arrangement does not demonstrate that it supplies adequate conversion power on a real bus.

Connect the sensor's VDD to the appropriate supply, GND to common ground and DQ to Arduino D6. For the Uno-based 5 V example, use a 4.7-kilohm pull-up from DQ to 5 V. Confirm the pin numbering and package view from the actual device datasheet before wiring a physical sensor.

The OneWire library documentation illustrates the data-line pull-up and discusses powered versus parasite-powered connections. A parasite-powered design has additional power-delivery requirements during conversion; we are not relying on that mode in this revised example.

The pull-up establishes the released bus level. It is not a series resistor between the sensor and Arduino. At 5 V, a 4.7-kilohm pull-up carries approximately 5/4700 = 1.06 mA when the line is held low, ignoring the small low-level voltage.

Wire the 20x4 LCD

The constructor LiquidCrystal lcd(12, 11, 5, 4, 3, 2) assigns the pins in the order RS, Enable, D4, D5, D6 and D7. The LCD's data-pin names are not the same thing as Arduino digital-pin numbers.

Connect the LCD power pins correctly and feed its contrast input from the potentiometer wiper. A 10-kilohm potentiometer across the supply and ground is a practical starting arrangement for a typical compatible module; check the display's own requirements.

The original picture labels a much smaller potentiometer value. Do not copy that value into hardware without considering the continuous current it would draw across the supply. The contrast circuit's purpose is to set a voltage, not to consume unnecessary power.

The Arduino LiquidCrystal library supports compatible HD44780-style character displays. Set the dimensions with lcd.begin(20, 4) for this circuit. If you substitute a 16x2 module, revise both the dimensions and text layout.

Install the Arduino Libraries

We need OneWire for the bus communication, DallasTemperature for the sensor-level operations, and LiquidCrystal for the parallel LCD. Use the Arduino library manager or the maintainers' documented installation procedure for the versions you choose.

The original article's three library downloads remain available below for readers maintaining an older project. They are historical archives, so they should not be assumed to contain the current maintained versions.

The maintained DallasTemperature project documents its OneWire dependency and provides examples. If compilation reports duplicate libraries, check which copy the IDE selected before adding another archive.

A missing-header error occurs during compilation on the computer. It is different from a missing sensor detected while the program runs. Solve the build error first; changing the simulated temperature cannot repair an unavailable library.

Arduino Sketch with Explicit Error Handling

This sketch discovers the first sensor at startup and retains its address for subsequent readings. It uses a blocking conversion for clarity and displays the result only after that request completes.

#include <OneWire.h>
#include <DallasTemperature.h>
#include <LiquidCrystal.h>
#include <math.h>

const byte sensorPin = 6;
OneWire oneWire(sensorPin);
DallasTemperature sensors(&oneWire);
LiquidCrystal lcd(12, 11, 5, 4, 3, 2);
DeviceAddress sensorAddress;
bool sensorFound = false;

void clearRow(byte row) {
  lcd.setCursor(0, row);
  lcd.print("                    ");
  lcd.setCursor(0, row);
}

void setup() {
  Serial.begin(9600);
  lcd.begin(20, 4);
  lcd.print("Welcome to TEP");
  lcd.setCursor(0, 2);
  lcd.print("DS18B20 temperature");
  sensors.begin();
  sensorFound = sensors.getAddress(sensorAddress, 0);
  if (sensorFound) {
    sensors.setResolution(sensorAddress, 12);
  }
  sensors.setWaitForConversion(true);
  delay(5000);
  lcd.clear();
  lcd.print("DS18B20 Temperature");
}

void loop() {
  if (!sensorFound) {
    clearRow(1);
    lcd.print("No sensor at startup");
    Serial.println("No sensor: check wiring and restart");
    delay(1000);
    return;
  }

  sensors.requestTemperatures();
  const float temperatureC = sensors.getTempC(sensorAddress);
  clearRow(1);
  clearRow(2);
  lcd.setCursor(0, 1);

  if (isnan(temperatureC) ||
      temperatureC == DEVICE_DISCONNECTED_C ||
      temperatureC < -55.0f || temperatureC > 125.0f) {
    lcd.print("Sensor read error");
    lcd.setCursor(0, 2);
    lcd.print("Check D6 and power");
    Serial.println("Temperature unavailable");
  } else {
    lcd.print(temperatureC, 2);
    lcd.print(" C");
    Serial.print("Temperature: ");
    Serial.print(temperatureC, 2);
    Serial.println(" C");
  }
  delay(250);
}

The address lookup happens once. If the sensor is absent at startup, correct the wiring and restart the example. A production system could add a deliberate rediscovery procedure, but silently switching to another sensor would be undesirable when each device represents a particular location.

The DallasTemperature API definitions identify DEVICE_DISCONNECTED_C as an error sentinel and expose the address-based reading and conversion-wait methods used here. The range check also rejects values outside this sensor's specified measurement interval.

We read the temperature once into a variable and use the same value for the LCD and serial output. This makes the two outputs describe the same observation rather than performing separate sensor reads for each display.

The row-clearing helper writes spaces before the next value. Without that step, changing from 100.00 to 9.00 can leave characters from the longer previous string on a character LCD.

Compile and Load the Program in Proteus

1. Select Arduino Uno as the target board.
2. Compile the sketch with the required libraries installed.
3. Export the compiled application binary from the IDE.
4. Select the resulting HEX file in the Proteus Arduino model's program property.
5. Check that the model's clock matches the Uno target, normally 16 MHz.
6. Run the simulation.

Arduino does generate a compiled firmware image. The issue for a simulator is locating the appropriate output file. Our Arduino HEX-file tutorial explains that workflow.

If you edit the sketch, rebuild and ensure that Proteus uses the new file. An unchanged display after a code edit may simply mean that the model is still executing a previous binary.

Observe Startup and Temperature Changes

The original startup screen is retained below. The revised sketch keeps a five-second introduction but uses a simpler layout, followed by a temperature heading and a separate value row.

After startup, adjust the temperature using the selected DS18B20 model's controls. The displayed result should change after the next conversion and display update.

This screenshot records the earlier simulation. Use it as an example of the intended sensor-to-LCD relationship, while following the revised wiring and sketch for the updated experiment.

Try a positive temperature, zero and a negative temperature. Also try changing from a three-digit value to a shorter value to check that the LCD does not retain old characters. These tests examine formatting as well as the sensor communication path.

Understand Conversion Time and Display Rate

A temperature request and a temperature result are separate events. The sensor needs time to perform its conversion. Reading before a new result is ready can return an earlier value or expose startup behaviour.

At 12-bit resolution, allow up to 750 milliseconds for conversion. With an additional 250-millisecond delay, this example has a nominal worst-case cycle around one second plus communication and display overhead. It is not a precise one-hertz scheduler.

If you need responsive buttons or other work during conversion, use an asynchronous design: request a conversion, record the start time, continue unrelated work, and read after completion or the required interval. Do not simply disable waiting and immediately read.

The sensor's power-on temperature register value is +85 degrees Celsius. Repeated startup-like readings can justify checking conversion and power behaviour, but 85 degrees Celsius can also be a valid measured temperature. Rejecting every occurrence of that number would create a different error.

Useful Temperature Calculations

For Fahrenheit, use T_F = 1.8 x T_C + 32. A reading of 25 degrees Celsius corresponds to 77 degrees Fahrenheit. Keep the unit with the number so a later display or data log does not silently mix scales.

For a temperature difference, the offset does not apply: a rise of 10 Celsius degrees is a rise of 18 Fahrenheit degrees. This distinction matters when displaying a change from a baseline instead of an absolute temperature.

At 12-bit resolution, a 0.25-degree change spans four nominal output increments because 0.25/0.0625 = 4. Displaying two decimal places rounds those increments for presentation; it does not change the sensor resolution.

If you later add an alarm, define separate turn-on and turn-off thresholds to avoid rapid toggling near one boundary. For example, turn an indicator on at 30 degrees and off below 29 degrees. Those values are an illustrative control rule, not a recommendation for a particular appliance.

Multiple Sensors and Real Wiring

With several sensors, associate each ROM address with a physical location such as inlet or outlet. An index returned during discovery is convenient for a one-sensor demonstration, but it should not be treated as a permanent installation label.

Requesting conversions together can reduce the time spent waiting for several readings. Read each identified device afterward and keep validity separate for each location. One disconnected sensor should not turn every remaining reading into a plausible but incorrectly labelled value.

Long cables add electrical complications that a short ideal schematic hides. The manufacturer's long-line 1-Wire guidance discusses the importance of network topology, cabling and the bus master. Do not assume that an arbitrary number of sensors on arbitrary wire lengths will work because their addresses are unique.

Start hardware testing with one sensor and short wiring. Confirm supply voltage, pin orientation, pull-up placement and reliable repeated readings before extending the cable or adding devices.

Review the Simulation's Limits

Changing a model control changes the simulated input. It does not reproduce a probe's thermal mass, contact resistance, waterproof enclosure, airflow or mounting arrangement. Those properties determine how a physical probe responds to its surroundings.

A display that changes immediately in simulation therefore says little about the time needed for a real sensor to reach equilibrium. When comparing hardware against a reference thermometer, place both appropriately and allow the temperatures to stabilize.

Keep invalid data visibly invalid. An old reading may remain useful in a log when accompanied by its timestamp, but it should not be presented as a fresh observation after communication fails. Our example replaces the numerical row with an error message.

Test the Display and Record Reliable Data

Use a Small, Repeatable Test Sequence

Begin with a model input of 25 degrees Celsius and wait for at least two display updates. Change it to zero, then to -10, and finally to a higher value within the model's supported range. Write down the input, displayed number and whether the previous characters were fully replaced.

Next check failure behaviour. Stop the simulation, disconnect the sensor data connection, and restart. The example should report the missing startup sensor instead of displaying a fabricated temperature. Restore the connection and restart again because this simple program does not rediscover a device that was absent during setup.

If the model supports runtime disconnection, you can separately examine a sensor that disappears after successful startup. That exercises the read-error branch instead of the startup branch. The two cases are different, so record which one you actually tested.

Keep Measurement and Display Timing Separate

When adding a data logger, record a timestamp with each accepted measurement and an explicit validity field. A row containing only a number cannot explain whether that number is fresh, repeated from an earlier sample or substituted after an error.

For example, log elapsed milliseconds, temperature in Celsius and a status such as valid or unavailable. On an unavailable row, leave the numerical measurement empty rather than replacing it with zero. Zero degrees Celsius is a legitimate temperature and cannot safely double as a generic failure code.

For a trend graph, decide whether the timestamp describes the conversion request or the completed read. Either convention can be useful, but mixing them creates misleading timing differences. If other sensors are sampled alongside this one, their acquisition delays may also differ.

Finally, avoid averaging invalid readings into a valid sequence. Check status first, then apply any smoothing to accepted measurements. Document the averaging window because a smoother display also responds more slowly to a real temperature change.

Troubleshooting

Frequently Asked Questions

Does 1-Wire mean only one physical connection?

No. It describes the data bus. A ground reference is still required, and our example also uses a separate supply wire.

Can I use an analogue input instead?

An analogue-capable Arduino pin can sometimes be used as a digital pin, but the DS18B20 still communicates digitally. Reading it with analogRead() does not decode its temperature.

Why not display -127 degrees as a measurement?

The DallasTemperature library uses that Celsius value as a disconnected-device sentinel. It is outside the DS18B20 measurement range and should be handled as an error.

Can the simulation replace hardware testing?

It helps check program flow, connections and display formatting. It cannot establish the accuracy, response time or wiring reliability of your physical installation.

Where can I continue with the physical circuit?

See our DS18B20 and Arduino hardware tutorial, while retaining the power, timing and error-handling principles explained here.