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

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

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

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

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.

Perhaps filtering adapters using MAC or serial number.

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 ?

Check is IR is available on the phones.

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.

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.

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

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: > [...]

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

Yes, it seems a good solution.

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

It seems it is possible:

I hope it isn't so difficult.

No problem.

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.

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.

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.

Reliably detecting 10ms DTMF tones should be pretty much impossible. Practical minimums under ideal conditions are more likely closer to

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.

You can do it via USB without writing any USB code at all on your M0. FTDI have a range of solutions:

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

Michael Kellett

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:

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?

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:

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.

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,

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

/Nils