Thursday, April 8, 2010

An Intellectual Property Tangent...

I'd like to take a few moments and discuss a rather heated topic that has been alive for quite some time, Open vs. Closed Source (i.e. "Intellectual Property", "Code Sharing", etc.), and how it relates to my project and blog. Several people now have asked me the following (or something close):

"Are you worried someone could 'steal' your ideas and profit?"

The short answer is no.

The goal of this blog has been to share, with EVERYONE, the experience I had taking an idea from concept to prototype. For this project, I have taken the stance that what I have learned should be open to anyone else looking to have a similar experience. I would feel nothing short of accomplishment if someday I found a shooting timer that has implemented some facet of my project.

Thus far, I have posted several items discussing, in detail, what my goals were with Project Smoke & Hope. Included in these items are detailed schematics, a demo user interface, and information pertaining to the necessary parts required to duplicate what I have done. In future posts I will provide source code for both the hardware and software aspects.

There are a few reasons why I feel sharing this information is important:
  1. Some of the problems I have faced and solved are ones that have already been solved by companies producing these timers. This information should be open to everyone so that someone might improve what already exists.
  2. The concepts I have attempted to expand upon are still in a rough stage, and need much work to become a fully functional consumer product.
  3. The prototype I have developed is only a single piece in a much larger implementation that I have in mind for future ventures. It is this concept that I would plan to expand and develop as a marketable product.
I hope this post has shed some light as to why I felt it important to share what I have done. I have conducted a purely academic study and simply tracked my progress, and I encourage anyone who finds this interesting to expand upon what I have done. Hopefully, they too find it as important to share what they learn.

I'd like to leave you with a final thought:

"The best way we truly learn is by sharing what we know with those around us."
• • •

Wednesday, March 17, 2010

10 Weeks to the Day!!

I am a couple days late in posting this but the message is the same:

I'm Finished!
(Start to Finish: Jan. 4 - Mar. 15)

That's right, I put in the time and have finished building a working prototype as described in my Design Specification. I am proud to say that I have been able to implement everything I intended to and even have some plans to further develop upon next term. I realize that I have not kept up on posting my current status, but I was really pushing to complete this on the 10 week mark. I will continue to post on my development process following this post, so do stay tuned, the best is yet to come!!

For now I thought it would be fun to post some interesting facts that accompany this accomplishment.

TIME FACTS:
- Avg. Time in Lab per Week: 25 hours
- Avg. Total Time Spent per Week: 30 hours
- Longest Contiguous Time in Lab: 15 hours
- Shortest Time in Lab: About 5 minutes (I forgot something at home)
- Earliest Arrival Time to Lab: 6:15 AM
- Latest Departure Time from Lab: 2:00 AM
- Total Time Spent (Thus Far): 300 hours (I still have documentation and testing)

MONEY FACTS:
- Estimated Final Cost (Materials Only): $440
- Estimated Labor Cost, as Intern (@ $20 / hour): $6,000
- Estimated Labor Cost, as Entry Level Professional (@ $30 / hour): $9,000

MOST FRUSTRATING MOMENT:
- This is a tough one because anytime you hit a wall, it is frustrating. I think if I had to pick one, it would be in just the first week or two of starting in on the project. I had spent about an hour in lab wiring the first test circuit for the gunshot detection interface. When finished, I looked over the circuit and everything looked correct, so I turned on the power. When nothing showed on the output, I started checking the circuit again, the first check being my opAmp. I touched the opAmp to see if it was warm... it was HOT, about 150 F hot. Needless to say, this was not a pleasant experience. As it tuned out, I had reversed the power and ground on the opAmp rails, which pretty much killed that device. This little slip up set me back almost a week because I had only one opAmp on hand, and I had ordered more online just the day before. Aside from the time delay, I had also burnt my finger a little, and left a nice melted spot on my wiring board.


MOST SATISFYING MOMENT:

- One major issue I faced with this project was using a custom user interface that I developed in Photoshop. This was difficult because the size of the picture was quite large and my memory space is very limited. In order to use my custom picture, instead of drawing the UI, I had to manually load the picture into the flash memory. Once in flash, I could read the picture and load it to the screen. This entire process took me the better part of three days, working with a friend. When we finally were able to load a picture from flash memory, into the data memory and display it on the screen... put simply, we were ecstatic.


