Your other terminal that you failed to mention is bogus (or does not support UTF8 if you are sending 2 bytes data)… if you print a string, the characters are sent as they are….
show a complete compileable sketch only printing your hello.
show a screenshot of what you receive in your still unknown "monitor software" with exactly this sketch.
Use a different serial monitor. For example coolterm from [url]https://freeware.the-meiers.org/[/url]
Post a link to the program, please. I'm not familiar with it but it seems to show what has been sent (IRP_MU_WRITE), not what was received.
I often use Realterm; it allows you to display the received values in HEX. CoolTerm might also have that option. That way you can exactly see what is received.
0d is part of the line-ending (it's the Carriage Return); Serial.println adds 0x0D (Carriage Return) as well as 0x0A (Line Feed).
I’ll chime in with the others. The Serial class will send the bytes just as they are and It’s by the very own serial nature that (bits of the) bytes are sent one after the other. It would make no sense to inject anything in between bytes.
Show the same screenshot when data is sent by Arduino.
Your monitor is NOT a usual serial Monitor like the one of the Arduino IDE. It is a debugging tool for serial lines.
It's the problem of a device. Though it doesn't affect anything. So I blamed "separate" messages wrongfuly.
The problem is that PC is very fast. It can send a lot in a very short period of time. So in my "special COM monitor" these messages were shown as one ("Hello"). I sent "Hello" both from .NET Core app and Arduino monitor. All messages from PC were "Hello".
"Special COM monitor" is faster than ESP32 + usb/com cable. That's why ESP32 sent "H-e-l-l-o" instead of "Hello".
I thought that was the cause of device not responsiveness. I was wrong.
Sorry for wasting your time.
The right answer: to send raw data one should use "Serial.print()"