A session talking about what people can/are doing with proximity sensing (and how/why in many cases, locative services aren't about absolute (geo) location, but relative location. Covering implementation and code of Bluetooth in particular, including information on the setup I used at Where 2.0 and WhereCamp 2008. (The morning session already covered lots of concerns about privacy that are applicable here, so this session will focus on cool stuff you can do and how to get out there and do it)
Many of the applications that fall under the LBS (Location Based Services) umbrella are actually proximity apps, but using absolute positioning - i.e. many types of friend, crowd-finding. These could conceivably be done cheaper, better, and less invasively w/o proximity sensing. Also, using proximity in combination w/ other methods can serve to greatly increase effectiveness of other methods.
Probably the most interesting bits of research or when meshes (active + passive) are combined, and when relative positions are combined with absolute positions to build out larger inference meshes (ie, when you have a scan from a beacon w/ a known location, you now know the location (within 10m) of the detected cohorts)
There's been a lot of Academic and Research work in the space. A search for "wireless sensor networks" is a good start. For more specific results, bluetooth sensor networks is also a good search.
Some particularly good places to start:
In terms of friendfinding, I led a team designing friendfinding use cases a few years ago. Nokia's Sensor was a similar project that was released in the wild but didn't gain much traction.
OK, into details for Location via BT.
The big picture, when you do a scan, you get the discoverable devices near you (Class 2 = 10m).
Now, lets think this through:
always: cloud of devices in temporal-spatial vicinity
maybe: single point w/ geolocation
maybe: user-to-device (mac address) mapping
Algebra problem! Plug X and Get Y
Inferred data: when you start layering these pings, you start generating a larger-scale mesh, all with a rough location. This is good enough to provide LBS for people/devices that otherwise have no accessible location data.
You could also attach this information say to your addressbook.
One of the things you can build from fixed location beacons, especially if they're time offset is that you can figure out whether someone is coming or going.
So, for example, if you have three beacons, with b firing first, and then a and c firing subsequently, you'll be able to tell which way someone is going based on the subsequent results.
a - b - c
With Bluetooth, the limitations are that you may not have the RSSI (and it's not necessarily dependable) and BT via the standard SDP (Service Discovery Protocol) is based on discrete queries. Unless you want to kill the batteries of devices you're sampling, you won't be doing this continuously (for my sensors I do a scan every 2 minutes)
Even with these limitations, there's a lot that can be pulled from this sort of sampling, especially in aggregate and if you have multiple location-aware beacons that are time offset. If anyone has the references for the math/algorithms that people are using, I'm still researching that (i.e. the math and research for network routing of scatternets would probably also apply to extracting physical proximity).
There's a heckuva lot of Bluetooth projects out there, please add interesting ones. To start off:
Bluetooth Proximity Detection on OS X - using Blutooth to activate/deactivate your screensaver (Linux, Windows?)
Consola - Open Source Blueeoth Proximity Media Server - for kiosks for placecasting
DZone Snippets - lots of code snippets for all kinds of BT functionality
Backtracking a little bit...
Source: http://en.wikipedia.org/wiki/Bluetooth
Bluetooth is a standard and communications protocol primarily designed for low power consumption, with a short range (power-class-dependent: 1 meter, 10 meters, 100 meters) based on low-cost transceiver microchips in each device.[2] Bluetooth enables these devices to communicate with each other when they are in range. The devices use a radio communications system, so they do not have to be in line of sight of each other, and can even be in other rooms, as long as the received transmission is powerful enough. Bluetooth device class indicates the type of device and the supported services of which the information is transmitted during the discovery process.[3]
| Class | Maximum Permitted Power | Range (approximate) |
|---|---|---|
| Class 1 | 100 mW (20 dBm) | ~100 meters |
| Class 2 | 2.5 mW (4 dBm) | ~10 meters |
| Class 3 | 1 mW (0 dBm) | ~1 meter |
Bluetooth SIG Press Release, 18-Sep-2007, BLUETOOTH SIG TESTING TOOL SETS INDUSTRY EXAMPLE:
Bluetooth is the most common Personal Area Network technology in use. If you have a cell phone, chances are good you have Bluetooth, although it's not necessarily discoverable.
Enough theory, lets start building stuff:
BlueZ - Linux
BluetoothIO - OS X
JSR-82 - J2ME
Python Libraries
The code:
# LightBlue
import lightblue
nearby_devices = lightblue.finddevices()
# PyBlueZ
import bluetooth
nearby_devices = bluetooth.discover_devices(lookup_names = True)
That was easy.
BlueZ returns signal strength, but BluetoothIO does not. YMMV.
Here's a link to all my BT code.
Data dump not published (potential bluesnarfing, etc.)
Discussion bits on what people were doing in the area, wanted to do...
Other types of sensors (digital compasses are cool), AR: