Is there a good way to (reliably) retrieve time on Pocket PC with resolution
of milliseconds?

I am implementing a stopwatch using the CF, and I have tried the following:

(1) System.DateTime.Now and GetSystemTime (in coredll.dll)
These always return zero for milliseconds.

(2) System.Environment.TickCount and GetTickCount (in coredll.dll)
These give milliseconds, but API documentation indicates that they are
accurate only to within 0.5 sec. Also, counting stops when the device is
turned off, which is unacceptable for my application.

(3) QueryPerformanceCounter (in coredll.dll)
Implementation of this one is OEM-specific, and it appears to me that most
manufacturers are not implementing it.

Any advice will be appreciated.

2) I don't see anywhere that the accuracy is only 0.5s. Certainly, on our
devices, the resolution is 1ms and the accuracy is pretty good, unless a
misbehaving driver has been installed and is disabling the timer interrupt
for long periods of time.

If you're going to have to keep counting when the device is off, I think
you're *completely* out of luck. Why would a Pocket PC device want to use
battery, even when off, to count something that 99.99% of all people care
nothing about? You'd need special hardware to maintain the count while the
power was off, battery-backed hardware.

Paul T.

"Thomas Taylor" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Is there a good way to (reliably) retrieve time on Pocket PC with
> resolution
> of milliseconds?
>
> I am implementing a stopwatch using the CF, and I have tried the
> following:
>
> (1) System.DateTime.Now and GetSystemTime (in coredll.dll)
> These always return zero for milliseconds.
>
> (2) System.Environment.TickCount and GetTickCount (in coredll.dll)
> These give milliseconds, but API documentation indicates that they are
> accurate only to within 0.5 sec. Also, counting stops when the device is
> turned off, which is unacceptable for my application.
>
> (3) QueryPerformanceCounter (in coredll.dll)
> Implementation of this one is OEM-specific, and it appears to me that most
> manufacturers are not implementing it.
>
> Any advice will be appreciated.
>
>

So you're after a ms resolution stopwatch that will track periods of time
long enough for the device to go to sleep? Even if the device supported it
(and it doesn't without a bit of hacking at best), then consider the fact
that the processor clock itself will have drift of up to several seconds per
day or more, which adds an error factor making milliseconds not terribly
significant.

Basically you're trying to use a screwdriver where a wrench is required.
What you need is a separate circuit, most likely a ms-resolution RTC that is
battery backed. Then you need some sort of interface bus to it, like a
serial connection.

A quick search shows that a DS87C530 would probably fit the bill quite
nicely, and it's I2C, so the communication could be cobbled together even
using the control lines of a standard serial port (an ugly hack, but
workable).

At any rate, an off the shelf Pocket PC isn't going to get you where you
need to be. Sorry.

--
<ctacke/>
www.OpenNETCF.org
Your CF searches start and end here


"Thomas Taylor" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Is there a good way to (reliably) retrieve time on Pocket PC with
> resolution
> of milliseconds?
>
> I am implementing a stopwatch using the CF, and I have tried the
> following:
>
> (1) System.DateTime.Now and GetSystemTime (in coredll.dll)
> These always return zero for milliseconds.
>
> (2) System.Environment.TickCount and GetTickCount (in coredll.dll)
> These give milliseconds, but API documentation indicates that they are
> accurate only to within 0.5 sec. Also, counting stops when the device is
> turned off, which is unacceptable for my application.
>
> (3) QueryPerformanceCounter (in coredll.dll)
> Implementation of this one is OEM-specific, and it appears to me that most
> manufacturers are not implementing it.
>
> Any advice will be appreciated.
>
>

Thanks Paul, I looked back at the documentation, and the point about
0.5-second accuracy comes from the Framework documentation for
System.Environment.TickCount
(http://msdn.microsoft.com/library/de...-us/cpref/html
/frlrfsystemenvironmentclasstickcounttopic.asp), which states "The
resolution of the TickCount property cannot be less than 500 milliseconds."
Perhaps this is a fudge factor for the managed environment to get the count?

The practical reason for needing to keep counting when the device is off is
that users may want to time events that last longer than their auto-suspend
time. One could easily start the stopwatch and have the device turn itself
off in the middle of the event.

From a programming standpoint, I would not really need it to keep counting
while it is off if, for example, I could save the start time (e.g., if
DateTime.Now gave milliseconds) and then compute the elapsed time any time
later, including after the device had been turned off and back on.

Thomas

"Paul G. Tobey [eMVP]" <ptobey no spam AT no instrument no spam DOT com>
wrote in message news:u4hq#(E-Mail Removed)...
> 2) I don't see anywhere that the accuracy is only 0.5s. Certainly, on our
> devices, the resolution is 1ms and the accuracy is pretty good, unless a
> misbehaving driver has been installed and is disabling the timer interrupt
> for long periods of time.
>
> If you're going to have to keep counting when the device is off, I think
> you're *completely* out of luck. Why would a Pocket PC device want to use
> battery, even when off, to count something that 99.99% of all people care
> nothing about? You'd need special hardware to maintain the count while
the
> power was off, battery-backed hardware.
>
> Paul T.