Needless to say, I am quite [excited, revealed, thankful, exhausted...] (you pick). I have really enjoyed this project, enough so, that I will keep working on it to make it better. I think the first thing I need to do is get my wife a big present for being so patient with all the late nights.


Sunday, March 14, 2010

Corrective Action

Well, I did not disappoint! As of last Friday (3/12) I was about 95% done. All I had left was to adjust timing a little for my buzzer and put the code onto my board. But, today I went to lab with the intent of only being there for a few hours... I was sadly mistaken. As intended, I was able to finish developing my C code that runs on the Nios CPU that I have developed. I was also able to program my hardware code such that, when the device is powered on, the FPGA will be automatically configured.

When I began running my project without a USB cable connected, the board would power down (slowly) after only 30 seconds of being on, not an intended feature! This slow and consistent death of my project pointed to only one culprit, the power regulation board. Before anyone begins to worry, all of my hardware is still fully functioning, including the power regulator. In fact, the the well being of my hardware is thanks to a built-in feature of the regulator, where it will shutoff if it becomes too warm. This excessive heat can be caused by a small number of things, and in my case it was simply due to a lack of cooling.

As it turns out, I made a small error in calculations. Instead of dissipating only about 0.3 Watts of heat (which is not much to worry about), the regulator was producing 3 Watts (definitely something to worry about)! A simple recalculation shows this:

12.5 V in - 7.5 V out = 5 V dissipated by the regulator
The system draws about 600mA's from the regulator
5 V * 600mA = 3 Watts

In order to fix this, I had to add a heat sink and a couple fans, not really a big deal by the sound of it. Unfortunately, to do this required moving the power supply to a new location where a fan could directly point at it. Also, I now need to make not one hole, but two, to accommodate the fans and create airflow.

This ordeal has set me back a day, and my project is currently in pieces due to the remodeling of the package. I now plan to spend a significant amount of time tomorrow finishing the remodel and completing the project. I have to have it all done by Thursday of this week (3/18) as I have made plans to go to the range and test it out.

Tuesday, March 9, 2010

Progress By Leaps and Bounds

I realized today, that it has been over a week since my last post. Crazy how quickly time moves when you're in lab! Anyway, it is with much satisfaction that I get to report, I am on track to finish by the end of this term, maybe by the end of this week even!

Over the last couple of weekends, I have been tirelessly working on integrating a System on a Programmable Chip (SoPC) into my development board. This basically means that I have developed a CPU architecture that runs on my FPGA (I will post soon about this topic, in more detail). As of last night, I have redesigned my UI (Main Screen - v2, seen Below).

In this new version, I have separated Final Time from the Time Sheet, and expanded the number of recordable shots. Also, I increased the type and size of the font for readability. I have successfully loaded the new UI in the the on board flash memory and have been able to print text in the tables.

While I have done much more than just the CPU and UI in past week, I don't have a lot of time to go into detail at the moment. Plus, many final tweaks need to be made, so I will wait till I am done before posting too much about the software. What I can tell you is that I have the following working:
  • Start button
  • Gunshot detection
  • Timing between gunshots (with a mere 1/10th of second in between shots)
  • Text printing to the screen
  • Internal LED's controlled by external button
  • Buzzer
  • Power supply
I don't have much left and plan to stay in lab until it is done tomorrow (3/11). I have a bottle of champagne in the fridge awaiting my completion that I must not disappoint ;)

Sunday, February 28, 2010

Major Milestone: Half-Way There!!

I am very pleased to report that today marks a rough half-way point! To date, I have completed:
  • Part Research
  • Design Specification
  • Design & construction of Gunshot Detection System
  • Design & construction of Buzzer / Power Conditioning Circuit
  • Design & construction of Prototype Case
As of Yesterday (Feb. 27), I also was successful at developing a NIOS CPU core and loading it into my FPGA. With this core I have been able to detect a user's touch and draw a dot at the point, as well as load my User Interface.

