Sys.getTimer() vs info.elapsedTime in compute data field

I adapted some helpful code from Travis Vitek here, https://forums.garmin.com/showthread.php?364579-Lap-time-and-Last-lap-time&p=919973#post919973, to output system time and time from compute, side-by-side.

In the simulator, the times showed the same, which I didn't find surprising, but my experience programming data fields in the past was that the data in the info passed to compute doesn't match the built-in data fields -- mostly it seems like a custom data field gets the data a bit later. So I'd see, for example, average pace derived from activity info lag the built-in data field pace.

When I tried showing system time vs activity info time from compute on my vivoactive, however, what I saw was that the compute time was about a quarter of a second greater than the system elapsed time. The code I have is like the below. I display the two times side-by-side in the onUpdate(dc) method:

hidden var _M_previous;

    hidden var _M_elapsed;

    hidden var _M_paused;

    hidden var _M_stopped;

    hidden var computeElapsed;



	function updateElapsed() {

        var current = Sys.getTimer();

        if (!_M_paused && !_M_stopped && _M_previous != null) {

            _M_elapsed += current - _M_previous;

        }

            _M_previous = current;		

	}



        function compute(info) {

		updateElapsed();

		computeElapsed = 0;

                if (info.elapsedTime) {

	 		computeElapsed = info.elapsedTime;

	 	}

       }

I'm really quite puzzled about the relationship between system elapsed time, and elapsed time in activity info. Although having onTimerLap is a massive plus compared to what was available at the end of 2015 when I had to guess when new laps began, it still seems non-trivial to accurately calculate your own lap pace for example, i.e. to match the lap pace the built-in field shows.

Can anyone explain the relationship between system elapsed time you get in onTimerLap, for example, and elapsedTime in compute? I'm also interested whether or not there is a lag between built-in data fields and custom data fields.

(Another thing I noticed was that the activity info elapsed time doesn't take account of any pauses. Although this is something I can live.)

Former Member over 8 years ago

I think you might get a more accurate lap time by setting _mTimerLastLap to Activity.getInfo().timerTime inside onTimerLap instead of setting it to _mTimer.

tg123 over 8 years ago

Thanks. That's what I'm trying to do in my latest code.

class PaceAvgLapView extends Ui.DataField {



	// time, distance at start of lap

	var t0;

	var d0;

	// whether to start a new lap in the next compute

	var startNewLap;

	// display values

	var inLap;

	var avgPace;

	var lapPace;

	

    function initialize() {

        Ui.DataField.initialize();



	t0 = 0.0; d0 = 0.0;

        

        startNewLap = false;

        

        inLap = false;

        avgPace = 0;

        lapPace = 0;   

    }

    

    function compute(info) {

        if (info.timerTime) {

			if (info.elapsedDistance) {

				var t1 = info.timerTime.toFloat() / 1000.0;

				var d1 = info.elapsedDistance;

				

				if (startNewLap) {

					t0 = t1;

					d0 = d1;

					startNewLap = false;

				}

				

        		        var lapTime = t1 - t0;

				var lapDistance = d1 - d0;

                                // display previous lap for some time after new lap starts

				var newInLap = lapTime > timeToDisplayNewLap && lapDistance > 0;			

				if (newInLap) {

					if (info.averageSpeed) {

						avgPace = lapLength / info.averageSpeed;

					}

					else {

						avgPace = t1        / (d1        / lapLength);

					}

					if (d0 > 0) {

						lapPace = lapTime   / (lapDistance / lapLength);

					}

					else {

						lapPace = avgPace;

					}					

				}

				inLap = newInLap;

			}

		}

    }



    function onTimerLap() {

	startNewLap = true;

    }

Possible I've got it wrong of course.

Now that I know I can't get the lap time (and distance) exactly, I'll stop worrying about my lap pace being so far away from the built-in lap pace (for the first quarter of a mile or so; after that it converges). To be honest, even taking the reciprocal of the average speed given in the info doesn't exactly match the built-in average pace, which is unexpected.

Thanks again.

fletch555 over 4 years ago in reply to tg123

Did you ever find a solution to this? I am building a data field with millisecond accuracy for lap pace. I managed to do this however I notice that my calculation is always slightly different to the Garmin calculated lap pace. I need millisecond accuracy as I am doing a run challenge that requires hitting exact splits.

FlowState over 4 years ago in reply to fletch555

But your GPS pace/distance is never going to be accurate enough to give you true millisecond accuracy for lap pace. Garmin rounds to the nearest *5 seconds* for pace in native fields, as they don't think their pace is accurate to even 1 second.

To me it makes more sense to want millisecond accuracy for *lap time*, run your challenge on a measured course/track, and press the lap button manually. Even in this case, various factors like human lag time, lag time on the watch, etc. means that your laps will probably only be accurate within a couple of hundred milliseconds.

(I have a stopwatch app which shows 100ths of seconds, and which updates approximately every 50 ms. I tried pressing the lap button as fast as I could while watching the numbers change, and the minimum lag time between the time I saw when I pressed Lap and the time recorded for the lap was about 140ms.)