Simple point-to-point communication with an embedded platform and an Android smartphone

I'm designing an embedded system based on a Cortex-M0+ MCU.  I have to 
choose a way to make a connection between this system and a generic 
Android smartphone.  The requirements are low-cost, simplicity and 
availability with the most of smartphones on the market.  I don't need 
long range: it's sufficient to exchange data when the smartphone is near 
the system.
The embedded system has an integrated GSM module (used for other things) 
that can be used for this purpose.

I was thinking about the following alternatives, but all of them have 
pros and cons.  Any suggestions?

SMS/voice
The app running  module in the embedded system.on the smartphone can 
sends/receives SMSs or make voice calls.  In this scenario I can use the GSM
Main cons are the cost of the connection and the old technology.

IP connection
The communication can be made on top of an IP connection, but I need to 
use a GPRS/UMTS modem (for my application, I need just a GSM modem).
Even this type of connection could be expensive for the user.
Moreover, the point-to-point connection could be troublesome depending 
on the mobile service providers: firewall, private NAT-ed IP addresses 
and so on.  I know I can provide a central server on the Internet, but I 
dont' want to offer this service (that should work everyday).

Bluetooth
Bluetooth connection has many advantages: wireless, point-to-point, 
short range.  The main problem I see is the complexity (cost) of the 
embedded system that must be keeped be very simple (low cost).  I could 
integrate a serial-Bluetooth module, but I think it is expensive (do you 
know how much could it cost for 1000 pieces?).
I could provide a RS232-Bluetooth dongle separated from the emebedd 
system, so the user can re-use it for many systems.  What is the cost of 
this type of product?
How complex would be developing and Android app that sends/receives 
asyncronous packets on a Bluetooth link, like on a RS232 link?  The app 
should open the connection, sends some bytes and waits for some other 
bytes from the embedded system.

USB
Every smartphone has at least one USB port that is used for battery 
recharging and communication with the PC.  The problem is it is usually 
a device port and I can't add the complexity of a host USB port on my 
system.
I know newer Android versions have a native USB host support, but the 
smartphone should have at least an OTG USB port.  How many smartphones 
provide this type of port?
If I have a smartphone with a OTG USB port and a decent Android version, 
could I connect a simple RS232-USB adapter and hope it will be detected 
without problems?  How simple is to write an app that open the virtual 
RS232 port and sends/reiceves data on that link?
Another possibility could be to directly integrate a USB slave port in 
my system.  This port should provide CDC interface and the Android 
smartphone should detect it as a virtual serial port (to open/close, 
write/read).
Actually integrating a host USB port in the system shouldn't be 
difficult and expensive, but how the smartphone will be detected by my 
system? As a mass storage device? And how could I exchange data between 
them as on a serial link?

pozz <pozzugno@gmail.com> writes:
> I was thinking about the following alternatives...
> SMS/voice...
> IP connection...
> Bluetooth...

