PMODTMP2 Temperature Sensor and Thermostat Control - Review

Table of contents

RoadTest: PMODTMP2 Temperature Sensor and Thermostat Control

Author: Unknown

Creation date:

Evaluation Type: Evaluation Boards

Did you receive all parts the manufacturer stated would be included in the package?: True

What other parts do you consider comparable to this product?: analog devices tmp36 / sensirion SHT series / Dallas IC DS18B20

What were the biggest problems encountered?: The device performed as expected throughout, there were no significant problems of note. The only downside being a lack of example code but those familiar with I2C devices should be more than capable of writing their own interface software.

Detailed Review:

Preface

 

One of my planned projects is to mod a Bigtrak which was a popular toy back in the 80's and has been reproduced recently, the modification is going to incorporate a Rapsberry Pi. Whenever a computing device is encapsulated it's a wise precaution to include some temperature sensing and some cooling to prevent the system from getting too hot! For this reason I applied for this roadtest and would like to extend my thanks to those involved in selecting my application.

 

I already have a number of temperature sensors but it was the features of the Digilent PmodTMP2 that caught my eye, identifying some features that would undoubtedly add a performance boost over the others that I had considered using.

 

Some of the other sensors would need analog to digital conversion and others would need an entire bus to themselves, using their own protocol rendered them unsuitable to be used along with other devices.

 

One of the things that all of the other sensors had in common was they would all need polling on a regular basis by the main controller which would then have to be responsible for the cooling system.

 

Reasons To Consider This Sensor

 

The PmodTMP2 in this review has the advantage of high temperature and critical temperature interrupts which are programmable to any temperature within the devices range of operation (-40 to +150 Celsius). This means that the main project processor doesn't have to be continuously checking as the sensor can raise an alert if the temperature gets too high.

 

It's not even necessary to alert the main processor in some cases the over temperature interrupt can independently trigger a cooling circuit without any intervention of the main controller. Of course with an additional critical temperature interrupt this allows the processor to be alerted if the cooling system isn't managing to adequately cool the system and the temperature continues rising towards a dangerous limit.

 

The sensor also has the ability to set a low temperature interrupt, one particular example of using this feature would be to monitor a greenhouse during the winter and early spring, if the temperature falls into a range where tropical plants are going to suffer or even freeze then the low temperature interrupt can be used to instruct a heater to turn on.

 

Test Setup

 

To test this sensor I used an Espruino which is one of my go to microcontrollers for rapid testing, eventually I will be using this device with the Raspberry PI but at present there aren't any straightforward libraries which is something that I will address in the near future, I plan on making a simple interface that should be relatively easy to use.

 

Example Code

 

There is a provided code example for chipKit MPIDE and also an external link provided to an instructable for using this device on the Raspberry Pi using Python in conjunction with the smbus library which I couldn't get to work and there isn't any actual example code in the link, maybe I'm not patient enough but I do feel I would be better creating my own control interface.

 

This is the code I used to gather an initial temperature reading using an espruino

 

var i2c=I2C1;
i2c.setup({scl:B6,sda:B7});
var devadd = 0x4B;
var temp_register = 0x00;

function getTemp(){
    i2c.writeTo(devadd,temp_register);
    raw_data = i2c.readFrom(devadd,2);
    data_16_bit = (((raw_data[0] & 0xff) << 8) | (raw_data[1] & 0xff));
    temp_deg_c = data_16_bit / 128;
    return temp_deg_c;
}
}

 

The top parts setup the I2C port whereas the function reads the data from the sensor and stores them as 2 8-bit values in an array which then shifts the 2 returned 8-bit values into a 16-bit variable and finally divides that with a value of 128 to give us the value in degrees C. From here, calling the function getTemp() will then return the temperature data as a value in degrees Celsius

 

 

Like mentioned in the video I'm leaving tomorrow to work away from home for the majority of next week so I won't be able to go any further until then. Once I do get back I'll spend some time getting the sensor to work with the Raspberry Pi and then testing the interrupt function and providing examples, this will all probably happen in a seperate blog but I'll paste a link into the comments below so don't forget to check back and see the progress.

Anonymous
Parents Comment Children
  • Former Member
    Former Member in reply to jc2048

    Great question, the Espruino is quite unique in that it has a live javascript compiler, because the function returns 8 bit bytes stored in an array the compiler automatically declares a Uint8array to store the values. The Espruino is great for quickly testing and prototyping as it contains all of the high level math functions and other time saving built in utilities. Its not so great for timing critical applications or even a final finished design so I often get something working on the Eapruino and then use the javascript program as a template to convert the program over to another device, being nicely structured this work very well.

  • The Arduino Uno isn't too hot on speed either.

     

    This trivial program

     

    void loop() {
      // here is where you'd put code that needs to be running all the time.
        digitalWrite(outputPin, HIGH);
        digitalWrite(outputPin, LOW);
    }

     

    compiled to 854 bytes

     

    "Sketch uses 854 bytes (2%) of program storage space."

     

    and produced the following waveform on the pin (in case it's not clear, the timebase is 2uS/div)

     

    image

     

    I had hoped it might be a bit faster than that - in assembler it should be possible to manage 1uS for the cycle.

     

    [I've just realised that I might have done better to use the PWM.]

  • Have you tried setting the port registers directly instead of using digitalWrite() ?

    https://www.arduino.cc/en/Reference/PortManipulation

     

    There have been quite a number of posts about digitalWrite() slowing things down a lot e.g.:

    Maximum pin toggle speed

  • Thanks Dave. I just copied the instructions from one of the examples, not knowing what I was doing.

     

    This works much better (I've taken it from that 'Maximum pin toggle speed' thread, but adapted it for output on pin 12)

     

    void setup() {
      DDRB = DDRB | 0x10;
    }

     

    void loop() {
      cli();
      while(1) {
        PORTB |= 0x10;
        PORTB |= 0x10;
        PORTB &= ~0x10;
        }
    }

     

    it gives a 2MHz square wave, if my scope is to be believed

     

    image