GetTickCount shouldn't suffer from that. As Chris indicated, only some sort
of external, battery-operated timer, is going to run when the device is
'off'.

Paul T.

"Thomas Taylor" <(E-Mail Removed)> wrote in message
news:u$F6C%(E-Mail Removed)...
> Thanks Paul, I looked back at the documentation, and the point about
> 0.5-second accuracy comes from the Framework documentation for
> System.Environment.TickCount
> (http://msdn.microsoft.com/library/de...-us/cpref/html
> /frlrfsystemenvironmentclasstickcounttopic.asp), which states "The
> resolution of the TickCount property cannot be less than 500
> milliseconds."
> Perhaps this is a fudge factor for the managed environment to get the
> count?
>
> The practical reason for needing to keep counting when the device is off
> is
> that users may want to time events that last longer than their
> auto-suspend
> time. One could easily start the stopwatch and have the device turn
> itself
> off in the middle of the event.
>
> From a programming standpoint, I would not really need it to keep counting
> while it is off if, for example, I could save the start time (e.g., if
> DateTime.Now gave milliseconds) and then compute the elapsed time any time
> later, including after the device had been turned off and back on.
>
> Thomas
>
> "Paul G. Tobey [eMVP]" <ptobey no spam AT no instrument no spam DOT com>
> wrote in message news:u4hq#(E-Mail Removed)...
>> 2) I don't see anywhere that the accuracy is only 0.5s. Certainly, on
>> our
>> devices, the resolution is 1ms and the accuracy is pretty good, unless a
>> misbehaving driver has been installed and is disabling the timer
>> interrupt
>> for long periods of time.
>>
>> If you're going to have to keep counting when the device is off, I think
>> you're *completely* out of luck. Why would a Pocket PC device want to
>> use
>> battery, even when off, to count something that 99.99% of all people care
>> nothing about? You'd need special hardware to maintain the count while
> the
>> power was off, battery-backed hardware.
>>
>> Paul T.
>
>

Wait, wait... The RTC in PPC devices still runs when it's powered off. You
don't have to set your clock every time you hit a power button, do you?
While this is not necessarily so in the generic CE devices, creating a
stopwatch out of PPC is a feasible idea. With the caveat described by Chris
(accuracy), you can have a stopwatch functionality. Nobody needs the device
actually counting milliseconds between power-off and subsequent power-on.
All he needs is to be able to tell upon resume that so many seconds have
passed since the "Start" button in his application has been pressed. Now, if
he needs to be able to to something when a time interval has elapsed and the
device may be powered down at that point, then there is trouble since
CeRunAppAtTime accuracy is way lower than it is acceptable for a stopwatch.

So I'd go with GetTickCount - should work IMO

