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

brendan mccloskey

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

Simon

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

or am I missing something here?

brendan mccloskey

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

Simon

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 ;-)

brendan mccloskey

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.