Bluetooth sounds like the best bet and is surely a lot cheaper than the
GSM module that you already have.  The TI CC2541 is around $2 in
quantity depending on variant
(http://www.ti.com/product/CC2541/samplebuy) though that might be more
than you really want to pay.

An unmentioned choice is an audio modem implemented in software at both
ends, using the wired headset connection.  This is how the Stripe credit
card reader works, for example: it's a small mag stripe reader that
plugs into the headphone jack of most phones.

Writing Android apps has a learning curve but there's lots of tools and
docs out there and the programming model isn't too crazy.  I haven't
done it myself yet, but have some projects in mind that will need it.

> Another possibility could be to directly integrate a USB slave port in 
> my system.  

Or a USB host slave controller.

> This port should provide CDC interface and the Android 
> smartphone should detect it as a virtual serial port (to open/close, 
> write/read).
> Actually integrating a host USB port in the system shouldn't be 
> difficult and expensive, but how the smartphone will be detected by my 
> system? As a mass storage device? And how could I exchange data between 
> them as on a serial link?

As an IP connection over ADB (Android Debug Bridge).

Paul Rubin <no.email@nospam.invalid> writes:

> pozz <pozzugno@gmail.com> writes:
>> I was thinking about the following alternatives...
>> SMS/voice...
>> IP connection...
>> Bluetooth...
>
> Bluetooth sounds like the best bet and is surely a lot cheaper than the
> GSM module that you already have.  The TI CC2541 is around $2 in
> quantity depending on variant
> (http://www.ti.com/product/CC2541/samplebuy) though that might be more
> than you really want to pay.

The OP did say right off the target is an Android phone, but beware that
you can't use these standard modules to connect to iPhone's etc. Apple
requires some magic hardware in the middle.
-- 
Randy Yates
Digital Signal Labs
http://www.digitalsignallabs.com

 
> The OP did say right off the target is an Android phone, but beware that
> you can't use these standard modules to connect to iPhone's etc. Apple
> requires some magic hardware in the middle.

Yes, Apple is known for taking standard interfaces (USB, charging) and making it non-standard and more expensive.  Hopefully, iPhone and iPad will follow the Mac PC's path to disappearance.

Randy Yates <yates@digitalsignallabs.com> writes:
> The OP did say right off the target is an Android phone, but beware that
> you can't use these standard modules to connect to iPhone's etc. Apple
> requires some magic hardware in the middle.

What?  Do you mean you can't use standard bluetooth headsets and other
such accessories with an iphone?  I'm glad I don't have an iphone in
that case.  Wow.  I do know they work ok with standard 3-pin stereo
headphones, but they switched two of the pins around in the 4-pin
connector for a headset mic.  However, there are now tons of 3rd party
headset mics using the Apple pinout and they're actually easier to find
than the "standard" pinout used by Nokia etc.

On 8/9/2014 8:26 AM, pozz wrote:
> I'm designing an embedded system based on a Cortex-M0+ MCU. I have to
> choose a way to make a connection between this system and a generic
> Android smartphone. The requirements are low-cost, simplicity and
> availability with the most of smartphones on the market. I don't need
> long range: it's sufficient to exchange data when the smartphone is near
> the system.

You haven't explained the extent of the comms involved -- both in terms
of instantaneous bandwidth and total traffic.  E.g., a short message 
communicated over a brief interval can be handled differently than a
streaming connection that must persist "indefinitely".  Nor whether
the comms are bidirectional (and, if so, whether full or half-duplex).
E.g., is data passed on the back channel?  Or, just acknowledgements?

Consider, for example, a traditional Ir remote control for a TV:
short messages, modest distances, brief intervals (during which the
connection must be "maintained")

Along these lines, you could design a visual or aural interface
to couple the phone to the "device" -- every phone can "send and
receive" audio; most can "send" video (receiving is more problematic
as cameras are often "event interfaces").

But, this would be impractical if the user had to interact with
the phone *while* it was "communicating" -- especially if the
user wanted to place a call, etc.

> The embedded system has an integrated GSM module (used for other things)
> that can be used for this purpose.
>
> I was thinking about the following alternatives, but all of them have
> pros and cons. Any suggestions?
>
> SMS/voice
> The app running module in the embedded system.on the smartphone can
> sends/receives SMSs or make voice calls. In this scenario I can use the GSM
> Main cons are the cost of the connection and the old technology.
>
> IP connection
> The communication can be made on top of an IP connection, but I need to
> use a GPRS/UMTS modem (for my application, I need just a GSM modem).
> Even this type of connection could be expensive for the user.
> Moreover, the point-to-point connection could be troublesome depending
> on the mobile service providers: firewall, private NAT-ed IP addresses
> and so on. I know I can provide a central server on the Internet, but I
> dont' want to offer this service (that should work everyday).

Are you (speaking on behalf of all users) comfortable requiring an
accessible and functional "third party service" to implement this
feature?  Or, would users complain if that service was "down",
"sluggish" or simply "inaccessible" at the present time?

> Bluetooth
> Bluetooth connection has many advantages: wireless, point-to-point,
> short range. The main problem I see is the complexity (cost) of the
> embedded system that must be keeped be very simple (low cost). I could
> integrate a serial-Bluetooth module, but I think it is expensive (do you
> know how much could it cost for 1000 pieces?).
> I could provide a RS232-Bluetooth dongle separated from the emebedd
> system, so the user can re-use it for many systems. What is the cost of
> this type of product?
> How complex would be developing and Android app that sends/receives
> asyncronous packets on a Bluetooth link, like on a RS232 link? The app
> should open the connection, sends some bytes and waits for some other
> bytes from the embedded system.

Why not use the BT as an audio conduit?  (or, is the audio channel
inaccessible in these phones?)

> USB
> Every smartphone has at least one USB port that is used for battery
> recharging and communication with the PC. The problem is it is usually a
> device port and I can't add the complexity of a host USB port on my system.
> I know newer Android versions have a native USB host support, but the
> smartphone should have at least an OTG USB port. How many smartphones
> provide this type of port?
> If I have a smartphone with a OTG USB port and a decent Android version,
> could I connect a simple RS232-USB adapter and hope it will be detected
> without problems? How simple is to write an app that open the virtual
> RS232 port and sends/reiceves data on that link?
> Another possibility could be to directly integrate a USB slave port in
> my system. This port should provide CDC interface and the Android
> smartphone should detect it as a virtual serial port (to open/close,
> write/read).
> Actually integrating a host USB port in the system shouldn't be
> difficult and expensive, but how the smartphone will be detected by my
> system? As a mass storage device? And how could I exchange data between
> them as on a serial link?
>

Paul Rubin <no.email@nospam.invalid> writes:

> Randy Yates <yates@digitalsignallabs.com> writes:
>> The OP did say right off the target is an Android phone, but beware that
>> you can't use these standard modules to connect to iPhone's etc. Apple
>> requires some magic hardware in the middle.
>
> What?  Do you mean you can't use standard bluetooth headsets and other
> such accessories with an iphone?  

Paul,

It depends on if those manufacturers have put in the necessary stuff. I
was working on a product awhile back that was eventually going to be
dual-use, apple and non-apple, and we were looking in to what was
necessary but never got to that state. Here are some (skimpy) notes from
my files on the subject:

  General Lingo protocol (added to SPP)
  IAP chip required (apple authentication process)
  MFI Library Required
  $6K for extra stack software from Stonestreet One to ease the transition from SPP to Lingo

--Randy


> I'm glad I don't have an iphone in that case. Wow. I do know they work
> ok with standard 3-pin stereo headphones, but they switched two of the
> pins around in the 4-pin connector for a headset mic. However, there
> are now tons of 3rd party headset mics using the Apple pinout and
> they're actually easier to find than the "standard" pinout used by
> Nokia etc.

Don't know about that. Actually I've been avoiding cellphones,
especially smartphones, for as long as I can. I currently have an
el-cheapo NET10 dumb phone that works perfectly well for me. If I want a
computer I go home and sit in front of my 64G desktop with 24-in
display.

We did break down and buy a GPS a few months back, though...
-- 
Randy Yates
Digital Signal Labs
http://www.digitalsignallabs.com

> 
> > I'm glad I don't have an iphone in that case. Wow. I do know they work
> > ok with standard 3-pin stereo headphones, but they switched two of the
> > pins around in the 4-pin connector for a headset mic. However, there
> > are now tons of 3rd party headset mics using the Apple pinout and
> > they're actually easier to find than the "standard" pinout used by
> > Nokia etc.
> 
> Don't know about that. Actually I've been avoiding cellphones,
> especially smartphones, for as long as I can. I currently have an
> el-cheapo NET10 dumb phone that works perfectly well for me. If I want a
> computer I go home and sit in front of my 64G desktop with 24-in
> display.

Did not know they did that with audio jack also.  Never had an iPhone, iPad or Mac.  Was with someone with a Mac Book, he forgot the charger and of course couldn't use my "standard" usb micro charger.  Had to go to the Apple store to get one.  "Did you say $80 for the charger?"

China tried to outlaw non standard usb chargers at one point, but probably made an exception for Apple, which would make the whole exercise pointless.  Don't know if they are still pushing it.

Il 09/08/2014 18:19, edward.ming.lee@gmail.com ha scritto:
>
>> Another possibility could be to directly integrate a USB slave port in
>> my system.
>
> Or a USB host slave controller.

OTG?


>> This port should provide CDC interface and the Android
>> smartphone should detect it as a virtual serial port (to open/close,
>> write/read).
>> Actually integrating a host USB port in the system shouldn't be
>> difficult and expensive, but how the smartphone will be detected by my
>> system? As a mass storage device? And how could I exchange data between
>> them as on a serial link?
>
> As an IP connection over ADB (Android Debug Bridge).

It seems ADB is a debug function of Android OS that is disabled by 
default.  I'd like to use a user-ready function of Android.

And a TCP/IP stack is too complex for my system.