Multiple sensor protocol issue

I’ve got a small desktop clock project using the DS1302 RTC. The desktop clock uses serial communication with an LCD (SCL,SDA), I2C with two DS18B20 temperature sensors, and the RTC clock using the virtuabotixRTC.h library. (schematic attached)

// Load Libraries
#include <Wire.h>
#include <LCD.h>
#include <LiquidCrystal_I2C.h>

// Load library for DS1302 real time clock
#include <virtuabotixRTC.h>

// Load Libraries for DS1820 and OneWire
#include <OneWire.h>
#include <DallasTemperature.h>

I’ve been using the DS18B20s in many small projects and never had a problem initializing them. With this clock, however, there seems to be some problem with initializing them, possibly due to all the other serial comm that’s going on. I’ve tried to start them prior to Serial.begin(), afterwards, with delays between them, etc. but my success seems random.

Is there a known issue between these three serial communications initializing during Setup? Interrupts or something?

Thanks.

clock circuit.jpg

Is that really the complete code you're using? Did you read the sticky note at the top of the forum?

Provide links to all libraries you used if they are not part of the standard IDE.

The OneWire bus is quite timing critical so the rest of the software is relevant for us to see to be able to help you.

I’m happy to get a complete review of the code, but the question really was more limited–is there a known issue(s) between the libraries that I’ve included?

Here are the external library links:
LCD-I2C DigisparkArduinoIntegration/LiquidCrystal_I2C.h at master · digistump/DigisparkArduinoIntegration · GitHub
Dallas Arduino-Temperature-Control-Library/DallasTemperature.h at master · milesburton/Arduino-Temperature-Control-Library · GitHub
VirtuabotixRTC https://virtuabotix-virtuabotixllc.netdna-ssl.com/core/wp-content/uploads/2014/01/virtuabotixRTC.zip

Here’s the code:

// Load Libraries
#include <Wire.h>
#include <LCD.h>
#include <LiquidCrystal_I2C.h>

// Load library for DS1302 real time clock
#include <virtuabotixRTC.h>

// Load Libraries for DS1820 and OneWire
#include <OneWire.h>
#include <DallasTemperature.h>
 
// Creation of the Real Time Clock Object
//SCLK -> 6, I/O -> 7, CE -> 8
virtuabotixRTC myRTC(6, 7, 8);
 
// Define variables LCD:
#define I2C_ADDR    0x27  // Define I2C Address where the PCF8574A is
#define BACKLIGHT_PIN     3
#define En_pin  2
#define Rw_pin  1
#define Rs_pin  0
#define D4_pin  4
#define D5_pin  5
#define D6_pin  6
#define D7_pin  7

// Data wire is plugged into pin 4 on the Arduino
#define ONE_WIRE_BUS1 4

// Setup oneWire instance to communicate with devices
OneWire oneWire1(ONE_WIRE_BUS1);
 
// Pass oneWire reference to Dallas Temperature.
DallasTemperature sensors1(&oneWire1);

int n = 1;
int loopi = 0 ;
char data ;
float mytemp1 ;
float mytemp2 ;
float mytemp1a ;
float mytemp2a ;
 
//Initialize the LCD
LiquidCrystal_I2C   lcd(I2C_ADDR,En_pin,Rw_pin,Rs_pin,D4_pin,D5_pin,D6_pin,D7_pin);

// --------------------Setup--------------------------- 

void setup() { 
  delay(100) ; // give LCD time to stabilize
  lcd.begin (20,4);
// Switch on the backlight
  lcd.setBacklightPin(BACKLIGHT_PIN,POSITIVE);
  lcd.setBacklight(HIGH);

  lcd.setCursor ( 0, 0 );
  lcd.print("Ver: Clock.1") ;
  delay(1000) ;
  
  // Start the OneWire library
  sensors1.begin();
  delay(100) ;   // delay added to see if it corrects the random initialization issue
  
// Start the serial hardware
  Serial.begin(9600) ;
  delay(100) ;  // delay added to see if it corrects the random initialization issue

// Set the current date, and time in the following format:
// seconds, minutes, hours, day of the week, day of the month, month, year
// myRTC.setDS1302Time(00, 36, 22, 0, 13, 4, 2014); // temporarily commented out
}
  
