At this point, the RSSI Trace application (v0.1 found in the results section) is practically complete and about ready to be cleaned up, formalized, and converted into an API.

Accordingly, I am working on a proposal and won't be working on the coding for a while.

A draft is available in the results section.

I added a new feature to RSSI Trace, namely kicking a device out of the output after n missed iterations. I will explain.

When an inquiry_with_rssi event runs, it returns a packet which can contain the device information for up to 255 detected devices. However, it does not always find all of them. In this case, a previously detected device should remain in the active output stream (represented as a Python dict). However, after a certain number of undetected iterations, the device should be removed from the output. In rssi_trace.py, this is set to a variable kick_iter which can be easily adjusted by the user.

RSSI Trace version 0.1 is now up. Differences include:

• Results matrix has more information (including time)
• New set of outputs (in directory timetrace) which contains Octave-compatible time-rssi matrices.

It can be found in the results section.

I just got back from a mini-vacation (within India) where I had no chance to work. Anyway, once I got back, I wrote an Octave-based graphing extension to the application. It outputs a file (timetrace/'datetimestamp'/bdaddr) which contains a loadable matrix and tracks RSSI (EMA stabilized) vs. time (sec). This can then be graphed to study a curve fit and correlate RSSI to distance. The file can be loaded very simply from within Octave with the command:

	      load 'file'
	    

The loaded matrix is the device's user-friendly name (with " " replaced by "_").

This information is the bulk of release v0.1, which will be up within the next couple days.

I also conducted my first experiment for the project- test00.

After flying to India (delaying my progress), I sorted through and produced v0.0 of RSSI Trace, the application described in the previous entry. I also wrote a README to explain how to use the app.

I also found the technical term for the algorithm I was using to balance the new and old values. It is called an Exponential Moving Average (EMA) algorithm. In version 0.0, I use a smoothing factor of 1-1/e. This implies that an individual RSSI value's weight depreciates as e-k where k is one data acquisition iteration.

RSSI Trace v0.0 can be found in the Results section.

Over the weekend I cracked down on some PyBluez code, and figured out the RSSI stuff. I think the best/fastest way to obtain RSSI values for multiple devices simultaneously is to do an inquiry_with_rssi. I also constructed a basic, pickle-based database system for storing addresses and corresponding names, instead of querying them each time.

The other big milestone was developing an algorithm to balance new and old RSSI values. Signal strength readings are not very accurate, so it makes sense to keep some sort of stable average of them. However, averaging values together produces lag if the signal strength were to actually change, because new values would merely be outliers in a growing average. My algorithm seeks to balance both quantitatively by an arbitrary, defined constant. I will outline the algorithm in an entry later.

The software so far can be accessed Results section.

After a long break, I finally began to retackle the problem, and I discovered that the long-lost _bluetooth model for PyBluez actually exists. The issue was, though, that it must be accessed as

	      import bluetooth._bluetooth
	    

not just

	      import _bluetooth
	    

as the PyBluez documentation suggests. I think now I can finally use the lower-level module to find the hci_read_rssi value, instead of resorting to C.

I'm still working on establishing a command-line-level, HCI connection. I've figured out what a connection handle is, and I've found a function, hci_create_connection() that takes a few parameters and sets a handle. The problem is that I haven't gotten it to work, so far. I've been reading through the source code a lot, and am just tracing functions and their arguments to figure things out. I also still haven't quite figured out what int to is. Just for reference, here is a prototype for hci_create_connection():

	      int hci_create_connection(int dd, const bdaddr_t *bdaddr, 
	      uint16_t ptype, uint16_t clkoffset, uint8_t rswitch, 
	      uint16_t *handle, int to) { /*definition*/ }
	    

The function can be found on line 01115 of <bluetooth/hci.h> here

After spending more than a week learning C from K&R, I wrote the prototype code for the scanner. It is available in the results section.

Since there is no official API or documentation for the Bluez code, I still have to figure out how to establish connection handles. The code (refer to lines 02342-02365) contains the following function definition:

	      int hci_read_rssi(int dd, uint16_t handle, int8_t *rssi, int to) { /*definition*/ }
	    

I have yet to figure out what ''int to'' is. Also, I have yet to establish a connection handle, although the Bluetooth book that I found discusses them (briefly).

For the next few weeks I'm going to work on the server-side of the application. This will involve a lot of Bluetooth programming in BlueZ, and I will also have to learn Python and C in the process.

