TMP007 5-6 seconds temperature latency

Hi,

I have notified the Apps Eng for IR Sensors. He will get back to you soon.

Mayrim

Hello Johan,

   I have a couple of quick questions regarding your problem. 

#1.  I assume you are trying to run a calibration, is this correct? 

#2.  What is the distance of the Device to the object?

#3  What is the distance of the device to the belt if no object is present?

#4  Can you confirm that you are using Conversion Rate 000

 I look forward to your reply.

Regards,

Tommy Santoyo

 

 

#1 No

#2 10mm during these tests, same with my hand over the sensor.

#3 Its measuring from the side of the belt when objects is passing by, a solid wall 3m away when no objects in its path. We have control over when there is an object infront of the sensor so we are not using it for detecting proximity to the object we need to control the objects temperature.

#4 Yes

/Johan

I would like to reduce the scope of our problem by removing parameters caused by our targeted end application or custom design because the issue can be reproduce with only moving the hand over the sensor on the EVM.

I found the following in a older thread (http://e2e.ti.com/support/sensor/temperature_sensors/f/243/t/366088):
Q:
2) I section 1.2.3, "Note this introduces a time constant of approximately 5 times the sample rate as set in the Configuration Conversion Rate bits", how to understand this statement? What do 5 times mean?
A:
The weighting co-efficients shown in section 1.2.3, equation 6 are 0.2 for the first term and 0.6 for the second term. This means in presence of a step change in temperature, it will take about five conversions to reflect the new value of the step change. For a default one second conversion rate, this means about 5 seconds to stabilize at the new value.

To me its seems like the weighting is NOT performed on each sample when we configuring it for 4HZ, weighting of each forth sample(1per/s) seems consistent with our experienced result and the explanation above. Please advise on how to configure the weighting co-efficients so that it matches the 5xsample rate.

To clarify we use the following configuration of the sensor everything else default "out of the box":
Write 0x1140 to 0x02 (Configuration Register)
Write 0xc000 to 0x05 (Status Mask and Enable Register)

By the way, the first table following figure 30 in the datasheet states that the POR value for 0x02 is 0x1140 (4HZ)but the second table states that the default vale for CR2-0 is 0x2 (1HZ).

Johan,

Can you confirm that you're using the TMP007 EVM software for all of your testing? I suspect this timing issue is inherent to the software, and not to TMP007. I will investigate this for you ASAP.

You are correct about the inconsistency in the datasheet. The default, POR value for Config Reg 0x02 is 0x1440.

Ren

Hi Ren,

No not for all testing the problem (5s delay with 4HZ sample) can be reproduced with both EVM software and custom software where the later one is using the assertion of alert to trigger a read of object temperature see our configuration above.

We receive ~5x4 sample before the temperature seems correct.

/Johan

Do I understand correctly that you are using transient correction in both? Have you tested without transient correction?

Ren

Can you log sensor voltage, local temperature, and object temperature during the temperature change event and share the data us?

Ren

Yes TC bit in register 0x02 is set in both cases, i have tried writing 0 to both TC0 and TC1 without difference. Did a quick test right now and disabled the TC bit on the EVM and yes its more responsive but it over/under shoots alot rendering the results useless.

/J

Yes but it takes 20 samples for me @4Hz samplerate right!? I understand thath there might be som timing issues with the windows software for the EVM but regardles the sensor should have sampled 4 samples per second!

So how can we adjust the TC coefficients so that it matches what is stated in the datasheet, 5samples not 5seconds @4Hz?
/J

The 5 samples discussed in the Calibration Guide (and discussed in the other thread) is a theoretical limit of the transient correction filter. If this were the only issue, you would be right to assume that it should settle faster (in terms of actual time) when a higher conversion rate is used. Since it does not, we can conclude that we are observing thermal settling that just happens to take 5 seconds. If you look at page 25 of the data sheet, you'll see that TMP007's own power dissipation is the same in both the 1Hz and 4Hz modes, so it makes sense that the thermal settling is the same.

But when turning of the TC the sensor reacts directly 22 to ~34C, the temperature (34) is not stable at this point but that's why you would need the TC right or some other external filtering?

If it where because of thermal settling time then it would take the same time with TC enabled or disabled!?

I will record data as requested earlier, and upload a video.

Hi thanks for your answers.

I will collect the data you requested during this week.