To top all of this, I have successfully designed and tested a state machine for detecting a gunshot in hardware. So far, the state machine only records the number of shots fired, not the actual times. With this state machine, I was able to accurately count gunshots with only 0.17 seconds in between (I think I could count faster, but this was the quickest I was able to fire the .22 pistol). Either way, with split times of 0.17, I have met and surpassed my target of 5 gun shots per second.

I am now in full gear developing the software to run on the NIOS core and will keep you updated!!

P.S.
A little celebration is in order, cheers :)

Tuesday, February 23, 2010

Part 2-c: Building a Prototype Case

Today's topic is something that doesn't get discussed much in my degree, probably because we're not packaging engineers. Whatever the case, I strongly feel that presentation greatly affects how interested people are or become in a project. For this reason, I spent the past week building small, clean, looking circuits and several painstaking hours drilling, carving, and gluing to construct a case for my project. The final product is a case that will, most importantly, protect all the components of my project and secondly, position the screen and buttons in a user-friendly manner. Hopefully, in the end, I also have created something eye-catching and intriguing.


I started with a prototyping case from OKW, a plastics company based in Germany. OKW had the widest selection of cases and very easy to work with representatives. I've forwarded a few friends in need of a case, and if you are in need of a good prototyping case, I strongly recommend them!




While I now had a good starting point, there was much work to do. A few key issues that needed addressing were:
  • There are no mounting points for the development board I am using.
  • There are no holes for I/O (buttons, power plug, touchscreen, etc)
  • The only offered cover for the gaping hole is metal (I want people to be able to see inside)
  • It doesn't "pop!" e.g. It needs to be a little more... bad-ass-ness :)
General Modifications:
Lets start with mounting points and I/O ports. Now, I can't very well throw everything in and let it rattle around, this is Senior Project after all. I solved this simply by marking points where the board raisers touched the plastic and drilled holes. Next I made some measurements and drilled holes for the start button, piezo buzzer, piezo sensor, power, power switch, and LED mode switch.

Where to put the Touchscreen?:
The reason for picking this case was the large, slanted, hole in front. This offers a perfect spot for a touchscreen. Unfortunately, the only cover offered through OKW was made of metal, and I want people to see what is inside. The solution is plexiglass, and the answer comes from Basin Glass and Aluminum. I took my case and touchscreen in on a Friday morning and described what I was looking for. Immediately, the gal at the front desk was taking notes and confirming what was said. She said "No problem, we can have it ready Monday". To my surprise, they called me in just a few hours and explained that the gentlemen assigned to my project had finished early and I could pick it up anytime. Now that is service!

Adding "Pop":
With my case cut up and modified there was just one problem left, it was BEIGE! I quickly remedied this with 3 cans of spray paint (not that I needed three whole cans, more that I wanted 3 different colors). I started by painting the inside a flat white, this way onlookers will be able to clearly distinguish detail in the hardware. I then tapped off the the top and bottom so that the outer color would not get on the white. Once I had sufficiently covered each half in gobs of blue tape, I was able to paint the top in a dark blue with metal flake, and the bottom with a textured gray/silver color. with a fancy drying technique (seen to the right), my case was put together by the end of the weekend.


Recap:
OKW has awesome cases, Basin Glass has great customer service, and my case looks bad-ass!
Extra Pictures:
I took many pictures while building my case, but did not want to post them all, as it would slow down page load. Here are a couple links to more pictures:
Building the case & hardware
Painting

Monday, February 22, 2010

Part 2-b: Developing Power Conditioning / Buzzer Circuit

Hell0 Everyone, what a crazy week it was! I apologize for the lack of updates, but I was swamped last week. I had to wake up with my wife at about 6:00 AM every morning, and didn't get to bed till about 12:00 AM. That's what happens when class work clashes and in one week there are: 2 tests (one got moved to today :) ) , 2 labs, multiple homework's, a Design Specification presentation, and trying to make some progress on SP. With that said, let me catch you up with my design of the power conditioning circuit and start buzzer control. I know all of you have read my Design Spec and are just dying to find out what my implementation of these circuits look like ;) .

