TEMPE vs EDGE: Thermal Latency

This was an interesting experiment... I fixed the TEMPE logic to handle 16-bit signed integers so it could handle sub-freezing temps and then gathered EDGE 1030 (device) -vs- TEMPE (external sensor) temperatures when both were in the freezer (for an hour) and then both out on my patio here in Orlando in temps in the high 80s. I logged the temps in the Device's LOG file so I could plot them.

The main reason I did this was to calibrate the offset I needed to apply to my TEMPE. Turns out, at about 4F, my TEMPE reads only about 1F more than my EDGE 1030. Close enough. I should have recorded a little longer to allow the EDGE to reach steady state and see how close the EDGE ended up -vs- the TEMPE as they warmed back up.

  • Thank you Jim for your input!

    To be honest - for my Edge datafield coding I have never used "background service".

    is that like: Background.registerForXxxEvent ?
    I don't find a register Event that fits to temperature...

    If it's not too much to ask - could you help me with the code?

    And one more question:
    Does it mean that Edge xx30 devices and Edge xx40 devices are to be coded differently?

    Thanks for your patience!

    (PS: I only will get the internal sensor temperature - not the external Tempe sensor)

  • See https://developer.garmin.com/connect-iq/connect-iq-faq/how-do-i-create-a-connect-iq-background-service/#howdoicreateaconnectiqbackgroundservice and

    https://forums.garmin.com/developer/connect-iq/f/discussion/5287/very-simple-sample-of-a-watch-face-with-a-background-process

    In the case of the temperature. upu can have a very simple "onTemporalEvent"

    where all is really does is Background.exit(Sensor.getInfo().temperature;

    Then you see it in onBackgroundData()

  • Thank you for your help!

  • looks like you have everything you need? See my post on my 108 mile ride and temperature compare. I highly recommend the cheap and more accurate TEMPE sensor if you care about temperature data, and if you ride under direct sun.

  • The main reason I did this was to calibrate the offset I needed to apply to my TEMPE.

    I have a long history with Tempe and recently I published here some of my insulation related stories in order to show whether you can succesfully fight direct sunshine with creativity or not.

    Now I am busy with another issue, the consistency and fluctuations of Tempe. I have 5 Tempe and did their calibration in the very same way. And multiple times, so the phenomenon I want to share with you is not user related.

    Three of the 5 Tempe is quite stable, if the environment is also stable during the calibration (full darkness, no lamps on, no movement around them, no floor heating on etc) then  it changes by 0.1. I dont call it fluctuation, just a simple tiny oscillation.

    The 4th has a bit more intense oscillation, meaning that even if generally it also oscillating only by 0.1, but the changes are more frequent. Even if it is a bit more "agile" it is measuring temperatue in a clean way, no strange values.

    But the 5th is totally different. Its pattern is like that (data are in Celsius degrees) :

    1)  for a couple of minutes it measures let's say 22.0, 21.9 or 22.1, but the changes are just 0.1

    2)  then suddenly from 22.1 it drops to 21.6 or its neighbours (so the change is 0.4-0.6) 

    3a) then the next value is against 22.1 or its neigbours (22.0 or 22.2, so the change against 0.4-0.6)

    OR

    3b) the next value is still  21.6, or sometimes  its neighbor  but then it suddenly jumps up by 0.4-0.6

     

    The change of drops and jumps is more frequently are 0.4 or 0.5 then 0.6, so they are around 1 Fahrenheit, but it may be just a coindicence


    The pattern follows, it repeats the sequence of 2) and 3) for a couple of times then it reverts to the real range of 22.0 (+/- 0.1) and then it stays there for a while. And  then again the drop and jump.

    Before you ask I  tested all of my Tempe with multiple CR2032, so I can exclude the role of battery, too. 

    I also checked whether this Tempe is more sensitive with the proximity of other Tempes, but it is not the reason. 

    I could call this Tempe as a faulty one, but if one measure temperature with it the average of the values after the calibration is quite accurate. One simply has to live with the outliers.

      I have no background in electronics, but I hope that some of you has a good bet on the reason. 

    Btw the 3 most stable Tempes are the oldest (having the lowest S/N), 7-digit starting with 8 and 9), and the other two were manufactured later (S/N are 8-digit starting with 12).

  • I added a #3 S-binder to my Tempe years ago, as that way I can have it in open air and out of direct sunlight.  On a bike, maybe under the seat?  For other things, maybe clipped to a pack or belt loop.  I never liked in on my shoe as it could be impacted by pavement heat.

    When watching the temperature, the tempe only updates once a minute,  If you are seeing change more often than that, you was watching the internal temperature of your device,

  • Sorry, Jim, but as I wrote this time my issue is not insulation, positining, shielding whatsoever, but  the strange behaviour of 1 piece of Tempe which totally differs from that of the other 4 pieces of Tempe.

    See” Now I am busy with another issue, the consistency and fluctuations of Tempe” 

    I just want to understand which element of my Tempe may be faulty and why? And no, I never measured the internal temperature of my watch, because I did not use the native Temperature datafield, but a ciq one.

    OFF: as regards shielding, positioning I was writing a lot in another thread which user Volker started about the discontinueing of Tempe

  • I know with mine, when the battery is getting low the data can be flakey,  Could also be the HW itself is failing.  The Tempe has been discontinued so it might be hard to find a replacement.

    Unless the CIQ app is doing it's own ANT calls, you'll see the same data as in a native data field - which can switch between the internal sensor and the Tempe

  • Own ant+ calls, Tempe must not ve connected as a sensor.

  • And of course HW seems to be failing, even if it is Tempe bought a month ago, but I am was not interested in a replacement, more in an understanding.  Understanding the details of this phenomenon I detailed above.

    Because it is not completely broken the measured avg is pretty fine, just there are some outlier data which the other 4 Tempe never never have shown.

    And Garmin would never replace it, because they would not focus on this difference, they would just mantra that its accuracy is blah-blah-blah and even these outliers are within the range