DS18b20 parasitic power P1AM-100

I've read most topics regarding these devices not working with Arduino. I've tried the following:

1:) The Sensors work currently on the DFR0162 X-Board V2. I know the sensors and program work within the resistor range of .8k to 2k

2:) I've tried a logic shifter because of the 5v not being available on the P1AM-100. I've also confirmed the logic shifter does work both before and after testing with the sensors. The logic shifter will also work on two sensors with a short run to a breadboard. The logic shifter is 3v to 5v using an external power supply.

3:) If there are two sensors on a breadboard wired the same it will work on the P1AM-100. The program works on the 3v Arduino too.

4:) I've tried lots of resistor ranges. Using a POT helps to find the resistor value needed.

What I have is (12) DS18b20 ran throughout the house over cat5. It has been (and still is) working for years over a HA7E to a computer. Wanting to migrate to an Arduino system. This is a long run, wired up as parasitic power. I'm using the standard example from the OnWire library.

I have read most topics that refer to changing the resistor value. I have used a POT and tried from 10ohms to 35k.

Any help is appreciated.

There are several omissions in your post:

  • No wiring diagram of your setup
  • No links to the used hardware
  • No code (including links to the used librarries)

I have used a POT and tried from 10ohms to 35k.

A 10Ω pull-up probably fried your Arduino pin if no level converter was in place. If it was in place it depends on the level converter's circuitry (which we don't know).

The DS18B20's are wired Parasitic power, like the attached image. The only difference is the power supply used when attached directly to the P1AM which has 3.3v inputs only. When attached to the HA7E it uses the voltage supplied by the serial port, and when attached to the DFR0162 or logic shifter it will use 5v. The manual from maxim states that the DS18B20's will operate as low as 3v.

Here is the standard example that is being used in the Arduino.

The input put pin works fine after all testing This was tested with 2 DS18B20's on a breadboard. No pins were "fried" in these experiments. Would 3.3v fry the Arduino input pin?

