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

Il 10/08/2014 02:02, Paul Rubin ha scritto:
> 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.

SMS was my first solution, but it could be expensive for the user.

The app could send 10 SMSes (about 1000 bytes) and, if something is 
wrong, the process must be repeated.

And if I need a feedback from the field device, I have to send other 
SMSes from that side.

On Sun, 10 Aug 2014 08:36:46 +0200, pozz <pozzugno@gmail.com> wrote:

>Il 10/08/2014 01:30, Don Y ha scritto:
>> 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?
>
>No problem.
>
>
>>>> 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.
>
>Yes, audio output/input is available on every phone, but I need to use a 
>custom application on it, so I need to have a modern smartphone.  I know 
>I could install apps even for older phones using some sort of Java, but 
>it seems to work for the past and not for the future.
>
>I'm sure the user will have a decent new Android-based smartphone or at 
>least it will be very simple to find one for this purpose.
>
>So I don't need a full compatibility with the most cells, just 
>Android-based devices.
>
>I think BT, USB and WiFi are always available on those phones.
>
>
>>>> 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!  :> )
>
>Another possibility is to use DTMF, because I already have a GSM module 
>that provides a DTMF decoder and can generate DTMF frequencies.
>
>I can send 4 bits per tone (there are 16 tones).  If the DTMF decode 
>works well with a tone duration of 10ms (I have to test it), I could 
>reach a baudrate of 400bps that sounds good.
>
>I hope it'll be simple to develop an Android app that decode and 
>generate DTMF tones.


Reliably detecting 10ms DTMF tones should be pretty much impossible.
Practical minimums under ideal conditions are more likely closer to
50ms, with ~20ms pauses between tones.

pozz <pozzugno@gmail.com> writes:
> The app could send 10 SMSes (about 1000 bytes) and, if something is
> wrong, the process must be repeated.  And if I need a feedback from
> the field device, I have to send other SMSes from that side.

Ok, if you need that much data and it has to be bidirectional, you want
either a cable connection or wifi/BT.  Have you picked out your Cortex
M0+ chip?  There is a Nordic Semi one with built-in BT.  Look at
rfduino.com and you should be able to find the data sheet from there.
There is also that $2-ish TI chip that I mentioned.

For using an audio cable (very cheap) I don't think you need anything
fancy like DTMF.  Some simple encoding on the wire, plus a checksum, is
probably enough.  Again it wouldn't surprise me if there's already code
for this around.

On 09/08/2014 16:26, 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.
> 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?
>
You can do it via USB without writing any USB code at all on your M0. 
FTDI have  a range of solutions:
http://www.ftdichip.com/Android.htm

I have used their UART terminal which will talk to one of the cheap USB 
to UART leads they sell. It seems to work OK and you need only pennies 
worth of interface parts on the target (+ the smart lead of course but 
you may not need one on every target.).

https://play.google.com/store/apps/details?id=com.ftdi.j2xx.hyperterm&hl=en_GB


Michael Kellett

MK <mk@nospam.co.uk> writes:
> You can do it via USB without writing any USB code at all on your
> M0. FTDI have  a range of solutions:
> http://www.ftdichip.com/Android.htm

Interesting.  My first reaction was "won't you'd need a USB host port
and a monstrous amount of code to implement the USB stack?".  But it
looks like they put all that on a single chip, the FT312D.  At $4.08
(qty 250) from digikey, it's kind of expensive, though maybe not out of
reach.  It might be simpler to get working than a BT solution. 

Il 10/08/2014 14:27, MK ha scritto:
> You can do it via USB without writing any USB code at all on your M0.
> FTDI have  a range of solutions:
> http://www.ftdichip.com/Android.htm
>
> I have used their UART terminal which will talk to one of the cheap USB
> to UART leads they sell. It seems to work OK and you need only pennies
> worth of interface parts on the target (+ the smart lead of course but
> you may not need one on every target.).
>
> https://play.google.com/store/apps/details?id=com.ftdi.j2xx.hyperterm&hl=en_GB

Good suggestion.

If I understood well, I can integrate the "classical" FTDI UART-USB 
adapter FT232 on my system and make a USB connection between 
Android-based phone and the device.  FTDI provides source code for the 
UART Terminal app so it should be simple to customize it.

There's only an important requirement of the smartphone: it must provide 
a USB *host* port.  Is it correct?  How many smartphones have USB host port?

pozz <pozzugno@gmail.com> writes:
> If I understood well, I can integrate the "classical" FTDI UART-USB
> adapter FT232 ...
> There's only an important requirement of the smartphone: it must
> provide a USB *host* port.  Is it correct?  How many smartphones have
> USB host port?

Yes, some phones (not all) have USB OTG which is basically a host port
where you need a special connector adapter, there are constraints about
drawing power from the port, etc.  I think the point of MK's post is
that there's now another chip, FT312, that has UART on one side and USB
host on the other.  So you can connect the phone to it using the phone's
device port.  

Il 10/08/2014 17:08, Paul Rubin ha scritto:
> pozz <pozzugno@gmail.com> writes:
>> If I understood well, I can integrate the "classical" FTDI UART-USB
>> adapter FT232 ...
>> There's only an important requirement of the smartphone: it must
>> provide a USB *host* port.  Is it correct?  How many smartphones have
>> USB host port?
>
> Yes, some phones (not all) have USB OTG which is basically a host port
> where you need a special connector adapter, there are constraints about
> drawing power from the port, etc.  I think the point of MK's post is
> that there's now another chip, FT312, that has UART on one side and USB
> host on the other.  So you can connect the phone to it using the phone's
> device port.

Ok, thank you for your clarifications.

Il 09/08/2014 17:26, pozz ha scritto:
> I'm designing an embedded system based on a Cortex-M0+ MCU.
 > [...]
> I was thinking about the following alternatives
 > [...]

There's another and modern alternative: NFC.

It's a technology that isn't thought for data exchange, but can be used 
for that if the amount of data and speed isn't too high.

The only problem I see it's a very new technology and only a few phones 
integrate it.

On 11.08.2014 07:38, pozz wrote:
> 
> There's another and modern alternative: NFC.
> 

Thanks for pointing this out.

I've done quite a bit of NFC in the past and there are some nice and
very cheap solutions to communicate with mobile phones available.

Most noticeable there is a good range of so called dual-interface
EEproms available now. These look from one side like an ordinary,
passive NFC tag and on the other hand have a simple I�C eeprom interface.

If you only transfer small amounts of memory and you can life with a
somewhat limited lifetime (EEPROM will wear out sooner or later) this
might be a good solution.

You can do all kinds of bidirectional data-transfer based on shared
memory with them. On the pro-side: It is very simple to get things
working because you don't need a full blown bluetooth or usb stack. The
chips are cheap as well because there isn't much in them.

You can expect NFC to do between 1 and 2 kilobytes/second data transfer
rate. Support for Android is pretty good. Regarding support for the
upcoming iPhone - we will see (rumors tell us NFC will be supported, but
you'll never know until it is confirmed).

http://www.st.com/web/catalog/mmc/FM76/CL1766/SC1412/SS1812/PF259140
(Link to example dynamic NFC tag from St-Micro)

/Nils