TMP04 Temperature Sensor with Arduino Not going HIGH

arduinodigital-communicationsduty cyclesensortemperature

I have a TMP04 temperature sensor (3 pin package). It outputs a square wave at approximately 35Hz and the duty cycle can be converted into a temperature reading (see datasheet).

It has an operating voltage of 4.5V-7V and I have it hooked up to the 5V supply of an Arduino Uno. Using a multimeter between the power pins confirms that the voltage is ~4.96V, which should be suitable.

I was using the pulseIn() function to read the time the pin was high, but the function would fail and always time out.

To check the output from the sensor I connected it to the Arduinos analog (ADC) input and took readings from the pin every millisecond.

There was a clear HIGH/LOW pattern, BUT there was an issue. The LOW signal was reading approximately ~15 (fine), but the HIGH signal was reading ~145. This is a very low voltage, as the ADC produces a number between 0-1024.

Hence, a reading of ~145 corresponds to a HIGH voltage of ~0.7V, which is of course not expected and wrong. The datasheet suggests that the HIGH voltage should never fall below \$V_{DD}-0.4\$.

I thought that it may have been a dud sensor, but after trying another one I get the same results.

I'm just prototyping on a breadboard, and have no decoupling capacitors as I was just testing them out.

My circuit is literally:

  • Sensor V+ to Arduino 5V

  • Sensor ground the Arduino ground

  • Sensor output in to Arduino (tried pin 5 and A1)

I have no other resistors or components in my circuit. Am I doing anything wrong? Have I misunderstood how I am supposed to use the sensor?

Here is a sample output from the ADC, with one reading every millisecond:

145
149
14
12
13
12
15
13
16
18
14
18
18
18
20
14
150
146
149
148
149
149
146
148
14
18
17
18
14
21
14
15
18
14
17
17
19
19
150
149

Best Answer

The problem was a dumb error on my part. The datasheet indicates the pinout as a "bottom view", while I was interpreting it as a "top view". Hence, my DATA and GROUND pins were swapped.

The almost correct data I was observing, was somewhat misleading to the actual problem.