Serial Getting Garbage Data with real data

Question

I have made an app in VS2015 C#.Net which sends data to Serial port. The data i am sending is:

stat>temp:39,38,;load:17,4,42,;fans>50,50,;

Where as I am receiving:

ððððstat>temp:39,38,;load:17,4,42,;fans>50,50,;

What I have tried:

• Set SerialPort Encoding to ASCII in C#
• Set SerialPort Encoding to UTF8 in C#
• Set SerialPort Encoding to Default in C#

All have no effect.

Some observations:

• When I send the data via Serial Monitor of Arduino there is no garbage data.
• When I send data via a USB to TTL converter via my App, no garbage. (This part confuses me more)

BAUD RATE IS: 115200.

This is the only thing I have not changed yet and I dont want to change this as the string length will increase over time. this is 43 bytes of data. It can grow to up-to around 64 or 100 bytes and that would take longer to send and even longer to read adding delays in functions that are already working before the serial interrupt.

Regards

• Milliways: The garbage is just that, it is noise sent and stored in the buffer before your application starts. You need to clear buffer, implement a delay or use a defined signal to identify the start of valid data. No amount of fiddling with encoding will change this.
• echo_salik: oh... how would i clear the buffer? I can implement the identification thing, but still a clear buffer should be implemented just for, well, clean buffers. hehe @Milliways
• echo_salik: @Milliways i should google before asking, but i though it wouldn't be that simple. Serial.flush()
• Visual Micro: C# Serial.DiscardOutBuffer() after opening the port in C# and before sending data.

Answer 1

The Arduino should read only whole lines (non-newlines until a newline). Discard the line if it doesn't start with "stat>".

This will make your program more robust and less likely to fail with bad input. Fixing the transmitting app instead still leaves your Arduino vulnerable.

Consider the rule of thumb for serial communication: "Be restrictive in what you'll transmit; be lax in what you'll receive." Specify your communication protocol (e.g. "Packets will begin with 'stat>' and end with <newline>", maximum length of a packet, formats of variables and numbers, etc.). Then write your sender to hold as tightly to the spec as possible and write your receiver to accept whatever minor variations in otherwise good packets, that won't cause you to mistakenly accept bad ones. This principle will make your communications systems more robust and easier to get working in the first place.