WAY OT: pushing data bits

I have a meager understanding of this subject so bear with me. I've been trying to get a Basic stamp to talk to a 1wire maxim DS1822 temperature
sensor with no success. With a huge number of trials I always get the same data back from the sensor. (several different sensors, wirings, temperatures at sensor) See below for output of data bits and program listing.
I keep checking one more theory per day. Its got me pissed, I'm going to crack this nut if it kills me. Today's theory, "Maybe the command to tell the DS1822 sensor to resample temp. isn't working " It would be this command: 'Send Convert Temperature command OWOUT OWpin, OWFERst, [SkipROM, ConverT]
If the sensor never resamples, it would explain why I always get the same data IF they come factory preset here.
OK, for the bit head types out there. How does one check if a sensor is receiving and acting on a bit level command? I must be getting data from the unit as its a non random string of 0 and 1.
Karl
Data sheet: http://datasheets.maxim-ic.com/en/ds/DS1822.pdf
1. Output of stamp program
1 1 1010000 101 1001011 1111111 11111111 111100 1000000 1110000 11111100
2. program listing
' File...... ds1920.bsp ' Purpose... Measuring of Temperature with DS1920 iButton ' Author.... Claus Kuehnel ' Started... 2001-08-11 'CHOPPED UP FOR DIAGNOSIS 1 26 10
' '{$STAMP BS2px} 'specifies a BS2p ' -----[ Constants ]------------------------------------------ ' OWpin CON 15 '1-wire device pin
OWFERst CON %0001 'Front-End Reset OWBERst CON %0010 'Back-End reset OWBitMode CON %0100 SkipROM CON $CC 'Skip ROM Command ReadScratch CON $BE 'Read Scratch Pad ConverT CON $44 'Convert Temperature ' -----[ Variables ]------------------------------------------ ' temp VAR Word 'Temperature Value CRem1 VAR Byte CRem2 VAR Byte CRem3 VAR Byte CRem4 VAR Byte CRem5 VAR Byte CRem6 VAR Byte CRem7 VAR Byte CRem8 VAR Byte CRem9 VAR Byte
' -----[ Initialization ]------------------------------------- ' init: PAUSE 1000 'open debug window
' -----[ Main Code ]------------------------------------------ ' Start: 'Send Convert Temperature command OWOUT OWpin, OWFERst, [SkipROM, ConverT]
DEBUG CLS CheckForDone: 'Wait until conversion is done PAUSE 2 OWIN OWpin, OWBitMode, [Temp] DEBUG CR, BIN temp 'conversion time IF Temp = 0 THEN CheckForDone 'Send Read Scratch Pad command OWOUT OWpin, OWFERst, [SkipROM, ReadScratch] OWIN OWpin, OWBERst, [CRem1,CRem2,CRem3,CRem4,CRem4,CRem5,CRem6,CRem7,CRem8,CRem9]
DEBUG CR, BIN Temp DEBUG CR, BIN CRem1 DEBUG CR, BIN CRem2 DEBUG CR, BIN CRem3 DEBUG CR, BIN CRem4 DEBUG CR, BIN CRem5 DEBUG CR, BIN CRem6 DEBUG CR, BIN CRem7 DEBUG CR, BIN CRem8 DEBUG CR, BIN CRem9
PAUSE 5000 'next measurement in 5 sec GOTO Start
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
wrote:

Can you get the correct response from 33h Read ROM?
jsw
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On 1/27/2010 4:09 AM, Jim Wilkins wrote:

Karl say 'no'.
Karl > "I've been trying to get a Basic stamp to talk to a 1wire maxim DS1822 Karl > temperature sensor with no success."
--Winston
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
wrote:

Can you get the correct response from 33h Read ROM?
jsw
I played with this a bit but abandoned this route. The data came out the same no matter which sensor (should be different) but also diddn't make sense. NOTE: The example programs were extremely complex so I'm sure I could have program errors. I also ran several "find serial no." example programs. They were unable to record a serial number. Again a complex program (for me)
If there's something worth looking at, I'll investigate more here. My thinking was get a simple one sensor circuit to work before playing with multiple units and serial numbers on the same bus.
Karl
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On 1/27/2010 3:40 AM, Karl Townsend wrote:

