|
Replies:
10
-
Last Post:
Sep 12, 2008 1:21 AM
by: nordenberg
|
Threads:
[
Previous
|
Next
]
|
|
|
|
|
|
System.currentTimeMillis() resolution problem.
Posted:
Sep 2, 2008 1:21 PM
|
|
|
Hi All!
I've been trying to get our application to run on pMEA on windows mobile
using the binaries found at: http://www.cs.kuleuven.be/~davy/phoneme/
Most things, including Bluetooth API, works fine, but the calls to
System.currentTimeMillis() returns the time in seconds only.
The millisecond part is always 0. (!)
Our application is dependant on this clock, and as an effect it looks like
the GUI is only updated every second. 
I'm running on a HP iPaq 614 Business Navigator with Windows Mobile 6.
Does anyone have an idea how to solve this issue or work around it?
/Mikael
|
|
|
|
|
|
|
Re: System.currentTimeMillis() resolution problem.
Posted:
Sep 2, 2008 3:24 PM
in response to: nordenberg
|
|
|
phonemeadvanced@mobileandembedded.org wrote:
> Hi All!
>
> I've been trying to get our application to run on pMEA on windows mobile
> using the binaries found at: http://www.cs.kuleuven.be/~davy/phoneme/
>
> Most things, including Bluetooth API, works fine, but the calls to
> System.currentTimeMillis() returns the time in seconds only.
> The millisecond part is always 0. (!)
>
> Our application is dependant on this clock, and as an effect it looks like
> the GUI is only updated every second.
>
> I'm running on a HP iPaq 614 Business Navigator with Windows Mobile 6.
>
> Does anyone have an idea how to solve this issue or work around it?
>
>
Hi Mikael,
To answer your question (Davy is out this week), on all Windows Mobile
devices, there is no API that will give you microsecond or better
accuracy when you get the system time.
See:
http://forums.microsoft.com/msdn/ShowPost.aspx?PostID=3567857&SiteID=1
Quote: "There is no API that will give you microsecond accuracy on
Windows Mobile, simply because the hardware does not support it."
So, in short, you can blame it on Bill Gates (or Steve Ballmer), since
it is not the fault of Java ME technology or phoneME Advanced that you
cannot get microsecond/millisecond accuracy when you get the system time
on a Windows Mobile device. 
Hinkmond
---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net
|
|
|
|
|
|
|
|
|
Re: System.currentTimeMillis() resolution problem.
Posted:
Sep 2, 2008 11:02 PM
in response to: Hinkmond Wong
|
|
|
Thanks for the reply.
As I stated in the original question, I'm not interested in microsecond accuracy.
Millisecond accuracy is good enough.
Normally a call to GetSystemTime should give millisecond accuracy, as stated:
http://msdn.microsoft.com/en-us/library/aa908972.aspx
I think it's a real pity if there's no possibility to get timings with a resolution higher
than one second. Most well written MIDP games rely on this timer for animations etc.
What are my possibilities here?
Is it possible to write a JNI-library and call this from my MIDP?
I should say that my app is _MIDP 2.0_, running under dual stack pMEA.
/Mikael
|
|
|
|
|
|
|
|
|
Re: System.currentTimeMillis() resolution problem.
Posted:
Sep 3, 2008 6:47 AM
in response to: nordenberg
|
|
|
Update:
Pocket PC/Windows mobile almost always ignore to fill in the millisecond field
when a call is made to GetSystemTime, as you correctly pointed out Hinkmond.
This seems to be caused by the fact that most Windows phones has an external
chip that keeps track of the real time, with a resolution of one second.
I have just found out that there is a way to circumvent this by enabling a software
clock using timers instead.
Setting the key: HKEY_LOCAL_MACHINE\Platform\SoftRTC = 1 in the registry
enables this software clock, which has much higher precision.
Another workaround could be to use a mix of GetSystemTime and GetTickCount
when requesting the current time to get a higher precision.
The first call to currentTimeMillis() would call GetSystemTime and GetTickCount
and store the results.
Subsequent calls would use these values in combination with another call to
GetTickCount.
There may of course be a drift in time if GetTickCount is not precise.
Thoughts?
/Mikael
|
|
|
|
|
|
|
|
|
Re: System.currentTimeMillis() resolution problem.
Posted:
Sep 3, 2008 5:14 PM
in response to: nordenberg
|
|
|
phonemeadvanced@mobileandembedded.org wrote:
> Update:
>
> Pocket PC/Windows mobile almost always ignore to fill in the millisecond field
> when a call is made to GetSystemTime, as you correctly pointed out Hinkmond.
>
> This seems to be caused by the fact that most Windows phones has an external
> chip that keeps track of the real time, with a resolution of one second.
>
> I have just found out that there is a way to circumvent this by enabling a software
> clock using timers instead.
> Setting the key: HKEY_LOCAL_MACHINE\Platform\SoftRTC = 1 in the registry
> enables this software clock, which has much higher precision.
>
> Another workaround could be to use a mix of GetSystemTime and GetTickCount
> when requesting the current time to get a higher precision.
> The first call to currentTimeMillis() would call GetSystemTime and GetTickCount
> and store the results.
> Subsequent calls would use these values in combination with another call to
> GetTickCount.
> There may of course be a drift in time if GetTickCount is not precise.
>
> Thoughts?
>
Hi Mikael,
You could circumvent that yourself on your device by changing your
registry on your Windows Mobile device. But, that would be a specific
fix for you, not a generic fix for the phoneME Advanced platform that
rests on top of a default Windows Mobile device.
Putting that registry key change in a CAB file would be one way to
automate the registry key change, but our installation of phoneME is not
always done by a CAB.
So, the workaround for the registry key fix is only interesting for
one-off solutions (like just for you or just for a single developer
wanting it to work a special way for their own device, not for a
distributed mobile app you want to sell or give away).
The second workaround to use a GetSystemTime/GetTickCount seems
imprecise, or is trying to make the Windows Mobile platform environment
appear to be more accurate than it really is. This workaround seems
less palatable than the registry key fix.
I think both workarounds are trying to cover up the deficiency of the
Windows Mobile platform in general (it cannot give you millisecond or
microsecond accuracy for the system time as an inherent behavior of
Windows Mobile). So, it might be better to go with what Microsoft gives
you instead of trying to make it something it is not.
The Microsoft Windows Mobile developer forum might give better opinions
on your approaches though. It might be interesting to hear what they say.
Thanks,
Hinkmond
---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net
|
|
|
|
|
|
|
|
|
Re: System.currentTimeMillis() resolution problem.
Posted:
Sep 4, 2008 1:31 AM
in response to: Hinkmond Wong
|
|
|
Hi again Hinkmond.
I absolutely agree that the registry tweak is not a general purpose solution.
There must be a reason for not using the software clock in the first place,
so manually forcing to use the software clock probably mean a sub-optimal
configuration of the device.
I don't agree that the workarounds try to cover up a deficiency in the windows
platform though. They are there to make Java applications more portable.
The sole purpose of them is actually to try to make the runtime behave closer
to the _expected_ behaviour.
Perhaps one could even use a runtime property to select the desired
strategy for the timer. That way it would be up to the developer to select
the beaviour that fits his/her application best.
There's always compromises when implementing a library/runtime on different
platforms, and, I think, not trying to hide the unevitable differences, would
be devastating for a technology trying to be "write once, run eveywhere".
Consulting Windows forums, there are successful uses of workaround 2.
But, understandably, not many users need a precise real time clock, since
they have other means for precise timings. (Like a performance counter, etc)
I think it's unfortunate that Java combines the real time clock and the most
precise delta-time function in a single API call.
As a last request I would be very grateful if you could point me in the right
direction for developing a JNI-library for phoneME advanced (MIDP),
so that I can leverage more precise timings to my application?
Cheers,
/Mikael
|
|
|
|
|
|
|
|
|
Re: System.currentTimeMillis() resolution problem.
Posted:
Sep 4, 2008 3:46 PM
in response to: nordenberg
|
|
|
Hi Mikael,
phonemeadvanced@mobileandembedded.org wrote:
> Consulting Windows forums, there are successful uses of workaround 2.
> But, understandably, not many users need a precise real time clock, since
> they have other means for precise timings. (Like a performance counter, etc)
>
> I think it's unfortunate that Java combines the real time clock and the most
> precise delta-time function in a single API call.
>
Yes, since the Java platform is not really an operating system (for
example, Windows Mobile is an operating system and Linux is an operating
system) but instead Java is an app programming language, it straddles
the space between low level system calls and higher level application
library calls, making it seem like it should do both.
> As a last request I would be very grateful if you could point me in the right
> direction for developing a JNI-library for phoneME advanced (MIDP),
> so that I can leverage more precise timings to my application
Here's a link for some background info:
http://forums.java.net/jive/thread.jspa?threadID=44283&tstart=15
In general, phoneME Advanced follows the JNI spec. and you can follow
the JNI tutorial:
http://java.sun.com/developer/onlineTraining/Programming/JDCBook/jniexamp.html#examp
(Do everything just like you would for Java SE (above), but when it says
to run the Java SE VM, instead use the phoneME Advanced *.lnk and -f
args file way of launching the cvm)
Hinkmond
---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net
|
|
|
|
|
|
|
|
|
Re: System.currentTimeMillis() resolution problem.
Posted:
Sep 4, 2008 11:46 PM
in response to: Hinkmond Wong
|
|
|
Hinkmond Wong wrote:
> Hi Mikael,
>
>
> phonemeadvanced@mobileandembedded.org wrote:
>> Consulting Windows forums, there are successful uses of workaround 2.
>> But, understandably, not many users need a precise real time clock,
>> since
>> they have other means for precise timings. (Like a performance
>> counter, etc)
>>
>> I think it's unfortunate that Java combines the real time clock and
>> the most precise delta-time function in a single API call.
>>
>
> Yes, since the Java platform is not really an operating system (for
> example, Windows Mobile is an operating system and Linux is an
> operating system) but instead Java is an app programming language, it
> straddles the space between low level system calls and higher level
> application library calls, making it seem like it should do both.
>
You also have to be carefull with using the tick counter. Older builds
used the current time when the VM was started, and the tick counter as
an offset
to compute the current time in milliseconds. This works reasonably well,
until you suspend your PDA while your app is still running. When you
resume, the tick counter just continues with the value where it left
off. This way, after a suspend and resume the current time would be computed
incorrectly and this bug was reported on the forum somewhere. That is
why in my builds I use the API call of Windows Mobile to compute the
current time.
I will try to look into it somewhere next week.
Davy
---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net
|
|
|
|
|
|
|
|
|
Re: System.currentTimeMillis() resolution problem.
Posted:
Sep 5, 2008 4:34 PM
in response to: Davy Preuveneers
|
|
|
Davy Preuveneers wrote:
> You also have to be carefull with using the tick counter. Older builds
> used the current time when the VM was started, and the tick counter as
> an offset
> to compute the current time in milliseconds. This works reasonably
> well, until you suspend your PDA while your app is still running. When
> you
> resume, the tick counter just continues with the value where it left
> off. This way, after a suspend and resume the current time would be
> computed
> incorrectly and this bug was reported on the forum somewhere. That is
> why in my builds I use the API call of Windows Mobile to compute the
> current time.
Good point!
>
> I will try to look into it somewhere next week.
Thanks, Davy!
Hinkmond
---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net
|
|
|
|
|
|
|
|
|
Re: System.currentTimeMillis() resolution problem.
Posted:
Sep 7, 2008 2:28 AM
in response to: nordenberg
|
|
|
On Wednesday 03 September 2008, phonemeadvanced@mobileandembedded.org wrote:
> Thanks for the reply.
>
> As I stated in the original question, I'm not interested in microsecond
> accuracy. Millisecond accuracy is good enough.
>
> Normally a call to GetSystemTime should give millisecond accuracy, as
> stated: http://msdn.microsoft.com/en-us/library/aa908972.aspx
I cannot get millisecond granularity on my device either, only second
granularity. This seems to be compliant with the "Remark" section in the link
you gave:
"Millisecond granularity may not be supported by a hardware platform. The
caller of this function should not rely on more than second granularity."
I going to try a slightly different combination of both GetTickCount and
GetSystemTime: Not only compute originTick (the number of ticks that have
elapsed since 1/1/70 until system bootup) at startup of the VM, but also
whenever the computed time (originTick + GetTickCount) drifts more than a
second away from the time returned by GetSystemTime due to suspend and
resume. I hope the overhead will be negligible. Just wait for new builds to
appear on my website.
Best regards.
Davy
---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net
|
|
|
|
|
|
|
|
|
Re: System.currentTimeMillis() resolution problem.
Posted:
Sep 12, 2008 1:21 AM
in response to: Davy Preuveneers
|
|
|
Hi Davy.
Thanks alot for your commitment to this issue!
I do think your approach should work well in almost all cases.
/Mikael
|
|
|
|
|
java.net RSS
