0

My current code that doesn't convince me:

#include <OneWire.h> 

int DS18S20_Pin = 3; //DS18S20 Signal pin on digital 3
unsigned long startTime = 0;
#define MEASURE_PERIOD 250
//Temperature chip i/o
OneWire ds(DS18S20_Pin);  // on digital pin 3

void setup(void) {
  Serial.begin(115200);
}

void loop(void) {
  if((millis() - startTime) >= MEASURE_PERIOD)
    {
        startTime += MEASURE_PERIOD;
        float temperature = getTemp();
        Serial.println(temperature);
    } //just here to slow down the output so it is easier to read

}


float getTemp(){
  //returns the temperature from one DS18S20 in DEG Celsius

  byte data[12];
  byte addr[8];

  if ( !ds.search(addr)) {
      //no more sensors on chain, reset search
      ds.reset_search();
      return -1000;
  }

  if ( OneWire::crc8( addr, 7) != addr[7]) {
      Serial.println("CRC is not valid!");
      return -1000;
  }

  if ( addr[0] != 0x10 && addr[0] != 0x28) {
      Serial.print("Device is not recognized");
      return -1000;
  }

  ds.reset();
  ds.select(addr);
  ds.write(0x44,1); // start conversion, with parasite power on at the end

  byte present = ds.reset();
  ds.select(addr);    
  ds.write(0xBE); // Read Scratchpad


  for (int i = 0; i < 9; i++) { // we need 9 bytes
    data[i] = ds.read();
  }

  ds.reset_search();

  byte MSB = data[1];
  byte LSB = data[0];

  float tempRead = ((MSB << 8) | LSB); //using two's compliment
  float TemperatureSum = tempRead / 16;

  return TemperatureSum;

}

the outcome of few seconds of recording:

22.31
22.31
22.31
22.31
22.31
22.31
22.31
22.31
22.31
22.31
22.31
22.31
22.31
22.31
22.31
22.31
22.31
22.31
22.31
22.31
22.31
22.31
22.31
22.31
22.31
22.31
22.31

EDIT: I inserted the suggestion of @frarugi87 and I inserted the sensor in my pants to test it:

22.50
22.50
22.50
23.69
23.69
23.69
23.75
23.75
23.75
23.75
23.75
23.75
23.81
23.81
23.81
23.81
23.81
23.81
23.81
23.81
23.81
23.87
23.87
23.87
23.87
23.87
23.87
23.87
23.87
23.87
23.87
23.87
23.87
23.94
23.94
23.94
23.94
23.94
23.94
23.94
23.94
23.94
23.94
23.94
23.94
24.00
24.00
24.00
24.06
24.06
24.06
24.19
24.19
24.19
24.25
24.25
24.25
24.31
24.31
24.31
24.44
24.44
24.44
24.50
24.50
24.50
24.56
24.56
24.56
24.56
24.56
24.56
24.62
24.62
24.62
24.69
24.69
24.69
24.75
24.75
24.75
24.81
24.81
24.81
24.87
24.87
24.87
24.87
24.87
24.87
24.94
24.94
24.94
25.00
25.00
25.00
25.00
25.00
25.00
25.06
25.06
25.06
25.12
25.12
25.12
25.12
25.12
25.12
25.19
25.19
25.19
25.25
25.25
25.25
25.25
25.25
25.25
25.31
25.31
25.31
25.37
25.37
25.37
25.44
25.44
25.44
25.44
25.44
25.44
25.50
25.50
25.50
25.50
25.50
25.50
25.56
25.56

I still find the change of temperature slow

1

I would expect some variations in temperature, but I would not say that is a problem caused by the 4Hz readings. You can test my assumption by reading every 3 seconds, does the temperature value change or is it still the same?

I see two potential problems:

  1. your DS1820 is defect.

  2. from your code I assume that you use parasitic power. In that case the chip consumes power from the data wire ( one wire ;-) ) through a pull up resitor (~4.7 kOhms). If you do not provide a special handling, to drive more current while the DS1820 is converting or copying data to EE or from EE memory to the scratchpad, then there will be (most likely) voltage drops. Then the Temperature conversion will not happen and you read the old value from the scratchpad in your read cycle.

