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?

Reply to
pozz
Loading thread data ...

Or a USB host slave controller.

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

Reply to
edward.ming.lee

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

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

Reply to
Paul Rubin

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 
 Click to see the full signature
Reply to
Randy Yates

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.

Reply to
edward.ming.lee

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.

Reply to
Paul Rubin

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.

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?

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

Reply to
Don Y

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

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 
 Click to see the full signature
Reply to
Randy Yates

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

Reply to
edward.ming.lee

Il 09/08/2014 18:19, snipped-for-privacy@gmail.com ha scritto:

OTG?

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.

Reply to
pozz

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

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

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

Reply to
edward.ming.lee

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.

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

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

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?

Reply to
pozz

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.

Reply to
edward.ming.lee

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.

Reply to
Paul Rubin

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?

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.

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

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

Reply to
Don Y

But most PC/laptop has Wifi.

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.

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

Reply to
edward.ming.lee

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.
Reply to
Paul Rubin

WiFi dongles are cheap, complete WiFi solutions are not.

Please share a link to this $2.28 WiFi adapter.

thanks

Reply to
hamilton

formatting link

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.

Reply to
edward.ming.lee

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

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

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

Reply to
Don Y

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.