Small stopwatch

[token]

As the title says - a small stopwatch.

Regards: Token

 

[nm7s9]

Hi Token,

I like your code and design:sign0098: especially the "Retour-en-vol" feature aka "Flyback", where the reset button works even while the stopwatch is running. This feature is very usefull for tennis umpires and golf referees.

If screen space permits maybe you could add a "Lap" feature which would stop updating the display (whilst still running the stopwatch) until the button is pushed again.

One thing I did notice is that it takes 67 real seconds on my PC for the stopwatch to clock up 1 minute and similar times in My PPC.

I think this is because the timer does not wake you up exactly as requested.

On My PC I observed an occasional 101 ms interval and about once every 10 or so events the interval was 110 ms (which explains the extra 7 seconds per minute). On the PPC the intervals tended to be more regular but were usually about 102 or 103 ms but still with the odd very large one.

One way to combat this would be to get the msec value of GetTickCount (from the dz.dll library) whenever the start button is pushed and divide by 10 to get a tenths of a second value. Then set the timer value to (for example) 31 msec so that you definetly get woken up multiple times every 1/10th of a second. Each time you wake up get a new value of Get TickCount, divide by 10 and if this value is greater than the last sample then increment your counters.

Cheers
Nick

 

[nm7s9]

:signOops:

After all that I found that the answer is even more simple.

Your counter for tenths of a second has 11 values (0 to 10) instead of 10

Therefore if you change If TimerTenSec < 10 to If TimerTenSec < 9 then the stopwatch wil be a lot more accurate.

However the method I suggested would ( I think) be still more accurate. I'll do some more timing test now.

 

[nm7s9]

Hi again,

Even after changing your constants "10 60 60" to "9 59 59" the stopwatch still lost about 10 seconds in 10 minutes on the PPC.

Using GetTickCount (divided by 100, not 10 as I said) the stopwatch was only 1 second out after 10 minutes on the PPC - I think the mechanical stopwatch I was checking it against may have a small problem. I'll check it now against a couple of quartz chronographs.

I'll get this right soon, I hope.

 

[token]

:signOops:

After all that I found that the answer is even more simple.

Your counter for tenths of a second has 11 values (0 to 10) instead of 10

Therefore if you change If TimerTenSec < 10 to If TimerTenSec < 9 then the stopwatch wil be a lot more accurate.

However the method I suggested would ( I think) be still more accurate. I'll do some more timing test now.

Seems to be right - stupid mistake of me... :sign0013:

Thanks a lot to everyone for the nice and helpfull feedback!

I've clicked this app together cause someone asked for a stopwatch for his diamond in an user-forum - seems to be not totaly trivial to build a really accurate timing, even aside from my mistake.

Many regards:

Token

p.s.: I've corrected the constants and updated the attachement within the first post.

 

[token]

As nm7s9 suggested, I've added some kind of a Laptimer. I'm not shure, if each lap has to start with 0 again - please advice me, if this is the case.

Will try to get a better timer-accuracy in a later version.

Regards:

Token

 

[nm7s9]

LapTimer feature works perfectly. No need to reset any counters since Lap time is just a "snapshot" of current counters.

I wonder if it is possible to display the bottom bit of the table rather than the top bit without having to reverse sort it or remove the top entries.

I don't seem to be able to use TableLap.RowCount in a filter expression.


PS -the GetTickCount method is still losing 8 seconds each hour on my PPC but is exactly correct on the desktop. I WILL find those missing seconds (maybe this weekend).

 

[token]

LapTimer feature works perfectly. No need to reset any counters since Lap time is just a "snapshot" of current counters.

I wonder if it is possible to display the bottom bit of the table rather than the top bit without having to reverse sort it or remove the top entries.

I don't seem to be able to use TableLap.RowCount in a filter expression.


PS -the GetTickCount method is still losing 8 seconds each hour on my PPC but is exactly correct on the desktop. I WILL find those missing seconds (maybe this weekend).

Could you tell me where I can find the dz.dll you've mentioned? Did a forum-search but without success.

I've searched for "timer" in the forum to get any hint about accuracy but also without success.

Perhaps the problem is, I'am adding only 1/10 tick-events together. I do not know if executing of every tick in windows-mobile is guaranted or if it can be lost by heavy os-load. I even not know, if one can trust the timer of a windows-mobile device.

 

[Cableguy]

PS -the GetTickCount method is still losing 8 seconds each hour on my PPC but is exactly correct on the desktop. I WILL find those missing seconds (maybe this weekend).

You should take in account that the desktop processing speed is much greater that the device, so the time lost in processing the code at each "Tick" is discrdable, BUT in the device is something to keep in mind... I would suggest to try different timer.interval values...

 

[nm7s9]

Hi Paulo,

