E-Targ is an open-source project with the goal of creating a comprehensive system to allow hobbyists to build their own electronic target system that plots impact locations quickly and accurately on a laptop. A basic system can be built for under $50.
Timer Board In The WorksOctober 9, 2013
Coincidentally, it’s been nearly a year since my last update. In the past two years, I haven’t done much on the project besides occassionally plotting things out in my head. I get some periodic e-mails about the project, though (many of which I still owe responses to–sorry, I’m going to get on top of it), so it’s time to get things in gear. The top priority right now is getting a timer board design all figured out and start getting some kits out there so people can build their own boards and start adding to the project.
At this point, I have a design in mind and I have all of the components on hand. I’m prototyping out all of the circuits while working on the programming. There’s not a lot of code that goes into the timer board, but I’m switching everything over to ARM and I’ve never dealt with ARM microcontrollers before.
I’m working with the LPC1114 ARM M0 microcontroller. This chip has been well-received in the hobby community due to its onboard bootloader, nice set of peripherals, and hey–it’s DIP. Neat! It’s also very cheap and can run significantly faster than any of the AVR chips. Having a 32-bit timer is also a HUGE advantage for this application, as it adds a lot of flexibility into the target size. The bootloader is a great feature and will allow people with basic skills to flash the board easily as I update the firmware, all using free tools that are available for Windows and Linux.
So the plan at this point is to get three signals to the microcontroller for each input channel (four channels total):
- Threshold-detector- A binary signal to indicate when the input waveform has reached a defined level.
- Zero-crossing detector- A binary signal to indicate when the waveform is positive or negative (so we know when it crosses zero). This is used to generate the TDOA data.
- Scaled/rectified analog input signal- This is something that won’t be used during operation, but can be called upon to get an idea of the input levels the board is seeing so the input scaling and the threshold levels can be set.
In order to add flexibility, I’m going to run the inputs through a high-speed, low-input-impedance op-amp input circuit that will use a digital potentiometer to set scaling. This should make it pretty easy to use the same board for piezo-based systems and microphone-based systems. It will also allow things to be set up and adjusted remotely, which can be pretty useful in this application.
Now, the timer board isn’t going to do the multilateration. This microcontroller is more than powerful enough to do that very quickly, but I’m going to just continue with the policy of leaving that job to whatever the system interfaces with. Speaking to that, I’m not going to put USB or RS232 on the board, or anything power supply-related. Communication to the host is going to be through TTL serial and the board is going to need 5V and 3.3V power externally. The idea here being that the system will be commonly interfaced to something like a Raspberry Pi, Beaglebone, Linux-converted router, etc, all of which have TTL serial and the requisite voltages available (the board won’t take much power). For people interfacing directly with a PC, use a TTL serial adapter that I can throw in with the kits for like $3.
On the host-side, my plans are pretty much as they were a year ago. Write a C program (this is mostly done, just need to dust it off and finish it) to handle dealing with the timer board, calculating the multilateration, and serving up the impact data for external programs. Then I’m going to provide a basic mobile-tailored web application that you can connect to to view targets/impacts.
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:
- 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).