LabVIEW android connection

[arya1]

Hi all

I would like to make LabVIEW (LV 2013 32 bit in Win 64 bit processor) in an RT target (myRIO or sbRIO) to communicate to an Android smartphone. I want to send a graph data (around 1000 points, could be downsampled) and chart data to the smartphone at a very fast rate (every10 to 20 ms) and would like to take in some control inputs from the smartphone (a full duplex communication). I have heard about SCCT, but unfortunately, they do not have an option for graph display. Data dashboard for android is not as good as the iphone version too. So, i guess there are two options left, one using web services and the other using TCP/IP (is this full duplex?). Which of the two will be better, in terms of development time, speed of transmission and usability/user experience? 

Thankyou

Arya

[mikeporter]

Well, unless you want to do a lot of Android development, your solution is going to be some sort of web-based interface.

Mike...

[arya1]

Hi Mike

Thanks a lot for the suggestion. 🙂 ..we wont be doing much of android development, its just for user experience and to give some user control parameters. Thats all. I was more worried about the speed of data transmission. I think that should not be much of a problem. I will start working on web services and see what develops. 

Thanks

Arya

[RTSLVU]

Have you tried the NI Data Dashboard for Android?

Nevemind I see you have tried it?

[arya1]

Hi RTSLVU

Yes, we had tried it in demo mode only, just to see the options and interfaces, then later changed the plan, as our application demands more. 

Thanks

Arya

[mikeporter]

You also are going to want to give some very careful thought to exactly what you are going to display and how fast to display it. For example, you mentioned charting data at a 10 - 20 msec rate. First, you are not going to be able to display data that fast over a wireless network connection to a smartphone. Second, even if you could, the display would be unusable. To see what I mean, prototype it by sending a random number to a chart every 10 ms and see what it looks like.

Obviously you can acquire and process data as fast as you need to, but the user interface has a separate speed limit: how fast a human beings can perceive a change and respond to it.

Mike...

[arya1]

Hi Mike

Thanks for the suggestions. We have been working only with PCs and this is the first time we are trying something like this, hence your comments value a lot. I get your point. For the user experience, we could downsample the data and the decrease the rate. We had tried the same using remote front panel options in a tablet and that works reasonably ok. Now, my query is, will there be any advantage in terms of the speed and the bandwidth if we try the web based method over a wired connection as opposed to a wireless connection? I could not spot any difference while we tried out remote front panel. 

Thanks

Arya

[dems]

Labview web services can't meet your rate, I don't think. I remember them being pretty slow on cRIO. Labsocket (http://labsocket.com/) might be an OK fit since it uses (basically) a tcp connection.

A simpler solution is to just keep a buffer on the cRIO and use web services to request that buffer at a slow rate (ie rather than 1 sample every 10 ms, 100 samples every second). I haven't used data dashboard so I don't know if it supports arrays, but I know you can make a pretty straightforward graph in javascript (http://startbootstrap.com/templates/sb-admin/charts.html as an example) which can be displayed in any browser. If you stick with web services its also pretty easy to send those commands you want to send.

---

Now, my query is, will there be any advantage in terms of the speed and the bandwidth if we try the web based method over a wired connection as opposed to a wireless connection? I could not spot any difference while we tried out remote front panel.  

---

Bandwidth I don't think so (at least not on the sort of scale you should be concerned about), but speed will be different just due to the inherent latency of wireless connections. HTTP is a request-response protocol which means that on every call you suffer the full latency of your network (twice!), which is higher with wifi than with wired. You won't notice any CPU issues, you'll just notice that your code is waiting a lot on both ends for data to be transferred across the network. Depending on the quality of your network you could see response times anywhere from a few ms up to 10s of ms.

[arya1]

Hi Dems

Thanks a lot for the suggestions. I had a look at the web services shipped example, weather monitor and tried varying the rates. It looked promising. As Mike had said, my rates could be slowed down according to the human perception levels. I went through the labsocket page. Its really cool stuff. I am a bit skeptical about using third party addons, but would definitely want to give it a try. The javascript plotting method would help people with no CS background like me. I will try out both the ways. 🙂

Thanks a lot

Arya

[mikeporter]

---

@arya1 wrote:

Hi Mike

Thanks for the suggestions. We have been working only with PCs and this is the first time we are trying something like this, hence your comments value a lot. I get your point. For the user experience, we could downsample the data and the decrease the rate. We had tried the same using remote front panel options in a tablet and that works reasonably ok. Now, my query is, will there be any advantage in terms of the speed and the bandwidth if we try the web based method over a wired connection as opposed to a wireless connection? I could not spot any difference while we tried out remote front panel. 

Thanks

Arya

---

There is in a sense no ultimately "right" answer as to which is better, wired or wireless. There are always situations where one will give better performance over the other. Wired connections have fewer connection reliability issues (the wire is either there or it's not) and are theoretically higher bandwidth; but you are potentially sharing the network bandwidth with a very large number of other users. So if your wireless AP is the only one in the area, wireless might give much better performance. On the the hand if your AP is but one of dozens in the same room (yes, I'm looking at you NIWeek), wireless can be very sketchy -- and then there's the whole issue of RF noise. Remember that WIFI is a radio protocol.

In terms of interface design, something you might want to consider is a layered UI where the initial screen gives high-level, overview data, but provides the ability to drill-down to greater levels of detail -- which would conceivably present more information and require more bandwidth.

Mike...