The Problems

Problem 1

As stated in the Design section, a number of problems were encountered when using the Bluetooth class. Recall that with the Btooth program the goal was to automatically unlock the doors when within range and connected. The issue that prevented this from working perfectly was that there was no method implemented in the class to check if the device was connected. In order to bypass this problem, error trapping was used to try to connect and see if an error occurred. If an error occurred then it was assumed the device was out of range and hence continues to try to connect.

Problem 2

A second problem was how to determine if the devices were still connected after a connection was successfully established. For example, if the user pressed unlock after successful connection, but had traveled out of range, then the device could not send the connect character sequence. This problem was a bit more complicated than the earlier problem and required a communication protocol between the HC11 and phone. A technique was used where the phone sent a character every 1 second. The HC11 would then echo that character back to the phone. If the phone sends the character and doesn’t receive a character with some number of tries, then the two devices must no longer be connected. Theoretically this logic is perfect and allowed the screen to be continually updated with information regarding the connection status. If a connection was lost the program would automatically go back into a connect routine and try to reconnect.

Problem 3

The final problem that resulted in an unstable program involved this continual transmission process. In order to use Bluetooth as well as transmit over a serial two classes were used; the earlier mentioned Bluetooth class and a standard iostream class. The iostream class allows for various types of input and output. The problem arose when trying to send a character to the HC11 when a connection had been lost. This obviously throws an error, but error trapping with try-catch statements was implemented to prevent the program from “freezing”. The problem is that when trying to use the iostream class to read or write a value, the method implemented tries to read/write for a given block of time before determining that the read/write can not be performed. The given amount of time happended to be around 4 to 5 seconds with standard the settings. When this value was altered, using a built-in properties method, an error continually occurred and compilation would not occur. After much research it was found that this was a problem with the Bluetooth class used and hence one can not alter the timeout value. For this reason the Btooth software was very unstable. It should be noted that this program is not multi-threaded and hence when the read/write methods tries to connect for 4 to 5 seconds the software interface is non respondent. Therefore the user has not control over the program for this amount of time. It was also found that if the user requested actions during this delay period the actions were performed much later or a fatal stack overflow error occurred. This then shut the program down and often times made the phone completely non-responsive requiring a reboot sequence. One possible solution was developed for this problem involving multi-threading the application. One could place the read/write function on a separate thread and hence allow the user-interface to remain responsive. This technique was not tested due to time constraints. It should be noted that although there is plenty of documentation regarding multi-threading applications and standard threading classes, multi-threading a mobile device requires its own set of classes.

Problem 4

Another situation faced was the access of the electrical controls of the vehicle’s functions. Although controlling the lock system was the main goal of the project, other functions such as the power windows, horn, rear window defogger, lights or even startup of the car were targeted. In the case of the power windows, this system works with a dedicated Control Unit. It would have been necessary to access this independent unit in order to manipulate the windows from the HC11. Other functions required major alterations of the car’s circuitry and integrity, which we refused to do to preserve the good conditions of the car. For example, many of the controls of the functions mentioned are located under the hood of the car, in the engine’s compartment, making it necessary to dismantle some engine components and rewire the original circuitry. An alternative solution could have been to bypass the car’s circuitry with our own, but that means that those functions wouldn’t work by themselves, without the control of the HC11.