Lower Levels
There are two threads dedicated to processing the incoming packets from the SpotOn tags. These packets that the tag sends out over the serial port are merely echoes of the packets that the tag is receiving from the RF layer on the tag from other tags in the network.
The serial port thread runs in an infinite loop to grab an available byte off of the opened and initialized com port.
- If there is no byte available, the thread sleeps for a millisecond to allow other threads operating time.
- If a byte is available, it is read and used to update a state machine in the formation of a packet based on IrDA packet structure.
- When a packet is completely formed, a mutex for packet queue is obtained, the packet is placed on a queue, and the mutex is released. The loop immediately repeats and looks for another available byte on the com port.
The packet handling thread runs an infinite loop which grabs the same packet queue mutex.
- The head of the queue is checked for a packet.
- If there is no packet, the thread returns control to the operating system for at least a millisecond ( sleep(1) ) after releasing the mutex. If a packet is waiting, it is popped off and handled and the loop repeats.
There are many possible types of packets, but the only packets that are processed with any interesting effects are the RSSI (received signal strength information) op-code packets. Each of these packets result form the server's tag receiving a broadcast from a remote tag which also sends their measurements of all other known devices encoded into the message. The server reads the signal strength datum from the received broadcast between the two tags and all of the stored signal strength data that was sent on the ping from the transmitting tag. Each measurement from one tag to another (directed graph) is entered into a databank on the server with a timeout so that this information will be valid and available for a limited amount of time. The databank timeout is currently set for 6 seconds.
Sockets and Clients
Upon signal from the GUI, an asynchronous MFC CSocket is set up (on ip and port defined by the user) to listen for connection requests from scrap devices. Upon a received request for connection a callback function is executed to create a client structure for the connecting scrap device. Within this structure is a new asynchronous CSocket to accept and continue the communication with the device. The state of the scrap device includes an id from the SpotOn tag attached to the device, a user id, a bit to indicate whether a user is logged on, a bit to indicate that the socket has been closed and the device should be removed, a bit to indicate whether this device should be considered by the proximity algorithm and a counter to indicate progress through establishing a user within or outside of proximity. All of these states are initially set to indicate that there is no user and that this device should not be considered for proximity. This client structure is added to a global ATL vector of clients.
Once the device profile has been set up with its own asynchronous CSocket, it waits to receive an XML packet from the scrap device. The message should be of the form <register> <id>###</id> </register>. An asynchronous CSocket callback function parses the message for all of the tags and does not consider it valid without them. Once a valid message has been received, the socket iterates through the global ATL vector of clients, searching for a reference to itself within each of the instances. Once the corresponding client profile is found, the state is updated to reflect the id value sent as the SpotOn tag attached to the device and is then considered valid to be considered in the proximity algorithm. The asynchronous CSocket is left open for notifications to be sent to the device when the proximity algorithm determines or debug signals are triggered by the servers GUI. The socket could have been closed after the scrap device registered, however the registering device would have to provide information to reestablish the communication and then listen for the server to reconnect when a notification was ready. Since this project is so small scale, it was determined a better idea to keep the scrap devices from having to accept socket requests from the server.
If an asynchronous CSocket for a scrap device is closed, the callback function alters the state of the corresponding client structure in the global vector to indicate that this scrap device should be removed from the list. The proximity algorithm will later detect this state, remove the structure and delete the socket.
Proximity Algorithm
Our proximity algorithm is fairly basic and is limited by the available
data. The RSSI data is not a real measurement
t
of distance. It is inversely related to distance with a curve similar to
that depicted in Figure S.1. Furthermore the signal strength can vary
from a multitude of influences from pure noise to relative angle of the antennae
to shielding from the human body. So it is very difficult to obtain a
constant RSSI value for a constant distance.
Two measures have been taken to combat the irregular RSSI data. The first is a split threshold system. Instead of specifying a single value above which a two tags are within proximity of each other and below they are not, we have specified one value above which the tags must pass to establish proximity. Another value is specified for which the RSSI must fall below to rescind proximity. By making the first value greater than the second a gray area in the RSSI will prevent the proximity from wavering from noise in the measurement.
The second countermeasure is a debounce counter. Once a measurement has risen above the upper threshold value (or below the lower threshold), a counter is set up for the next time proximity is checked. If the RSSI remains above the threshold for a defined number of iterations without failure, proximity is established (or revoked for the lower threshold). This also helps prevent noise from causing spurious fluctuations in proximity.
This algorithm is installed as a callback function from a CWnd::Timer resource, operating at a period of about 10 milliseconds. On each call a loop begins iterating through the global ATL vector of scrap device clients. Each client is first checked to see whether its socket has been closed and it should be destroyed. When a client with an open socket is found, it is checked to see whether it is to be considered for the actual proximity algorithm. It may be possible that for debugging purposes or an error that a client is removed from this callback routine. If it is not the loop continues on to the next client. A valid client will then be processed based on whether it has a user logged on or not.
A client with a user logged on will then iterate through all of the measurements in the SpotOn databank and try to match the clients id with the measurers id, and the scrap device user's id with the measured's id. No match will result in an immediate logout. This can happen if no data is received for a while in the SpotOn ad-hoc network and the timeout mechanism expires the needed entry. Upon matching, the proximity is then checked against the lower threshold, as determined by the GUI. If the measurement is lower than the threshold, the debouncer is decremented until zero is reached, at which point an XML logout ( <logout> </logout> ) is sent to the scrap device. If the measurement is greater than the threshold then the debouncer is set to the value from the GUI and the whole logout process will have to begin again.
When a client has no user logged on, it can still have a user of interest. If the debounce is set to zero, then there is no user of particular interest. The databank is searched for any measurements that have the same measurer as the scrap device's id. If a measurement is above the threshold, the debounce is incremented and the scrap device's user field is updated as the measured device from the databank entry, but the user is not officially within proximity yet and no logon message is sent. When a client has a debounce greater than zero, the databank is checked for the matching measurer/device and measured/user entry. If the measurement is still greater than the upper threshold, the debounce is incremented again, otherwise it is reset to zero. When the debounce reaches a critical value determined by the servers GUI the a logon message ( <logon> <id>###</id> </logout> ) is sent to the scrap device for the current user over the already open socket.
Server GUI
The server's GUI was developed with the aid of MSVC++ class wizard and resource editors. There are many text boxes for the user to control the proximity algorithm and server sockets as well feed back on the status of operation.
When the server starts none of the above threads or algorithms are running yet. The user is free to alter any of the edit boxes on the GUI. There is a ip box which must be manually set to the correct IP address of the server's host box. This can also be set to local addresses (i.e. 127.0.0.1 ) for debugging. The port box is set to a default value which is perfectly valid, but may be changed if desired. The comm port box is set to 1 but must be set correctly to the corresponding serial port to which the scrap device is attached. These three settings must be set correctly before start button is pressed.
The start button uses the above settings to initialize the listening socket and the serial port thread. All of the necessary initialization for the databank also occurs when this button is pressed. This is also the moment when the CWnd::Timer is installed for the proximity algorithm.
Once the start button has been pressed, a few other boxes will become un-editable. The GUI allows the user to alter the thresholds and critical debouncing constant for the proximity algorithm before the start button is pressed or after the pause button is pressed. The pause button will cause the timer callback function to merely return without doing anything, ignoring the thresholds and debouncing numbers. The start button must be pressed again for the proximity algorithm to become operational again. This will not cause the listening socket to be reset or any other initialization to take place. By starting and stopping, the proximity algorithm can be fined tuned to the level of noise this day, or the battery levels, etc.
Further below are four buttons for manually overriding the proximity algorithm. The logoff all and logon all buttons will iterate through the global vector of valid clients and send them the appropriate message with the user specified in the edit box to the right. To the right, the server administrator can specify a specific scrap device to which he can send a message. Depending on the current state of the scrap client, a logon or logoff message will be sent with the specified user when the "logon/logoff" button is pressed. Pressing this button will invalidate the client from the proximity algorithm so that the algorithm will not "correct" the state that we have just manually established. The button below, "revalidate", will put this client back into the algorithm for normal opperation.