Dallas 18B20 1-Wire sensor help - pullup???

Wookie

Gang,

I have a question about the Dallas 18B20 1-Wire temperature sensors interfacing with the Propeller.

I ordered some 18B20 epoxy encapsulated sensors that are pre-wired into the parasitic mode (i.e., only 2 wires are comming out of the casing).
As I read through the sensor datasheet, it says

"To assure that the DS18B20 has sufficient
supply current, it is necessary to provide a strong pullup on the 1-Wire bus whenever temperature
conversions are taking place or data is being copied from the scratchpad to EEPROM. This can be
accomplished by using a MOSFET to pull the bus directly to the rail as shown in Figure 4. The 1-Wire
bus must be switched to the strong pullup within 10μs (max) after a Convert T [noparse][[/noparse]44h] or Copy Scratchpad
[noparse][[/noparse]48h] command is issued, and the bus must be held high by the pullup for the duration of the conversion
(tCONV) or data transfer (tWR = 10ms). No other activity can take place on the 1-Wire bus while the pullup
is enabled."

However, everything on the web I have found suggests just using a 4.7K resistor to Vpu does the trick.
I need to be careful that these sensors read correctly (I will have 4 on the bus), but I also want to use as few pins as possible (not wasting one to drive a MOSFET).

Anyone have any experience with these? Tips, experience, or advice would be greatly appreciated!!!
Thanks!!!!

BradC

Wookie said...

However, everything on the web I have found suggests just using a 4.7K resistor to Vpu does the trick.
I need to be careful that these sensors read correctly (I will have 4 on the bus), but I also want to use as few pins as possible (not wasting one to drive a MOSFET).

The data sheet does not lie. A 4.7K pull up is not sufficient to supply the conversion current.
Having said that, I've used a single port pin with a 4.7k pu to +3.3v. You make the port pin an output and high to give the device a hard pullup. Don't think you'd want to do that for 4 devices on the same chain though. For more than 2 devices I use 3 pins. Pull up, Pull Down and Data In.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.

Wookie

I hate it when the data sheet is right

BradC, might you have some code around that I could use to perform your pullup, down, and data routine. As I am still new to spin, it would be a big help. I assume you are just adding in the pullup/down callouts right into the regular 1-wire spin code right?

BradC

Wookie said...
I hate it when the data sheet is right

BradC, might you have some code around that I could use to perform your pullup, down, and data routine. As I am still new to spin, it would be a big help. I assume you are just adding in the pullup/down callouts right into the regular 1-wire spin code right?

No, I wrote my own from the ground up. Although the search routine is *heavily* based on the code structure from the OBEX one wire code, but converted to SPIN.

I've attached the last code I used, but to be honest I don't actually know if it works. It certainly compiles, but from memory I started re-writing it and experimenting with this one and I'm not sure what state I left it in.

The pins are defined in the Start() method.

  Pin := iPin
  pdpin := Pin-1
  pupin := 0

Don't look too closely at the temperature calculations. I seem to recall I was experimenting a bit and I'm not quite sure what I was doing.
This is a polled driver. You need to do a search to determine the devices on line.
Then you start conversion, which runs a conversion cycle on each device on the bus.
One by one you use Select_Chip() and then Get_Temperature

Get_Temperature reads the entire device ram and performs a CRC check to make sure it was a valid read.
It then just calculates the temperature from the buffer. I was experimenting with the extended precision temperature read, but the code looks pretty untidy.

The other thing is this code does not comply with the actual bus speed specifications. I've used it since about April 24/7 on a boat in a noisy environment with the sensors on 15M unshielded cable in a parasite configuration. I've had about 500 poll errors since April, and they are converting top to tail, so convert/read cycles with no pauses. That's not too bad.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.

Wookie

Brad,

Thank you very much for the help!

I will go over this in the morning.

ElectricAye

Be aware that there is a parasitic version and a non-parasitic version of the DS18B20.

Somebody here pointed out to me a couple months ago that even the data sheets for those two versions of the chips are different. So I think you CAN run a normal D18B20 in parasitic mode if you want: you have that option to configure it with the MOSFET, etc. But you MUST run the parasitic (PAR) version of the DS18B20 in parasitic mode: in other words you have NO option with the PAR version.

http://forums.parallax.com/showthread.php?p=833222

I am certain of one thing: the parasitic version of the DS18B20 will NOT work with the same set-up as for the non-parasitic version of the DS18B20 chip.

See this link for the PAR version of the data sheet.

datasheets.maxim-ic.com/en/ds/DS18B20-PAR.pdf

Personally, I have only used the non-parasitic version, so I'm sorry to say I can't help you with code for the parasitic version.

I hope that helps rather than adds to any confusion,
Mark

Post Edited (ElectricAye) : 12/15/2009 1:24:04 AM GMT