Bytes are left in hardware buffer

Feb 26, 2013 at 2:43 PM
When I write single AT command to GSM modem and receive response using DataReceived event, it appears that this response stays in hardware output buffer. If I change AT command string and run application again, previous response is returned. I am using WriteLine method for writing and ReadExisting method for reading.
Coordinator
Mar 28, 2013 at 6:45 AM
ondrej wrote:
When I write single AT command to GSM modem and receive response using DataReceived event, it appears that this response stays in hardware output buffer. If I change AT command string and run application again, previous response is returned. I am using WriteLine method for writing and ReadExisting method for reading.
GSM modems have an "Echo" mode. You need to ensure you disable this with ATE0 for reliable communication. How is your modem attached to the computer? Via serial, USB? What driver is being used?
Mar 28, 2013 at 7:04 AM
jmcurl wrote:
ondrej wrote:
When I write single AT command to GSM modem and receive response using DataReceived event, it appears that this response stays in hardware output buffer. If I change AT command string and run application again, previous response is returned. I am using WriteLine method for writing and ReadExisting method for reading.
GSM modems have an "Echo" mode. You need to ensure you disable this with ATE0 for reliable communication. How is your modem attached to the computer? Via serial, USB? What driver is being used?
It is attached via USB and I am using USB to serial converter, so I connect to virtual COM1 port. I will try that ATE0 command, I did not know about echo mode and how it works.
Coordinator
Mar 28, 2013 at 3:50 PM
When you've performed your tests, please look at the page TraceSwitch Settings. Use this configuration and send the log files. This will help me identify any issues. Do you set up any hardware flow control?
Mar 28, 2013 at 8:34 PM
jmcurl wrote:
When you've performed your tests, please look at the page TraceSwitch Settings. Use this configuration and send the log files. This will help me identify any issues. Do you set up any hardware flow control?
_serialPort.DtrEnable = True
_serialPort.RtsEnable = True
Coordinator
Mar 29, 2013 at 6:53 PM
Edited Mar 29, 2013 at 6:54 PM
Any reason why you set the pins explicitly? Try setting to turning off RtsCts flow control (the RTS pin should indicate to the GSM terminal it can send when off). Also, are you using a PL2303 chipset? If so, then have a look also at the documentation Hardware Compatibility. This problem didn't occur with a 16550A UART or a USB/SER bridge based on FTDI.

You could try compiling the source and running the unit test cases just to make sure there are no driver issues.
Mar 30, 2013 at 9:26 PM
I am using this hardware: http://www.belkin.com/us/F5U409-Belkin/p/P-F5U409?q=::categoryPath:/Web/WSCBLS/WSCBLSMAP
I don't know what chipset it have. I have no particular reason for setting that properties to True, I was just trying different configurations.
Coordinator
Mar 31, 2013 at 8:10 AM
It appears to be a not very supported chipset, not based on PL2303 or FTDI, but rather see here. I'd recommend turning off flow control for first debugging. It should still work. Problems with flow control begin with high speed data transfer such as PPP and internet data transfer. Then when it works, set handshaking to Rts.
Coordinator
Jan 12, 2014 at 1:27 PM
ondrej wrote:
When I write single AT command to GSM modem and receive response using DataReceived event, it appears that this response stays in hardware output buffer. If I change AT command string and run application again, previous response is returned. I am using WriteLine method for writing and ReadExisting method for reading.
I saw your comment on the dotnetportal.cz site and reread my original answer. Another plausible explanation for bytes left in the hardware buffer is as follows:
  • You receive a DataReceived notification on the first byte that arrives back.
  • Documentation for ReadExisting states that it returns data that has been received in the buffer, so it's guaranteed to have only the first byte. Other bytes may not have arrived yet from the GSM modem.
You need to wait for another DataReceived event until all data arrives, or use the ReadLine()/ReadTo() method to read data up until a new line (or if a timeout occurs).
Jul 23, 2015 at 12:04 AM
Edited Jul 23, 2015 at 11:38 PM
One of the workarounds for the Prolific PL2303 chipset involves ignoring serial port receive events during pending read requests. When it begins listening again for those events, it may have already missed some. Although it looks like the workaround is for the specific chip, it is a build time option and changes the behavior of the IO thread regardless of the actual chip in use. The behavior I saw is similar to the one discussed here, with bytes of data left in the receive buffer until one or more bytes are received while the receive events are being monitored. I submitted patch 17708 for this.
Marked as answer by jmcurl on 8/1/2015 at 8:37 AM