The Nexus tablet is powerful enough for the job, refreshing
the screen 10 times per second with new data.
There are 3 thick needles, each one accompanied with a smaller one and a corresponding number of the same color.
The blue data is for STW (Speed Through Water), the green data is for VMG (Velocity Made Good), and the red data is for AWA (Apparent Wind Angle). The small needles are the instantaneous measured values, refreshed 10 times per second. The thick needles and the corresponding numbers are dampened data (moving averages over 1 to 5 seconds, recalculated 10 times per second by the tablet). The damping period (4 s in this screenshot) is adjustable on the fly by sweeping a finger on the tablet up and down.
The small black circle is a moving target (depending on current True Wind Speed), which represents the optimal AWA for best VMG.
The next screenshot is for downwind mode. Here, the red needle represents TWA (True Wind Angle), a more useful information when flying the asymmetrical spinnaker.
There is also a night mode available, created by inverting the black and white colors.
The tablet is not bright enough to be used as a fixed
display in the cockpit, but very usable as a personal display, like the tacticians in the last America Cup.
Ben Ainslie (Oracle Team)
Ray Davies (Team New Zealand)
Hi,
ReplyDeleteI have a similar task I am working on (Android App receiving data over network by UDP broadcast at 10 Hz rate, and display it) and I tried to implement it that Service is receiving network data, and sending it in Intent over BroadcastReceiver to Activities, that display data. And this apprach is not working, the App is laging. Could you please share the approach on App design you have chosen? What's the best concurency model on Android in terms of performance? Thanks in advance.
Tomas,
DeleteI'm using Async task, building on the small example that I present in a previous post.
The Wifly module is programmed to send a fixed number of bytes of the size of my data structure.
Within the doInBackground routine, I have a continuous loop like:
...
while(true)
{
socket.receive(packet);
nr = packet.getLength();
// retrieve and store the data in global variables
...
// then
publishProgress("dummy");
}
Then:
protected void onProgressUpdate(String... ss)
{
// calculate the running averages
...
myView.invalidate(); // refresh the screen with new data
// I am using a custom view
}
This works well for me. The Async task is started manually after the app itself has started. I will have to add some error checking, as once in a while, the packet data is corrupted (there is no delivery guarantee with UDP).
Hi,
Deletethanks for your reply, fast and very helpfull. I actually skipped AsyncTask, just because in the official manual, it's written that it's meant for short one time tasks. And I was afraid to put it constant loop. That's why I moved network receiving part into service separate thread, and chose Broadcasts of Intents for inter process communication. Once I started thinking that this broadcast of intents was causing lag, but actually I found out that this is network issue.
I did this experiment, I ran my app on WiFi Access Point which is used at my home and measured time before and after socket.receive(), mostly it was 300ms (for 10Hz data), and what's strange it had a lot of 0ms samples. What's the meaning of these 0 miliseconds? Isn't receive() a blocking operation? Maybe you have an idea how to debug this ho come it's quite often that receive() is completed in 0 ms?
Then I chose a new WiFi access point (dedicated only for this project, no other activity) and mainly it was 100ms for receive to complete (as it's supposed to be for 10Hz data), but it also had some data in 200ms range, but I guess it's UDP, so you never guarantee all data received at ideal 100ms rate.
Anyways thank's for your help.
Tomas