Usb Modem Is Echoing Back Wrong Characters

Identify the cause of \r artifacts when reading from a serial terminal?

Reading between the lines, you are running something like a Linux shell on your embedded device.

This will have the same set of Linux app/TTY/driver hierarchy as your host and is defaulting to cooked mode processing of the input that it receives from your application. This is why running the command to change the number of columns (on your embedded application) works. It is telling the line discipline in that device to treat the screen as being 200 columns wide (and so the line-editing logic doesn't need to split the line).

Switching to raw input on both your host and embedded shell should fix it.

If you'd like to know more details of how Linux terminals handle input (and echoing of input back to the output stream), see https://www.linusakesson.net/programming/tty/

reading from serial port always returns what was written

I learned a lot from everyone's answers and am grateful for them because I will need them as I move on with this project. For this particular case, however, the issue ended up being permissions. Yep, file permissions on ttyGSO.

I completely expected a permission denied error from open and never got one, so I never considered the possibility. Especially since I opened the files in RDWR mode, I could write to the serial file, and it appeared I was reading data (although the same data) it never dawned on me that perhaps I didn't have read permissions.

DB9 Serial communication

You have the echo option enabled in your terminal emulator program, so what happens you send the character, your terminal emulator prints it on the screen and at the same time the modem at the other end echos the character back to you so you see it twice.

However, since the mode only gets the character once, it is fine for it.

It's basically a cosmetic problem really. You can fix it if you want by turning off the ehco characters option in your terminal emulator program

Linux cdc_acm device - unexpected characters sent to device

The ^@^@^@^A string which is sent to your device is the result of echo performed by the terminal subsystem in the kernel in response to incoming bytes from your device.

This line in your log:

Feb 13 18:14:32 localhost cpcenter: df046a80 3672670191 C Bi:3:006:4 0 4 = 00000001

actually means that your device sent 4 bytes to the computer (Bi means “Bulk endpoint, input”). By default all terminal devices have echo enabled, therefore the kernel echoes those bytes back to the device, but because those bytes were in the control character range, they are echoed in the escaped form: ^@^@^@^A. Those echoed bytes are also sent in separate 1-byte write calls, which corresponds to 1-byte bulk out URBs in the subsequent log.

You need to fix your test program so that it turns off echo and other tty processing before trying to communicate with your device. The cfmakeraw() function can be used for this if your test program is in C/C++.

The program might be working in Ubuntu just because some other program happens to touch the port before your test program and change the port settings to turn off echo.

.NET SerialPort class with USB modem on Windows 10

Turns out I just need to dig harder.

I come across this page and find the solution

What I did wrong:

The port initialized is not using the right encoding.
The NewLine characters \r\n is not properly escaped.

The correct way

ModemPort.DtrEnable = True
ModemPort.Handshake = Handshake.XOnXOff
ModemPort.NewLine = Chr(13) + Chr(10)
ModemPort.Encoding = System.Text.Encoding.ASCII

The modem is able to reponse

ATZ
OK

If you do not want the "ATZ" echo, use the "ATE0" with "AT" command. "ATZ" will reset ATE0.

C#: COM port, GSM device just sending back what I send him

Have you communicated to it with PuTTY? You should first try to send and receive data from a terminal application (PuTTY Download Link) to rule out any issues with the modem itself, then move on to writing an application to communicate.

As for the code, you should be using sp.WriteLine instead of sp.Write... The modem needs to see a newline character to know your command is finished. You can set the newline character by using sp.NewLine so that it matches what the modem needs to see. Alternatively, you can just append '\r' to any AT command you are writing.

The GSM modems I have used all have echo on by default, you can disable echo by sending 'ATE0' to it. While echo is on, the modem will first echo anything you send it, then it will send it's response. I suspect you are seeing the echo come back but not the response, due to the way you are reading the data. Try this method for reading the data:

//add this just before opening the port
sp.DataReceived += new 
    SerialDataReceivedEventHandler(port_DataReceived);

Add the following method outside the method you are setting up the port:

private void port_DataReceived(object sender, SerialDataReceivedEventArgs e)
{
  Console.WriteLine(port.ReadExisting());
}