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

> > Or a USB host slave controller.
> 
> OTG?
>

Just USB Host.  Android phones might not do OTG anyway. 

> 
> >> 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.

You only need to enable it once.  As opposed to USB MSD, you need to enable it every time to reconnect.

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

The USB Host controller does TCP/IP, then you can talk to it with serial or SPI.

Il 09/08/2014 22:13, Don Y ha scritto:
> 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?

Oh yes, I haven't explained all the details about the communication I'd 
like to implement.
It is very simple and should be similar to a RS232 half-duplex link with 
a low baudrate (9600bps or similar).  The amount of data exchange is 
minimale: packets of 100 bytes is more than sufficient.
Moreover the communication doesn't need to stay active for a long time. 
  I expect the user make some changes in the app and sends the overall 
data to the embedded system with a button.  At this time, the 
communication channel is opened and data is exchanged. The communication 
than is closed and stop.


> 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.

No, it isn't a needed feature, but I think I didn't completely get your 
point.  Are you suggesting to send data through the mic of the phone, so 
using a modulation tecnique?  This is the same suggestion of Paul Rubin, 
but I need to implement a software modem in the app (I think some 
materials is already available) and in my system (and this task could be 
more difficult).


>> 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?

I don't want to use a "third party service" out of the user control.


>> 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?)

I have to exchange binary data and I think BT could do that.  Why to use 
audio and invent a "codec" on top of BT audio?


>> 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?

> > Why not use the BT as an audio conduit?  (or, is the audio channel
> > inaccessible in these phones?)
> 
> I have to exchange binary data and I think BT could do that.  Why to use 
> audio and invent a "codec" on top of BT audio?

Android is a well packaged sandbox.  It's easy to do audio or even video.  But to do raw data, you have to dig very deep in the library codes.

pozz <pozzugno@gmail.com> writes:
> I need to implement a software modem in the app (I think some
> materials is already available) and in my system (and this task could
> be more difficult).

It shouldn't be terribly difficult, especially at lower bit rates.  You
don't have to deal with anything like the obstacles that a phone modem
has.  I haven't gone looking but it wouldn't surprise me if there's
already code floating around that you can use or adapt.

On 8/9/2014 3:09 PM, pozz wrote:
> Il 09/08/2014 22:13, Don Y ha scritto:

>> 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?
>
> Oh yes, I haven't explained all the details about the communication I'd
> like to implement.
> It is very simple and should be similar to a RS232 half-duplex link with
> a low baudrate (9600bps or similar). The amount of data exchange is
> minimale: packets of 100 bytes is more than sufficient.

Is there a practical upper limit on how long a user would be comfortable
waiting for this exchange?  E.g., 100 bytes at 9600bps is about a tenth
of a second.  Would the user be annoyed if that was a *full* second?
Or three?

>> 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.
>
> No, it isn't a needed feature, but I think I didn't completely get your
> point. Are you suggesting to send data through the mic of the phone, so
> using a modulation tecnique? This is the same suggestion of Paul Rubin,
> but I need to implement a software modem in the app (I think some
> materials is already available) and in my system (and this task could be
> more difficult).

Note that you don't have to be a REAL "modem" -- just some sort of
MODulator-DEModulator.  The choice of modulation techniques is up
to you -- because *you* have defined both ends of the comm channel.

For example, instead of something as traditional as FSK, you could
use ASK -- especially if the exchange is short enough in duration
(i.e., so the amplitude of the signal wouldn't likely change because
of motion between the two parties)

My point was to look at what you KNOW *every* phone has available
by way of I/O's.  E.g., audio can be passed over a regular POTS
link... no "data plans" involved, etc.

>> 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?
>
> I don't want to use a "third party service" out of the user control.

Personally, I would agree thinking it unwise any time you add another
dependency to your design.

>>> 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?)
>
> I have to exchange binary data and I think BT could do that. Why to use
> audio and invent a "codec" on top of BT audio?

