"Button matrix" problem

[seppoman]

Hi all,

as a new university project i´ve built a sensor floor. it´s 3x4 meters, 6x8 diode matrix "buttons" large. the lower part is built from separate areas of aluminium foil, each row connected via diodes at the edge. Above a separating layer (some rubber-like net) rows of alu foil are glued to the carpet. This construction is connected to a core / DinX1 /DoutX1 board using the SM_example2 application.

Now to the problem: As long as only one "button" is closed, everything works, also when the second "button" is in the same row or line as the first one. But when a second button is pressed e.g. like

x o o

o x o

so that row and line are totally independent, the application sends a fast tremolo alternating both respective notes. This happens with some (but not all) other combinations that are not in the same row or line. I hope the description is understandable - it´s difficult to describe because I don´t find a real logic in when this happens and when not.

I did fear that problems would arise because of the long cable lengths and the large "capacitor-like" button fields. But as single actions work alright, I suppose it has to be something not directly related to cable lengths. Is there some configuration thing in the sm driver I missed that could be responsible, or should I add e.g. some caps somewhere that could stabilize this rather strange system?

Any help is greatly appreciated - this thing has to work next week or I´ll have a big problem  :o

Seppoman

edit: I made more tests today - the first three rows don´t show the problem. It starts from between row 3 and 4, i.e. when the cable lengths become larger. So if no other solution comes up, I could split the area and connect it to 3-4 cores. But this would mean more wires, more electronics and MIDI mergers  :-\

[pay_c]

Hi there!

Perhaps dumb question, but you never know:

Did you try shielded cables? Like those known from headphones or similar (diode cables e.g.)? The outer shield always connected to the ground and the inner cable having the actual signal? Normally this helps a LOT.

[TK.]

Hi Seppoman,

like Pay_c I suppose that this is a shielding problem. The button matrix sends very short pulses over the select lines, than longer the cables, than higher the propability for crosstalk effects. Shielded cables help to eliminate crosstalk

Best Regards, Thorsten.

[seppoman]

Let me first post a few pictures so you know what I´m talking :)

The squares are connected seperately because I didn´t want the diodes and the solder joints to be stepped on.  I chose transformator wire because the wire has to be thin and must stand being walked on, which is not the case with cheap shielded audio/headphone wire. Apart from these considerations it would be A LOT of work to exchange these. But I will try to replace at least the wires along the edge by shielded ones.

Anyway, the aluminium is of course also a BIG antenna - it´s around 20 quare meters foil netto. And around this floor there will be a lot of electronic devices - amps, D/A converters, computers etc. so I already fear what will happen when the floor is in the actual setup...

So would it be possible to set the application to a more relaxed timing to reduce crosstalk sensibility? Hopping around on a floor it´s not possible to play a fast melody precisely anyway, and the floor won´t be used to trigger notes, so I´d have no problem with e.g. 5-10 ms latency. Is there a way to achieve reduced crosstalk sensibility by simply initializing the timer to a different rate? Or should I better use the SM example 1?

Thanks a lot for your input :)

Seppoman

[Davo]

So, if you can't use shielded cable, how about twisting a ground wire around each signal wire?  Perhaps try flat speaker wire?

[seppoman]

Hi Davo,

I suppose I could have found some suitable cable, but now everything is connected, taped together etc. To change the cables at the edge is a few hours, but to rewire everything is not possible in the next few days - I´d have to build nearly the whole thing from scratch again.... This is a part of a university project which will be presented this friday to the press and next week on the PopKomm fair in Berlin, so I´ve got quite limited time to get it running. If there´s no way to make it more stable through timing and edge rewiring (see above), even splitting the area into parts with more than one Core would be a faster solution than complete rewiring.

Seppoman

[TK.]

Yes, relaxing the timings is a good idea. If you are using the sm_example1, you only need to increase the "MIOS_SRIO_UpdateFrqSet" setting in main.src - currently it is set to 1 mS, just try 10 or 100 mS

Best Regards, Thorsten.

[seppoman]

Hi Thorsten,

thanks a lot for your hint :) Today I experimented with the SM example1, and it works like a charm even with the standard 1ms setting and 1 SR config. I set the timing to 2 ms and changed the surrounding cables for shielded ones, so I think there won´t be any bad surprises even in RF intensive surroundings  ;D

Thanks again,

Seppoman