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 of 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 programatically, 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.
This is basically 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.
This is Ad Hoc TCP/IP over Bluetooth. Works well with both Windows Mobile 6 and Windows 7. Some manual configuration might be needed. It also works with Mac OSX.
PAN is not supported by stock Android (no root access).
On iOS, PAN is used as an underlying protocol for tethering, or for the Bluetooth GameKit framework. The latter allows two iOS apps to discover each other via an Apple proprietary protocol / Bonjour / TCP / PAN / Bluetooth stack. However, you cannot implement that on the WinMobile 6 end of the connection.
Keep in mind the limitations of Bluetooth range (30-100 m) and data rate (2 mbps)
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), 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, 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, no global standard.
Some WinMobile 6 devices support BT 4 LE, but it’s not something widespread at the moment.
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.