Hi folks,
i'm trying to read 5 bytes coming from a Python script via Serial, the value of the bytes is a number between 0 and 180, until the value of the bytes is <127 everything works fine but after that i get an extra byte of value =194 in between the actual bytes i need.
I'm Reading in bytes as unsigned char.
So for example:
sent bytes = 127 127 127 127 127
received bytes = 127 127 127 127 127
sent bytes = 128 128 128 128 128
received bytes = 194 128 194 128 194
sent bytes = 180 180 180 180 180
received bytes = 180 194 180 194 180
ecc ecc
Here's the Code:
#include <Servo.h>
Servo s1;
Servo s2;
Servo s3;
Servo s4;
Servo s5;
int las1 = 2;
int las2 = 3;
int las3 = 4;
int las4 = 5;
int las5 = 6;
const unsigned int maxLen = 5;
unsigned char frame[maxLen];
int posArray[maxLen];
static unsigned int frame_pos = 0;
unsigned char inByte;
void setup()
{
Serial.begin(115200);
s1.attach(9);
s2.attach(10);
s3.attach(11);
s4.attach(12);
s5.attach(13);
pinMode(las1,OUTPUT);
pinMode(las2,OUTPUT);
pinMode(las3,OUTPUT);
pinMode(las4,OUTPUT);
pinMode(las5,OUTPUT);
}
void loop(){
while (Serial.available()>0){
inByte = Serial.read();
if (inByte != '\n' && (frame_pos<=maxLen-1)){
frame[frame_pos] = inByte;
frame_pos++;
}
else {
for (int i = 0; i<maxLen; i++){
posArray[i] = int(frame[i]);
Serial.write(frame[i]);
Serial.print(" ");
}
Serial.println("");
s1.write(posArray[0]);
s2.write(posArray[1]);
s3.write(posArray[2]);
s4.write(posArray[3]);
s5.write(posArray[4]);
frame_pos=0;
}
}
}
What is this unwanted Byte 194 and why is it there?
Sorry if it is a simple error but i haven't fully undestood the relation between ASCII or unicode ,
hopefully a good soul can help me on this one
Thanks a lot to everybody, and have a great Day!
I actually switched to Serial.write() to check what was the weird char, with the serial print gives me the decimal value of it, the char is Â, thank you for your answer
194 is C2 hex. UTF-8 encodes codepoints 80 through BF as C2 followed by the codepoint. Looks like oqibidipo may be right—it seems the Python code is somehow interpreting a raw value (e.g., 0x80) as if it's a character codepoint and then sends it over serial in UTF-8.
Does python insert chr$(0x20) or does it insert so if it inserts multiples of the character in question, they are treated as multiple spaces (in the case of ) rather than ignoring multiple inserts of chr$(0x20)?
i'm sending the bytes from TouchDesigner Serial OP.
i'm actually sending chatacters obtained with the chr() python function.
the aactual code is like that:
op('serial1').sendBytes(chr(int(op('OutPos')[0])),chr(int(op('OutPos')[1])),chr(int(op('OutPos')[2])),chr(int(op('OutPos')[3])),chr(int(op('OutPos')[4])))
i've also tried sending a String with the 5 character concatenated using the str() python function.
but i get the same results.
When it comes to UART communication, here what I think is important to check:
is UART 7bit with Parity? Is any side (sender or transmitter) assuming bit 7 is Parity?
It can be also the host: when it sends ASCII code - which is just 7bit - it might lock OK when receiving characters 0..127 but it fails with >= 128
If Receiver would assume "with parity" - actually it should fail very often. But if Rx is 8bit, but Tx is with Parity (bit 7) - it works most of the time, except for >= 128 as code
I would assume: your Python UART transmitter is not configured in the same way as receiver (MCU). Make sure: same Parity-Mode or not, same 8bit, sometimes also no HW or SW flow control protocol (with SW flow control you can see additional characters like CTRL-S and CTRL-Q inserted).
UNI-Code: good question: actually 8bit vs. 7bit, Uni-Code can be also a 16bit value for any character. If so: it would fail so much (UART is just 7 or 8bit, never 16bit).
Check also number of Stop Bits expected: if MCU needs two but host sends just with one Stop Bit: you might get corrupted characters.
Why not writing a test program? Send any ASCII Character, from 0 to 127 to 128 to 255: if all characters are received (in an incrementing loop) - you would know the "physical UART link" is OK.