// ---------------------Loop-------------------------- 
void loop() {
// This allows for the update of variables for time or accessing the individual elements. 
  myRTC.updateTime(); 
 
// Start printing elements as individuals 
  lcd.setCursor (0,0) ;
  switch (myRTC.dayofweek) {
    case 0:
      lcd.print(" Sunday") ;
      break ;
...
...
    case 7:
      lcd.print("Noday") ;  // no clue yet if the 1302 "day" rolls over to 0 or 1
      break ; }
      
   lcd.print(" ") ;
   if (myRTC.dayofmonth<10) lcd.print(" ") ;
   lcd.print(myRTC.dayofmonth) ;
   lcd.print(" ") ;   
      
  switch (myRTC.month) {
    case 1:
      lcd.print("Jan ") ;
      break ;
...
...
    case 12:
      lcd.print("Dec ") ;
      break ; }     

  lcd.print(myRTC.year) ; 
  lcd.print(" ") ;
  
  lcd.setCursor(6,1) ; 
  if (myRTC.hours<10) lcd.print("0") ;
  lcd.print(myRTC.hours);
  lcd.print(":");
  if (myRTC.minutes<10) lcd.print("0") ;
  lcd.print(myRTC.minutes);
  lcd.print(":");
  if (myRTC.seconds<10) lcd.print("0") ;
  lcd.print(myRTC.seconds);
  
  sensors1.requestTemperatures(); // Send the command to get temperatures
  // delay(700) ;  // delay added to see if it corrects the random initialization issue
  
  mytemp1 = sensors1.getTempCByIndex(0) ;
  mytemp2 = sensors1.getTempCByIndex(1) ;
  mytemp1a = DallasTemperature::toFahrenheit(mytemp1) ; 
  mytemp2a = DallasTemperature::toFahrenheit(mytemp2) ;  

  lcd.setCursor ( 1, 3 ) ;
  if (mytemp1a < 100 && mytemp2a >= 10 ) {
    lcd.print(" ") ; }
  if (mytemp1a < 10 && mytemp1a >= 0) {
    lcd.print("  ") ; }
    lcd.print(mytemp1a,2) ; 
  
  lcd.setCursor ( 12, 3 ) ;
  if (mytemp2a < 100 && mytemp2a >= 10 ) {
    lcd.print(" ") ; }
  if (mytemp2a < 10 && mytemp2a >= 0) {
    lcd.print("  ") ; }
    lcd.print(mytemp2a,2) ;   
}
// ----------------------------------------------------

With this clock, however, there seems to be some problem with initializing them, possibly due to all the other serial comm that's going on.

Can you describe in more detail what problems you have? Does the initialization need more time than you'd expect? Does it not find all sensors?

How did you wire the sensors to the Arduino? What length does the cable have? Did you use two (parasite) or three wires? What kind of cable are you using?

I'm happy to get a complete review of the code, but the question really was more limited--is there a known issue(s) between the libraries that I've included?

I don't know of any issues between these libraries but it's relatively seldom to have exactly this combination of libraries.

The LCD and clock initialize correctly. The actual code that is currently in the unit omits the clock update line (so that it maintains time if power is lost).

The DS19B20s are connected via 2-wire (parasite power) on D4 with a 4.7K pullup. The wire is 22-gauge twisted pair telephone wire, about 3 feet long. (I have used these devices in a star topology up to 60 feet, which works well only if you add a pullup resistor for each leg.) The sensors work great, currently. I can remove power and restart the system and they continue to initialize correctly.

The error I was having was that the system would start up and the first read from the two sensors was +185 degrees F (the max). The next read was -196 (the minimum) for the first index and +185 for the second, which remained that way for all subsequent reads. I can only assume that there is some I2C signalling going on, since the sign bit on the second read is 0. All the other significant bits seem to be 1s.

At one point I reversed the order of the "sensors1.begin()" and the "Serial.begin()", which seemed to fix the problem, but it soon failed. The current sequence (sensors first), with the 100 msec delay between them, works, but I don't know why.

Initialization seems long-ish, about 5 seconds, including the 1.3 seconds of programmed delays and initialization of the LCD. I'm not that familiar with the internals of the Dallas code, so I don't know if several seconds is excessive.


(yes, I had read the "how to use this forum," but a two of details had escaped me. Thanks. :astonished:)

Initialization seems long-ish, about 5 seconds, including the 1.3 seconds of programmed delays and initialization of the LCD. I'm not that familiar with the internals of the Dallas code, so I don't know if several seconds is excessive.

You need almost 3 seconds to read the 2 sensors in parasite mode. The initialization code does some searches and checks for power mode used so it probably needs also more than one second per sensor in parasite mode.

The DS19B20s are connected via 2-wire (parasite power) on D4 with a 4.7K pullup. The wire is 22-gauge twisted pair telephone wire, about 3 feet long. (I have used these devices in a star topology up to 60 feet, which works well only if you add a pullup resistor for each leg.) The sensors work great, currently. I can remove power and restart the system and they continue to initialize correctly.

The cable is OK, I used much longer cables for my sensors and I never had problems. I would expect problems with unshielded cables in a electrically very noisy environment like and industry complex but for home usage this should be great.

At one point I reversed the order of the "sensors1.begin()" and the "Serial.begin()", which seemed to fix the problem, but it soon failed. The current sequence (sensors first), with the 100 msec delay between them, works, but I don't know why.

The I2C should not interfere with the OneWire bus because both have exclusive control over the Arduino while they're used. The serial communication is the only one in your setup that is interrupt based. So you might try to add a Serial.flush() after each block of serial output before you do any OneWire communication again (the OneWire protocol is quite timing critical, so delays caused by interrupts will have consequences in that communication first).

You need almost 3 seconds to read the 2 sensors in parasite mode. The initialization code does some searches and checks for power mode used so it probably needs also more than one second per sensor in parasite mode.

Great insight. I had forgotten that parasite mode is slower. It would be easy to do an experiment to see if direct power mode eliminates the issue, but right now I only have 2-wire cables. If I get around to it, I'll report back.

If I have further issues, I'll give that serial flush a try.