How come my DS18S20 code still works?

[Acetronics2]

Hi,

At this time, there's another thread running about the 18S20 or 18B20 ...

just have a look to the methods used ...

http://www.picbasic.co.uk/forum/showthread.php?t=7079

Alain

[Wilson]

Thanks Alain

As I mentioned when I started the thread, I have already searched the forum read all the posts about the 18S20.
The only thing I learned was that someone wrote a piece of code a long time ago and it seems to be the defacto standard- everyone uses it. The samples are the same, comments and all. Thats okay. Cutting and pasting is easy but it doesn't help me learn.

Wilson

[Acetronics2]

Hi, Wilson

Learning is on your own whatever the book ...

so just trying to understand what happens is ... enough !!!

Why not cut and paste ... if you know what you're pasting ...

LOL ...

Following you, ... you also can make it work without Owin ansd Owout ... just toggling pins on the adequate moment ...

Alain

[b1arrk5]

Have you looked at Bruce's website? His Rentron Electronics site has some tutorials on using one wire devices, and explains it very well. He used the 18b20 in his examples, but I was able to get an 18s20 working after reading his explanations. I'm not where I can look it up, but I think the count remaining is a way of checking to see if the temperature conversion is completed or not, instead of just waiting a set amount of time like the 'pause' command does. So just pausing 750ms eliminates the need to check if the conversion is completed. Bruce also has an example that uses DIV32 to get better precision, but for my application anything within three degrees was close enough. Here is the link to the first example.

http://www.rentron.com/PicBasic/PBP1-wire.htm

Jerry.

[Wilson]

Thanks Jerry,

Been there and it helped a little bit but I still don't know what the count_remain is.
You could be right but I'm still not sure. To be honest, I don't think anybody knows exactly what it is. I'll just treat it as a Dallas magic number.

I monitored its value and it jumps around from 1 to 16 when the device temperature rises and falls, but when the temperature stabilises, it just sits around 8 to 9.
Anyhow I think I had a major breakthrough.

The temperature of my device right now reads 002AH
temperature2 = (temperature >> 1) effectively divides the value by 2 and gets rid of the radix point and now equals 0015h beacause of this move.

Because Dallas gave us this formula with the assumption everyone can follow it,
I just used it and hoped for the best.
first I moved 0015h left 8 bits so it becomes 1500h
then subtract 2.5 degree C (100h/4 = 40h =0.25C in Hex)
so 1500h minus 0040h = 14C0h

Dallas says count_per_C = 10h and I picked a number for count_remain - 9h
so 10h minus 9h = 7h then Dallas says to multiply this by 100h then divide 10h
okay, 7h * 100h = 0700h then divide by count_per_C (10h) = 0070h
now I have 14C0h + 70h = 1530h
so the 15h = 21C and the decimal part, 30h = 30h/100h = 48/256 = 0.1875 or 0.19
So my display now shows 21.19 C

DQ VAR PORTB.5 ' One-wire data pin
temperature VAR WORD ' Temperature storage
temperature2 VAR WORD
temperature3 VAR WORD
count_remain VAR BYTE ' Count remaining
count_per_c VAR BYTE ' Count per degree C
fractemp var word

loop:
	 
OWOut DQ, 1, [$CC, $44] ' Start temperature conversion
pause 750 'NEEDED FOR TEMP STABILIZING

waitloop:
OWIn DQ, 4, [count_remain] ' Check for still busy converting
IF count_remain = 0 Then waitloop
OWOut DQ, 1, [$CC, $BE] ' Read the temperature
OWIn DQ, 0, [temperature.LOWBYTE, temperature.HIGHBYTE, Skip 4, count_remain, count_per_c]

temperature2 = (temperature >> 1)

temperature3= (temperature2 <<8 -64) + (((count_per_c - count_remain) * 100) / count_per_c)
fractemp = ((temperature3 <<8 >>8*64) >>8)

lcdout $FE,1, "Raw ", hex(temperature)," ", hex(temperature2), " ", dec(count_remain)
lcdout $FE, $C0, "Real ", dec(temperature2), ".", dec2(fractemp)

goto loop

I don't know how accurate the fraction part is but I reckon the whole number is okay

Bottom line is Jerry, I need someone willing to point out mistakes, offer sugestions or give constructive critisism.

Wilson

[b1arrk5]

Hi Wilson,

I am back where I can access better resources, and I think I can explain this satisfactorily now. The Dallas 18s20 offers a 9 bit thermometer that can measure from -55 degrees C. up to 125 degrees, a total range of 180 degrees C. Nine bit resolution allows for numbers from 0 to 511, so if the temperature is -55 degrees we would read a 0, and a reading of 511 would equate to 125 degrees. However, the ninth bit is used to provide a positive or negative reading, so our resolution now drops to 8 bits, from 0 to 255. Starting at -55 degrees C we should read 0, and +125 degrees will result in 255. Each step is roughly .7, but the device only measures in half degree steps, so as you guessed before, dividing by 2 will get you close. The Dallas 18B20 (a different chip!) offers user selectable resolution of 9 to 12 bits, consequently it can distinguish smaller changes in temperature, less than a half of a degree. The 18S20 uses the Count Remain byte to allow the user to calculate a little better resolution, so if you need to know the difference between say 20.5 degrees and 21.0 degrees you can calculate it if you need to. My guess is that internally the 9 bit chip really converts to higher resolution, and puts the extra bits in the Count Remain byte, but that is only my guess. The steps must be different, that would explain why the Count Per Degree C. is fixed at 10h in their formula.
Realistically most of us don't need that much precision, anything within two or three degrees will be close enough. Dallas/Maxim shows the accuracy as being 0.5 degrees C. in the middle range, and most other manufacturers give an accuracy of +/- 2.0 degrees C. in their high precision sensors.
In my earlier post I was mistaken (happens often!), you can perform time slot reads to see if the conversion is finished, or you can just pause 750ms like you did. Temperature doesn't usually change so fast that you can't waste a few milliseconds waiting for the conversion to finish, however if your application is doing other things as well then reading the time slot will be faster. If you were trying to service USB ports or something then you might not want to pause that long.
I have two identical LABX-USB boards, running identical programs, using two identical 18S20 chips, and they are always two degrees different, even sitting side by side on my bench. Part of this discrepancy is likely due to my conversion to Fahrenheit, but it is close enough for my application.

Jerry.

[Wilson]

Hello Jerry.

Excellent explanation. Now I understand it a lot better.

You are right, I really do not need that much accuracy but it was good to find out how it can be done.

Thanks very much.

Wilson