I am designing a hand-held piece of test equipment for a client that sells these devices to plants that work with stamping operations. The architecture of this device involves serial communication between an off-the-shelf Android tablet as the HMI and a custom Microchip-based circuit that has a serial interface. The most convenient way to connect the Android tablet to the PIC is with a Bluetooth-to-serial module - even though the two devices are mounted right next to each other in a single box. But my client tells me that security concerns in many of these plants, especially the ones in China, are so high that they will not allow a device that uses Bluetooth into their plants. So my client wants me to look for a hardwired solution based on the USB. Unfortunately stock Android tablets do not come with USB drivers for the typical USB-to-serial modules, so the hardwired option looks to be quite difficult.

So my question is "Is my client worrying needlessly"? What if we came out with a device that only used Bluetooth to communicate 2 inches from a tablet to a PIC board? Will he have a hard time selling his test equipment to some metal stamping plants? (BTW, the device measures the amount of lubricant on the metal before it gets stamped by the die, and my client has been selling an older version of this instrument for many years.)

 

I'd look at simply using USB on the android side and a FTDI chip to serial on the Microchip side. Probably just a little less easy and probably cheaper than Bluetooth. The FTDI stuff is used a lot for embedded processors and you should be able to find an Off The Shelf board or adapter from many sources. Look around the Atduino sites for minimum cost ideas. It's a little less kludgey than Bluetooth for a couple inches and would head off any security issues. Drivers should not be an issue as this is done all the time with Linux, which people forget, is what Android is running on.

As a side note, does anyone else think Android is kind of an improbable product? To take pains to create a low power, high function, state of the art platform, running an efficiency tailored, low resource OS and plopping Java the hut on top just seems wrong somehow. Maybe it's just me.

Regards
cww

 

Most Android devices do have ports for SD flash memory cards. I have not seen a market for adapters using the SD interface the way that USB is used, but clearly, it has this capability.

By the way, Bluetooth has several modes of operation. You would select a high security mode in which the data stream is encoded with at least 256-bit encryption. The developers call this "wired equivalent privacy." You can also achieve a non-intercept mode by using identical transmit/receive antennas that are too short to allow much external transmission range.

However, since they are matched, you will get excellent short-range
coupling.

Dick Caro

 

First, in response to Curt, to use an FTDI chip on the Microchip side would be my preference too, except for the fact that current Android tablets do not come with USB host-mode drivers for such devices. And unlike desktop computers, there is no easy way to add drivers for new USB devices. So I would be faced with making a custom build of the Android core - something that is way beyond my ability or desire.

And Dick, you may be right that hardware-wise the SD card interface is just a 3-wire SPI interface. But again the problem is not hardware. It is software. The Android OS does not provide any low-level access to the SD card slot. It only provides software for accessing SD memory card as file systems. I suppose I could simulate a file system on the Microchip side, but that sounds like a lot of work.

But my real question is what is the real security concern a potential customer may have about using this equipment? The data being transferred from the Android HMI to the PIC is not particularly sensitive, so I doubt that the customer is worried about outside devices corrupting our data stream. My client seems to indicate that the concern is the other way around. He indicated that the end customer is worried that our device will use its Bluetooth capability to spy on other devices in their factory and do industrial espionage. This seems really far-fetched to me, so that is why I am asking if anyone can confirm that such a fear might exist, especially among the Asian stamping plants.

 

In my opinion Hard wired is always better, and if the customer wants it you might want to look into it further.

I thought I read online somewhere that there were ways to get different kernels into the Android devices that had serial support. I've not done it with "android linux" but with standard linux all that is required is to enable the USB-serial converters for the chipsets you care about. Enabling the FTDI and prolific drivers into the kernel should not be a problem even if you have to recompile your kernel. I'm almost positive that there are groups out there who have already done this, check it out.

As for programming, you may or may not be able to use the Java programming, but as pointed out already by PVBrowser, QT C/C++ programming for linux is available for Android with the Necessitas development software.

KEJR

 

The main problem is that it doesn't matter if we think the customer is being paranoid. Customers are inclined to think whatever they please. Since it sounds like you have the device mounted, perhaps you could use an "unbundled" tablet or device, that is an SBC
that amounts to a tablet without the case which would generally provide more communications options. It would mean more integration, but having a device that you can know something about might be worth it and for sure would be easier to develop for. Or you could try finding out if the tablet has serial capability that is simply not pinned out, that's fairly likely . I think the unbundled approach is where I would have started if the tablet could be stationary. It's kind of a case where you need something it hasn't got and you don't want to do what it takes to get it.

In that situation, I think you need a different customer. Or a redesign.

Regards
cww