Limiting a String length

Projects Programming
1

im collecting data from bluetooth, and it works... 85% of the time.

the bluetooth app sends data configured to be 1,2,3 > 97, 98, 99

the results should always be a 1, or 2 digit number, but every so often, when i send the data it kind of collects and then when the bluetooth does receive, all the data is clumped together.

whilst this isnt affecting the running of the program, how can i truncate the data, losing everything after a 2 digit maximum?

 ready 
 ready 
String: 1
String: 2
String: 0
String: 99
String: 5633562
String: 0
String: 0
String: 1
String: 1
String: 0
String: 1
String: 0
String: 1
String: 0
String: 2
String: 2
String: 99999999

bluetooth.listen(); 
while (bluetooth.available() > 0) {
    char inChar = bluetooth.read();
        if (isDigit(inChar)) {
      inString += (char)inChar;
    }
    if (inChar == '\n') {
    Serial.print("String: "); Serial.println(inString.toInt());
    program=inString.toInt();
      inString = "";
    }
  }
bluetooth.flush();

Moderator edit: corrected thread title.

2

Perhaps you are flushing the line terminator. Try it without the bluetooth.flush().

If you have any delays or loops in the part of the sketch you didn't show you may be overflowing the buffer.

Does the bluetooth.listen() mean that sometimes you aren't listening? Couldn't you be missing some line terminators when you aren't listening?

3

If the sender is wrong (as you say) you should fix the sender. And at the receiving end you should throw away the data.

@johnwasser
as far as I know flush is only used to flush outgoing data, so it should not affect the receive and (to OP) is therefore not needed at all if you are not sending data.

4

as far as I know flush is only used to flush outgoing data

For the HardwareSerial class, that is true.

For the SoftwareSerial class, flush() does nothing.

5

how can i truncate the data, losing everything after a 2 digit maximum?

if(inString.length() > 2)
  inString[2] = '\0';
6

PaulS:

if(inString.length() > 2)

inString[2] = '\0';

Legend! I knew it would be easy!

To address the others :slight_smile:

I can't affect the output from the app in the phone (sender) I can change what is being sent (the specific code) but in case of failure / non sent / non read etc I simply can't.

I added Bluetooth.flush as a later addition. I have the same issue without it being there. It however did nothing to the code / result.
However flushing excess data seems like the right thing to do. If I've already taken what I need, what's the point keeping it.

And yes, there are many many interrupts in the rest of the code that deeply affect the serial. However as long as I keep the data sent under 2 characters it works ok. 1 character works fine, 2 is fine 85% of the time, 3 is glitchy 85% of the time.

This truncating is a workaround to reduce the number of funky results.

In theory, when the app / system mucks up, and you press button 56 once and it doesn't work, you press it again, and again, and will then send 565656. The system reads it eventually and reports back that 565656 is not allocated and does nothing. This truncating will chop the 565656 to 56 and run program 56.

It's not perfect, but it'll kinda do.

Thanks all

7

It however did nothing to the code / result.

void SoftwareSerial::flush()
{
  // There is no tx buffering, simply return
}

Wonder why that seemed to do nothing.

However flushing excess data seems like the right thing to do.

But flush() is NOT how to do it. "flushing excess data" and dumping random amounts of unread data are NOT the same thing.

I find it difficult to believe that any intelligent application is not sending some kind of start of packet marker and some kind of end of packet marker. What I suspect is more likely is that you do not recognize them as such.

8

PaulS:

void SoftwareSerial::flush()

{
  // There is no tx buffering, simply return
}



Wonder why that seemed to do nothing.
But flush() is NOT how to do it. "flushing excess data" and dumping random amounts of unread data are NOT the same thing.

I find it difficult to believe that any intelligent application is not sending some kind of start of packet marker and some kind of end of packet marker. What I suspect is more likely is that you do not recognize them as such.

point taken!