Close

Code and Math...

A project log for Low-Cost Touchscreen Anywhere

An acoustic 'touchscreen' interface that can be easily attached to a variety of surfaces.

thatcher-chamberlinThatcher Chamberlin 07/26/2014 at 17:290 Comments

...Two of my favorite things. In this post I'd like to fill you in on the code I wrote before I started this hackaday.io project and discuss the mathematics that will be used both for testing and for the final product.


Here's a link to the mbed code I'm using on the LPC1114 right now. It's a repository, so it will be updated as I make progress. Here's what it does:

Two interrupts are attached in code to two pins on the chip. These interrupts, when fired, first check whether the other has been triggered by way of the first boolean value. If that interrupt is the first one to fire, it detaches from the interrupt pin,  starts a timer t, and sets first to false, indicated that the next interrupt to fire is second. It also sets a reset timer for 0.01s that will reset everything that interrupt has done in case the other interrupt is never fired. This reset function is to avoid hangups caused by invalid interrupt triggerings. If the interrupt fires and finds it is the second to do so, it first stops the timer t and stores its value, then disables the reset timer set by the other interrupt, and sets the boolean value timeAvailable to true.

Wow. That's a confusing read. I promise it will make more sense if you look at the actual code instead. Anyway, that whole part, the really important and time-sensitive part of the program, is all written in interrupts and timers. This allows for speedy, asynchronous execution of the code and (hopefully) very accurate measurements of time. The other part of the program is the main loop. It is written normally (without interrupts) and simple polls timeAvailable to see if there is valid data ready to be sent to the computer. If there is, all the data is sent and the interrupts completely reinitialized. The data sent to the computer will be processed to determine the origin of the vibrations detected by the sensors.

That brings us to the math behind this whole thing: based on a few values indicating the delay between vibrations arriving at sensors, how do we calculate position? At the moment, I've only got two sensor attached to my prototype circuit. This limits us to sensing vibrations in one dimension, or along a line between the two sensors. I'm going to test the setup with just these two sensors for now before adding the third sensor and thus the two-dimensional sensing capabilities of a real touchscreen.

Here's how I derived the equation I'll use position calculation:

That first equation was adapted from a PDF of a pretty dated Navy text on how to navigate by LORAN signals. If you don't know what LORAN is, it was the standard of digital navigation in ships and planes before GPS was available. It actually operates on a fairly similar concept to how my touchscreen will work, but LORAN used radio waves instead of sound waves. You should look it up - it's cool example of older technology.

If you read through my derivation above, you'll notice a constant k. It is used to convert the microsecond values detected by the sensors and microcontroller and sent to the computer into a scale useful for a touchscreen interface. The value k will have to be determined experimentally. I'll get back to you on how I plan on determining k and what it actually is in another log.

Thanks for reading!

Discussions