Thanks for the reply. I believe that my method is independent from processing time in the subroutines and cpu workload. I just use the difference of the GetTickCount at button start to what it is now to determine whether to bump the counters or not (and make sure I am woken up multiple times in each time window.

What I have noticed is that I allowed a very small incemental error to accumulate, which I think explains my 7 sec/hour error. I've coded around this and will test its accuracy a bit later tonight.

BTW do you know of a method to display the bottom bit of a table rather than the top bit. I.E can you scroll the scrollbars under program control??

Token, The GetTickCount function can be called using the dzHW.dll and dzHWdesktop.dll. See the thread "Font Problem" in the Questions and answers section which contains a link to this "Useful Library"

Cheers
Nick

 

[nm7s9]

OK -success,

I've run the code on 2 PC's and 2 PPC. One PPC was 520MHz single core and the other 200MHz dual core. After one hour all agree almost exactly.

I've attached a copy of the code with the 11 lines I added in.

Lines 10, 14-16, 25-26 and 31-35. I'm sure there are better ways to do this but this does appear to be accurate.

 

[Cableguy]

Hi Paulo,


BTW do you know of a method to display the bottom bit of a table rather than the top bit. I.E can you scroll the scrollbars under program control??

Nick

Place the table in a panel and place the panel in a way that only the part you want visible, is in fact visible...(i.e.:Top-50 in 100 heigth panel will show only the bottom half of the panel...)

 

[nm7s9]

Ok -thanks, I'll give it a try.

Token - BTW in the sbp I attached I had also altered the timer control to 31 millisec ( I like prime numbers ) This number needs to be significantly less than 100 msec in order to maintain the accuracy.

 

[Cableguy]

I would also suggest the use of 2 tables.... a temp (visible) one with only, lets say, 3 rows, in wich the new values would enter the last row, and the older value row would be deleted... And a "perm"(hidden) table, wich would contain ALL the lap values...
Also a feature suggestion...
The ability to save or export the table, and to compare 2 tables/files....

 

[klaus]

Here is a simple method to show the last lap time in top.

  Sub ButtonLap_Click
    LapNr = LapNr + 1
    TableLap.AddRow(LapNr,TimerMin&":"&TimerSec&":"&TimerTenSec)
    [COLOR="Red"]TableLap.TableSort("Time DESC")
    TableLap.SelectCell("Lap",0)[/COLOR]
  End Sub

I think that it would be interesting to also have the stop time in the list.

Best regards.

 

[nm7s9]

Hi token,

Cableguy was right about cpu load affecting the counting method. Even hitting "Lap" can steal enough cpu cycles to cause a timer miss. If srb time or active sync are running in the background then the stopwatch really loses time rapidly. Also if the PPC goes to sleep then the stopwatch also stops.

The best way to solve all these problems is to caculate the values each time rather than incrementing them. The resulting code is very simple and results in an extremely accurate stopwatch whch is just about indestructable.

Even the PPC goin to sleep doesn;t stop it displaying the right time once it awakes and if active sync is running, the stopwatch may appear to run roughly but it is still keeping exact time.

I also found a way to display the bottom bit of a table. You just access the bottom left cell of the table and then move focus to a button hidden under the lap button. This work perfectly on the desktop but causes an exception on the PPC when LAP is pushed - I'm not sure why yet.

I've attached the new sample code (with the focus thing commented out).

I think that the only way you can slow this stopwatch down is to drop it in a bucket of water .

 

[token]

Hi token,

Cableguy was right about cpu load affecting the counting method. Even hitting "Lap" can steal enough cpu cycles to cause a timer miss. If srb time or active sync are running in the background then the stopwatch really loses time rapidly. Also if the PPC goes to sleep then the stopwatch also stops.

The best way to solve all these problems is to caculate the values each time rather than incrementing them. The resulting code is very simple and results in an extremely accurate stopwatch whch is just about indestructable.

Even the PPC goin to sleep doesn;t stop it displaying the right time once it awakes and if active sync is running, the stopwatch may appear to run roughly but it is still keeping exact time.

I also found a way to display the bottom bit of a table. You just access the bottom left cell of the table and then move focus to a button hidden under the lap button. This work perfectly on the desktop but causes an exception on the PPC when LAP is pushed - I'm not sure why yet.

I've attached the new sample code (with the focus thing commented out).

I think that the only way you can slow this stopwatch down is to drop it in a bucket of water .

Hi,

sounds very good - I'll try it out, when I'am home. Any solution for the issue with the water-bucket?

 

[nm7s9]

Interestingly - On my WM6 PPC the GetTickCount keeps going when the PPC goes to sleep, but on the WM5 PPC the GetTickCount stops which effectively also stops the stopwatch.

The "srb time" timers gets around this problem (on WM5) by giving the OS a swift kick in the ribs every time it tries to go to sleep. On WM6 it does not do this since the counters will still be correct on next wakeup.

Maybe we need a control which will tell us we are about to go to sleep and give us the option of denying this or at worst saving away some useful info to a file for use by a wakeup subroutine.

 

[nm7s9]

The show bottom bit of table work properly if I use rowcount-1.:sign0161:

However I like Klaus' idea of reverse sorting it and also Cableguy's idea of having a small display table (which eliminates the scroll bars) and a full table to display when stopwatch is in stopped mode.

 

[Cableguy]

The best way to solve all these problems is to caculate the values each time rather than incrementing them. The resulting code is very simple and results in an extremely accurate stopwatch whch is just about indestructable.

.

By always calculating the elapsed time, you are making the computing cycling always the same so they take always the same amount of time...

Nice going....
You had me starting my own topWatch.....