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

On Saturday, August 9, 2014 6:15:26 PM UTC-7, edward....@gmail.com wrote:
> > > 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.

BTW, here is the Realtek 8188 that does not work with Linux 3.15:

http://www.ebay.com/itm/USB-Wifi-Micro-Adapter-Dongle-802-11n-Plug-and-Play-/400753751090?pt=US_USB_Wi_Fi_Adapters_Dongles&hash=item5d4ec8f432

> 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 Saturday, August 9, 2014 6:32:56 PM UTC-7, Don Y wrote:
> 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!

I think he is using ARM.  I am sure he can get one with USB host.

> 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*!

They are just as easy.  It's a matter of the base station (OP's board) design.

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

Yes, there should be one.  OK, i'll make one eventually.

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

But Wifi hostAP would be much more flexible, since he (OP) already have GSM access to the internet.  Basically, i already have what he need and want: a laptop with GSM uplink and Wifi hostAP.  We just need to make it small enough to fit in the ear.

My Athereo Wifi hostAP driver was around 1.5MB, but it includes almost everything Athereo made.  After striping most other chips, i have around 500KB.  So, it should fit in a micro with 1MB flash.

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

Perhaps filtering adapters using MAC or serial number.

On Sat, 09 Aug 2014 23:55:41 +0200, pozz <pozzugno@gmail.com> wrote:

>Il 09/08/2014 18:19, edward.ming.lee@gmail.com ha scritto:

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

Does Android support UDP/IP ? This would be easier to implement on the
embedded side.

Is there by chance any IR connections on Android as in old cellular
phones ?

On Sun, 10 Aug 2014 00:09:11 +0200, pozz <pozzugno@gmail.com> wrote:

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

Check is IR is available on the phones.

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

Have you looked at the Kansas City standard from mid 1970's for
storing microcomputer programs on standard audio cassette. It uses
simple f/2f modulation, which is simple to generate and decode. The
original version was for 300 bit/s, but variants existed also for 1200
bit/s. 

Since the standard was designed to be compatible with telephone
frequency band, the high tone was 2400 Hz, but the smart phone audio
interface must have much larger bandwidth, so 2-4 higher throughput
would be expected.

> >And a TCP/IP stack is too complex for my system.
> 
> Does Android support UDP/IP ? This would be easier to implement on the
> embedded side.

Yes, UDP is part of TCP.  Android is just using a customized Linux kernel.  It supports most Linux features.  But unlike Gnu/Linux system, user accesses are more restricted.

Gnu/Linux is like a gold mine.  You can dig anywhere to get stuff.

Android/Linux is like a sandbox.  If you dig outside the box, you don't get anything.

However, sandbox is easier to play with than gold mine.

On Sat, 9 Aug 2014 21:35:41 -0700 (PDT), edward.ming.lee@gmail.com
wrote:

>
>> >And a TCP/IP stack is too complex for my system.
>> 
>> Does Android support UDP/IP ? This would be easier to implement on the
>> embedded side.
>
>Yes, UDP is part of TCP.  Android is just using a customized Linux kernel.  It supports most Linux features.  But unlike Gnu/Linux system, user accesses are more restricted.


Just to be pedantic, UDP *is* part of TCP/IP, but is most certainly
not part of TCP.

To the OP: there are Bluetooth-to-serial port converters out there
(HC-05, for example), you could add one to your device for about $15.
That should be supported by most Android devices (subject to enabling
Bluetooth and pairing the devices as usual).  To your device it's just
a serial port/modem looking thing (even has "AT" commands).

On Sat, 9 Aug 2014 21:35:41 -0700 (PDT), edward.ming.lee@gmail.com
wrote:

>
>> >And a TCP/IP stack is too complex for my system.
>> 
>> Does Android support UDP/IP ? This would be easier to implement on the
>> embedded side.
>
>Yes, UDP is part of TCP.  Android is just using a customized Linux kernel.  It supports most Linux features.  But unlike Gnu/Linux system, user accesses are more restricted.
>
>Gnu/Linux is like a gold mine.  You can dig anywhere to get stuff.
>
>Android/Linux is like a sandbox.  If you dig outside the box, you don't get anything.
>
>However, sandbox is easier to play with than gold mine.

So the situation seems to be similar than on the desktop environment,
in which it becomes increasingly hard to use UDP (or horror, even raw
Ethernet frames with MAC addressing), without Administrator/root
privileges and punching a lot of holes into various firewalls.

Il 10/08/2014 07:05, Robert Wessel ha scritto:
 > [...]
> To the OP: there are Bluetooth-to-serial port converters out there
> (HC-05, for example), you could add one to your device for about $15.

It's too much, anyway I see a single piece of HC-05 can be bought for 
about $3.

> That should be supported by most Android devices (subject to enabling
> Bluetooth and pairing the devices as usual).  To your device it's just
> a serial port/modem looking thing (even has "AT" commands).

Yes, it seems a good solution.

Il 10/08/2014 00:18, edward.ming.lee@gmail.com ha scritto:
>
>>> 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.
>

It seems it is possible:
https://www.youtube.com/watch?v=XqxV9QOqkiI

I hope it isn't so difficult.

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.