Schematic, please.
Is your 'Vdd' pin properly grounded?
Do you have the required 5K data pullup resistor in place between system Vdd and the data pin? How about the FET in parallel with the pullup to provide the 'strong pullup' for data conversion?
Do you get the same pulse string when your sensor is disconnected from your processor?
--Winston
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

I've tried two ways, see the DS1822.pdf. There are three pins on the 1822. It can be run in parasite mode with the power pin grounded, or in power mode. Both ways call for a 4.7 Kohm pull-up resistor from 5 volt to data line.

My son is mailing my logic probe but I get 0 resistance to known ground on VOA meter.

Yes, 4.7 actually.

??? Don't understand you here. Both the resistor and the DS1822 have one leg on 5V and one leg on data so that would be a parallel connection. I didn't show a program I chopped up from a 1wire weather station to a stamp. It was written slightly different with turning the data pin into an output for a strong pull-up prior to the OWOUT command. This program gives same results.

No, that gives a long string of "1"s. Also get all "1"s with sensor in backward.

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

other program clip:
' ******************************** ' Retrieve and display temperature ' ******************************** ' Show_Temp: eeAddr = DS1820 ' load device serial number GOSUB Load_SN
OWOUT OWpin, OW_FERst,[MatchROM, STR romData\8, CnvrtTemp]
HIGH OWpin ' extra juice during conversion PAUSE 750 INPUT OWpin
OWOUT OWpin, OW_FERst,[MatchROM, STR romData\8, RdScratch] OWIN OWpin, OW_BERst,[tLo, tHi]
tSign = sign ' save sign bit tempIn = tempIn >> 1 ' round to whole degrees IF (tSign = 0) THEN NoNeg1 tempIn = tempIn | $FF00 ' extend sign bits for negs
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On 1/27/2010 10:53 AM, Karl Townsend wrote:

So we are powering the DS1822 separately, not in 'parasite' mode. One remaining mystery is why we aren't resetting the sensor. It doesn't have to work properly if we choose not to !INIT it.

I don't see where your program sends an !INIT pulse to reset the sensor.
Show_Temp: eeAddr = DS1820 ' load device serial number GOSUB Load_SN
OWOUT OWpin, OW_FERst,[MatchROM, STR romData\8, CnvrtTemp]
HIGH OWpin ' extra juice during conversion PAUSE 750 INPUT OWpin
OWOUT OWpin, OW_FERst,[MatchROM, STR romData\8, RdScratch] OWIN OWpin, OW_BERst,[tLo, tHi]
tSign = sign ' save sign bit tempIn = tempIn >> 1 ' round to whole degrees IF (tSign = 0) THEN NoNeg1 tempIn = tempIn | $FF00 ' extend sign bits for negs
(...)
--Winston
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
I've left the unit set up with power to the DS1822, non parasite mode. Communication with Don Foreman and others says this is the best most reliable way.
OWIN and OWOUT are stamp commands written just for 1wire comm. They talk about this pulse in the mode parameter. See below but it doesn't copy well to text. Or there's a link to the manual on this page: http://www.parallax.com/tabid/440/Default.aspx
I've found four stamp programs that do 1wire. They all just use the OWIN and OWOUT commands.Note the second program example turns the comm. pin into an output to give extra power to the 1wire device while doing a temperature sample. This shouldn't be necessary in non parasite mode.
Now, I agree the DS1822 must not be receiving, or is not acknowleding this pulse. I'm just stuck, don't know what else to try.
Karl
OWIN - BASIC Stamp Command Reference
Page 296 . BASIC Stamp Syntax and Reference Manual 2.2 . www.parallax.com
This code will transmit a "reset" pulse to a 1-Wire device (connected to I/O
pin 0) and then will detect the device's "presence" pulse and then receive
one byte and store it in the variable result.
The Mode argument is used to control placement of reset pulses (and
detection of presence pulses) and to designate byte vs. bit input and
normal vs. high speed. Figure 5.19 shows the meaning of each of the 4
bits of Mode. Table 5.64 shows just some of the 16 possible values and
their effect.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
wrote:

It's time to drag out the oscilloscope.
If you don't have one, 2 channels, 20MHz should be enough. Be sure you get at least two good probes, 3 is better. At that speed they can be different types and lengths.
I would use another Stamp output as a trigger just before the start of your data stream.
jsw
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On Wed, 27 Jan 2010 14:42:05 -0800, Jim Wilkins wrote:

