Software | pepguard

Camera Module

Commands to the camera module typically involves 2-5 header bytes followed by the payload (if exists). The module returns a response packet if the action is completed successfully. For example, a successful system-reset command appears on the right.

To simplify our code and improve on readability, we packaged common command packets into macros, to which the payload is passed in as a function parameter (see Appendix).

Typical Camera Operation

Camera Reset and response

After a photograph is taken, it has to be retrieved by accessing memory-mapped addresses of the RAM directly, beginning at location 0x0000. In our implementation, the photograph is first divided into chunks of 32-byte based on its size. Data is then incrementally queried by the microcontroller and routed to the Bluetooth module until the terminator string (0xFFD9) is observed.

The screen capture on the left shows a typical camera operation following the above-described sequence of actions, as recorded by our debugging utility echoed onto PuTTY.

Bluetooth Module

The Bluetooth module automatically performs a system-reset upon powering on. In discovery Mode, the microcontroller sets up the module as a server and waits for the cell phone to be connected as a client. During an operation, the module receives data packets routed from the microcontroller and forwards it to the cellphone. The figure on the right illustrates this process.

Note that no form of handshaking or error detection algorithm is implemented in our prototype. Communication may become more reliable if these techniques were employed, and they probably should be in a more mature product as the JPEG file format is intolerant to error.

Bluetooth typical operation

Push button De-bouncing

As mentioned in Hardware / Software Tradeoff, de-bouncing of the pushbutton trigger is realized in software. A typical approach is to use a state-machine to monitor the changes in an input pin (INT2), and thus confirm a valid button press. The advantage of this approach on a microcontroller is that it allows the processor to cater to other tasks while de-bouncing a switch, which is an efficient way to utilize limited computational resources. However, this would require slightly longer code than a simple busy-wait in an interrupt service routine (ISR). In our device, chip memory, rather than CPU time, is the truly scarce resource. The microcontroller has no other tasks to cater to before a valid button press, but requires every savings in memory-space possible in order to temporarily store the picture data. Therefore, pushbutton de-bouncing is implemented as a busy-wait in an ISR.

Android Application

The android application receives emergency alerts and a picture of the crime suspect over Bluetooth when the pepper spray is triggered. By using the built-in Bluetooth API in Android SDK, we configured the cell phone’s Bluetooth transceiver as a client to PepGuard. The received picture is saved on the cell phone while an emergency call is initiated.

The cell phone needs to be paired with the Bluetooth module at all time. If PepGuard is switched on, it automatically enters server mode and waits for an active connection with the correct passcode. The android app is programmed to find the PepGuard device from all paired Bluetooth devices that the phone kept track of. At any given time, if the app is activated, it will attempt to establish a connection to PepGuard as a client. After the connection is established, the application waits for a triggered alarm.

In case of an emergency and the push-button is pressed, the application immediately examines the incoming data stream to look for an alert message. Once this is identified, the application blinks a red "Warning" message on the cell phone screen and immediately starts to convert the incoming data stream into hexadecimal numbers and append to a long hexadecimal string. For each of the 32-byte chunk of received data, the application looks for the JPEG terminating strings "0xFF, 0xD9" to terminate its operation. If this is found, the long hexadecimal string will be converted back to byte array and saved as a "photo.jpeg" file in the device storage. Once the image is successfully saved, it is converted into bitmap to be displayed on the home screen of the application. In the meantime, it initiates an emergency call to a pre-configured number to call for help.

Not all cell phones support concurrent programming, and therefore we did not allow the phone call and image transfer to occur simultaneously. Since the JPEG file is a relatively error-intolerant format, we felt that preserving this information is a more critical and time-sensitive task than initiating the phone call. Note that our application does support background operation. The entire chain of events will remain operational even if the cell phone is in sleep mode (with screen powered off). Furthermore, in case of the cell phone running into memory exhaustion, the emergency call will still preempt the home screen and the picture will be saved.