I have a CNC milling machine based on GRBL. The machine works perfectly and I want to make an external display for showing the actual machine position.
The GRBL Arduino is connected with USB to my computer and sends continously some data through the GRBL Arduino TX pin. I can see this data in my computer program ' Universal Gcode Sender'.
I have connected a second Arduino to the TX pin of the GRBL Arduino. I want the same incoming data to be visible in the second Arduino's Serial Monitor.
At this moment the incoming data is simular but not exactly the same. The data is filled with some mirrored question marks.
Can you help me to fix this problem?
I checked and tried different baudrates (except the GRBL baudrate). I also try to minize the amount of Serial.println() by adding a counter, see script.
#include<SoftwareSerial.h>
SoftwareSerial SUART(13, 3); //SRX = DPin-2; STX = DPin-3
int i = 0;
String val = "";
void setup()
{
Serial.begin(9600);
while(!Serial){} // Loop until USB is ready
SUART.begin(115200);
}
void loop()
{
if (SUART.available() > 0) //a charctaer has arrived; it has been auto saved in FIFO; say 1 as 0x31
{
char x = SUART.read(); //read arrived character from FIFO (say 1) and put into x as 0x31
val += x;
i = i+1;
}
if(i>20) {
Serial.println(val); //send 0x31 to Serial Monitor to show 1 via UART Port
i = 0;
val = "";
}
}
I think the problem is that SoftwareSerial doesn't work well at 115200, especially when you are forwarding the characters at 9600. Try using 115200 or higher on Serial.
Thanks John. I just tried Serial.begin() with 115200 and 230400. It gives the same result as seen in the start post print screen.
In my script I combined multiple characters to one Serial.println(). Therefore, I think there is a issue on readout the data or maybe something with non viewable data.
If a faster output rate doesn't help, I think the problem is with SoftwareSerial not working well at 115200 baud.
I wonder if it is a baud rate mismatch outside the 10% tolerance? Try 110200 and 120200 on SoftwareSerial. With luck, shifting the baud rate by about 5% will get you a better match.
I am having a similar issue trying to connect a nano and an esp-01. Most characters do come through, but occasionally I'll have some reversed question marks or lost characters. Also, it's hard to tell, but I think that the data corruption happens from the esp's Serial Tx to the nano's software serial Rx, but not the other way around.
To make sure I'm understanding correctly, should the baud rate of the software serial on the nano be different from the esp's? I have tried a wide range of baud rates, from 300 to 115200, and my problem persists, but I have always matched the baud rates of the two devices.
Anybody who gets software serial to run at more than 38400 is probably lying or kidding themselves.. There is a possibility that the ESP works better with software serial, but that doesn't alter the fact that a Nano is a plain-vanilla Arduino. You will be a lot better off sticking rigorously to 9600 baud on both, reasonably secure in the knowledge that it will actually work, and certain that you will thereby cause no confusion here.
You may find that the real problem has little to do with baud rate and quite a lot to do with serial input procedure.
Similar in that characters are often dropped or come through as the backwards question marks when using software serial on the nano. I have mostly stuck with 9600, because higher baud rates typically make things worse. I was just trying to determine what exactly the OP had done to get his setup working. Or, if software serial is going to continue being an issue, I'm probably going to just move away from a nano/esp-01 combo and just use an esp32.
I followed the serial input basics guide that you linked when writing the code. I use brackets to indicate when a message has started and ended, writing char by char into a buffer. Again, the messages mostly come through, but it's only occasionally that a character is dropped or misread.
My problem is that I was also running the FastLED library while trying to use SoftwareSerial. Hardware worked better (no backwards question marks) but still dropped characters with too many LEDs.