Again, your CODEC can employ any coding scheme that makes sense for
*you*.  It doesn't have to be compatible with anything else on the
planet!  (at least, your requirements haven't indicated any such need)

The appeal of BT is just that it avoids having to have a microphone and
earpiece AND the requirement for the user to hold the phone proximate
to your device during the exchange.  I *think* most phones have BT
capability -- and, BT earpieces are dirt cheap.  This suggests the BT
channel is the ubiquitous one (you don't see many WiFi earpieces!  :> )

>  I *think* most phones have BT capability --

But most PC/laptop has Wifi.

> and, BT earpieces are dirt cheap.

Wifi adapters are also dirt cheap.

I am waiting for one for $2.28.  Since i couldn't get the $3 one to work, it has a newer chip than what Linux support.

>  This suggests the BT channel is the ubiquitous one (you don't see many WiFi earpieces!  :> )

No reason why it cannot.  USB Wifi adapters are as small as BT.  Getting the drivers and setup to work is another story.

If we implement an Wifi port with default SSID and short enough range, we don't have to figure out how to enter the SSID in your earpieces (and perhaps a fake tooth microphone).

pozz <pozzugno@gmail.com> writes:
> should be similar to a RS232 half-duplex link...  The amount of data
> exchange is minimale: packets of 100 bytes is more than sufficient....
>  user make some changes in the app and sends the
> overall data to the embedded system with a button.

Is this basically 1-directional communication?  Is it just something
like configuration settings, rather than code updates, i.e. can you live
with perhaps a dozen bytes instead of 100 bytes?  Another cheesy
possibility is put a 10 cent photodetector on the embedded board, and
display something like a bar code on the phone screen.  Then wave the
phone over the photodetector to transfer data.  An LED on the embedded
board would signal the transfer's success or non-success.

I agree that it's bad to have to rely on the external mobile network,
but if you do want to use it, most GSM modules can receive SMS which is
140 text chars.  I'm not sure how many data bits you can encode in it.

On 8/9/2014 5:46 PM, edward.ming.lee@gmail.com wrote:

>
> Wifi adapters are also dirt cheap.
WiFi dongles are cheap, complete WiFi solutions are not.

>
> I am waiting for one for $2.28.  Since i couldn't get the $3 one to work, it has a newer chip than what Linux support.
Please share a link to this $2.28 WiFi adapter.

thanks

> > I am waiting for one for $2.28.  Since i couldn't get the $3 one to work, it has a newer chip than what Linux support.
> 
> Please share a link to this $2.28 WiFi adapter.
> 

http://www.ebay.com/itm/191260373943?_trksid=p2059210.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT

Not sure if this will work yet.  The Realtek didn't.

I have a HP mini with a poorly supported Broadcom PCIe.  I actually got it to work with an Athereo PCIe, but it burnt out after several months.  Unfortunately, HP is very picky about non-hp PCIe; so, i am trying USB.

On 8/9/2014 4:46 PM, edward.ming.lee@gmail.com wrote:
>> I *think* most phones have BT capability --
>
> But most PC/laptop has Wifi.

But the OP's customers are using smartPHONES... not smartPC's!
So, the issue is the prevalence of the interface on those phones!
I.e., getting a phone with WiFi and BT is easy.  Getting one with
JUST BT is probably *easier*!

>> and, BT earpieces are dirt cheap.
>
> Wifi adapters are also dirt cheap.
>
> I am waiting for one for $2.28.  Since i couldn't get the $3 one to
> work, it has a newer chip than what Linux support.
>
>> This suggests the BT channel is the ubiquitous one (you don't see
>> many WiFi earpieces!  :>  )
>
> No reason why it cannot.  USB Wifi adapters are as small as BT.
> Getting the drivers and setup to work is another story.

It's not a question of what COULD be used in phones but, rather,
what *is*!  You could get a phone with a ZigBee I/F.  But, you don't
*see* any of those!

When it comes to "the other end" of the "link" to a phone, the solution
seems to predominantly be BT (discounting the primary telecomm channel,
of course).

> If we implement an Wifi port with default SSID and short enough
> range, we don't have to figure out how to enter the SSID in your
> earpieces (and perhaps a fake tooth microphone).

And hope you are never standing next to someone (on a bus/train)
using a similar phone+I/F?  <frown>  Seems like impending FAIL...