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

Or a USB host slave controller.

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

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

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.

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

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.

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.

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

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 
http://www.digitalsignallabs.com

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.

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.

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.

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?

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

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

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

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.

WiFi dongles are cheap, complete WiFi solutions are not.

Please share a link to this $2.28 WiFi adapter.

thanks

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.

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