Lost data in data logger with ds18b20 sensor

Other Hardware Sensors
1

hello every one. i'm making a simple program to be able to display data from ds18b20 on labview. the data in Labview is successfully displayed but I have a problem when I want to save the data in a txt file, the record results show that the data is always lost for 1 second. has anyone encountered such a problem? please solution.

thanks in advance

image
image1307×618 20 KB

this is my code

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

OneWire ds18b20_pin(2);
DallasTemperature DS18B20(&ds18b20_pin);

float value_temperature;

unsigned long samplingTime_ds18b20;
unsigned long samplingTime_serial;
const unsigned long interval_ds18b20 = 1000;
const unsigned long interval_serial = 1000;

void setup() {
  Serial.begin(9600);
  DS18B20.begin();
}

void loop() {
  DS18B20.requestTemperatures();
  unsigned long currentTime = millis();
  if (currentTime - samplingTime_ds18b20 >= interval_ds18b20) {
    value_temperature = DS18B20.getTempCByIndex(00);
    samplingTime_ds18b20 = currentTime;
  }
  if (currentTime - samplingTime_serial >= interval_serial) {
    Serial.println(value_temperature);
    samplingTime_serial = currentTime;
  }
}
2

Now I know the difference is small but instead of samplingTime_serial = currentTime; which is an old time. Consider the time it takes to print Serial.println(value_temperature); plus/minus the +/-5micro second millis() error and eventually the time will slip away.

The same may be said for the above, no telling how long the DS18B20.getTempCByteIndex(100) takes plus/minus 5 micro seconds millis() drift.

What I've done in the past when using millis() and to account for code latency time is to, at the start of loop() store the starting loop() millis(), at the end of the loop() subtract current millis() from the starting loop millis and use the difference to adjust the desired timing rates.

3

This looks more like a LabView question/issue. Is the problem readily repeatable? If so, do you see the same problem if you use the Arduino IDE serial monitor (or any other serial monitor program) if you take LabView out of the equation?

4

I don't understand what you mean sir, do you have a reference that I can reads or maybe a tutorial to solve it

5

currently I don't have a datalogger device, but when I used a datalogger this problem also appeared when using the ds18b20. for normal data analog type sensors nothing disappears

6

Sorry, I am unable to help you. Good luck.

7

That wasn't really what I asked.

If you connect your Arduino to your PC, then download the code you posted in #1, do you observe missing seconds on the Arduino IDE serial monitor?

8

Ok, I think I may know what is happening. I connected up an old 328P based board that has a DS18B20 on it and ran your code from post #1 but modified to reflect the pin I have my DS18B20 wired to. This is a section of what I saw on the serial monitor:

15:00:56.824 -> 20.56
15:00:57.843 -> 20.62
15:00:58.910 -> 20.56
15:00:59.935 -> 20.56
15:01:00.959 -> 20.56
15:01:01.985 -> 20.56
15:01:03.010 -> 20.56
15:01:04.079 -> 20.56
15:01:05.100 -> 20.56
15:01:06.126 -> 20.56

Note the apparently "missing" reading from 15:01:02.

It's not really missing. If you look carefully at the previous reading, the timestamp is almost 15:02:00 but not quite. There is slightly over 1 second between readings. So what I think is happening is that the next reading after 15:01:01.985 + slightly more than 1 second shows up as 15:01:03.010.

You are probably seeing something similar in your LabView logging but it's not that obvious because the log is showing whole seconds.

9

Something to take into account with your timing is that requestTemperatures takes 750mS. By the look of your data, either the library or the sensors take care of ignoring another request if one is in progress.

10

ok thanks for your suggestion, i will try to take a slow look and compare labview with serial monitor again. thank you

11

I still don't understand your whole point sir. can you give me an example ?

13

See if this mod makes a difference:

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

OneWire ds18b20_pin(2);
DallasTemperature DS18B20(&ds18b20_pin);

float value_temperature;

unsigned long samplingTime_ds18b20;
unsigned long samplingTime_serial;
const unsigned long interval_ds18b20 = 1000;
const unsigned long interval_serial = 1000;

void setup() {
  Serial.begin(9600);
  DS18B20.begin();
  DS18B20.requestTemperatures();
  delay(1000);
}

void loop() {
  unsigned long currentTime = millis();
  if (currentTime - samplingTime_ds18b20 >= interval_ds18b20) {
    value_temperature = DS18B20.getTempCByIndex(00);
    samplingTime_ds18b20 = currentTime;
    DS18B20.requestTemperatures(); // <<<< moved to here 
                                   // results will be ready
                                   // 750ms from now 
  }
                                               
  if (currentTime - samplingTime_serial >= interval_serial) {
    Serial.println(value_temperature);
    samplingTime_serial = currentTime;
  }
}
14

I think it would be more accurate to do:

samplingTime_ds18b20 = samplingTime_ds18b20 + interval_ds18b20;
15

It would in the long run, but with the inaccuracy of the "resonator" clock source, it probably wouldn't make a noticeable difference.

16

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.