We have recently explored how to connect – wireless – to embedded devices scattered across factories and warehouses. Windows Embedded Handheld (the successor of Mobile 6.5) is a typical choice of OS for such devices, and most of them can have Bluetooth and WiFi on board – so these technologies are obvious choices. What they don’t have is a SIM chip in every device and a data plan. Their users have laptops (PCs and Macs), iPads, iPhones, Android phones, and tablets, and can physically walk in the same room where devices are located.

Here’s what we found.

WiFi Infrastructure mode + DHCP

This is the obvious choice working with all platforms (Windows 7 PC, Mac OSX, iOS, Android). You need to have a wireless router in infrastructure mode, and assign addresses via DHCP. The wireless router must be in range both of the device and the PC (one obvious place is to plug it near the device itself)

Once both the device and the PC are in the same LAN, the device can broadcast information about itself via some discovery protocol: UPnP, Bonjour, or you can write a simple custom UDP-based discovery mechanism. It is easy to write a client that uses this information, on all platforms.

Mobile Data service

Same as above, but use a MiFi – like gadget to connect the device to a 3G network. Tape it to the device. Write software on the device to connect to a server – and use it to authenticate and do NAT traversal that way.

Bluetooth DUN might work as well instead of WiFi to connect the device with a 3G modem.

WiFi Ad-Hoc mode

Windows Mobile 6 devices can set up WiFi networks in Ad-Hoc mode. Clients on Windows 7, OSX, and iOS can then connect to this ad-hoc network.

On iOS, it’s not possible to do it programmatically, and there is some user interaction needed in the iOS Settings – the user should manually choose the network to connect to.

As far as I know, Android devices cannot connect to WiFi Ad-Hoc networks.

WiFi Direct

This is basically a Bluetooth-style discovery and service presentation added on top of WiFi. It’s only supported by Android 4+ and Windows Phone 8. It’s rumored to be introduced by Apple in their next products.

The Win Mobile 6 devices do not support WiFi direct – but perhaps this could be a choice for the future.

Bluetooth 2

You can write your own custom protocol on top of RFCOMM on Bluetooth. The simplest would be directly HTTP / RFCOMM / Bluetooth instead of TCP.

However, you need to write custom software for the PC, Mac, and Android in order to proxy the HTTP requests over this protocol – so a simple web browser won’t work anymore.
It does not work with iOS.

Bluetooth 4 Low Energy

This is low power, low range (<50 m), and low data rate (200 kbps). You can try to create a service that proxies HTTP, as above.

It is supported by iPhone 5. It is also supported by a few Android devices (like Samsung Galaxy S3, and S4), but with proprietary SDKs – the mainstream support is still being added currently.

It is also supported by a few, newer PCs and Macs. SDKs are also proprietary, with no global standard.

Some WinMobile 6 devices support BT 4 LE, but it’s not something widespread at the moment.

Other approaches

A framework pioneered by Qualcomm, https://www.alljoyn.org/, tries to abstract out the underlying mechanism for peer-to-peer communication between devices. Programmers can use it to ignore the low-level details of connectivity; the framework will use all the technologies known and available on a given platform ( WiFi and Bluetooth on Android, WiFi on iOS). It’s not as mature yet, however.