[ANSWERED] Sending data from Arduino to Isadora

Skulpture

@dusx wonder if you might be able to help? We have data coming into Isadora via the serial monitor but we can't figure out the serial actors and how to view the numbers.

Juriaan

@ravenetta

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

Juriaan

@ravenetta

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

Ravenetta

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

Ravenetta

@juriaan this is the message i receive if i use the serial watcher- text actor this happens after about a minute, the actor itself does not show any signs of receiving data, once i have this data accurately coming into Isadora the plan is to have this data be able to be readable within the soft wear so i can send these values to edit brightness of content based on the distance of a person.

DusX

@ravenetta

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

Ravenetta

@dusx

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.

Juriaan

@ravenetta

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

Ravenetta

@juriaan this is the current code I have in the arduino the error message above was when using the serial in watcher - Text

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

No code changes with arduino

skuven

@ravenetta

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?

DusX

@ravenetta

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.

Woland

@ravenetta @skuven

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:

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.
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.
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].
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.
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:

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
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:

Verify sensor protocol matches this exact format
Check physical connections
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);
}

Ravenetta

@woland @Juriaan @DusX here is a video i have of the full set up i am doing in isadora at the moment, i now have the data i am looking or coming in at the end as you can see, however this data does not keep receiving for an extended period as you'll see if you skip to the end of the video, the actor also now shows no indication that it is receiving input? i have used "msg:string={00-FF}" within the actor itself and from using the code suggested above the speed is now 57600 instead of 9600

DusX

@ravenetta

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.