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


    Jul 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.

    • Jul 12 2011 | 5:18 pm
      Have you tried Maxuino?
      Easy enough to route from Arduino pins then
      or am I missing something here?
    • Jul 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
    • Jul 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 ;-)
    • Jul 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
    • Jul 12 2011 | 10:26 pm
      Here's one
      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!
    • Jul 13 2011 | 1:03 am
      "You might enjoy this thread of mine...."
      which I forgot to link to
      Brendan