Ditto. For this task the cheapest digital scope that you can find may be better than a fancy analog one -- it's nice to be able to capture the whole transaction once and spend your time looking at it.
That having been said, I've done a lot of this sort of debugging with analog scopes.
--
www.wescottdesign.com

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

I've been using digital scopes for decades and still have a little trouble figuring out new ones, most recently a LeCroy. You really have to know what you should be seeing to confirm that the scope is set right, and isn't aliasing or triggering on some glitch.
My wild guess was that the problem is power or levels or slow risetime or such, all easily seen on an analog scope without examining the whole bit stream. If those check out the transmission can be broken into short loops for closer examination. Once you know that each block of code produces the correct output a digital scope is valuable to look where the target should reply.
I'd send the simplest command that should get a response, IOW a 'ping', which is why I suggested the ROM code. If you have a second trigger output you can move it around the data stream and magnify the area of interest on the analog scope display. With a digital scope you can use it to mark a position within a long data stream, since otherwise tracking your place in several feet of captured data scrolling across the small screen window is very difficult.
I own a 25MHz Phillips analog and a 1G HP digital scope. I almost always use the analog one because the HP is so awkward to operate.
jsw
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On Sun, 31 Jan 2010 06:12:32 -0800 (PST), the infamous Jim Wilkins

Jim, what windage and elevation click settings are you using? Your target should never be able to reply if they're set correctly.
<gd&r>
-- Imagination is the beginning of creation. You imagine what you desire, you will what you imagine and at last you create what you will. -- George Bernard Shaw
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
wrote:

Usually they reply with a flick of the tail as they run out of sight. This is shotgun / muzzleloader / bow country, the underbrush is too dense for a scope anyway.
Target in this case means the device being addressed, or programmed.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On Sun, 31 Jan 2010 09:59:48 -0800, Larry Jaques

If it has clicks, it's a digital scope, right?
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On Sun, 31 Jan 2010 23:17:36 -0600, the infamous Don Foreman

Damned literalists. You're not supposed to be _thinking_ here. Just enjoy the joke, will ya? ;)
-- Imagination is the beginning of creation. You imagine what you desire, you will what you imagine and at last you create what you will. -- George Bernard Shaw
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
By the way, your goodies were mailed on Wednesday.
On Wed, 27 Jan 2010 17:19:23 -0500, "Karl Townsend"

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On 1/27/2010 10:24 AM, Karl Townsend wrote:
(...)

So, *both* the Vdd and GND pins of the DS1822 are grounded, yes? We are in 'parasite' mode, correcto?

See the first schematic on page 6, if you would please: http://datasheets.maxim-ic.com/en/ds/DS1822.pdf
In 'parasite' mode the chip needs a low impedance Vdd source connected to the data pin for at least 750 mS before each reading. The FET is needed since we have both the GND and Vdd pins of the DS1822 at GND potential.
Your program needs to turn on that separate output pin to drive the FET 'on' and then 'off' for the required amount of time before you take your reading.

Oopsy. We should see a 480 uS long negative going pulse on the data line every time your microcontroller reads the DS1822. All bets are off if we don't !INIT the chip.
--Winston
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

I've tried both ways. Current set up is NON parasite mode.
...

Maybe I'm not understanding right, but I'm thinking the stamp does this as part of the OWIN command. I have no way to verify.
...

OK, my first assumption is that the example programs I've found on the Parallax site are correct from a software sytax point of view. I'm thinking this is handled for the programmer - I may be all wet here.
Karl
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
(...)

Have a look at:
AppNote001a_Getting_Started_with_1-Wire.PDF (Which is archived as:) http://www.parallax.com/ProductInfo/Microcontrollers/Applications/tabid/430/Default.aspx#AN001
...if you would, please.
You might be able to create a version of their source that'll talk to your DS1822.
Their source appears to have a bunch of initialization stuff in the beginning. This may be useful to you.
You'll note the use of a reset command in their example:
// Send reset pulse to 1-wire bus. oneWireBus.reset();
*That* is what I was looking for. :)
--Winston
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here. All logos and trade names are the property of their respective owners.