Update, Current PlansOctober 15, 2012

The academic portion of the project ended nearly a year ago. In the meantime, I have made very little progress, mostly due to not having enough time, but also because I keep going back and forth on how I want to do things in order to create something that could be called a final product. At this point, I have settled on what exactly I want to do and make available and how I’m going to do it. Now it just comes down to finding time. I do get e-mails from interested folks pretty regularly, so that certainly helps motivate me.

At the moment, I am focusing on software development. I am writing what I call the etarg server (etserve), which is a linux command-line application (or a daemon) that communicates with one or more target timers. It manages the target hardware as well as the firing line clients. It is being written in a sort of bare-essentials C using sqlite for basic database needs. It is intended to be compiled on a lightweight, single-board computer (SBC) like a router running OpenWRT. The router/SBC would be mounted in a water resistant enclosure along with a target timer and battery, which would then all be installed down-range near the target. The user would then use a laptop or, more likely, a smartphone to connect to the target system wirelessly. Alternatively, the whole SBC part could be bypassed, with serial communications directly from the laptop to a target timer and etserve running on the laptop (Linux for now).

As for the target, I am focusing on foam board targets for the time being, as we have shown that to be a workable solution. As things progress, I plan on working on hardened steel targets.

For the target timer, my goal is create a design that I am satisfied with and then run off a batch of PCBs. I need to do some research and testing to see if I can find a better way of buffering the piezo sensors, as I feel like the JFET solution that we have shown to work involves too many components. I am also still trying to decide whether to stick with a traditional AVR like the ATtiny and force people to use ISP to program it, or build something around a USB AVR breakout board (like from Sparkfun) with a bootloader. Lastly, I need to decide how much to componentize it, as there are basically three different sections:

• microcontroller
• event detection (zero-crossing and threshold triggering)
• sensor interface (buffer/amplification)

Should I throw them all on the same board, or build separate boards that all plug in to one another so you have more choices in terms of the microcontroller and the sensor interfacing? At a minimum, I think the sensor interface section should be separate.

As far as time frame goes, you shouldn’t hold your breath. Hopefully I’ll have code and schematics/board layouts you can download and maybe kits or at least PCBs to buy sometime in the spring of 2013. We’ll see, though.

Musical Ping PongOctober 14, 2012

Towards the end of the senior design project, I was looking for some info on multilateraton techniques. I found a blog post by Jason Hotchkiss about a project to create a musical ping pong table that would generate MIDI signals based on the impact location of a ping pong ball. The information I found there proved very useful and I provided some input based on my research that proved very helpful in finally getting his project to work.

I was helped here by Matt Waterman, who got in touch with me via my blog and suggested using zero crossing detection as a solution to this. My understanding here is that once the initial wave front passes the sensor and triggers it, the vibrational displacement will reach a positive peak, then fall down to to zero, then reach a negative trough before repeating. At some point the displacement it crosses the “zero” value, and this is a distinct point in time which can be detected without the same sensitivity difference issues (since we’re comparing positive level with negative level, not two different positive levels, this can be detected more accurately). Since the positive wave front should have the same front-to-back width across all the sensors, the zero-crossing time measurement should be just as suitable for my purposes as a hypothetical perfect measurement of the arrival time of the wave front (becaise we’re working with relative time of arrival at the sensors, not the absolute times of arrival).

Read about it here, here, and here. There are a lot of very interesting similarities between his project and mine.