To summarize my Design Spec, the FPGA development board needs about 7.5 volts at roughly 600 mA in order to function. The tricky part comes from the piezo buzzer that I have selected, which needs 12 volts and must be controlled by only a 3.3 volt signal. In steps two very helpful devices: (1) a power regulator that will convert 12 volts to 8 volts (LM7808), and (2) a MOSFET (IRLZ34N), the same used in the gunshot detection circuit. Below are the block diagrams of these 2 devices being used (the power regulator is within the "Power Conditioning" block):


You may have noticed that the regulator outputs 8 volts, and the block diagram shows 7.5 volts. In reality, the regulator is not perfect and only outputs about 7.8 volts (with the power LED connected and now load being connected). As it turns out, there is enough conditioning on the the FPGA board that it can comfortably handle 7.8 volts.

Here are the schematics I developed for these 2 circuits:
TOP: Buzzer Circuit
BOTTOM: Power Conditioning Circuit



Below are the pictures of the final products:
TOP: Final Piezo Board
BOTTOM: Final Power / Buzzer Board


Sunday, February 14, 2010

Design Specification / General Update

Design Specification

As promised, I am uploading my Design Specification. In this new document you will find:
  • Updates to design
  • More in depth detail for implementation
  • Expanded sections on testing, constants, time line, and a price breakdown
Also, as I am a little ahead in implementing my hardware (custom circuits) and have included appendices with schematics of various uses, as well as oscilloscope images from testing the gunshot detection interface.

I have my presentation this Wednesday (2/17/10) and will upload my slides soon.

WARNING: **foreshadowing**
This weekend I have made some significant progress with my packaging and will be uploading details (including pictures) by next weekend, probably.

Wednesday, February 10, 2010

Part 2-a: Developing A Gunshot Detection Interface

Now that you've had time to look over the general concepts of Project: Smoke & Hope, it's time to roll-up our sleeves and dig into the finer details. A good place to start (in my mind) is with detecting a gunshot, because without this, there is no project.

When I first started thinking about detecting a gunshot, the initial thing into my mind was a microphone of some sort. I didn't take long for me to rule this type of sensor out, because I anticipated too many complications. For instance:
  • It is easy for a human to make a noise loud enough to overpower a common microphone (cause clipping in audio).
  • Microphones are expensive. A nice microphone costs a lot and is a sensitive piece of equipment, usually because they are used to detect and replicate a wide range of frequencies.
  • I don't need to detect frequency. Since I am only looking for "very loud" sounds, I don't really care what frequency they occur at.
  • Signal Processing is intensive. Two issues here: (1) I don't have the equipment to accurately profile the acoustical characteristics of a gunshot, (2) there is a large amount of overhead for the hardware in order to constantly measure the amplitude of a sound wave.
My desired input would be a single line (or bit) input to my board, that I would treat as an interrupt signal (meaning that an active logic level would signify a gunshot). With this in mind, I went searching for a sensor that I could build into my own circuit. After about a week of research, I found what I needed.

Piezoelectric Transducers:
A piezoelectric Transducer (piezo for short) is a crystal with a very special property. When pressure is applied (distorting the physical shape), the crystal will produce a variance in electrical potential (voltage). In simplified terms, when you hit the crystal, it causes the voltage to increase. A particularly interesting feature of the piezo, is that this process works backwards. Meaning, if a voltage potential is applied to the crystal it will vibrate at some frequency. This is very useful, as it is the technology that drives my buzzer.

Here is a link the piezoelectric transducer I used.


Application:
In order to take advantage of this sensor, I spent some time developing an amplifying circuit. Below is a picture of a basic Current to Voltage Amplifier / Converter that I implemented using an LM358P.

After amplifying the signal, it was rather noisy and oscillated between 0V to 3.3V, depending on the dB level detected. From here, I needed to condition the signal to be much smoother (in order to have time to detect the shot).

In order to do this, I connected the output of the OpAmp to the gate of a MOSFET (Metal Oxide Semi-Conductor, Field Effect Transistor). The source and drain of the MOSFET are connected to 0V and 3.3V, respectively. With a pull-up resistor on the output (creating a faster changing, active low, signal) and a capacitor tied to ground (smooths out the signal) I was able to create a signal that went low and stayed their until the sound was gone. For a better idea of how this works, see the following schematic below:


The following 4 pictures show the signals we've been discussing in more detail. The yellow line is the signal coming out of the OpAmp and the blue line is the signal after the MOSFET (notice how the signal has been converted to active low logic).

LEFT: Shows a good example of the oscillating signal out of the OpAmp.
RIGHT: Shows the output from the MOSFET with no conditioning (i.e. before I added the capacitor).


LEFT: Shows the time it takes for the capacitor to charge back up after the sound has stopped.
RIGHT:Shows what two, successive, shots would look like.


*NOTE: These waveforms are the product of lab testing. As I am not able to discharge a firearm in lab, these waveforms were generated by sharply striking the piezo (in attempt to replicate a concussive gunshot sound wave).

There you go, we are caught up with this particular interface! I am still waiting to have time to go to the shooting range with a scope and test this out better. I must sign off for now, as my Design Specification is due Friday (Don't worry, I should have it posted by Sunday for your reading pleasure).

Friday, February 5, 2010

Side Note: Bad Circuit?

So I was typing up the next installment of my SP blog a couple nights ago and ran into a little problem. The blog post was going to be all about my gunshot detection interface (back-story, theory, my implimentation, schematics... the works), but as I was reviewing my circuit and creating the schematic, I realized that my OpAmp circuit was a little odd. After doing some snooping I found that an extra resistor had been either added or misplaced to the circuit. This can cause some very bad times depending on the circumstances. I spent a couple hours in lab only to find my circuit was oscillating (this was not at all intended). I've come the conclusion that I've probably destroyed this particular OpAmp (not a big deal, they cost only about $0.40).

Anyways, I know I said we have quite a bit of ground to cover, but for the mean time I need to fix and verify this circuit before I can tell you how it works.

Thanks for being patient,
I'll be in touch.

Monday, February 1, 2010

Part 1: The Project

As I mentioned, we have a lot of ground to cover in these first days since I've had over 3 weeks to think about and work on my project. So, Here we go...

Competition Shooting Timer
(a.k.a Project: Smoke & Hope)

For my SP, I have decided to create a timer that will track the number of gun shots fired and the time of each one, relative to the starting buzzer. The user will be able to interact with the device via a 4.3'' LCD (full, 24-bit, color).

For this project/prototype, I will be developing on Altera's DE1 board and displaying my user
interface (UI) on a touch screen daughter board.










Altera DE1








4.3'' Touch Screen

Pictures from www.terasic.com

For detailed information (specifications, limitations, other components), please refer to my
Functional Specification
----OR----
Functional Specification Presentation

Sunday, January 31, 2010

A New, Temporary, Direction… Senior Project

Well, it has been some time since I have looked at my blog, so it is with little surprise that I find no more comments or views than when I last left it. If ignored blogs could gather dust as ignored hobbies do, then my blog would be twice the spider web collector that my snowboards have become :( , but I digress. As I grow tired of my Unix lab and find myself losing steam in this late hour, thus delaying my Networks lab yet again, I find myself thinking about Senior Project. I have discussed my idea with many people, family and friends alike, and with every conversation I find myself leaving out detail and simply glossing over to keep from spending hours explaining it, again and again and again...

NO MORE, I proclaim! I have decided to keep a detailed log of my Senior Project doings (SP, from now on). Since I have been working and formulating for the last few weeks, we have much to discuss! In my blogs I plan to cover:
  1. Non-Technical things
  • The basic concept of my SP (I will find a way to post my papers and presentations for everyone)
  • A guide of the basic things I need to get done
  • Information about the technologies that I will be using
2. Technical Stuff
  • Details of the parts used (links to data sheets)
  • Circuits I've built
  • Code I'm using / developing (pseudo code at least)
  • Testing information (results and whatnot)
In this journey that we are about to embark on, I will share every bit of gritty technical information, but I will try my best to explain it for all levels of readers. I also make no claims that I am a technical guru; it is important to remember that there is always someone better and worse than your or I, and that the best way for everyone to improve is by spreading the knowledge that each of us posses.

So with no further ado, I give you my SP!