Modem flow-control troubles

Go To Last Post
8 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello,

Having some problems communicating with a Simcom SIM300Z GPRS modem hooked up to a mega640 (low voltage logic levels, not RS232) and just wanted to double check with like-minded people that I've not got thing mixed up.

I can issue AT commands etc. quite happily when not attempting to do any flow control, so the modem is happy to talk it would seem. However, the modem's CTS line spends almost all of its time high (deasserted) no matter what I do with the RTS line so I cannot get hardware flow control to work properly.

When we're talking about logic level modem control signals, RTS low means the uC has data to transmit and CTS low means the modem is ready to receive. This is correct, yes?

When the modem is initialising it transmits the unsolicited response "Call Ready" to the uC. When it does this, CTS goes low briefly. Does this sound as if the modem's CTS line might be non-inverted (i.e. active high instead of active low)?

The datasheet for the modem inconsistently refers to the CTS line as CTS and /CTS and says nothing about the exact operation of this line, which is really helpful! :evil:

Anyway, if someone could confirm that my thoughts are correct or not, I'd be grateful.

Matt.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

MattBucknall wrote:
Anyway, if someone could confirm that my thoughts are correct or not, I'd be grateful.

If your thoughts are "It's a confusing mess" then yes, I can confirm your thoughts :-)

My most recent experience is with the following setup (using an FTDI module, which works with ordinary 5V or 3.3V logic levels):

PC <-USB-> FTDI <-RS232-> Micro-controller

There is an input on the FTDI module labelled CTS# and when this is at +5V then transmission of data from the PC to the micro-controller is inhibited. This is consistent with active low logic (which seems to be the significance of the #), and CTS being an acronym for "Clear To Send".

Quote:
Does this sound as if the modem's CTS line might be non-inverted (i.e. active high instead of active low)?

In my view the evidence points that way, yes.

Christopher Hicks
==

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The real question is why do you even need to use flow control? If it works without reliably, I would leave it like it is. Hardly anyone uses flow control anymore because it is such a kludge. ;)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

UNiXWHoRe wrote:
The real question is why do you even need to use flow control? If it works without reliably, I would leave it like it is. Hardly anyone uses flow control anymore because it is such a kludge. ;)

Agree - if you mean hardware RTS/CTS type flow control. Most every serial data system uses some sort of message level flow control or XON/XOFF. Those that don't are often ones with very low volume/infrequent messages.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Most every serial data system uses some sort of message level flow control or XON/XOFF. Those that don't are often ones with very low volume/infrequent messages.

"Most every"? Perhaps "most every" >>full-duplex<<. I think your statement breaks down quite rapidly when you just start to consider half-duplex systems.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My personal opinion on this is that if you are congesting up an asynchronous serial channel to the point it needs flow control, it is time to switch to a synchronous serial link. ;)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Agree - if you mean hardware RTS/CTS type flow control. Most every serial data system uses some sort of message level flow control or XON/XOFF. Those that don't are often ones with very low volume/infrequent messages.
That is not the impression I am under (not to say that I am right). In any case, I may well be forced to use software flow control. To not use any flow control at all would require me to makes all sorts of presumptions about buffer and packet sizes, which I'd rather not rely on.

Quote:
My personal opinion on this is that if you are congesting up an asynchronous serial channel to the point it needs flow control, it is time to switch to a synchronous serial link.
You are assuming that the modem will be able to transmit data over the cellular network at at least the same rate the host can send data to the modem. My experience with GPRS suggests that this is rarely the case! It will usually take a lot longer for the modem to transmit data over the cellular network than it will take for the host to send data to the modem which means the modem's buffer is likely to fill quite often. That's why I need flow control. I could slow the baud rate right down, but that won't make use of bandwidth when it is available.

Matt.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

UNiXWHoRe wrote:
The real question is why do you even need to use flow control? If it works without reliably, I would leave it like it is. Hardly anyone uses flow control anymore because it is such a kludge. ;)

The answer to this is obvious. If you're using a modem whose specification requires flow control and states "thou shalt not send data when my CTS output is inactive" then you'd better adhere to that, otherwise the design will not be reliable. The question as to why the modem designer decided to require flow control is for them to answer.

This is really just the same concept as encapsulation in software design. The interface specification is a contract between the parties on either side of that interface. If either side bends the rules of the contract then the system may not operate as desired.

CH
==