0

I'm studying Bluetooth protocol and implementing a position system reading RSSI in dBm from some devices. System will be implemented with 3 fix stations with an known latitude and longitude and a mobile station. Positioning will be done on mobile station with the power received in dBm from each fix station and the typically position algorithm.

In order to increase the efficiency of the system, some parameters from Bluetooth devices needs to be changed. This parameters could be:

  • Scan time on fix stations to decrease time on response to Inquires.

  • Inquires access codes to get answered to inquires just from selected devices(our 3 fix stations)

  • Some others.

There are some scenarios that can be used to do that depending on used tecnologies(some of them are limited):

  • Fix stations with Linux OS(no problem to modify parameters), mobile station with Android (seems to have just typically functions on its Bluetooth library but bluetooth setting are difficult or impossible to be modified). See: http://developer.android.com/reference/android/bluetooth/BluetoothAdapter.html

  • All stations running Linux OS, and C++ on mobile station(seems to be easy to run from shell scripts hcitool for fix stations modifying our settings, but it seems difficult to implement source code on C++ to get RSSI with our need values on dBm of links to fix stations on mobile station).

  • The nasty way. All stations running Linux OS and shell scripts, on mobile station running under shell scripts parsing values from RSSI from output redirection of hcidump after lunching inquires.

It seems to be very difficult to find useful info related to this scenario. Maybe some one of you can help to choose best scenario and to describe how should be implemented.

(Sorry if something it's not explained in a better way.. my English is terrible..)

Thanks.

amartinezi
  • 3
  • 2

1 Answers1

0

I'm sorry, I didn't follow everything you wrote, but I think the first step is to get down to the HCI layer on the fixed stations. That is fairly straight-forward to accomplish and gives you a fair bit of control.

As you mentioned, hcitool is very useful, but it doesn't matter what tool or language you use. You can access HCI commands from any language.

For example, I did something like this with Voyage Linux on an ALIX box. Voyage is debian based so now problem to load BlueZ, PyBluez, and Python. Python made it easy to quickly prototype a solution which you can convert to C++ later if need be. (More here.)

But that's just an example - use whatever stack you are comfortable with as long as you can get at the HCI layer. (Getting past the HCI layer requires you to work with a specific chipset and load code directly into the Bluetooth chipset.)

On the mobile device you might be severely limited: if you are trying for potential real world implementation. If this is just for the lab, you should get rooted Android devices that use the standard Bluez stack and then, like on the fixed devices, you can get at the HCI interface. Android is, after all, just Linux so you can do what you want if you have root.

Community
  • 1
  • 1
Tom
  • 17,103
  • 8
  • 67
  • 75