TMP116: Polling the data ready flag seems to clear it inadvertently

Hi Charles,

I've seen some successes with the method you are using currently and it's certainly possible. How much time is there between reads of the configuration register?

For debugging, I would start by setting bit 2 of the configuration register high, to tie the alert pin to the data ready flag. That way you can see on an Oscope how much delay there is between the data being ready, and your read of the configuration register, followed by your read of the temperature register. 

If that is still causing you issues there are two other options you can try. 

1. Set the alert pin of the TMP116 to reflect the data ready pin as before, using bit 2 of the configuration register. This pin can then be used as an interrupt to trigger a new measurement, and you won't have to worry about constantly polling the device. This has the added benefit of reducing overhead and I2C bus traffic. 
2. You can simply read the temperature register of the device every 500ms. Using this method you will occasionally get the same read twice, or miss a read entirely, but you will always have data every 500ms. Depending on your application this may or may not be tolerable for you. If every temperature read has to be captured I would recommend option 1.

Please let me know if you have any other questions. 

Best Regards,
Brandon Fisher

Thanks for replying

As a following of your point 1, I say that I am not able to test the alert pin because all my TMP116 are encapsulated in resin. Furthermore this solution does not suit my application.

As of your point 2, I agree that I'll get the same read twice. And this is not good for me.

With a delay even greater between each read (700ms), we are sure to read a raised data ready flag.  I made this test. I read 8000 times the config register and I always got a +1 . So I would say that in this case, it is working as expected.

You asked me how much time is there between reads of the configuration register?
I made a test so as to show how much missing samples there are vs the delay between config register reads. Here are the results:

no delay:  20% missed
1ms delay: 9% missed
3ms delay: 3% missed
5ms delay: 1.5% missed
10ms delay: 1% missed
100ms delay: less than 1% missed
200ms delay: less than 1% missed

To me it is consistent with a data ready flag inadvertently cleared during a read.

Best regards

Hi Charles,

charles lahure said:

no delay:  20% missed
1ms delay: 9% missed
3ms delay: 3% missed
5ms delay: 1.5% missed
10ms delay: 1% missed
100ms delay: less than 1% missed
200ms delay: less than 1% missed

To me it is consistent with a data ready flag inadvertently cleared during a read.

I agree with your conclusion on the cause. There is not much value in polling the TMP116 at those faster rates, given that you are only converting once every 500ms.

Do you immediately check the data ready status after a configuration register read? I would recommend this so you do not accidentally overwrite your stored configuration register value it when it contains an active data ready flag, and you can immediately trigger a temperature read. If you wait too long, reading the temperature register also erases the data ready flag from the configuration register. 

Best Regards,
Brandon Fisher

With your programming sequence:

1 write config address = 1
2 read config
3 if data ready flag reset
      wait  some ms
      goto 2
   else read temp
read temp ...
...

I get the same results

10ms delay: 0.9% missed
100ms delay: 0.07% missed
200ms delay: 0.04% missed

Sure that 100ms or 200ms are a better choice.

But it's not working as expected. It seems that the read of the config register
is not atomic and we get a collision probability of about 0.015 %

Regards

Hi Charles,

0.04% of reads is a fairly small amount missed. If you need the data to be fresh every 500ms then i would recommend increasing the conversion cycle to 250ms on the TMP116, and reading temperature every 500ms. No reads of the configuration register would be necessary in that case. 

Is there a specific reason you need to capture every single conversion? 

Best Regards,
Brandon Fisher

Hi

The need for every single conversion is the need for a fixed sampling rate.

A fixed sampling rate is required for many signal processing techniques.

I need to process for analyzing the transient response of the sensor.
When a sample is missing, about 100 samples are lost because
I cannot process them. So it's not 0.04% lost but 4% of the transient
responses that I cannot process.

I don't need a workaround. I can find one myself.

If you think it's a silicon bug, tell me if it's still there in the TMP117.
If the TMP117 is bugged too, tell it to the big brains in TI.

Regards
Eric

see last message

Hi Eric,

Thank you for sharing the source of your requirement. I am recreating a setup to test this and see if I can gather some data that will be helpful. If you are looking for a workaround the DRDY alert interrupt is still what I think is the best option, but I have a few more questions that will hopefully clarify the issue.

If you probe the I2C lines on the device, do you correctly see that the configuration register data is being taken every 200ms?

Normally when we see issues with polling data the cause is unintended delay from other processes that the host might be performing. This would show up on the oscilloscope as inconsistent delays between these reads of the config register. If possible, you can try increasing your I2C bus frequency to reduce the time that your master spends sending and receiving data and free up some resources in addition to the ones you free by sampling more slowly.

How are you determining that reads were missed? Are you attaching time stamps to the reads after you take them, or is this something you are verifying in the lab?

charles lahure said:

If you think it's a silicon bug, tell me if it's still there in the TMP117.
If the TMP117 is bugged too, tell it to the big brains in TI.

I'm not convinced its a silicon bug, but we will look into it on both devices. Keep in mind that reads of both the temperature register and the configuration register will erase the DRDY bit, this is by intent to allow sampling based on the interrupt pin. Are there any other register reads of the device that you are regularly performing? 

I will follow up with you again shortly.

Best Regards,
Brandon Fisher

Thanks for trying. I admit it's more likely to be my fault. In that case, I promiss I'll apologize.

I use a 32 Mhz PIC processor with a simple loop checking only one TMP116.
I report errors with a serial link.

I cannot do thorough measurements with my *analog* scope.

I made a new simple program test:
Now there's only one loop of reads of the config register.
I do not read the temperature.
On my scope, I see a steady rhythm of reads.
I'm reading every ms.

> Are you attaching time stamps to the reads ?
Yes

Each time I get a  Data Ready = 1, I note the time.
When the following successful Data Ready  is more than 0.8 second after, I consider
there was a missing Data Ready.
And there are errors as before.

I emphasize that I'm only reading the configuration register each ms.
No write (except during initialization) , no read of temperature.

HI Charles,

Are you able to set a timer and ISR to perform these reads instead of using a loop? I'm currently able to use a timer based polling method without seeing any of these issues occurring on my logic analyzer. I would still recommend slowing down the polling rate as well, reading every ms is not necessary for a device that only converts every 500ms. This will free up your system resources for your serial data transmission. 

Are you transmitting this data to a monitoring PC where you attach timestamps? When in the data transmission chain are these timestamps being generated? 

Best Regards,
Brandon Fisher

Hi

> Are you transmitting this data to a monitoring PC where you attach timestamps?
Yes

> When in the data transmission chain are these timestamps being generated?
I have timestamps generated on both sides. I also count the polling loops.
When a problem occurs I can see that the
  - serial link output stops for half a second
  - one PC time stamp is missing
   - the loop counts have doubled 
        for example : * 2.01 or  * 2.008

> I would still recommend slowing down the polling rate
1 ms delay (or no delay at all) is only  useful to show the problem
Please try with no delay, or a 1 ms delay

> Are you able to set a timer and ISR to perform these reads instead of using a loop?
Not now. I'll do it this week, if its still required

I'm just asking you to try with no delay, or a 1 ms delay, for the purpose
of this issue only. Thank you

Best Regards