Using this ascii chart: upload.wikimedia.org/wikipedia/commons/d/dd/ASCII-Table.svg

I can see that when you receive a Distance, you are getting the value followed by cm and a carrage return and a line feed. so "\r\n"

You get the same EOL for your errors, so you should be able to use the Serial In Watcher - Text actor with a EOL of 13. You can use this same msg:string={00-FF} to allow all character thru.

Here's what you had:*

*I think it is anyway. I cannot tell if you had
"Serial.printIn" with an upper-case "i" (incorrect)
or
"Serial.println" with a lower-case "L" (correct)

#include <SoftwareSerial.h>
SoftwareSerial mySerial(11,10); // RX, TX
unsigned char data[4]={};
float distance;
void setup()
{
    Serial.begin(57600);
    mySerial.begin(9600);
}
void loop()
{
    do{
    for(int i=0;i<4;i++)
    {
    data[i]=mySerial.read();
    }
    }while(mySerial.read()==0xff);
    mySerial.flush();
    if(data[0]==0xff)
    {
    int sum;
    sum=(data[0]+data[1]+data[2])&0x00FF;
    if(sum == data[3])
    {
    distance=(data[1]<<8)+data[2];
    if(distance>30)
    {
    Serial.print("distance=");
    Serial.print(distance/10);
    Serial.println("cm");
    }else
    {
    Serial.println("Below the lower limit");
    }
    }else Serial.println("ERROR");
    }
    delay(100);
}

I'm unable to trouble-shoot your code myself, but I've had success troubleshooting JavaScript Code with ChatGPT, so here's what it said about your code:

Issues Identified:

1. Incorrect Use of mySerial.read() in the do...while Condition:
   1. The do...while loop reads an extra byte with mySerial.read() in the condition. This might lead to unexpected behavior as it consumes a byte that is not being processed.
2. mySerial.flush() Usage:
   1. mySerial.flush() in SoftwareSerial does not flush the input buffer; instead, it waits for outgoing data to finish transmitting. Using it here is unnecessary.
3. Handling mySerial.read() Return Values:
   1. mySerial.read() can return -1 if no data is available. This needs to be checked before assigning the read value to data[i].
4. Hardcoded Limit Check:
   1. The condition distance > 30 is hardcoded. If this is a threshold specific to the application, it would be better to define it as a constant for clarity.
5. Lack of Non-blocking Delay:
   
   1. The delay(100) call blocks further execution, which can be problematic if the loop needs to process data continuously or in real-time.

#include <SoftwareSerial.h>
SoftwareSerial mySerial(11, 10); // RX, TX
unsigned char data[4] = {};
float distance;
const int LOWER_LIMIT = 30; // Define threshold as a constant
void setup()
{
    Serial.begin(57600);
    mySerial.begin(9600);
}
void loop()
{
    // Ensure enough data is available before proceeding
    if (mySerial.available() >= 4)
    {
        // Read 4 bytes into the data array
        for (int i = 0; i < 4; i++)
        {
            int byteReceived = mySerial.read();
            if (byteReceived == -1) return; // Exit if no valid data is read
            data[i] = byteReceived;
        }
        // Check the first byte for the expected header
        if (data[0] == 0xFF)
        {
            // Calculate checksum
            int sum = (data[0] + data[1] + data[2]) & 0x00FF;
            if (sum == data[3]) // Validate checksum
            {
                // Calculate distance
                distance = (data[1] << 8) + data[2];
                if (distance > LOWER_LIMIT)
                {
                    Serial.print("Distance = ");
                    Serial.print(distance / 10.0); // Divide by 10 for decimal result
                    Serial.println(" cm");
                }
                else
                {
                    Serial.println("Below the lower limit");
                }
            }
            else
            {
                Serial.println("ERROR: Checksum mismatch");
            }
        }
    }
    delay(100); // Optional: Use millis() for non-blocking delays if needed
}

(Personally I'm not sure about the "</SoftwareSerial.h>" in the last line, so if this code doesn't run, try it with the last line as just "}".)

Claude said similar, but not identical things:

1. Error Handling in Serial Reading:
   1. mySerial.read() returns -1 if no data is available, which might cause unexpected behavior
   2. The current do-while loop may get stuck if no valid data is received
2. Checksum Calculation:
   1. The checksum calculation looks correct, but ensure the sensor protocol matches exactly
   2. The &0x00FF might be unnecessary if you're using standard 8-bit arithmetic

Key changes:

• Check mySerial.available() before reading
• Use bitwise OR | instead of addition for distance calculation
• Added decimal to distance division for float precision
• Simplified error handling

Potential debugging steps:

1. Verify sensor protocol matches this exact format
2. Check physical connections
3. Use Serial Monitor to verify data reception

#include <SoftwareSerial.h>
SoftwareSerial mySerial(11, 10); // RX, TX
unsigned char data[4] = {};
float distance;
void setup() {
    Serial.begin(57600);
    mySerial.begin(9600);
}
void loop() {
    if (mySerial.available() >= 4) {
        for (int i = 0; i < 4; i++) {
            data[i] = mySerial.read();
        }
        if (data[0] == 0xFF) {
            int sum = (data[0] + data[1] + data[2]) & 0xFF;
            if (sum == data[3]) {
                distance = (data[1] << 8) | data[2];
                if (distance > 30) {
                    Serial.print("Distance = ");
                    Serial.print(distance / 10.0);
                    Serial.println(" cm");
                } else {
                    Serial.println("Below lower limit");
                }
            } else {
                Serial.println("Checksum error");
            }
        }
    }
    delay(100);
}

Since it appears your EOL is causing the buffer to fill, you could try not using Serial.println() to automatically add a EOL (end of each text  segment), and instead use Serial.print("\r") to add an EOL that you have control of. Often "\r\n" are used, these correspond to the ASCII values 13 (CR) and 10 (LF), in this case we only need to add/find "\r" or value 13

EOL = 13, sets the actor to look for a carriage return (13). 
You can learn a bit about using these here: newline - Difference between \n and \r? - Stack Overflow

Once you are adding your own EOL, you can makes changes and test in Isadora until you get the output you are expecting.

Might be most helpful to copy and paste the code than an image we can't copy the code from..? maybe upload a text file with it if thats possible?

The videos if data being 'recived' was with using the serial in watcher - binary 

No code changes with arduino 

Well, according to the error message your EOM character is not 13. Could you share the Arduino code with us?

hi thanks for the suggestion, I'm not sure how this actor works as the error message above is when I tried the text actor, I wasn't receiving any indication that data was being received by this actor other than the error above popping up every minute or so? The message received part of the actor wasn't even triggering unlike the digital actor witch seemed to trigger this section.

Looking at your messages, I think you should try the 'Serial In Watcher - Text' actor.

@juriaan here are some screen recordings from both Arduino and the results i am getting in Isadora- this is using the binary watcher

The question after that Is the following:

- What is the format of your message; since the Isadora actors can only 'sent' a message to the actor out, if it has been specified what the format is. 

If you double click a 'Serial In Watcher - Text'' or a  'Serial In Watcher - Binary' you will an empty text window. According to the help dialog (press the help button) you will see exactly what format is being required for all the different types of data that Isadora supports. It is up to you now to define the amount of bytes, characters or numbers that you expect, and how that is message is being 'terminated'

Feel free to showcase us how the data comes in in the Arduino IDE, and happy to help you out :)

Hi there, a couple different things here really:

1) When a port is 'Busy' be opening the Serial monitor (From the Arduino IDE) it causes Isadora not to be able to see it, please close this and 'restart' the Arduino to your computer

2) Make sure that you setup your Serial ports in the Serial Port Setup window. The important thing is the 'Port' (Device in Isadora window) and the 'Baud rate' (Speed in the Isadora window). Speed has to match the speed that you wrote down in your setup function within the Arduino IDE

3) Now that we got everything setup we need to start our serial devices, you can simply do that by going to Enable Serial Ports, underneath the Communications menu.

After that you should be able to see messages from your Serial device in the Windows > Show Monitor tab