Im have my feather 328p running 2 ds18b20 temp sensor saving to a sd card, when the board is running off my usb from my computer the sketch works fine and the sensor report back with the correct temp but I am trying to run the board off of an adafruit tpl5110 to keep the power draw down. With the tpl5110 in the circuit the sensors are reporting back with 85 degrees. What would be causing this communication error?
#include <OneWire.h>
#include <DallasTemperature.h>
#include <SPI.h>
#include <SD.h>
#include "RTClib.h"
#define ONE_WIRE_BUS 4
File myfile;
const int chipSelect = 10;
RTC_PCF8523 rtc;
OneWire oneWire(ONE_WIRE_BUS);
DallasTemperature sensors(&oneWire);
void setup(void)
{
pinMode( 3, OUTPUT);
// start serial port
Serial.begin(9600);
sensors.begin();
Serial.print("Initializing SD card...");
if (!SD.begin(10)) {
Serial.println("initialization failed!");
while (1);
}
Serial.println("initialization done.");
}
void loop(void)
{ myfile = SD.open("out1.txt", FILE_WRITE);
if (myfile) {
sensors.requestTemperatures();
delay(25);
//Printing temp/time
DateTime now = rtc.now();
Serial.print(now.month(), DEC);
Serial.print('/');
Serial.print(now.day(), DEC);
Serial.print(" ");
Serial.print(now.hour(), DEC);
Serial.print(':');
Serial.print(now.minute(), DEC);
Serial.print(" ");
Serial.print(sensors.getTempCByIndex(0));
Serial.print(" ");
Serial.print(sensors.getTempCByIndex(1));
Serial.print("C");
Serial.println('\n');
// Saving to SD
myfile.print(now.month(), DEC);
myfile.print('/');
myfile.print(now.day(), DEC);
myfile.print(" ");
myfile.print(now.hour(), DEC);
myfile.print(':');
myfile.print(now.minute(), DEC);
myfile.print(" ");
// taking temp
myfile.print(sensors.getTempCByIndex(1));
myfile.print(" ");
myfile.println(sensors.getTempCByIndex(0));
//myfile.print(" ");
//myfile.print(sensors.getTempCByIndex(1));
//myfile.print("C");
myfile.println('\n');
delay(1000);
myfile.close();
}
else { Serial.println("error opening file");
}
delay(1000);
digitalWrite(3, HIGH);
}
timmerflyer:
What would be causing this
It is probably caused by your failure to read to read the data sheet. You have not allowed the sensor time to do its job. If you move the delay(1000) to the top of the loop, it should be OK.
further reflection: By "time to do its job", I mean time from power-on, not the loop, and you should only see the 85 once. You don't often have to worry about it as the time is usually covered in setup.
If you are getting the 85 consistently, it would appear that you have a serious problem in the power supply and the sensor is the victim
Your delay(25) and activities on pin3 all seem pointless, but I guess not part of the problem.
What is the need of this delay: delay(1000);?
If using Dallas Library for the DS18B20, then this instruction: ** sensors.requestTemperatures();**
takes as much time as is required (that depends on the resolution) for the conversion of temperature signal. After that the temperature is ready to read.
How long does the tpl5110 keep the power on?
Read reply #3 again..
I now believe that, if you are seeing 85 consistently, this does not indicate a serious problem in the power supply.......
GolamMostafa:
What is the need of this delay: delay(1000);?
1000ms is a nice sensible round number that everybody understands, and covers all sins.
If using Dallas Library for the DS18B20, then this instruction: sensors.requestTemperatures();
takes as much time as is required (that depends on the resolution) for the conversion of temperature signal. After that the temperature is ready to read.
This implies that anybody who uses the Dallas Temperature library will never have the 85 problem, but they do, so I guess it isn't true. This may be because it is not relevant to the problem, which is the memory map, not the temperature conversion per se.
Nick_Pyner:
It is probably caused by your failure to read to read the data sheet. You have not allowed the sensor time to do its job. If you move the delay(1000) to the top of the loop, it should be OK.
further reflection: By "time to do its job", I mean time from power-on. and you should only see the 85 once. You don't often have to worry about it as the time is usually covered in setup.
If you are getting the 85 consistently, it would appear that you have a serious problem in the power supply and the sensor is the victim
Your delay(25) and activities on pin3 all seem pointless, but I guess not part of the problem.
Adding the delay (1000) at the beginning of the loop solved the problem, thanks very much
Good.
I might point out that, contrary to my comment, the datasheet does not really explain this, but it is alluded to in table1 and fig7.
timmerflyer:
Adding the delay (1000) at the beginning of the loop solved the problem, thanks very much
What happens if you add that delay to the end of your 'setup' area, instead of at the beginning of the loop?
Adding initialisation delays in the software code for providing some time for 'settling' during system power-up is/was quite typically done ---- to give certain hardware devices (serial communications devices etc) some time to start up and become running properly. If certain operations were/are carried out before those devices are in a state to function properly, then the results would be ........ glitchy stuff, things not working, etc.
It's not because us users aren't capable of understanding that kind of thing. It's just that those idiots that write the manuals don't properly explain the need for delays to be put strategically in particular spots of our code, which is the life story of many operating manuals, instructions etc. They just want users to find out the 'hard way' or the 'long way'. But after encountering that sort of thing once or a few times, we'll know all about it.
Southpark:
What happens if you add that delay to the end of your 'setup' area, instead of at the beginning of the loop?
Adding initialisation delays in the software code for providing some time for 'settling' during system power-up is/was quite typically done
That would be fine. As I said, other activities in the setup may cover this anyway, e.g. a splash screen on LCD, and you don't get to see the problem. However, you would expect some sort of timing control in the loop and the delay was in place - just the wrong place. Putting it in the right place serves both purposes, which is the common practice.
Having said that, I suspect this project may actually be being controlled by that power thingy, the loop is redundant, and the whole programme could be in the setup, hence your point.
It's not because us users aren't capable of understanding that kind of thing. It's just that those idiots that write the manuals don't properly explain the need for delays to be put strategically in particular spots.
Indeed.
Nick..... your suggestion about delay was spot on! Totally agreed with what you wrote and recommended.