--
Alex Feinman
---
Visit http://www.opennetcf.org
"Paul G. Tobey [eMVP]" <ptobey no spam AT no instrument no spam DOT com>
wrote in message news:(E-Mail Removed)...
> GetTickCount shouldn't suffer from that. As Chris indicated, only some
> sort of external, battery-operated timer, is going to run when the device
> is 'off'.
>
> Paul T.
>
> "Thomas Taylor" <(E-Mail Removed)> wrote in message
> news:u$F6C%(E-Mail Removed)...
>> Thanks Paul, I looked back at the documentation, and the point about
>> 0.5-second accuracy comes from the Framework documentation for
>> System.Environment.TickCount
>> (http://msdn.microsoft.com/library/de...-us/cpref/html
>> /frlrfsystemenvironmentclasstickcounttopic.asp), which states "The
>> resolution of the TickCount property cannot be less than 500
>> milliseconds."
>> Perhaps this is a fudge factor for the managed environment to get the
>> count?
>>
>> The practical reason for needing to keep counting when the device is off
>> is
>> that users may want to time events that last longer than their
>> auto-suspend
>> time. One could easily start the stopwatch and have the device turn
>> itself
>> off in the middle of the event.
>>
>> From a programming standpoint, I would not really need it to keep
>> counting
>> while it is off if, for example, I could save the start time (e.g., if
>> DateTime.Now gave milliseconds) and then compute the elapsed time any
>> time
>> later, including after the device had been turned off and back on.
>>
>> Thomas
>>
>> "Paul G. Tobey [eMVP]" <ptobey no spam AT no instrument no spam DOT com>
>> wrote in message news:u4hq#(E-Mail Removed)...
>>> 2) I don't see anywhere that the accuracy is only 0.5s. Certainly, on
>>> our
>>> devices, the resolution is 1ms and the accuracy is pretty good, unless a
>>> misbehaving driver has been installed and is disabling the timer
>>> interrupt
>>> for long periods of time.
>>>
>>> If you're going to have to keep counting when the device is off, I think
>>> you're *completely* out of luck. Why would a Pocket PC device want to
>>> use
>>> battery, even when off, to count something that 99.99% of all people
>>> care
>>> nothing about? You'd need special hardware to maintain the count while
>> the
>>> power was off, battery-backed hardware.
>>>
>>> Paul T.
>>
>>
>
>

Not accurate to ms, though (most RTC clock chips aren't).

Paul T.

"Alex Feinman [MVP]" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Wait, wait... The RTC in PPC devices still runs when it's powered off. You
> don't have to set your clock every time you hit a power button, do you?
> While this is not necessarily so in the generic CE devices, creating a
> stopwatch out of PPC is a feasible idea. With the caveat described by
> Chris (accuracy), you can have a stopwatch functionality. Nobody needs the
> device actually counting milliseconds between power-off and subsequent
> power-on. All he needs is to be able to tell upon resume that so many
> seconds have passed since the "Start" button in his application has been
> pressed. Now, if he needs to be able to to something when a time interval
> has elapsed and the device may be powered down at that point, then there
> is trouble since CeRunAppAtTime accuracy is way lower than it is
> acceptable for a stopwatch.
>
> So I'd go with GetTickCount - should work IMO
>
> --
> Alex Feinman
> ---
> Visit http://www.opennetcf.org
> "Paul G. Tobey [eMVP]" <ptobey no spam AT no instrument no spam DOT com>
> wrote in message news:(E-Mail Removed)...
>> GetTickCount shouldn't suffer from that. As Chris indicated, only some
>> sort of external, battery-operated timer, is going to run when the device
>> is 'off'.
>>
>> Paul T.
>>
>> "Thomas Taylor" <(E-Mail Removed)> wrote in message
>> news:u$F6C%(E-Mail Removed)...
>>> Thanks Paul, I looked back at the documentation, and the point about
>>> 0.5-second accuracy comes from the Framework documentation for
>>> System.Environment.TickCount
>>> (http://msdn.microsoft.com/library/de...-us/cpref/html
>>> /frlrfsystemenvironmentclasstickcounttopic.asp), which states "The
>>> resolution of the TickCount property cannot be less than 500
>>> milliseconds."
>>> Perhaps this is a fudge factor for the managed environment to get the
>>> count?
>>>
>>> The practical reason for needing to keep counting when the device is off
>>> is
>>> that users may want to time events that last longer than their
>>> auto-suspend
>>> time. One could easily start the stopwatch and have the device turn
>>> itself
>>> off in the middle of the event.
>>>
>>> From a programming standpoint, I would not really need it to keep
>>> counting
>>> while it is off if, for example, I could save the start time (e.g., if
>>> DateTime.Now gave milliseconds) and then compute the elapsed time any
>>> time
>>> later, including after the device had been turned off and back on.
>>>
>>> Thomas
>>>
>>> "Paul G. Tobey [eMVP]" <ptobey no spam AT no instrument no spam DOT com>
>>> wrote in message news:u4hq#(E-Mail Removed)...
>>>> 2) I don't see anywhere that the accuracy is only 0.5s. Certainly, on
>>>> our
>>>> devices, the resolution is 1ms and the accuracy is pretty good, unless
>>>> a
>>>> misbehaving driver has been installed and is disabling the timer
>>>> interrupt
>>>> for long periods of time.
>>>>
>>>> If you're going to have to keep counting when the device is off, I
>>>> think
>>>> you're *completely* out of luck. Why would a Pocket PC device want to
>>>> use
>>>> battery, even when off, to count something that 99.99% of all people
>>>> care
>>>> nothing about? You'd need special hardware to maintain the count while
>>> the
>>>> power was off, battery-backed hardware.
>>>>
>>>> Paul T.
>>>
>>>
>>
>>
>
>