I've written a 'final', developer-level GUI for the Android- Bluetooth Mapping App (BlueMap) v1. It now has buttons to 'reconnect', and trilaterate. The code can be found in the results section. This app still uses the random connections, because Google has not yet released Bluetooth support for the Android emulator. Another difference in this code is that a three-part connection is now treated as an object instead of a set of static methods. This makes it easier to save information and reconnect.

I've implemented the first version of a simple, developer-level GUI for the Android phone- Bluetooth Mapping App v0-a. The package runs on the Android emulator. I also updated the core math+bluetooth code. If you want to run this, you will either have to use Eclipse (with the Android SDK plugin) or use the SDK's activityCreator.py tool to generate a build.xml file custom to your system. Instructions can be found here.

This version of the app...

• has a method introduceError() that introduces a variable (current 10% maximum) error into the distance readings.
• has no interactive components. It produces three points random points and the trilaterated point, and then displays them.
• utilizes Android's XML features- the layout is controlled in <project>/res/layout/main.xml.

This code can be found in the results section.

I've coded the basic trilateration algorithm in Java (so that it works with Android). The algorithm consists of a three classes in two packages:

	      bluetooth: Connect.java

	      calc: Point.java, Connect.java
	    

Connect produces four random points {p, p1, p2, p3} and then computes the distance (using Point methods) between p and {p1, p2, p3}. It then returns an array:

	      [ x1  y1  r1 ]

	      [ x2  y2  r2 ]

	      [ x3  y3  r3 ]
	    

Notice that p is suppressed. The trilateration algorithm uses this array to recompute p. Of course, in a real setting, p is unknown and the points are not randomly generated, so this is appropriate for testing the algorithm. Also, later when I introduce small, random errors into rn this will also be useful in observing how effective the algorithm is in a real setting.

I have not included this code because it is (right now) somewhat difficult to run. I had to create a very messy test.java class (with a main) routine to test that everything works.

I've written a relatively simple, brute force algorithm for trilaterating an object's position given three scanners which supply position and distance data. In other words, given

	      {(x1, y1), r1} 

	      {(x2, y2), r2} 

	      {(x3, y3), r3}
	    

We can now compute (x,y). Furthermore, the algorithm accounts for inaccuracy in {r1, r2, r3} by averaging the results of three linear equations (there is redundant data). Refer to the results section for a quick write-up of the algorithm (assumptions and the algorithm itself).

This is to observe whether the stability of signal-strength readings varies (proportionally) with distance. It is a rough study, without any real distance data: instead it assumes that different distances have different RSSI values, and compares readings at further and further RSSIs graphically.

Here is the graph of results:

Distance 1 is the closest and Distance 3 is the farthest. Distance 2 is in between (closer to distance 1, however).

The red set of lines represents the closest distance, the blue lines represent the medium distance, and the green lines represent the farthest distance. The graph seems to demonstrate that the RSSI readings are actually more stable with increased distance (greater |RSSI|, lesser RSSI), but without a quantitative stability vs. distance analysis, it is impossible to make any definitive conclusions in that respect. However, the most important result of the experiment is how widely the RSSI values vary regardless of distance. I don't think a quantitative comparison is a necessary future test, because any correlation seems weak and the results would be somewhat irrelevant.

This experiment is to compare the Bluetooth dongle with the built-in Bluetooth chip (included with my laptop). I placed one phone (htc) at a constant, arbitrary distance and took 5 readings with each chip (build-in, dongle).

Here is the graph of results:

The '+' points represent the in-built chip and the '*' points represent the dongle. The results clearly show that the dongle maintained a higher signal strength with the device (A negative RSSI is the level of signal less than some predefined golden range). Another interesting point is that the dongle seemed to demonstrate much more variation than the in-built chip. However, that is a very surprising result, and it may have just been due to the circumstances- so I will evaluate this phenomenon in further tests.

This experiment was to test the stability of RSSI readings. I set up two Bluetooth-enabled phones (both Nokia) at different, arbitrary distances from the computer (one close, one far). I also used the Bluetooth dongle (MSI Star Key 2.0) instead of the chip built into my laptop. I took about 9 readings (each ~ 74 seconds long).

Here is the graph of my results:

Theoretically, both sets of lines (one for each device) should be horizontal and completely overlapping, because the system was completely still. However, RSSI readings are somewhat inaccurate, so that is not the case with the graphs.

It is also relevant to note that the farther away device (lower on the graph, greater |RSSI|) shows considerably more variation per cycle than the closer one, implying that readings get less accurate with distance. Also, neither of these phones was very far away. Both were easily within 5 meters, which is only 5% of the advertised range of the dongle. Further tests will test devices at consecutively larger ranges. This test was admittedly also a simple way to go through the process of using Octave, producing graphs, etc.