top of page

Copyright 2013, PepGuard. No Animals or Humans were harmed in the making.

Logical Structure

Conceptual Overview of PepGuard Operations.

         PepGuard communicates with a Bluetooth-enabled cell phone using client-server architecture. The system initializes in Inactive Mode with the Bluetooth transceiver on our device acting as the server. After a cell phone connects with PepGuard as client, the system enters Active Mode and waits for the button-press trigger. In case of an emergency, the user would press the push-button to release the pepper deterrent, thereby triggering the Camera Module to take a photo of the crime suspect (LED flashes at the same time). Immediately thereafter, the microcontroller retrieves the photograph from the camera and routes it to the Bluetooth Module to be forwarded to the cell phone. All communications between the ATmega1284P microcontroller and the Bluetooth and camera modules are based on the universal serial asynchronous receiver / transmitter (USART) channels. At the receiving end, the cell phone application receives an alert message, saves the incoming picture data as a JPEG file and initiates an emergency phone call.

Hardware / Software Tradeoff

        There exists commercially available hardware that allows the camera to save photographs directly to a MicroSD card. While this off-the-shelf solution would simplify our software design significantly, it complicates the user interface by requiring more steps to set up the system and thus contradicts our design philosophy. The choice to implement a routing mechanism in this trade-off between hardware and software allows our prototype to be more realistically evaluated.



        Push-button de-bouncing can also be accomplished in either hardware or software. Following a similar train of throught, a simple software de-bouncing mechanism is implemented because the former would introduce extra components into the circuit board, which goes against our goal of keeping a small device footprint.

Industry Standards and Patents Compliance

  • Communication: The Bluetooth module that we used has been marketed and sold with approval from the FCC.
  • Android Application: Our prototype currently employs a demo version of the app that we developed and has not been submitted for approval to the Google Play store. It is used as a proof-of-concept user terminal.
  • Patents: Existing patents cover fixed security fixtures that involve less-than-lethal deterrent (US 2010/0128123 A1), or hand-held security devices that require multiple steps of human intervention (US 2002/0057365 A1). We assume that our prototype developed for this class is not in violation of existing patents.
bottom of page