I'm developing an application to perform range measurements at 40Hz and display them on a UI.
To achieve this I have created a Runnable class to perform each cycle and I post to the message queue using the postDelay command to schedule the next command for 25ms. My run method is as follows.
@Override public void run() { m_handler.postDelayed(this, (int)m_samplePeriod_ms); displayRangeData(); } My timing measurements have shown that around half of the time the run method gets executed at 25ms intervals, whereas the rest are typically around 29-32ms.
Is there a way to increase the priority of the Runnable thread so that I can achieve a consistent 40Hz?
Am I being unrealistic in my expectations? I am running on a Samsung Galaxy S3.
Are there other alternatives? I have tried using a thread but I run into problems when I try to update the UI.
On Tuesday, October 30, 2012 2:41:05 PM UTC-5, marcpolo wrote:
> Hi,
> I'm developing an application to perform range measurements at 40Hz and > display them on a UI.
> To achieve this I have created a Runnable class to perform each cycle and > I post to the message queue using the postDelay command to schedule the > next command for 25ms. My run method is as follows.
> @Override > public void run() > { > m_handler.postDelayed(this, (int)m_samplePeriod_ms); > displayRangeData(); > } > My timing measurements have shown that around half of the time the run > method gets executed at 25ms intervals, whereas the rest are typically > around 29-32ms.
> Is there a way to increase the priority of the Runnable thread so that I > can achieve a consistent 40Hz?
> Am I being unrealistic in my expectations? I am running on a Samsung > Galaxy S3.
> Are there other alternatives? I have tried using a thread but I run into > problems when I try to update the UI.
marcpolo, this illustrates why you should take advice with a grain of salt and a pound of verification.
'Timer' does not guarantee an exact interval, thus does not solve the OP's problem.
marcpolo wrote:
> I'm developing an application to perform range measurements at 40Hz and > display them on a UI.
> To achieve this I have created a Runnable class to perform each cycle and > I post to the message queue using the postDelay command to schedule the > next command for 25ms. My run method is as follows.
Underscores in variable names violate the Java Coding Conventions, with the exception of constant variables.
> displayRangeData(); > } > My timing measurements have shown that around half of the time the run > method gets executed at 25ms intervals, whereas the rest are typically > around 29-32ms.
> Is there a way to increase the priority of the Runnable thread so that I > can achieve a consistent 40Hz?
> Am I being unrealistic in my expectations? I am running on a Samsung > Galaxy S3.
> Are there other alternatives? I have tried using a thread but I run into > problems when I try to update the UI.
What do you mean "tried using a thread"? Show us the code.
You certainly don't want to put that delay on the GUI thread.
When I mentioned that I used a thread, I meant that I extended the Thread class with the run() method being overriden. I'm at home at the moment so can't show some code. Basically I would start/stop the thread from a button 'click' handlers. Inside the Run() method was simply a loop to perform the range measurements and sleep for the remainder of the 25ms. This solution didn't work because I couldn't update the UI entities from this thread. Runnable seems to be the better option for accessing views.
I appreciate that android is not a realtime system but thought that 40Hz wouldn't be too difficult to achieve, with the occasional overrun, which wouldn't impair my app. I am getting nowhere near this - even when I remove the range measurement functionality from the run method.
I'll investigate both the timer and scheduledThreadPoolExecutor.
On Tue, Oct 30, 2012 at 8:10 PM, marcpolo <marc.armstron...@gmail.com> wrote:
> I appreciate that android is not a realtime system but thought that 40Hz
> wouldn't be too difficult to achieve, with the occasional overrun, which
> wouldn't impair my app. I am getting nowhere near this - even when I remove
> the range measurement functionality from the run method.
It's not that it's "too difficult to achieve," it's just that for most
circumstances it's easier and more efficient to schedule with very
loose timing guarantees. So this isn't really the framework's fault,
per se, it's more of a "feature" :-)...
} On Tuesday, October 30, 2012 7:10:57 PM UTC-5, marcpolo wrote:
> Thanks very much for the feedback.
> When I mentioned that I used a thread, I meant that I extended the Thread > class with the run() method being overriden. I'm at home at the moment so > can't show some code. Basically I would start/stop the thread from a button > 'click' handlers. Inside the Run() method was simply a loop to perform the > range measurements and sleep for the remainder of the 25ms. This solution > didn't work because I couldn't update the UI entities from this thread. > Runnable seems to be the better option for accessing views.
> I appreciate that android is not a realtime system but thought that 40Hz > wouldn't be too difficult to achieve, with the occasional overrun, which > wouldn't impair my app. I am getting nowhere near this - even when I remove > the range measurement functionality from the run method.
> I'll investigate both the timer and scheduledThreadPoolExecutor.
I used java.util.Timer and TimerTask instead of the Runnable and this resulted in much improved performance, allowing me to schedule the task at 40Hz (on average).
As expected, given this is not a RTOS, the cycles vary +/-1-2ms, however I the the average cycle time is 25ms as desired.
So, it is shown that the Timer performs better than Runnable for scheduling tasks at frequencies around 40Hz (on the Galaxy S3).
> I used java.util.Timer and TimerTask instead of the Runnable and this
> resulted in much improved performance, allowing me to schedule the task at
> 40Hz (on average).
> As expected, given this is not a RTOS, the cycles vary +/-1-2ms, however I
> the the average cycle time is 25ms as desired.
> So, it is shown that the Timer performs better than Runnable for
> scheduling tasks at frequencies around 40Hz (on the Galaxy S3).
> Thanks very much for your help.
> --
> You received this message because you are subscribed to the Google
> Groups "Android Developers" group.
> To post to this group, send email to android-developers@googlegroups.com
> To unsubscribe from this group, send email to
> android-developers+unsubscribe@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/android-developers?hl=en
