Serial port data transmission


I am trying to send data to my GPS/GSM device using the serial port. My code that reads serial input works just fine if i enter the data manually using windows hyperterminal (data is properly read and processed).
I have another device(device X :slight_smile:) that generates some data and will send it to the GPS/GSM device by the serial port. This device is working properly(if i connect it to a PC i can see the data no problem) , generating new data every 2 seconds.
If i connect these two devices using the serial port no data is received by the GPS/GSM device. I’ve setup so that the RX from device X connects to pin no 2 (TX), TX from device X connects to pin no 6(Rx) and to pin 9 i’ve connected the GND. (baud rates used are the same for both devices)
So everything seems to be ok just that the two devices don’t communicate.
What am i doing wrong?


And don’t forget that the modems use hardware flow control (at least RTS/CTS) by default.

ciao, Dave

Ok sot let see if i understood right.

I need to set TX to TX and RX to RX, GND to GND.

And then i have two options:

  1. connect RTS to CTS and DSR to STR
  2. set AT+IFC=0,0

Will any of this interfere with using GPRS and GPS? Or updating the software by serial cable connection to PC’s hyperterminal?

Only the serial port is affected.

Hardware flow control is required for this.

Solution one does the trick . Thanks guys :slight_smile:

No. Just use Xmodem-CheckSum if hardware flow control not used by you.


The Wavecom implementation does require hardware flow control!

I know that’s daft, and it shouldn’t be so - but that’s Wavecom for you!

You might get away with it with 128-byte XMODEM, and with small downloads using 1K-XMODEM, but large downloads (over ~56K?) will fail with 1K-XMODEM unless hardware flow control is used.

Search for previous discussions…

This choice is a matter of taste: useless declaration from the book or personal experience. I prefer practice proven solutions and CheckSum-ĐĄmodem never let me down (on different modules and download sizes), which I cant say about 1K-Xmodem.

It really shouldn’t be necessary to use hardware flow control at all with any form of XMODEM, since XMODEM is inherently “self-paced” - ie, the sender cannot send the next block until the receiver has indicated that it is ready by acknowledging the previous block.

Unfortunately, Wavecom have not taken advantage of this to pause the transfer while the module is doing a flash block erase. :unamused:

The point is that the module stalls the transfer while it does a block erase of the flash - and it relies upon hardware flow control to do this.

With 128-byte XMODEM blocks (ie, “XMODEM checksum”?) - because the block is so small - you are just lucky to “get away with it” during these stalls; but with 1K-XMODEM, you don’t.

See: and linked threads for more details.

I’m not just lucky :slight_smile: Some form of sinchronisation surely exist, pauses at specific places clearly visible during transfer.
Maybe RX buffer size equal or close to 1K and can’t receive one additional 1K block, already requested. But for 128 bytes there is plenty of space. And, ATTENTION, now download processor wait for flash operations to complete and anly after that requests next block.

I think you are! 8)

Yes - it’s called hardware flow control!

awneil, you’re awesome. :wink: Lavabo manus meas.

This does appear to be fixed now: I’ve just successfully updated a WMP100 from R73a to R74a and then to R7.46 using just a 3-wire link - ie, no flow control (other than the inherent pacing of the XMODEM protocol itself).


However, I would still prefer to use harware flow control if at all possible - “belt and braces”