Bluetooh OBEX file distribution

In the past month quite a number of people contacted me about bulk sending files using OBEX. Bluetooth spamming, bluntly put.

Common goals are mostly:

• small, cheap, low-power, wifi-enabled
• bulk sending, largely in parallel

Here are a few tips on that.

Hardware ————

The common request here is for small form factor, cheap of-the-shelf hardware, optionally battery powered and wifi controlled if possible.

OpenOBEX and ObexFTP support a wide range of platforms. There are prebuilt distributions for well-known open routers like Linksys WRT54G or newer AVM Fritz!Box models. You can as well go with something like a Soekris, NSLU, or alike (openbrick still around?).

• OpenWRT seems to have some support for ObexFTP
• Freetz has a module for ObexFTP

If you’ve got some project in that regard or even prebuilt binaries, let me know!

Software ————

The software requirements are specific to each project. Mostly there are basic requirements like automatic detection and bulk sending. And then, obviously, the capacity to process transfers in parallel.

These two requirements can not be intertwined easily. Automatic proximity detection requires a device inquiry loop which is a lengthy process and ties down bt resources. Upon detection you’ll then need to queue (more on this below) a SDP browse and eventually the file sending. Browsing the devices SDP records will tell you if the device accepts OBEX PUSH and on which service channel it’ll be. You can then decide to start pushing a file to the device.

Even if the software layer will support concurrency your bt hardware most likely will not. You’ll need to process packets in a round-robin fashion for all connections. And there a serious limitations on the number of connections per bt interface — 2-4 concurrent connections are common. A bunch of bt dongles (spaced with e.g. some usb cable!) will improve this. Be advised that threading won’t help you here. The hardware is restricted and threading will get you into lots of trouble like blocking the hardware. Please use an event loop, esp. on low-end hardware this yields consistent and fast processing.

You can roll your own event loop, use a higher language (like e.g. python) to run the event loop or try the GLIB extension and it’s event loop. Users reported success on all of them. I’ve got some work-in-progress patches and C examples for the GLIB event loop, let me know if you are interested in testing and improving those.