This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMP107: missed reading in Shutdown mode

Part Number: TMP107

(1) I have three sensors in series on the bench running for several days using a RaspberryPi and 9600 baud.  On one occasion the first sensor came back with 0.1  C while the other two still read ambient around 22 C.  This is after processing so I have no further details to add to the equation. They are all running in shutdown and here is my read temperature code.  tDLY is only a couple of msec.  i.e. 2 x character time

/****** read temperature TMP107s ******/
float readTemp(AA)
  int AA ;                        /* device number */
{
  int iTemp ;
  float rTemp ;
  fprintf(stdout, "\n3: ") ;
  serialPutchar (ftmp, cCAL) ;    /* calibration byte for write Oneshot */
  delay(tDLY);
  serialPutchar (ftmp, (AA << 3)) ;        /* address device */
  delay(tDLY);
  serialPutchar (ftmp, 0xA0 + cCONFIG) ;    /* temp register */
  delay(tDLY);
  serialPutchar (ftmp, (cSHUTDOWN + cONESHOT) & 0xFF ) ;/* LSB Oneshot */
  delay(tDLY);
  serialPutchar (ftmp, ((cSHUTDOWN + cONESHOT) >> 8) & 0xFF) ;/* MSB Shutdown */
  serialFlush(ftmp) ;
  delay(tDLY) ;
  readByte(5) ;                    /* read expected bytes */
  printByte(5) ;
  delay(22) ;                    /**** delay 22 msec ****/

  serialPutchar (ftmp, cCAL) ;    /* calibration byte for read temp */
  delay(tDLY);
  serialPutchar (ftmp, cREAD + (AA << 3)) ;    /* read device */
  delay(tDLY);
  serialPutchar (ftmp, 0xA0 + cTEMP) ;        /* temp register */
  serialFlush(ftmp) ;
  delay(22) ;                                /**** msec ****/
  readByte(5) ;
  printByte(5) ;
 
  iTemp = (rByte[3] >> 2) + (rByte[4] << 6); /* 20170210 decode temp */
  if (iTemp & 0x2000)                        /* -ve sign set */
  {
    iTemp = ~iTemp & 0x3FFF ;    /* ones complement, zero upper bits */
    iTemp =  iTemp ^ -1 ;        /* exclusive OR with -1 */
  }
  rTemp = iTemp * tLSB ;        /* scale to LSB */
  fLog = 1;
  return rTemp ;                /* degrees C */

I have a 22 msec delays between sending the Oneshot command requesting data and reading the data whixh I'm hoping is sufficient and just wonder whether it's worth throwing out a 0xFF or some such as a wakeup call before the 0x55 hits the wires?

(2) I have assumed that I have to transmit both OS and SD to trigger a one-shot and still leave the device in Shutdown mode.  Is this true?

(3) The TMP107 data sheet says OS bit always reads zero (Table 5) yet I appear to be receiving 0x1800 in response to reading the configuration with the following code:

/****** read configuration TMP107s ******/
int readConfig(AA)
  int AA ;                                    /* device number */
{
  fprintf(stdout, "\n4: ") ;
  serialPutchar (ftmp, cCAL) ;
  delay(tDLY);
  serialPutchar (ftmp, cREAD + (AA << 3)) ;    /* device */
  delay(tDLY);
  serialPutchar (ftmp, 0xA0 + cCONFIG) ;    /* configuration register */
  serialFlush(ftmp) ;
  delay(22) ;                                /* msec */
  readByte(5) ;                                /* read expected data */
  printByte(5) ;
  return (rByte[3] & 0xFF) + (rByte[4] << 8) ; /* config */
}

(4) For your interest, my 'lab' stores didn't contain a suitable TxD  interface buffer so I used a 4N37 optocoupler.  I'm only running 9600 baud but even than I had to ground the transistor base through 100K to improve the signal edge times.

David Whiteley

  • Hi David,

    Let us review this, and someone will get back to you.

    Aaron
  • Hi David,

    I apologize for the delay getting back to you.

    1. I'm not familiar with raspberryPi. Can you tell me if your serialPutchar command holds the microcontroller execution until the packet is sent? It would seem that it does since you don't have an interrupt routine or a flag check. If this is the case, you shouldn't need the delay statements. When you perform readByte, you may need to disable or extend any timeout functionality. This is particularly true when you are executing global commands from the TMP107 command set. There's no need to send additional data as you suggested.

    2. Yes, this is correct. The config register value should contain both OS and SD to trigger and maintain shutdown mode.

    3. You may have corruption of your communication; let's address my other questions and come back to this.

    4. It would be helpful to see an oscilloscope picture of your waveform.

    Thanks,
    Ren
  • Ren,

    The Raspberry Pi operating system is Raspbian, a derivative of Debian Linux.  Most 'stuff' is running in background, 4-cores at 1.2GHz, I don't think it even knows I'm there!

    I agree I likely don't need the delay between characters, it just gave me a warm fuzzy to see them separated.

    The delays are OS calls which I don't think have any affect on the serial interface activity but I honestly can't say my timeouts don't produce problems.You might smile at my attempIndividual Read at 9600 baudt at waveform capture.  The Oscilloscope is a 30 years old, 20MHz Philips 3214 which I'm trying to 'capture' on a WebCam connected to a Win7 laptop.  Unfortunately it is rather pix-elated but I think you can see the last byte of the configuration reply has a 0x18 (OS +SD) in it rather than the 0x08 (SD) per the Datasheet (p24, Table-5).  The RxD captures shows 0x55, 0A, A1, 00, 18 at 9600 baud.

    The on-site version of this set-up has been running over a month and in that time I've only seen one other missed reading with outside temperatures hitting -20C at times.  I was only asking about Read Configuration because it was one funny in my system where the 0x1800 indicates OS+SD and the Data Sheet says "OS always reads zero". 

    Of interest, I have a friend who would like me to try and measure the temperatures inside his beehives so the second unit may soon be braving a Canadian Winter rather than being hooked up to my furnace!

    David Whiteley

  • Some of our devices read back OS=1 while a conversion is active. In those devices, the OS bit changes to 0 when conversion completes to indicate the data is ready. If this feature is implemented in TMP107, it would mean the datasheet is wrong about OS.

    I don't think we'll be able to address your original question about intermittent read back error unless you can capture the event. It's hard to gleam any information from your oscilloscope other than the fact that you seem to be communicating correctly and understand it well enough.

    Ren
  • For your interest I have attached a recent chart from four TMP107s probes, three of which were inside a pod of bee hives.  Hive-2 died early on and it's sensor was left outside to follow the air temperature.  Ottawa Airport Temperature was taken from the Canadian Weather Archives.

    Hive-1 fairs the best, hardly dipping below 20C while night time temperature reach -20C.  Hive-3 takes a dive shortly after we installed the probes but then recovers and is now up at 30C along with Hive-1.  The Barn probe is sat atop a RaspberryPi some 18ft away.

    I see no erroneous 0C readings over this 42 day period.

    Bee201704.pdf

  • That's great news. Thanks for sharing information about your application.

    Ren