Error in DS1620.java?

Chorlton

I've been trying out the DS1620 class and seem to be getting 1/2 the temperature I'm expecting. DS1620.getTempRaw uses

tempIn = (CPU.shiftIn(dataPin,clockPin,9,CPU.POST_CLOCK_LSB) >> 7);

which uses POST clock data sampling, but all BS2 programs use

SHIFTIN DQ, Clk, LSBPRE, [noparse][[/noparse]tmpIn\9]

which uses PRE clock data sampling.

I think that the DS1620 class is failing to read the least significant bit and the line should read

tempIn = (CPU.shiftIn(dataPin,clockPin,9,CPU.PRE_CLOCK_LSB) >> 7);

which then seems to return the correct value.
Anyone want to verify this?

Dave.

Dorling

it is this true? (I think it is from the datasheet)

I am getting the wrong values too?

my code

package stamp.peripheral.realtimeclock;

import stamp.core.CPU;
import stamp.core.Timer;
import stamp.peripheral.sensor.temperature.DS1620;

public class RealTimeClock {

  private static DS1620       temp;

  static Timer timer = new Timer();  //timer for blinking led connected to DS1307 SQW output

  public static void main() {


    temp = new DS1620(CPU.pin9,CPU.pin10,CPU.pin11);


    while (true) {

      if (timer.timeout(7500)) { //display realtime clock every 15 seconds
        timer.mark();
        System.out.print("\nTemp: "); 
        System.out.print(temp.getTempRaw());

      }

    }

  }

}

jmspaggi

I know I'm replying to a pretty old post, but I had some strange reactions with my DS1620. Sometime it was giving the right temperature, sometime it was giving half of it. Now with the PRE instead of the POST, it's always giving the right temperature. So if you have the same issue, just update you DS1620 file like Chorlton did above.

JM

jmspaggi

Hi,

I did the update, but I just figure that I still have, sometime, the issue. It's sometime working fine, and sometime not.

