top of page

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

Design Outcome vs Expectation

         In our original proposal, we suggested the basic use case and architecture of our system, including some possible hardware / software solutions that may be combined to produce a working prototype. In particular, we proposed that:



  • Camera and bluetooth modules will communicate with the MCU using USART
  • Camera flash (perhaps a high power LED) is driven by a de-coupling circuit
  • Photographs of the crime suspect should be saved to a microSD card
  • A phone call should be initialized

         We are glad that most of our objectives are met in this prototype. The idea of interfacing with the microSD card had to be abandoned halfway through our project because our teammate (Adrian) who should have been working on this part of the project was stuck on the west coast due to Hurricane Sandy. As a remedy, we decided to transfer the photos directly to the cell phone via Bluetooth. One potential drawback of this approach is the extra level of uncertainty that an unreliable wireless communication adds to the overall success of our system. Routing camera data directly to flash (microSD card) through physical wires is almost certainly going to be more reliable.



         One thing that we learned from this project is the paramount importance of making progress in interlocked steps. A lot of time could have been saved if we had measured the operating current consumption of each device accurately at the beginning, and performed relevant power calculations.



          In addition, we also had ample opportunities to record our weekly progress (see below), and when problems occur, use these records to eliminate improbable causes. Such information has also proven to be really useful in preparing this final report.



Applicable Standards & Intellectual Property Considerations

We have completed a broad survey of industry standard / IP considerations here. We would like to elaborate on some specific questions that have been raised regarding IP concerns.



  • Did you reuse code or someone else's design?

   Yes, we referenced the uart communication code from the course website.

 

  • Did you use code in the public domain?

    Not directly, but we referenced and studied code written by other enthusiasts who have worked on similar peripheral modules.

 

  • Are you reverse-engineering a design? How did you deal with patent/trademark issues.

     No.

 

  • Did you have to sign non-disclosure to get a sample part?

     No. 

 

  • Are there patent opportunites for your project?

    We would certainly love to. However, as discussed in an earlier section, we did discover existing patents that vaguely (and very broadly) cover similar use cases. Although it should be reasonable to assume that developing a non-commercial prototype for academic purposes would not constitute an active infringement on these patents, we should look further into them before making any decisions to patent our device.

 

  • Are there publishing opportunities for your project?

    Not as of now.

Ethical Considerations

         Two areas in the IEEE Code of Ethics are especially applicable to our project and its implications at large. Firstly, engineering design and decisions have to be consistent with the safety and health of the general public. Our project suggests a technical improvement or a potentially hazardous non-lethal deterrent that has been commercially banned in many states (including New York). Despite our genuine concern for public safety (which is in part where this project originated from), we cannot and should not develop or test our system using any actual hazardous substance without first acquiring the necessary permissions and supervision. Secondly, honesty in making claims and estimates based on available information has been crucial in our project. In particular, due to the innate unreliability of wireless data transmission in our system, the photograph that we captured may not be successfully saved during each run - and a multitude of factors may influence our system's performance in this area. To recognize this, and record it as a shortcoming of our prototype while suggesting possible future improvements based on our trials are honest claims to the best of our understanding.

bottom of page