Sending data from Arduino to Isadora
-
Hi everyone just a quick one but I'm really struggling to get the distance information from an ultrasonic sensor and Arduino into Isadora, the code to make the sensor work has been clashing with the fermatter code so the Arduino add on for Isadora has not worked for me, the data is showing amazingly in the Arduino software itself with the serial port so i tried the serial watcher in Isadora however it hasn't even recognized inputs after adding the Arduino in the communications tab. any ways round this or advice would be amazing, thank you.
-
@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.
-
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
-
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 :)
-
@juriaan here are some screen recordings from both Arduino and the results i am getting in Isadora- this is using the binary watcher
-
@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.
-
Looking at your messages, I think you should try the 'Serial In Watcher - Text' actor.
-
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.
-
Well, according to the error message your EOM character is not 13. Could you share the Arduino code with us?
-
@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
-
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?
-
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) and10
(LF), in this case we only need to add/find "\r" or value13
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 OverflowOnce you are adding your own EOL, you can makes changes and test in Isadora until you get the output you are expecting.
-
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:
- 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:
- 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:
- 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:
- 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:
- 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:
mySerial.read()
returns -1 if no data is available, which might cause unexpected behavior- The current
do-while
loop may get stuck if no valid data is received
- Checksum Calculation:
- The checksum calculation looks correct, but ensure the sensor protocol matches exactly
- 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); }
- Incorrect Use of mySerial.read() in the do...while Condition:
-
@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
-
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.