send serial ONLY when sensors are touched?

Hallo all

I am using the following code to detect force from multiple FSRs, and return that value as brightness, for multiple LEDs. That bit is easy. I am also sending this data to MaxMSP, which uses a “metronome” type object to poll the serial port.

//read 12 FSRs, convert force value to LED brightness

int inVal;
int brightness;

void setup(){
  Serial.begin(9600);
  //multiple LED pins/////////
  for(int x=2; x<14; x++){
    pinMode(x, OUTPUT);
  }
}

void loop(){
  //multiple FSR pins
  for(int i=0; i<12; i++){
    inVal = analogRead (i);
    inVal/=3;
    inVal=constrain(inVal, 0, 255);
  
    brightness=inVal;
    //prepend sensor value with pin# ident
    Serial.write(i);
    Serial.write(brightness);
    analogWrite((i+2), brightness);
  }
  delay(10);
}

My problem is the fact that the Arduino code is continually running, sending sensor ID and value - for example, at any time it could be sending "5, 0; 6, 0; 7, 143; 8, 0; when I begin polling the serial port I might get EITHER the sensor value first followed by sensor ident, OR ident then value. I thought that a solution might be to only send the data to MaxMSP when a sensor is pressed. How would I do this?

if sensorVal >0{
send all the data;
}
else{
blank space here;
}

Would this result in jittery data? Or is another solution to listen to the serial port and wait for a keystroke or ascii value (from MaxMSP). I know how to send stuff from Arduino to Max, but have no idea how to do this the other way round. What I wish to achieve is a guarantee that whenever I begin polling the serial port I will always get sensor ident FIRST, followed by the associated sensor value.

Any suggestions?
Thanks
Brendan

I suggest you read a proper description of how serial communications are supposed to work.

If you are concerned with mis-interpreting a message which you started reading part-way through, then you need to consider a more foolproof method of encoding each part of your message, so that you can tell when the message sequence starts and ends.

If you think you have started half-way through a message, it is normally the best course of action to ignore the incoming data until you can determine that you have reached the start of the next, hopefully complete, message.

It is possible to consider trying to interpret data from a message you start reading part way through, if you can tell exactly where you are, but it is usually a bad idea.

But all of this is missing a key point, which perhaps you don't understand. Any normal serial communication implementation will buffer a reasonable amount of information, so that when your program starts "reading" it, it will start reading from the beginning of the first message sent to it. ( Assuming that you haven't sent so much data that the buffer has overflowed already).

When I download a sketch to the Arduino, it starts running right away, faster than I can mouse-click on the button to open the "serial monitor" program. But despite this, I usually get the first serial message output by the arduino sketch to the PC, even though this serial data was actually sent by the Arduino BEFORE the serial monitor commenced, because the first data received at the PC end is buffered in the serial port hardware ( or virtual serial port hardware ).

I figured that at the receiving end you would have a loop with Serial.available()>n condition. So, at some point it would get to the waiting state and whenever it's raised from that state, the received data would always be in order. But if it's a continuous stream of data, I can see the problem.

My first thought was that you could use a synchronizing byte in the data sequence. Just send 0xFF or something to mark the start of the sequence. Then again, that might be only necessary at the start of the communication, think handshaking. You sync it at the beginning, and can then expect to receive the data in the correct order and save one byte per packet.

Edit: Heh, obviously, 0xFF as the synch wouldn't work if the rest of the data ever included that byte...

If you want to "send data only when sensors are touched", you could consider sending a message for each sensor touch change, instead of sending all sensors at once.

Thanks everyone, some valuable suggestions;

@michinyon

I'm attracted to this solution the most, could you perhaps pseudo-code this for me? Is this close?:

for (loop to read all pins)

which pin >0 ??
send a pair: pin# and value

Thanks

4 years later ?

Why not start your own thread with a sensible title and details of your problem ?