#include <OneWire.h>
// OneWire DS18S20, DS18B20, DS1822 Temperature Example//// http://www.pjrc.com/teensy/td_libs_OneWire.html//// The DallasTemperature library can do all this work for you!// https://github.com/milesburton/Arduino-Temperature-Control-Library
OneWire  ds(10);  // on pin 10 (a 4.7K resistor is necessary)
void setup(void) {  Serial.begin(9600);}
void loop(void) {  byte i;  byte present = 0;  byte type_s;  byte data[12];  byte addr[8];  float celsius, fahrenheit;    if ( !ds.search(addr)) {    Serial.println("No more addresses.");    Serial.println();    ds.reset_search();    delay(250);    return;  }    Serial.print("ROM =");  for( i = 0; i < 8; i++) {    Serial.write(' ');    Serial.print(addr[i], HEX);  }
  if (OneWire::crc8(addr, 7) != addr[7]) {      Serial.println("CRC is not valid!");      return;  }  Serial.println();   // the first ROM byte indicates which chip  switch (addr[0]) {    case 0x10:      Serial.println("  Chip = DS18S20");  // or old DS1820      type_s = 1;      break;    case 0x28:      Serial.println("  Chip = DS18B20");      type_s = 0;      break;    case 0x22:      Serial.println("  Chip = DS1822");      type_s = 0;      break;    default:      Serial.println("Device is not a DS18x20 family device.");      return;  } 
  ds.reset();  ds.select(addr);  ds.write(0x44, 1);        // start conversion, with parasite power on at the end    delay(1000);     // maybe 750ms is enough, maybe not  // we might do a ds.depower() here, but the reset will take care of it.    present = ds.reset();  ds.select(addr);      ds.write(0xBE);         // Read Scratchpad
  Serial.print("  Data = ");  Serial.print(present, HEX);  Serial.print(" ");  for ( i = 0; i < 9; i++) {           // we need 9 bytes    data[i] = ds.read();    Serial.print(data[i], HEX);    Serial.print(" ");  }  Serial.print(" CRC=");  Serial.print(OneWire::crc8(data, 8), HEX);  Serial.println();
  // Convert the data to actual temperature  // because the result is a 16 bit signed integer, it should  // be stored to an "int16_t" type, which is always 16 bits  // even when compiled on a 32 bit processor.  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) + 12 - data[6];    }  } else {    byte cfg = (data[4] & 0x60);    // at lower res, the low bits are undefined, so let's zero them    if (cfg == 0x00) raw = raw & ~7;  // 9 bit resolution, 93.75 ms    else if (cfg == 0x20) raw = raw & ~3; // 10 bit res, 187.5 ms    else if (cfg == 0x40) raw = raw & ~1; // 11 bit res, 375 ms    //// default is 12 bit resolution, 750 ms conversion time  }  celsius = (float)raw / 16.0;  fahrenheit = celsius * 1.8 + 32.0;  Serial.print("  Temperature = ");  Serial.print(celsius);  Serial.print(" Celsius, ");  Serial.print(fahrenheit);  Serial.println(" Fahrenheit");}

The DS18B20's are wired Parasitic power, like the attached image

There is no attachment.

Would 3.3v fry the Arduino input pin?

The voltage won't fry the pin, it's the current. If you draw more than 40mA from one pin it will be gone. As parasitic power means the pin is sinking that power during a low phase the pull-up resistor you install is important.

pylon:
The voltage won't fry the pin, it's the current. If you draw more than 40mA from one pin it will be gone. As parasitic power means the pin is sinking that power during a low phase the pull-up resistor you install is important.

If the calculations are correct at 10 Ohms it is only a 33ma load at 3.3 v, which still falls under those limits. Right?

If the calculations are correct at 10 Ohms it is only a 33ma load at 3.3 v, which still falls under those limits. Right?

3.3V/10Ω = 0.33A = 330mA which is far above the limit!

Fortunately, the DIN still works. So is there anything to suggest to try?

derekmm:
Fortunately, the DIN still works. So is there anything to suggest to try?

What's DIN in this context?

Format your code to make it readable. The IDE offers an tool to help you (AutoFormat in the Tools menu).

Do you know the DallasTemperature library?

For this temp sensor to function you need to get the sensor address. You will need to map each address and enter this in the p1am program. Without the address the one wire sensor will not return any usable info.
Google Dallas one wire address finder and you should be able to download the program. Query the sensor and write down the address. I use tape so I don't get mixed up as I build the circuit. Best temp sensor I have used and very accurate.

pylon:
What’s DIN in this context?

Digital Input

robnevada:
For this temp sensor to function you need to get the sensor address. You will need to map each address and enter this in the p1am program. Without the address the one wire sensor will not return any usable info.
Google Dallas one wire address finder and you should be able to download the program. Query the sensor and write down the address. I use tape so I don't get mixed up as I build the circuit. Best temp sensor I have used and very accurate.

Agreed; the sensors are physically labeled with their address. The program works flawlessly on the X-Board, just not the P!AM. Thank you for the suggestions.

pylon:
Do you know the DallasTemperature library?

I do not know the library in-depth. There have been some posts regarding timing within the library to offset processor speeds, but they are older posts and do not match the current library. Again; I am using stock code. It was simply copied and pasted from the examples provided. Once the sensors are working correctly on the P!AM, then I will start cleaning code and making changes that are better suited for this application. Until then I'll keep it simple.

I do not know the library in-depth. There have been some posts regarding timing within the library to offset processor speeds, but they are older posts and do not match the current library. Again; I am using stock code. It was simply copied and pasted from the examples provided. Once the sensors are working correctly on the P!AM, then I will start cleaning code and making changes that are better suited for this application. Until then I'll keep it simple.

The library that might depend on processor speeds is the OneWire library. The DallasTemperature simply depends on it and does the part that is specific to the DS18B20 sensors. I strongly recommend to use it as does it's stuff correctly.

Please format your code to make it readable, the IDE may help you with the AutoFormat tool in the Tools menu.

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