Android for T&M products

[kerpal]

When you're talking about T&M equipment, you're talking about a closed system where the software has a singular purpose. What advantage does Android give you there? You probably don't want an ecosystem with apps and whatever. So why not just stick to plain Linux? Development would become much more flexible in terms of tools you can use, and at this point there are probably more devs familiar with the low level details.

Yeah, GUI-wise it'll be easier to develop a nice touch-driven app on Android... but imo knobs and buttons work a lot better for T&M equipment than a touch screen.

The big guns were all going touch-screen last year, and I have to say, as a user for just one month, moving to touch really helped in usability.  I agree with you that knobs and buttons are still useful for certain functions, which is why those companies are still leaving them there despite going touch-screen.  There are too many analysis stuff that is way easier to navigate and adjust using the touch-screen that using the knobs.

Based on all the feedback, I think the GUI part is the only item remained that made us look into Android.  Existing GUI frameworks on WinCE or Linux just isn't updated enough.

[kerpal]

I would think twice about using Android. The thing is, it cold-boots slowly on top of the Linux kernel. You can pretty much tune the kernel to boot up very fast by following the book. But the Android framework coming up on top is another story. You'd have to creatively fine-tune it. Or you have to have your instrument constantly powered and just put the OS in sleep mode.

That's a very good point. Most Android devices take at least 20-30 seconds to boot, whereas pure Linux can easily be made to boot in under 5 seconds.

You are right, that's one more point to consider.

But looking at the Tektronix DPO4000 that we have, it takes several minutes to boot, so we are willing to sacrifice on that. 

But still, a good point.

[kerpal]

Avoid WinCE. It's horrible. We used it on a product with touch interface and it was just a disaster. Trying to get the OS to boot quickly, have a 3D accelerated GUI so it looks like it was written this century and keep power consumption down was a nightmare.

Android is ideal. You can customize it to your needs easily as it is completely open source. Native code works perfectly, no performance issues, well supported and easy to interface to Java if you want to write you app in that. Full access to all hardware, and you can use any Linux driver you need.

Hm ... seems like your experience is exactly something we are trying to avoid.

Which WinCE version was that?  Is WinCE 7 any better, with Silverlight support?

[kerpal]

Cons:

• Java may not be the best language for a computationally-intensive product.  Android does provide an NDK to allow code to be written in C++, but the additional layer of translation will be an overhead, and is even not recommended by Android.
• Probably unable to access hardware freely like we could on the older OSes which are created for this purpose.

I've been doing quite a lot of development with Android of late for communicating with industrial embedded applicaitons, I like it but it's quite different from your scenario.  Just one point though about computationally intensive applications.  The NDK is really meant for running legacy code, not high performance.  Android does have RenderScript, which to a degree is somewhat like CUDA for nvidia.  You need to have a look at it to see if it's suitable for your application, but it does provide a mechanism to achieve computationally intensive tasks that (in some cases) can utilize both multi-core cpus and the gpu in a hardware agnostic manner.  However, gpu support is fledgling and depends on Android API version and hardware.

Seems like development mess to decide which part of the code to run those at those special layers.  This really concerns me, but I wonder if the new GHz range CPUs will negate any overhead when using Java.  In other words, a native C++ code running  fast on a sub 500MHz platform, is it comparable with a Java-based code running on a GHz CPU? 

Would they be equivalent?

[kerpal]

Avoid WinCE. It's horrible. We used it on a product with touch interface and it was just a disaster. Trying to get the OS to boot quickly, have a 3D accelerated GUI so it looks like it was written this century and keep power consumption down was a nightmare.

Android is ideal. You can customize it to your needs easily as it is completely open source. Native code works perfectly, no performance issues, well supported and easy to interface to Java if you want to write you app in that. Full access to all hardware, and you can use any Linux driver you need.

Any driver you like but linux is not the first thought for most people making a device rather than a host.

When you're talking about T&M equipment, you're talking about a closed system where the software has a singular purpose. What advantage does Android give you there? You probably don't want an ecosystem with apps and whatever. So why not just stick to plain Linux? Development would become much more flexible in terms of tools you can use, and at this point there are probably more devs familiar with the low level details.

Yeah, GUI-wise it'll be easier to develop a nice touch-driven app on Android... but imo knobs and buttons work a lot better for T&M equipment than a touch screen.

The underlying OS just provides a shortcut for developing various features, android focuses on UI and mobile phone oriented needs while a piece of electronic test equipment is usually more concerned about its features as part of a larger automated system. So you'd want strong support for one or more of operating as a device over:
USB, GPIB, SCPI, LXI, serial

Oh yeah, your last point on support for GPIB and LXI is spot on.  We'll have to look into whether Android supports that.

Anyway, the common comment is that Android is focus on mobile, while T&M is focused on measurement.  That is what we are trying to break -- focused on measurement, but at the same time keeping up with the GUI trends to improve usability.  LeCroy oscilloscopes seems to be heading that way, although development seems to slowed down.

We can't win against the big boy's ASIC R&D, but we believe we can beat them at our market segment with this direction.

[C]

Why just one processor?
Do you really have to cram it all together?

Take a scope for example, If you think of overlays, you could have some parts of the screen be updated by the gui processor and some of that could be bit map pictures out of the fpga.
Say for example you built a scope, lets go big time and use a HDMI display and pushing it to HD limits just to make it harder.
Say  every thing on the front panel but the bnc connectors was part of the GUI processor section. So the GUI is handling the touch screen, knobs, buttons & switches.
The BNC with it high speed requirements really needs a FPGA and once the data is in the FPGA's memory really could use a lot of parallel processing. It would take a very slow data rate for the GUI section to pass the needed control information to the FPGA section and it could pass along some more data saying put trace 1 in this window on the display.
The GUI section could output Full HD and send it to a simple video overlay processor, a part of the FPGA section which would do the simple thing of using GUI data for all but the defined windows where it would use the the data created by the FPGA section, the wave form.
Think of this you could stack a second board behind the scope's FPGA and have a second instrument or a second scope fpga system able to add it's traces to data windows to where they were needed if they were needed at the time.
Want a 8 channel scope, just stack 4 two channel boards. Granted stacking scope boards would need some communications between scope boards for triggers and sample timing. Chanels 1 & 2 would have a hard time effecting any thing but 1 & 2.
The GUI board could be a common part used in many different equipment.

Want to use a normal PC & the GUI board? You would have two HDMI's that you would need to use a fancier overlay processor that had sync capability.
   
C