I did a graph with the values I retreive over the night ( https://ssl.spaggiari.org/eau.html ). As you can see, the value is usually between 50 and 52. But at one point, I retreived 25.5... Right the half of the expected temperature.

So if you "play" with PRE and POST, sometime you will get the half, or sometime you will get the double. But it's never 100% accurate.

Has someone any idea what's wrong with the DS1620 class?

I think it's more than just this PRE/POST issue.

Thanks,

JMS

Peter Verkaik

Here is the modified code as suggested:

  public int getTempRaw(){
    CPU.writePin(enablePin,true);
    CPU.shiftOut(dataPin,clockPin,8,CPU.SHIFT_LSB,READ_TEMP);
    //tempIn = (CPU.shiftIn(dataPin,clockPin,9,CPU.POST_CLOCK_LSB) >> 7);
    //modified
    [color=blue]tempIn = (CPU.shiftIn(dataPin,clockPin,9,CPU.PRE_CLOCK_LSB) >> 7);[/color]
    CPU.writePin(enablePin,false);
    [color=red]sign = (tempIn >> 8);[/color]                         // isolate sign bit
    tempIn = (tempIn & 0x00FF);                   // mask sign bit from temp
    if (sign == 1) // temp is negative
      return (tempIn | -256);                     // tempIn | 0xFF00
    else
      return tempIn;
  }

Notice the marked lines.
It shifts right tempIn.
But using >> keeps b15, so if tempIn is negative,
the red line will not make sign 1.

Try this:

  public int getTempRaw(){
    CPU.writePin(enablePin,true);
    CPU.shiftOut(dataPin,clockPin,8,CPU.SHIFT_LSB,READ_TEMP);
    //tempIn = (CPU.shiftIn(dataPin,clockPin,9,CPU.POST_CLOCK_LSB) >> 7);
    //modified
    [color=red]tempIn = (CPU.shiftIn(dataPin,clockPin,9,CPU.PRE_CLOCK_LSB) >>> 7);[/color] //move sign into b8
    CPU.writePin(enablePin,false);
    sign = (tempIn >> 8);                         // isolate sign bit, move to b0
    tempIn = (tempIn & 0x00FF);                   // mask sign bit from temp
    if (sign == 1) // temp is negative
      return (tempIn | -256);                     // tempIn | 0xFF00
    else
      return tempIn;
  }

Optimizing:

  public int getTempRaw(){
    CPU.writePin(enablePin,true);
    CPU.shiftOut(dataPin,clockPin,8,CPU.SHIFT_LSB,READ_TEMP);
    //tempIn = (CPU.shiftIn(dataPin,clockPin,9,CPU.POST_CLOCK_LSB) >> 7);
    //modified
    tempIn = (CPU.shiftIn(dataPin,clockPin,9,CPU.PRE_CLOCK_LSB) >>> 7);
    CPU.writePin(enablePin,false);
    if ((tempIn & 0x0100) == 0x0100) // temp is negative
      return (tempIn | 0xFF00);
    else
      return tempIn;
  }

·regards peter

Post Edited (Peter Verkaik) : 4/18/2009 6:40:32 PM GMT

jmspaggi

Hi Peter,

Thanks for your reply.

I tried the optimized version but Jide don't like it because, I think, 0xFF00 is to big. It's saying something about a constant beeing to big. The non-optimized version compile well, but the received value is still 2 times bigger than expected. Even after I shut the power off then on. So I tried back with the POST instead of the PRE, and it'S working, but I'm not sure if it'S really what need to be done and how long it's going to work.

Thanks,

JM

Peter Verkaik

Change 0xFF00 to (short)0xFF00
That should do it.

And it probably must·be POST_CLOCK.

regards peter

Post Edited (Peter Verkaik) : 4/18/2009 8:20:13 PM GMT

jmspaggi

It works with (short), thanks.

I will keep the POST and monitor over the comming hours to see if there is any issue.

Thanks,

JM

Peter Verkaik

Thinking about it, using >> with the shiftIn
should already keep the sign, so no need to add it afterwards.
So this should work also:

  public int getTempRaw(){
    CPU.writePin(enablePin,true);
    CPU.shiftOut(dataPin,clockPin,8,CPU.SHIFT_LSB,READ_TEMP);
    tempIn = (CPU.shiftIn(dataPin,clockPin,9,CPU.POST_CLOCK_LSB) >> 7); //extend sign also
    CPU.writePin(enablePin,false);
    return tempIn;
  }

regards peter

jmspaggi

Hi Peter,

I just tried with what you send above, and it's ready twice the real temperature. I switched the power off, tried to reset the Javelin, and I'm still getting the temperature twice. So I putted back PRE, and it's now fine.

But seems that I need to switch between PRE and POST each time I update the Javeline content. Are we not missing some initialisation somewhere?

I did'nt get a chance to test to negative temperatures so far.

Thanks,

JM

Peter Verkaik

Does the device not return 0.5deg units?
(eg. LSB stands for 0.5)
So divide the signed result by 2 to get 1degC units.
That's what getTempC() does.

regards peter


Post Edited (Peter Verkaik) : 4/19/2009 1:12:48 AM GMT

jmspaggi

Hi Peter,

he sensor is on my water tank. Temperature should be close to 52C. But sometime, the sensor is giving me 26C, sometime 104C, and more often 54.

When it's giving me the wrong number, I do a couple of reset, sometime remove the power suply, and then I finally get the right number. But when I will add another DS1620, if they don't work well at the same time, I will be in trouble.

That's why I'm little mixed up [noparse]:([/noparse]

Do you have any suggestion to troubleshot that?

Thanks,

JM

jmspaggi

Hi Peter,

So far, seems that things are working fine. I did not received a wrong temperature for the last 24h. Will continue to monitor.

Regards,

JM