Forums > MaxMSP

[sharing/testing] multiple sensors to Max; from one n00b to another

July 11, 2011 | 12:22 pm

For several weeks I was faced with the challenge of parsing data from multiple sensors in MaxMSP. 15 FSRs need ‘hardwired’ to a predetermined pitch set. However, sending this data over the serial port introduces a variable: the timing of serial initialization prevents reliable ordering of the multiple data stream, i.e. sensor1 – sensor15 may not always arrive in that order, depending on when the serial object is initialized. After much head-scratching, forum-pounding and extensive research, the solution lies in ‘tagging’ the bytes with a header value. Before each serial byte is sent, pair it with an ascii value ("1" = 49, "2" = 50 etc). Then in Max, the [zl group 2] makes the pair (header ascii and readVal), and [route 49 50 51.....] parses the tags. It seems to work even if the readVal coincides with an ascii value. This is a proof of concept patch, demonstrating the intended functionality.

http://www.youtube.com/watch?v=l2ZU9RG6y1M

http://brendan-admi.blogspot.com/2011/07/diy-fsr-matrix-part-1-parsing-multiple.html


July 12, 2011 | 5:18 pm

Have you tried Maxuino?
Easy enough to route from Arduino pins then

or am I missing something here?


July 12, 2011 | 7:25 pm

I totally understand your concern/comment – "why re-invent the wheel?" as my PhD supervisors are always saying. But. I have tried a number of these ‘prefab’ solutions, including Maxuino, SARCduino and others. I am building a customized interface for users with physical disabilities and consequently need to maintain optimum ‘tweakability’; because my programming skills are a little limited I can’t hack these prefabs, so I need to build my code from scratch, meanwhile developing my own nascent programming skills.

Brendan


July 12, 2011 | 9:22 pm

Hmm, I think I’m with your supervisors.
I have been working with the disabled community for the last ten years or so, have used several different micro-controllers & lots of different sensors often FSRs.
Its always good to hone your skills, but these days its also too easy to take one’s eye off the target with diversions.
I don’t seem to follow what ‘tweakability’ you are gaining by adding tasks on the Arduino.
Does your code yield noticeably less latency in sensor operation?

-Sorry, devils advocate mode ;-)


July 12, 2011 | 9:55 pm

Hi Simon
do you have any links to your work?

I also favour FSRs, for their tactility, but I have built my own, and I have also hacked a resistive touchscreen. I don’t regard hacking/programming as a diversion, rather a key component of custom interface design. I and my participants demand control over all elements of the environment.

Thanks for posing these reservations though, as I will no doubt encounter the same and more in my end of PhD viva voce.

You might enjoy this thread of mine….

Brendan


July 12, 2011 | 10:26 pm

Here’s one

http://www.port.ac.uk/research/mediate/

my own website is err ‘under revision’…..
Poor self-publicity on my part,as for me, that is a diversion.

Keep on keepin’ on Brendan!


July 13, 2011 | 1:03 am

"You might enjoy this thread of mine…."

which I forgot to link to

http://cycling74.com/forums/topic.php?id=34100

Brendan


Viewing 7 posts - 1 through 7 (of 7 total)