You can test point 2 by adding VCC to the DS1820, and do not use parasitic power. If that is your problem, you can fix it with a switching FET Transistor, that provide more current (see DS1820 Datasheet from Maxim) or by using an additional VCC wire.

3
  • There's no variation because it's just measuring the room temperature. Apr 9 '16 at 12:26
  • But the DS18S20 produces heat. So a change of +-0.01 should be probable. Your second time series is very interesting. There are blocks of some measures (3-5) with the same value. Why isn't it increasing continously. It seams that the conversion speed is too high. The first jump is over 1.07 degree, followed by 2 times 0.06 degree, followed by 0.07 degree. Then 2 times 0.6 degree, followed by 0.07 degree and so on. That may be by coincidence but I think it is interesting. Perhaps it's a matter of resolution or conversion time. It's time to reactivate my old DS18S20 and uv your question. ;-) Apr 11 '16 at 17:00
  • I hope it will be the same with your sensor Apr 12 '16 at 12:08
0

Not sure if this is the only problem, but when shifting bytes you will lose the msb. This can be solved by casting the variable to an int.

And moreover you don't need the two variables MSB and LSB.

Try to correct it with this:

float tempRead = ((((int)data[1]) << 8) | data[0]); //using two's compliment
5
  • The temperature change is still slow when I apply the finger. Apr 9 '16 at 12:26
  • @GabrieleGiordano Ok, so it is slow. But.. Is it accurate? I mean, after a lot of time, is the reading correct or not?
    – frarugi87
    Apr 11 '16 at 8:00
  • I suppose yes. Seems also in other fields the reading of skim temperature has a low variance Apr 12 '16 at 12:09
  • If it is accurate, then the problem can be a bad thermal coupling or a high thermal capacitance, even if it seems too high. Can you make measurements at "full speed" and see if the time is the same? Can you try to make a measurement, leave it running for some seconds *just tu see the trend) and then reset the device? If it is a software problem you will see a "jump" in the temperatures, if it is a thermal problem nothing will change the trend
    – frarugi87
    Apr 12 '16 at 12:12
  • "and see if the time is the same?" which time? Apr 13 '16 at 16:36
0

Is it possible to make 4hz readings with the DS18S20 temperature sensor?

Yes, but only at 9-10 bits resolution. See Table 2. Thermometer Resolution Configuration. At full resolution, 12 bits, the conversion time is 750 ms. With the commands, reset, etc, this gives just over 1hz.

I guess this also gives you a hint on what to fix in your sketch.

Cheers!

3
  • unfortunately no, this doesn't give me an input Apr 9 '16 at 12:25
  • for (int i = 0; i < 9; i++) { // we need 9 bytes data[i] = ds.read(); } this is the part to modify? It's the only option I see at the moment Apr 9 '16 at 12:33
  • no I think it's here the hot spot } int16_t raw = (data[1] << 8) | data[0]; if (type_s) { raw = raw << 3; // 9 bit resolution default if (data[7] == 0x10) { // "count remain" gives full 12 bit resolution raw = (raw & 0xFFF0) + 9 - data[6]; } } else { byte cfg = (data[4] & 0x60); if (cfg == 0x00) raw = raw & ~7; else if (cfg == 0x20) raw = raw & ~3; else if (cfg == 0x40) raw = raw & ~1; Apr 9 '16 at 15:00
0

The rate of change of the temperature reading depends on the thermal properties of the sensor package, not on the rate at which you read it. The less expensive, plastic packaged sensors that most of us use will be the slowest to respond to change just because that is the thermal nature of the plastic. Do note that the ground pin of that package has more influence than the package itself, so do your best to ensure the ground pin is exposed to the temperature you're trying to measure, or is at least thermally insulated from the surrounding air, unless the air temperature is what you are trying to measure. If you need faster response to temperature change, you'll need to pay attention to keeping the entire device at or close to the temperature of interest and insulated from surrounding temperatures.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.