Watchdog time limit knowable?

I have a long running calc that I can't complete in one pass of onUpdate. Currently I'm just doing a few iterations and hoping I don't hit the watchdog limit. It occurred to me that if I actually knew that limit then I could be smarter and do something like:

function onUpdate()

var beginTime = System.getTimer();

...do draw watch face here...

...then...

do {

...iteration of long running calc...

} while (System.getTimer() - beginTime < wdTimeLimit * someSafetyFactor) // such as 0.9

Assuming wdTimeLimit in ms, is this value knowable, and if so, does it vary by device or is the limit the same across the board?

  • <facepalm> After some experimenting with both the simulator and a real device I've determined that the limit has nothing to do with time, and that the limits for the sim and hardware are much different. For the Forerunner 235 if I go past 100 ms I risk the watchdog error, on the watch it's a little past 10000. For the Fenix 7x the sim limit is 2000, at least the hardware limit is around 1200. But these only apply if I have a System.println in the loop. If I take it out the numbers change. This limit is a ghost. </facepalm>

  • The watchdog varies by device in both the sim and on real devices, and the way I understand it, it's also not time, but byte codes executed since returning to the VM.

  • So basically it's like a highway with no speed limit signs where you could get pulled over at any time and cited for "I think you were going too fast". Sounds like Montana.

  • that only works on montana7xx devices though

  • I found in the ConnectIQ\Devices\fenix7x directory the simulator.json file has an entry for watchdogCount : 240000. For the Forerunner 235 it's 80000. I can't find anything comparable for the actual device. I wonder if it's possible to get an idea for bytes to be executed from the .mir files?

  • What you see in those files is what the values are on reall devices, so with the f7 it's 3x the 235.  The watchdog has been around far longer than the mir files.  Your best bet is plan for the 235 in all cases.

    There are cases where instead of using a huge loop to do something, it's much faster to just do things as it's being built.

    Take for example a huge array, and you want the min value.  You can walk the entire array looking for the smallest value, or as you add something to the array, if there is a new min, just save that off and you can skip the huge loop..

  • I did learn that for calculating moon rise. Starting with the mean position, getting to a true position requires calculating dozens (or thousands if you are JPL) of sines and cosines. A loop with just the array indexes and one sine and one cosine seemed like the obvious solution, but it took way more memory and time than 200 individual trig functions. It's not that loop that's the problem. It's the "little one", where I calculate the position every half hour and look for where it crosses the horizon. Once I find that I can quit looking. That's why I want to execute on something other than straight time chunks. The loop goes faster as I get to the end. The faster I can get though to the end the faster I can display it on the watch face. On the Fenix 7x it takes 2-3 seconds. On the FR 235 it takes 2-3 minutes which is a lot better than it was when I started this project.

    When I convert clock hand coordinates from polar (because polygons are WAY easier to lay out in polar coordinates) to raster I get the bounding box at the same time so like you say avoid doing things more than once if you can.

    I did find a post where it turns out that the simulator getTimer() only has a resolution around 16ms vs 1ms for the real thing which makes it theoretically possible to tell if you are in a sim or not. This seems to be working, sort of. The trick is finding something in the code that takes between 2 and 10 ms when the speed difference between the Fenix 7x and FR 235 seems to be somewhere around 20 to 1. Getting the abbreviations for the days of the week takes 4ms on the Fenix 7x and 85ms on the FR 235, but both take 0 in the sim.

  • You need to ask yourself how accurate the result needs to be.  Does it need to be down to the ms, sec, minute, and how accurate is the location you are using?  Is it from the last time you used GPS?

    True story.  Years ago I was looking for a function to get sunrise/set based on the date and lat/lon.  In that case, I felt being within a minute or two was fine (I was using it in my home automation system to turn on and off lights at sunset/rise.  I was on one site and the hard core astronomy types had these huge complex algorithms, and just couldn't understand why I didn't need anything that exact.  Didn't I care the lights could turn on at 17:15:20 instead of 17:15:57? (the answer was "no"!)

    In the end, I found a way to do what I wanted in maybe 25 lines of c code, and it's worked fine for about 20 years now.  Can it be off by a minute? Yes, but not worth worrying about and is much easier to do.

  • It's only accurate within a few minutes now since I'm interpolating between 30 minute intervals. The sun is easy and like you say 20ish lines of code. The moon is a bit wonky. Also, accuracy is mostly determined by the number of terms in each step. The steps themselves don't change but yes some of the corrections are "optional".