Siemens Mux_guide_v06 manual RTS/CTS on the logical channels, Com M Com N Com P Rts/Cts

Page 15

Multiplexer User's Guide

Confidential / Released

s

mobile

RTS/CTS on the logical channels

The customer application needs to regulate the data flow according to the logical flow control. The implementation of the WinMux2k is a good example. It maps the 3 decoded channels to 3 serial interfaces as well as the logical flow control information (FC-BIT in MSC message) directly on the RTS/CTS-control lines.

In this case CTS superposes the STOP information (data sending disabled) sent by the module to control the data transmission from the customer application to the module. If RTS is reset, a STOP is transmitted to the module to control the data transmission from the module to the customer application. Figure 2 illustrates the data flow.

COM M

COM N

COM P

RTS/CTS

RTS/CTS

RTS/CTS

Controller

 

(maps RTS/CTS of

 

the unframed

 

channels to log. FC)

 

Multiplexer

ser

Protocol

IO

GSM 07.10

 

TE

 

Customer application

 

(WinMux2k)

 

 

 

CSD

 

 

Channel 1:

 

Multiplexer

RTS/CTS

ser

 

Protocol

 

IO

 

GSM 07.10

Channel 2,3:

 

 

 

RTS

 

 

(/CTS)

 

 

AT

MS

 

Interface

Module

 

 

HW flow control

logical flow control (FC) Flow control between the applications

Figure 2: Logical flow control and RTS/CTS signaling behind the decoder

RING/DCD

Unlike all other lines DCD and RING are transmitted additionally on the UART directly by the module. These signals are logical ORs from the three logical channel status lines. However, the customer application must carefully decide how to handle these lines and ensure, that no conflicts occur between the different channels. E.g. in some situations it may be advisable to display RING on channel 1 only.

Please keep in mind that a call can be accepted on one channel only. Therefore some kind of mutual locking mechanism must be used.

Mux_guide_v06

Page 15 of 36

30.06.2004

Image 15
Contents Siemens Cellular Engines Version DocID Muxguidev06Muxguidev06 Document Name Multiplexer Users GuideMultiplexer Users Guide June 30Contents Multiplexer protocol version control TablesDocument history Chapter What is newIntroduction References Supported products and related documentsAbbreviation Description Term and abbreviationsProduct concept and architecture Multiplexer protocol an overviewVirtual channels and AT commands Restrictions CharacteristicsIntegrating multiplexer into the customer application Basic requirementsFunctions without channel dependencies Timing conditions RTS/CTS on the physical channels Multiplexer control and signaling linesFlow control Logical flow controlCOM M COM N COM P RTS/CTS RTS/CTS on the logical channelsPower saving Bandwidth of logical channelsEscape sequence Structure of the multiplexer protocol Introduction of the multiplexer protocolData link layer Address field Flag sequenceFrame Type Control fieldBit Length indicatorInformation field Frame checking sequence field FCSState diagrams Relationship between the customer µC and the GSM engine µC AT+CMUX Serial Interface Customer GSM engineCustomer µC Serial interfaceResponder CustomerEngine GSM engineType field Close-down procedureDLC release Multiplexer control channelTest command Test Multiplexer close down CLDLength field Modem status command MSC Break signal optional Bit Not supported Value octet Length=1 Bit Power saving control PSCCommands Bit Description Type BitNo Value octet Length=0 Non-supported command response NSCValue octet Bit Command Type Non-supported commandAT+CMUX Customer GSM engine µCIntroduction Multiplexer protocol version controlMultiplexer protocol versions Modem status command MSCSignals Break Signals Octet Optional Command Bit Signals BitImplementing version control TroubleshootingExample of TestCommand message Coding of TestCommand message