Fenix 5x, SW 5.1: Three bugs in pressure history iterator.

Former Member over 8 years ago

After update from SW 4.1 to 5.1 on Fenix 5x:

Bug1:
The first couple of minutes after the watch has been turned on, the timestamp of the first (oldest) sample in the pressure history is illegal (in my case it is a negative number!!). After this couple of mintes the iterator will return a valid first/oldest time stamp. Iterator-returning function attached.

Bug2:
Right after the SW update from 4.1 to 5.1 I had to wait 6 hours before being able to retrieve valid data from the pressure history buffer. I didn't do any debugging at that time and now I am not interested in going back and forth from 4.1 (since I will loose my settings) so I haven't reproduced the issue but I guess it has to do with the above mentioned Bug1.

Bug3:
In 4.1 the barometer time plot settings would reflect in the depth of the pressure history buffer (going up to 48 hours). In 5.1 only 6 hours af pressure history is available to the API no matter what the device settings are. The provided Garmin barometer widget is still working fine showing up to 48 hours of pressure history but the API is stock at only 6 hours of history.

I have not tested if the above iterator problems also applies to the other sensors.

jim_m_58 over 8 years ago

It almost sound like you are getting oldest first -based on bug2 and the negative "when". That's why you had to wait 6hrs for data.

in your code, you have this:

return getMethod.invoke[ {:order => true} ];

try just changing it to this:

jim_m_58 over 8 years ago

return getMethod.invoke[ {} ];

I've seen odd things with both period and order with SH on different devices and FW, and it seems the defaults are the safest. For order, using the mc names also helps when looking at the code, so I'd use

:order=>SH.ORDER_NEWEST_FIRST

for example, as the proper value for order for newest first is 0 and not sure what setting it to "true" does.

This might have been a bug pre-5.10 where "true" was treated as "0" or something (maybe CIQ 2.3.1 vs 2.3.2 and a general fix and nothing to do with SH)

Former Member over 8 years ago

Good remarks. I tested again and still found strange values within the first couple of minutes after the watch has been turned on:

return getMethod.invoke( {:order=>SH.ORDER_NEWEST_FIRST} ); Returns: Oldest sample time=-21480, First iterator sample time=0. Later it returns valid Epoch values but oldest sample is only 6 hours back in time.

return getMethod.invoke( {:order=>SH.ORDER_OLDEST_FIRST} ); Returns: Oldest sample time=-21480, First iterator sample time=-21480. Later it returns valid Epoch values but oldest sample is only 6 hours back in time.

return getMethod.invoke( { } ); acts like return getMethod.invoke( {:order=>SH.ORDER_NEWEST_FIRST} );

No improvements :-(

Former Member over 8 years ago

Hey,

Thanks for all the work you have done. I was able to follow the steps in the thread and reproduce what you are seeing. We will take a look at this this week.

Thanks,
-Coleman

Former Member over 8 years ago

Hello,

I've just talked to the device team. They have a fix in place to be released on the next Beta. Production software will be thereafter.

Thanks,
-Coleman