Smart recording vs. 1s vs. compute() in a DataField

If you recorded a fit file using smart, when you play it back in the sim, you may only see new data every few seconds.

On a real device, they run the same regardless of the setting.

I don't think ActivityInfo, compute(), and onUpdate() are affected by the choice of smart recording vs. per-second recording. That option should only affect how often data is recorded to the activity FIT file.

The big difference between compute() and onUpdate() is that compute() is guaranteed to be called (roughly *) once per second, regardless of whether your data field is visible or not.

onUpdate() is only called while your data field is visible, roughly once per second.

And if you scroll towards or away from the page containing your data field, onUpdate() may be called several times in rapid succession. [Sorry, I was thinking of onShow/onHide - I haven't double-checked what onUpdate() does in that situation lately, so I'm not sure about the previous statement which I've now crossed out]

That's why it's recommended to do computations in compute() and to only handle display updates in onUpdate().

(*) if you time the calls to compute() using something like System.getTimer(), you'll see that it's not exactly once per second. And in some cases, maybe under high CPU load, compute() might seem to "skip" a second, only to be called twice in the next second. This can also be seen if you create a data field that displays the activity time in seconds or milliseconds.

I've done that, plotting it out in the FIT file, I haven't seen it "skip a second". at least on my EDGE 1050, it varies like a heartbeat, normally spot on at 1000 ms, but varying between maybe 980ms and 1020ms, when I assume it does some internal housekeeping every 20 secs or so. I've never seen it go to 2000ms and then 500ms. Just in my case. On my older 1030 with many CIQ apps running and turn-by-turn routing, I have seen it slow to a crawl in processing the routing... but in that case I'm guessing it de-prioritized the time slices for routing to make sure the other processes were run on a more predictable latency - just guessing on that based on observation.

I should clarify that for me it was a pretty rare occurrence (especially since I'm not usually looking for it). Again, one way for me to see this would be to have a CIQ data field that displayed the activity timer, and display that right next to the native activity timer field. IIRC, in some rare circumstances, I would see the two fields go out of sync briefly (the update of the CIQ field would seem to pause for 1 second, then catch up in the next second).

Also, I only use Garmin watches (and not Edges) - I assume watches have much weaker resources than Edges (e.g. slower CPU, less memory), so I'm guessing this could be something that's more likely to affect a watch than an Edge.

I'm just saying I wouldn't take it for granted that compute() is always called literally once per second, but it's probably close enough to once per second for most people's purposes. Like if you wanted to count seconds by incrementing a counter in compute, that probably wouldn't be the worst idea in the world, although if you need more precision, it would probably be better to use the activity timer or System.getTimer() (system uptime), depending on your specific use case.

Here is my view as a long-time Edge user in connection with IQ data fields:
The “smart recording” setting only causes a different method of GPS point recording and has nothing to do with the second cycle of IQ functions.
While with “1 second” a GPS point is saved every second along with all the associated values (HR, power, distance...), fewer values are recorded with “smart recording”. On straight sections of the route, the number of points is reduced, while more points are saved on winding sections.
The IQ timer runs normally and increases the timer value every second.

Agree. I've looked at FIT files using Smart Recording and it seemed like it could record from every second to up to every 12-15 seconds worst case. It seemed like if there was any sensor data that changed, it went ahead and saved a new line, such as HR or Cadence or Power or in a turn. There must be some change threshold that it assumes is close enough to delay a write, since some sensor data is FP and is always changing a least fractionally. I use 1-sec recording now however.

Thanks everyone for chiming in.

On a related note, since we can't accurately rely on compute() being called exactly every second, what would be the best way to compute vertical ascent ? I've been using a rolling queue of altitude values that I update every time compute () is called, should I also be storing a timestamp with the corresponding altitude value ?

DirtJezus said:

since we can't accurately rely on compute() being called exactly every second,

Personally I think it’s good enough for most purposes, including calculating averages for activity metrics.

Like you will very rarely (or never) see compute() “skip a beat” like I described, and I think, on average, compute should be called pretty to close to exactly once per second.

I just think you just can’t rely on there to be exactly 1000 ms between each call to compute (which is probably unreasonable to expect anyway).