No, it is not, but do you think the OP really needs msecs? I mean if you
have to use your finger to press start/stop button, what do you care about a
few hundred msec anyway?

--
Alex Feinman
---
Visit http://www.opennetcf.org
"Paul G. Tobey [eMVP]" <ptobey no spam AT no instrument no spam DOT com>
wrote in message news:(E-Mail Removed)...
> Not accurate to ms, though (most RTC clock chips aren't).
>
> Paul T.
>
> "Alex Feinman [MVP]" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> Wait, wait... The RTC in PPC devices still runs when it's powered off.
>> You don't have to set your clock every time you hit a power button, do
>> you? While this is not necessarily so in the generic CE devices, creating
>> a stopwatch out of PPC is a feasible idea. With the caveat described by
>> Chris (accuracy), you can have a stopwatch functionality. Nobody needs
>> the device actually counting milliseconds between power-off and
>> subsequent power-on. All he needs is to be able to tell upon resume that
>> so many seconds have passed since the "Start" button in his application
>> has been pressed. Now, if he needs to be able to to something when a time
>> interval has elapsed and the device may be powered down at that point,
>> then there is trouble since CeRunAppAtTime accuracy is way lower than it
>> is acceptable for a stopwatch.
>>
>> So I'd go with GetTickCount - should work IMO
>>
>> --
>> Alex Feinman
>> ---
>> Visit http://www.opennetcf.org
>> "Paul G. Tobey [eMVP]" <ptobey no spam AT no instrument no spam DOT com>
>> wrote in message news:(E-Mail Removed)...
>>> GetTickCount shouldn't suffer from that. As Chris indicated, only some
>>> sort of external, battery-operated timer, is going to run when the
>>> device is 'off'.
>>>
>>> Paul T.
>>>
>>> "Thomas Taylor" <(E-Mail Removed)> wrote in message
>>> news:u$F6C%(E-Mail Removed)...
>>>> Thanks Paul, I looked back at the documentation, and the point about
>>>> 0.5-second accuracy comes from the Framework documentation for
>>>> System.Environment.TickCount
>>>> (http://msdn.microsoft.com/library/de...-us/cpref/html
>>>> /frlrfsystemenvironmentclasstickcounttopic.asp), which states "The
>>>> resolution of the TickCount property cannot be less than 500
>>>> milliseconds."
>>>> Perhaps this is a fudge factor for the managed environment to get the
>>>> count?
>>>>
>>>> The practical reason for needing to keep counting when the device is
>>>> off is
>>>> that users may want to time events that last longer than their
>>>> auto-suspend
>>>> time. One could easily start the stopwatch and have the device turn
>>>> itself
>>>> off in the middle of the event.
>>>>
>>>> From a programming standpoint, I would not really need it to keep
>>>> counting
>>>> while it is off if, for example, I could save the start time (e.g., if
>>>> DateTime.Now gave milliseconds) and then compute the elapsed time any
>>>> time
>>>> later, including after the device had been turned off and back on.
>>>>
>>>> Thomas
>>>>
>>>> "Paul G. Tobey [eMVP]" <ptobey no spam AT no instrument no spam DOT
>>>> com>
>>>> wrote in message news:u4hq#(E-Mail Removed)...
>>>>> 2) I don't see anywhere that the accuracy is only 0.5s. Certainly, on
>>>>> our
>>>>> devices, the resolution is 1ms and the accuracy is pretty good, unless
>>>>> a
>>>>> misbehaving driver has been installed and is disabling the timer
>>>>> interrupt
>>>>> for long periods of time.
>>>>>
>>>>> If you're going to have to keep counting when the device is off, I
>>>>> think
>>>>> you're *completely* out of luck. Why would a Pocket PC device want to
>>>>> use
>>>>> battery, even when off, to count something that 99.99% of all people
>>>>> care
>>>>> nothing about? You'd need special hardware to maintain the count
>>>>> while
>>>> the
>>>>> power was off, battery-backed hardware.
>>>>>
>>>>> Paul T.
>>>>
>>>>
>>>
>>>
>>
>>
>
>

Thanks Chris, Alex, and Paul. Your responses help a bunch, especially in
confirming that I was not missing something in the OS. Now I just have to
decide whether to try to bend that screwdriver into the shape of a wrench.

Thanks again,
Thomas Taylor

p.s., Great work at http://www.opennetcf.org.