NOt sure this relates to the Moteino specifically, however I am getting something that makes no sense to, and hoping someone can shed some light. I am testing for a failed temp sensor, which I have, it's unplugged and the "if (tempC == -127) works, but whenever I add a simple print statement it produces garbage on the screen? I am only doing a snippet of code, if more is needed let me know.
/*-----( Import needed libraries )-----*/
#include <OneWire.h>
#include <DallasTemperature.h>
#include <RFM69.h>
#include <LowPower.h>
#include <SPI.h>
#include <SPIFlash.h>
#include <avr/wdt.h>
#include <WirelessHEX69.h>
....
sensors.requestTemperatures(); // Send the command to get temperatures
float tempC = sensors.getTempC(deviceAddress);
// Returns -127 from DallasTempature.h if fails to collect data
// Measurement failed or no device found
if (tempC == -127.00) {
// This test triggers when no DS18 connected, but garbage comes out with simple println// see attached image
Serial.print("Test....");
Serial.println();
} else {
// This test triggers when a DS18 is connected, and works fine... Serial.print(probeNum);
Serial.print(":C=");
Serial.print(tempC);
Serial.print("/F=");
Serial.println(DallasTemperature::toFahrenheit(tempC)); // Convert to F
}
Quote from: lilpint97 on January 27, 2014, 12:38:11 PM
// Measurement failed or no device found
if (tempC == -127.00) {
// This test triggers when no DS18 connected, but garbage comes out with simple println
// see attached image
Serial.print("Test....");
Serial.println();
Shouldn't the "Serial.println();" be "Serial.println(tempC);" ?
I tried that, I was trying to make it basic, because no matter what I put in that part of the if block it spits garbage like the baud rate is wrong or some such.
That's pretty weird. If you remove the if statement and just leave the code called by the "else", does it spit out garbage when the DS18 is removed?
Just a wild guess, maybe with no sensor some of the dallas functions return garbage and mess up your program.
After you call sensors.begin() perhaps you should call sensors.getDeviceCount() to make sure at least one sensor is found.
If I'm not mistaken you need to wait after calling for temperatures before the actual data calls are valid. I've got a 750ms delay in my code between the call to get temperatures and any use of the data created by that call. I was having the same problem with my data until I did that.
sensors.requestTemperatures(); // Send the command to get temperatures
delay (750); Wait for valid data
float tempC = sensors.getTempC(deviceAddress); // grab data
Hopefully that gets you going....been there.
@lilpint97, I think hexibot might be on to something. But could you please provide the entire sketch also. It might be easier to spot any trouble.
That delay(750) fixed it, thanks a lot for the help.
Thought I would update the info I gave you.
The DS18b20 defaults to 9-bit resolution.
@ 9 bit resolution wait time is 93.75ms
@10bit resolution wait time is 187.5ms
@11bit resolution wait time is 375ms
@12bit resolution wait time is 750ms
So based on that data I only had to wait 93.75ms, and not 750ms. Perhaps that might be all the delay you need.
Great information thanks.
Quote from: hexibot43 on February 07, 2014, 11:00:55 PM
The DS18b20 defaults to 9-bit resolution.
Incorrect. Default is 12-bit resolution. The following is from page 8 of the Maxim DS18B20 datasheet:
QuoteCONFIGURATION REGISTER
Byte 4 of the scratchpad memory contains the configuration register, which is organized as illustrated in Figure 8. The user can set the conversion resolution of the DS18B20 using the R0 and R1 bits in this register as shown in Table 2. The power-up default of these bits is R0 = 1 and R1 = 1 (12-bit resolution). Note that there is a direct tradeoff between resolution and conversion time. Bit 7 and bits 0 to 4 in the configuration register are reserved for internal use by the device and cannot be overwritten.
Yes, that is correct for the actual sensor itself if directly accessing it. But when you use the DallasTemperature.h library it has a default of 9 bit. I including a section of code from an
example on using it.
http://milesburton.com/Dallas_Temperature_Control_Library (http://milesburton.com/Dallas_Temperature_Control_Library)
#include <OneWire.h>
#include <DallasTemperature.h>
// Data wire is plugged into pin 2 on the Arduino
#define ONE_WIRE_BUS 2
// Setup a oneWire instance to communicate with any OneWire devices (not just Maxim/Dallas temperature ICs)
OneWire oneWire(ONE_WIRE_BUS);
// Pass our oneWire reference to Dallas Temperature.
DallasTemperature sensors(&oneWire);
void setup(void)
{
// start serial port
Serial.begin(9600);
Serial.println("Dallas Temperature IC Control Library Demo");
Start up the library
sensors.begin(); // IC Default 9 bit. If you have troubles consider upping it 12. Ups the delay giving the IC more time to process the temperature measurement
}
void loop(void)
{
// call sensors.requestTemperatures() to issue a global temperature
// request to all devices on the bus
Serial.print("Requesting temperatures...");
sensors.requestTemperatures(); // Send the command to get temperatures
Serial.println("DONE");
Serial.print("Temperature for Device 1 is: ");
Serial.print(sensors.getTempCByIndex(0)); // Why "byIndex"? You can have more than one IC on the same bus. 0 refers to the first IC on the wire
}
It is in the coding of the DallasTemperature.h library. I was scratching my head after reading your post myself. Thinking I'm really getting old.