Werde heute einige Dinge bestellen. Die Liste ist noch offen und befindet sich in der Dropbox. Oszilloskop und Signalgenerator sprengen allerdings das Projektbudget. Die sollten an sich an der TU in Massen herumliegen, zB. ums Eck in der Floragasse. Es wird allerdings immer irgendeine Art der Mitgliedschaft verlangt. Hat hier jemand interfakultäre Kontakte?

armin hat mir letztens erzählt, dass peter gerne beim kommenden metaday über die capacitative touch sparte präsentieren will, um leute aufzureißen. ich halte das allerdings zu diesem zeitpunkt für einen taktisch bzw. auch strategisch recht unguten zug nach meinen bisherigen erfahrungen mit dem metalab, und hier ist warum:

1) generell ist es für open-source projekte ganz schlecht, volunteers zu suchen, bevor schon was funktionierendes da ist: die motten fliegen zum erfolg, nicht zu den challenges. aus genau diesem grund warte ich auch immer selbst, bis eins meiner projekte "fertig" ist, bevor ich es poste/twittere/etc. open-source funktioniert als kreislauf von lernen und beitragen, d.h. wenn noch nichts da ist, durch das ich die materie des projekts erlernen kann, gibt es auch wenig anknüpfungspunkte, bei denen ich beitragen kann. bestes beispiel: GNU hurd vs. Linux – guess which one already worked when it was announced.

2) das metalab ist sehr bunt gemischt. insbesondere traue ich dort genau 4 leuten zu, sinnvolle contributions machen zu können, also rein aufgrund ihrer fähigkeiten. genau die sind bei den metadays aber so gut wie nie dabei, sondern sitzen hinten im lab und basteln. umgekehrt kämen aber sofort ganz ganz viele grenztriviale hillfsvorschläge von den unbewusst weniger qualifizierten anwesenden, a la "habt ihr schon decoupling caps probiert?". zu den 4 guten leuten hab ich einen guten draht, d.h. wenn einmal was da ist, frag ich sie lieber direkt, als uns am metaday der masse zu exponieren – wobei ich da auch keine großen hoffnungen habe, die leute sind busy und selbst für ihre eigenen interessen schwer zu begeistern: ich versuch seit monaten, RepRap-mäßig was auf die beine zu stellen, aber klappt nicht – derweil ist noch nicht einmal ihr eigener mendel fertig.

3) das metalab mag kurze, einfache, eindrucksvolle projekte, keine aufwändigen mühsamen mit wenigen fanfaren: wenn wir wen brauchen, der uns eine pong-demo mit unserer surface programmiert, perfekt, aber für die grundlagen werden wir nur leute anziehen, die sich profilieren wollen.

4) die schwierigkeiten, die wir momentan haben, lassen sich auch nicht einfach lösen, indem wir wen von außen hinzuziehen: das prinzip haben wir schon verstanden, schwierig sind eher die limitation einzelner komponenten (z.b. die eingangskapazität unserer opamps) bzw. die tatsache, dass die smartskin-lösung auf dem exakten tuning ihrer komponenten basiert, die mehr experimentellen als rechnerischen charakter hat. und die 50Hz welle ist an sich beim momentanen stand relativ egal, da wir ohnehin einen integrator brauchen werden (schaut halt im oszilloskop nicht schön aus, ist aber aufgrund ihrer gleichförmigkeit ziemlich egal) – und ansonsten kämpfen wir bei 400KHz nicht gegen viele böse wellen, da kein funkstandard dort sein baseband hat. und trotzdem können wir das durch ordentliches shielding bzw. ordentliches ground-wiring sofort lösen – remember, im moment wohnt unser prototyp auf einem breadboard, das mit seinen vielen langen leitungen selbst nochmal eine dicke antenne ist! also vereinfacht: um aluminiumfolie um unser ding zu wickeln, brauchen wir echt keine hilfe.

5) das projekt hat aber auch gerade das potential, einige metalabber zu begeistern, *wenn* schon etwas funktioniert. jetzt schon das pulver zu verschießen heißt, eine riesen-chance weg zu schmeißen.

zusammengefasst: don't do it, not right now.

Nach dem Erfolgserlebnis letzten Donnerstag, hier eine Skizze des momentanen Aufbaus:

Wow, it's excellent and suprising that your prototype shows such high sensitivity. You may make a 3D input device as well as multi-touch :)
3D input device: http://www.touchuserinterface.com/2011/02/amazing-nemopsys-3d-gesture-co...

By the way, I also implemented my own and tested it with scanning electronics attached. It works for a single point. But when scanning starts, it fails to sense. My sensor is based on MIT's electric field imaging method. Scanning electronics I used is a modified version of ArduMT1.

Since I'm preparing for the next release of OpenMT, this capacitive multi-touch project is a little delayed ...

Differential Amplifier
http://www.electronics-tutorials.ws/opamp/opamp_5.html

Peak detector
http://en.wikipedia.org/wiki/Precision_rectifier

Single supply opamp circuits
http://www.eng.yale.edu/ee-labs/morse/compo/sloa058.pdf

I'm touching the lower right corner of the matrix and I'm getting the following image (I marked the problematic areas). The image corresponds with the received string, so I don't think there's an error in the drawing or parsing routine. From my current point of view it's either an issue with the serial buffer or with the multiplexer.

Last Thursday Georg and me upgraded our prototype to 176 crosspoints. Using linear interpolation we can already produce some nice low-res images. Here's a short video.

@OpenMT: Your package just arrived and the sensing area looks great! I will try to test it as soon as possible.

Some thoughts on next steps:

• We still haven't figured out what causes the row order bug.
• We do have line artefacts and they seem to appear every 2nd row. Last Friday we managed to compensate these errors by adjusting the signal amplification, but this feels a bit like a workaround for me. At least we do not know the cause yet and our solution might actually degrade the sensor's sensitivity.
• I ordered two little FFC-Breadboard connectors so we can finally test our circuit with Wook's sensor panel. And we should try to increase the number of sensors of our own matrix.

concerning our new arduino-processing transmission issue: Georg's encoding and decoding algorithms are sound (I personally recalculated the binary numbers, no joke), but the buffer on the receiving side contains erroneous data. So far I came to the following insights:

Our little test program can not reproduce the same numbers on my Macbook (OS 10.7.3). Downgrading RXTX to 2.1-7 or upgrading Processing to the pre-alpha version didn't change that.

It actually produces the correct numbers when executed on a Linux box (white Intel Core 2 iMac, Ubuntu, Java 1.6.0_26-b03, Processing 1.5.1 and 1.2.1).

Maybe we can narrow it down a bit more…

Here's a picture of the new sensor matrix.

The conclusion of our last session was that our multiplexer weakens our signal in the last few channels. We are using four multiplexers and the attached image should illustrate our problem quite well.

I also attached an article about multiplexer crosstalk in analog multiplexers.

We went back to using only two multiplexers and we also rearranged some components on the breadboard. The processing sketch now features a signal cutoff slider, supports two different blob detection libraries and is able to send TUIO messages. The data gets sent to another computer which runs Pd and generates the audio feedback. A short video is available here: http://youtu.be/AaGAN2iooCA

This discussion forum is closed. For further updates please visit wiretouch.net.