G
APPLICABILITY TABLE
SW Versions
GE Family ( Embedded )
GE910-QUAD 13.00.xx4
GE910-GNSS 13.00.xx4
GE910-QUAD AUTO 13.00.xx6
Note: the features described by the present document are provided by the products equipped
with the software versions equal or higher than the versions shown in the table.
G
SPECIFICATIONS SUBJECT TO CHANGE WITHOUT NOTICE
Notice
While reasonable efforts have been made to assure the accuracy of this document, Telit
assumes no liability resulting from any inaccuracies or omissions in this document, or from
use of the information obtained herein. The information in this document has been carefully
checked and is believed to be entirely reliable. However, no responsibility is assumed for
inaccuracies or omissions. Telit reserves the right to make changes to any products described
herein and reserves the right to revise this document and to make changes from time to time
in content hereof with no obligation to notify any person of revisions or changes. Telit does
not assume any liability arising out of the application or use of any product, software, or
circuit described herein; neither does it convey license under its patent rights or the rights of
others.
It is possible that this publication may contain references to, or information about Telit
products (machines and programs), programming, or services that are not announced in your
country. Such references or information must not be construed to mean that Telit intends to
announce such Telit products, programming, or services in your country.
Copyrights
This instruction manual and the Telit products described in this instruction manual may be,
include or describe copyrighted Telit material, such as computer programs stored in
semiconductor memories or other media. Laws in the Italy and other countries preserve for
Telit and its licensors certain exclusive rights for copyrighted material, including the
exclusive right to copy, reproduce in any form, distribute and make derivative works of the
copyrighted material. Accordingly, any copyrighted material of Telit and its licensors
contained herein or in the Telit products described in this instruction manual may not be
copied, reproduced, distributed, merged or modified in any manner without the express
written permission of Telit. Furthermore, the purchase of Telit products shall not be deemed
to grant either directly or by implication, estoppel, or otherwise, any license under the
copyrights, patents or patent applications of Telit, as arises by operation of law in the sale of a
product.
Computer Software Copyrights
The Telit and 3rd Party supplied Software (SW) products described in this instruction manual
may include copyrighted Telit and other 3rd Party supplied computer programs stored in
semiconductor memories or other media. Laws in the Italy and other countries preserve for
Telit and other 3rd Party supplied SW certain exclusive rights for copyrighted computer
programs, including the exclusive right to copy or reproduce in any form the copyrighted
computer program. Accordingly, any copyrighted Telit or other 3rd Party supplied SW
computer programs contained in the Telit products described in this instruction manual may
not be copied (reverse engineered) or reproduced in any manner without the express written
permission of Telit or the 3rd Party SW supplier. Furthermore, the purchase of Telit products
shall not be deemed to grant either directly or by implication, estoppel, or otherwise, any
license under the copyrights, patents or patent applications of Telit or other 3rd Party supplied
SW, except for the normal non-exclusive, royalty free license to use that arises by operation
of law in the sale of a product.
G
USAGE AND DISCLOSURE RESTRICTIONS
License Agreements
The software described in this document is the property of Telit and its licensors. It is
furnished by express license agreement only and may be used only in accordance with the
terms of such an agreement.
Copyrighted Materials
Software and documentation are copyrighted materials. Making unauthorized copies is
prohibited by law. No part of the software or documentation may be reproduced, transmitted,
transcribed, stored in a retrieval system, or translated into any language or computer language,
in any form or by any means, without prior written permission of Telit
High Risk Materials
Components, units, or third-party products used in the product described herein are NOT
fault-tolerant and are NOT designed, manufactured, or intended for use as on-line control
equipment in the following hazardous environments requiring fail-safe controls: the operation
of Nuclear Facilities, Aircraft Navigation or Aircraft Communication Systems, Air Traffic
Control, Life Support, or Weapons Systems (High Risk Activities"). Telit and its supplier(s)
specifically disclaim any expressed or implied warranty of fitness for such High Risk
Activities.
Trademarks
TELIT and the Stylized T Logo are registered in Trademark Office. All other product or
service names are the property of their respective owners.
Copyright © Telit Communications S.p.A.
G
1. Introduction ................................................................................................................... 7
2. GE910 Family Ports Arrangements and VSD ............................................................. 9
3. AT#PORTCFG Command ........................................................................................... 11
4. CMUX Protocol ........................................................................................................... 17
5. Services ....................................................................................................................... 22
6. The Winning Ports Configuration.............................................................................. 31
G
G
The purpose of the present document is to provide a guideline to logically connect the
physical interfaces of the module to the services provided by the module itself. The GE910
Family modules need to be configured in suitable way to avoid hardware/software resources
conflicts.
Scope of this guide is to describe the ports/services arrangements provided by the GE910
Family modules. With ports/services arrangements is intended the logical connection of an
available serial port to an available Access point (e.g. AT0, AT1, AT2, TT, PYSER, GPS,
etc.).
This document is intended for User Application designers who want to exploit at best the
communication resources offered by the GE910 Family modules without run up against
resources contention among services.
For general contact, technical support, to report documentation errors and to order manuals,
contact Telit Technical Support Center (TTSC) at:
Alternatively, use:
http://www.telit.com/en/products/technical-support-center/contact.php
For detailed information about where you can buy the Telit modules or for recommendations
on accessories and components visit:
http://www.telit.com
To register for product news and announcements or for product questions contact Telit
Technical Support Center (TTSC).
Our aim is to make this guide as helpful as possible. Keep us informed of your comments and
suggestions for improvements.
Telit appreciates feedback from the users of our information.
G
[1] Telit’s CMUX Implementation User Guide, 1vv0300994
[2] AT Commands Reference Guide, 80000ST10025a
[3] Easy Script in Python 2.7, 80378ST10106A
[4] GE910 Hardware User Guide, 1vv0300962
Revision Date Product/SW Version Changes 0 2013-05-16 First issue
1 2014-02-18
/
The title of the document has been
changed from “GE910 Family Ports
Arrangements (Virtual Service Device)”
in “GE910 Family Ports Arrangements”.
New chapters have been added.
Products added:
GE910-QUAD AUTO / 13.00.xx6 /
DTE Data Terminal Equipment
GPS Global Positioning System
RTD Real Time Debugger
USIFx Universal Serial Interface
VSD Virtual Service Device
G
Before describing the several logical connection configurations between physical ports and Services provided
by the modules belonging to the GE910 Family, it is useful to introduce the Virtual Serial Device. To have
information on physical ports of the modules refer to document [4].
Virtual Serial Device, hereafter called VSD, is a piece of software designed to run on GE910 Family modules.
It basically manages logical connections between the physical serial ports, accessible to the user, and the
services provided by the module. To accomplish this activity, VSD supports several Software Access Points
used as anchorage points for the logical connections. The following table shows the items involved in the
logical connections management: Physical Serial Ports, Software Access Points, AT Parsers and TT Utilities,
Services and Protocols.
Services
Physical Serial Ports Software Access Points AT Parsers and TT Utilities Protocols
USIF01 AT0 Instance #1 Python CMUX (VC1÷VC4)
2
USIF1 AT1 Instance #2 GPS USB (USB0÷USBx)
3 AT2 Instance #3
TT RTD VHWDTE0 VHWDTE1 PYSER
·············· ··············
GPS/NMEA
Tab. 1: Items managed by VSD
It is advisable to remind the concept of instances and their relationships with the Access Points. GE910
Family provides three AT Commands Parser Instances which are logically independent. Each one is managed
by the same control software block and is connected to an Access Point as sketched in the figure below.
fig. 1: AT Parser Instance concept
1 In document [4] USIF0 and USIF1 are called respectively Modem Serial Port 1 (Main) and Modem Serial Port 2 (Auxiliary). 2 Four CMUX channels: VC1÷VC4. 3 USB channels: the number of channels depends on the software version installed on the module.
AT0
Access point
AT2
Instance # 3
AT1
Instance # 2
AT1
Access point
AT2
Access point
Virtual Service Device
AT0
Instance # 1
Unique AT Parser Control Software
Block
G
The physical connection between the module and the generic device can be accomplished via the interfaces
provided by the module itself (USIFx, USBx). A sketch is shown in fig. 2.
The generic device can be developed by the user in accordance with its needs. In general, the device can be a
micro-controller (Application Processor) entirely developed by the user and equipped with an operating
system accomplishing the requirements of the user application.
fig. 2: Module and Application Processor
Interfaces
Module
Application
Processor
G
The logical connection examples described in this document assume that the module is connected to a
Windows-PC.
Tab. 2 shows the #PORTCFG variants supported by the modules in relation with the software version
installed on them. To have detailed information on AT command syntax refer to [2].
#PORTCFG variants supported
Module Software Versions
13.00.xx4 13.00.xx5 13.00.xx6 GE910-QUAD 0 0 0, 1, 3
GE910-QUAD AUTO 0 0 0, 1, 3
GE910-GNSS 0 0, 9 0, 1, 3, 8, 9
Tab. 2: #PORTCFG variants supported by Modules/Software Versions
NOTICE: the user shall use only the #PORTCFG variants showed in the table. All other parameter values
provided by the AT#PORTCFG command are reserved for Telit internal use only.
Before dealing with #PORTCFG variants, it is advisable to see how the USBx channels are mapped into
virtual COMx ports on the DTE side. The figure below shows an example of mapping. In general, it depends
on the Windows PC configuration and the number of the USB channels. The GE910 USB drivers are provided
by Telit and must be installed on the Windows-PC.
fig. 3: USBx mapped into Virtual COMx ports
As previously described, the GE910 Family
provides two USB channels, see the figure on the
left side. In this example the mapping is:
• USB0 channel COM21 (or VCOM21)
• USB1 channel COM22 (or VCOM22)
Now, it is possible to assign a VCOMx port to
each USBx channel.
NOTICE: SW 13.00.xx6 provides three USB
channels: USB0, USB1, USB2.
G
G
Assume that the factory setting of the module is
not changed and the USB cable is not plugged in.
Now, power on the module: the factory
arrangement of the logical internal connections
among physical ports and “Access points” is
depicted in the table below.
AT#PORTCFG=0 (Factory setting)
AT0 AT1 AT2 TT
No USB cable
USIF0 X
USIF1 RTD
Tab. 3: #PORTCFG=0, no USB cable
Assume that the module is powered on and its
configuration is the factoring setting configuration
shown on the left side. Now, connect the USB
cable to the module. The module recognizes the
“plug in” event and assumes the factory
arrangement depicted in the table below.
AT#PORTCFG=0 (Factory setting)
AT0 AT1 AT2 TT
USB0 X
USB1 X
USIF0 X
USIF1 RTD
Only for SW version: 13.00.xx6
AT#PORTCFG=0 (Factory setting)
AT0 AT1 AT2 TT
USB0 X
USB1 X
USB2 N/A N/A N/A N/A
USIF0 X
USIF1 RTD
Tab. 4: #PORTCFG=0, with USB cable
The fig. 4 and fig. 5 show details concerning the logical connections among external physical ports and
internal “Access points”.
fig. 4: #PORTCFG=0, no USB cable connected
AT0
Access point AT1
Access point
AT2
Access point
TT
Access point
USIF0
Physical port
HyperTerminal Session
connected to AT0 parser
(instance # 1)
USB
Physical port
USB
USIF1
Physical port
DTE RTD
Application
COM1 COM2
USB
Channels
USB1 USB0
Virtual Serial Device
G
fig. 5: #PORTCFG=0 with USB cable connected
NOTICE: RTD tool is available to the end user.
AT0
Access point
AT1
Access point AT2
Access point
TT
Access point
HyperTerminal Session
connected to AT0 parser
(instance # 1) DTE
RTD
Application
Virtual Serial Device
USB0 AT1
USB1 AT2
USB
Channels
USB1 USB0
USIF0
Physical port
USB
Physical port
USIF1
Physical port
USB COM1 COM2
G
Only for SW version: 13.00.xx6
AT#PORTCFG=1
AT0 AT1 AT2 TT
No USB cable
USIF0 X
USIF1 ???
Tab. 5: #PORTCFG=1, no USB cable
Only for SW version: 13.00.xx6
AT#PORTCFG=1
AT0 AT1 AT2 TT
USB0 X
USB1 X
USB2 RTD
USIF0 X
USIF1 N/A N/A N/A N/A
Tab. 6: #PORTCFG=1, with USB cable
fig. 6: #PORTCFG=1 + USB cable connected
TT
Access point
USIF1
Physical port
USB
Physical port
USIF0
Physical port
AT0
Access point AT1
Access point
AT2
Access point
HyperTerminal Session
connected to AT0 parser
(instance # 1) USB1 AT2
USB
USB0 AT1
DTE
RTD
Application
USB1 USB0
Virtual Serial Device
COM2 COM1
USB
Channels
USB2
USB2 RTD
G
Only for SW version: 13.00.xx6
AT#PORTCFG=3
AT0 AT1 AT2 TT
No USB cable
USIF0 X
USIF1 X
Tab. 7: #PORTCFG=3, no USB cable
Only for SW version: 13.00.xx6
AT#PORTCFG=3
AT0 AT1 AT2 TT
USB0 X
USB1 N/A N/A N/A N/A
USB2 RTD
USIF0 X
USIF1 X
Tab. 8: #PORTCFG=3, with USB cable
fig. 7: #PORTCFG=3 + USB cable connected
TT
Access point AT2
Access point
AT1
Access point
AT0
Access point
DTE
HyperTerminal Session connected to AT0 parser
(instance # 1)
USB0 AT2
USB
USB
Physical port
COM1
USIF0
Physical port
USB
Channels
USB0 USB1
Virtual Serial Device
Application
(instance # 2)
USB2
USIF1
Physical port
COM2
USB2 RTD
G
This section shows examples of ports arrangement supporting CMUX protocol. If you need to develop a
Multiplexing Protocol running on a desired application processor (e.g. a user micro-controller) refer to [1] to
get detailed information.
The module is configured as indicated in fig. 4: #PORTCFG=0 no USB cable plugged in. In addition, suppose
that the used DTE is a Windows PC and its device configuration is shown in fig. 8. Now, run on the DTE the
TELIT Serial Port MUX application, configure the virtual serial ports of MUX as shown on fig. 9, and
logically connect the virtual serial ports to the physical port COM1, refer to fig. 10. When the user starts an
application (e.g. Hyper Terminal) connected to one of the four virtual ports, TELIT Serial Port MUX
application sends automatically the AT+CMUX=0 command to the module and the CMUX protocol is
activated.
fig. 8: Physical COMx Ports
fig. 9: Virtual Serial Ports of MUX
NOTICE: the virtual serial ports of the TELIT Serial Port MUX application must be configured in such a
way to avoid conflict with the physical or virtual serial ports already present on the Windows PC (DTE).
G
Tab. 9 summarizes the VCOMxCOM1/USIF0VCx configuration and the RTD application
connection via USIF1/COM2 physical ports. The fig. 10 shows the connections details.
Module DTE connection VCOMx VCx AT0 AT1 AT2 TT
USB not used
USIF0 COM1
VCOM16VC1 X
VCOM17VC2 X
VCOM18VC3 X
VCOM19VC4
USIF1 COM2 RTD
Tab. 9: Ports Arrangement with CMUX + RTD
fig. 10: Ports Arrangement with CMUX + RTD
CMUX
Standard Protocol
AT0
Access point
AT1
Access point
AT2
Access point
USB
Physical port
DTE
HyperTerminal
Session connected
through VC1 to AT0
Access Point
HyperTerminal
Session connected
through VC3 to AT2
Access Point
TELIT Serial Port MUX
VCOM16 VCOM17 VCOM18 VCOM19
COM1
HyperTerminal Session connected
through VC2 to AT1
Access Point
VC4 spare
USB
VC1
VC2 VC3
VC4 spare
RTD Application
Virtual Serial Device
USIF0
Physical port
USIF1
Physical port
COM2
TT
Access point
G
The module is configured as indicated in fig. 5: #PORTCFG=0 (factory setting) plus USB cable plugged in. In
addition, suppose that the used DTE is a Windows PC and its device configuration is shown in fig. 3 (two
USB channel are available). Now, run on the DTE the TELIT Serial Port MUX application, configure the
virtual serial ports of MUX as shown in fig. 11, and logically connect the virtual serial ports to the USB1
channel mapped into VCOM22 virtual port as shown on Tab. 10, and fig. 12. When the user starts an
application (e.g. Hyper Terminal) connected to one of the four Virtual Ports, TELIT Serial Port MUX
application sends automatically the AT+CMUX=0 command to the module and the CMUX protocol is
activated.
fig. 11: Virtual Serial ports of TELIT MUX
As previously described, the GE910 Family
provides two USB channels, see the figure on the
left side. In this example the mapping is:
USB0 channel COM21 (or VCOM21)
USB1 channel COM22 (or VCOM22)
In addition, the figure shows the virtual serial ports
generated by the TELIT Serial Port MUX
application.
NOTICE: the virtual serial ports of the TELIT Serial Port MUX application must be configured in such a way
to avoid conflict with the physical or virtual serial ports already present on the Windows PC (DTE). An
example is shown in fig. 11.
G
The table below summarizes the new ports arrangement.
Module DTE connection Channels USBx VCOM VCOMx VCx AT0 AT1 AT2 TT
USB USB
USB0
USB1 VCOM22
VCOM16 VC1 X
VCOM17 VC2 X
VCOM18 VC3 X
VCOM19 VC4
USIF0 not used
USIF1 COM2 RTD
Tab. 10: Ports Arrangement when CMUX is connected to USB1 channel
Referring to fig. 12: it is worth noting that the AT0 (instance # 1) is disconnected from USIF0 and connected
to VC1USB1 channelUSB physical portVCOM22VCOM16Hyper Terminal. Instead,
the RTD stays on USIF1.
G
fig. 12: Ports Arrangement when CMUX is connected to USB1 channel
Virtual Serial Device
CMUX
Standard Protocol
AT0
Access point
USIF0
Physical port
AT1
Access point
AT2
Access point
TT
Access point
USIF1
Physical port
COM1 COM2
USB
Physical port
USB
Channels
USB0 USB1
VC1
VC2
VC3
VC4 spare
USB
DTE
HyperTerminal
Session connected
through VC1 to AT0
Access Point
HyperTerminal
Session connected
through VC3 to AT2
Access Point
TELIT Serial Port MUX
VCOM16 VCOM17 VCOM18 VCOM19
HyperTerminal
Session connected
through VC2 to AT1
Access Point
VC4 spare
USB1VCOM22
RTD
Application
G
This section describes the interaction between the ports arrangements and the services provided by the
modules.
The module equipped with GPS receiver can send NMEA sentences on a physical port in accordance with the
current ports configuration.
The AT#PORTCFG=8 connects directly the GPS Access point to the external physical port USB2, no AT
commands (AT$GPSP, AT$GPSNMUN ) are needed to route the NMEA sentences towards USB2 port.
Only for GE910-GNSS, SW version 13.00.xx6
AT#PORTCFG=8
AT0 AT1 AT2 TT GPS/NMEA
USB0 X
USB1 X
USB2 X
USIF0 X
USIF1 RTD
Tab. 11: #PORTCFG=9
fig. 13: USB1 channel supports only NMEA sentences
AT0
Access point
AT1
Access point AT2
Access point
TT
Access point
HyperTerminal Session
connected to AT0 parser
(instance # 1) DTE
RTD
Application
Virtual Serial Device
USB0 AT1
USB1 AT2
USB
Channels
USB2 USB0
USIF0
Physical port
USB
Physical port
USIF1
Physical port
USB COM1 COM2
NMEA sentences
GPS
Access point
USB1
USB2 only NMEA
G
Assume that the AT#PORTCFG=0 command is entered and an USB cable is connected to the module, the
internal logical connections of the module are shown in Tab. 4 and fig. 14. Now, to allow the NMEA
sentences run on the physical port USIF0 the operator must enter the AT$GPSP and AT$GPSNMUN
commands. After executing the two AT commands, NMEA sentences and AT commands can share the USIF0
port at the same time See figure below.
fig. 14: USIF0 port supports AT commands + NMEA sentences
GPS
Access point
NMEA sentences
AT0
Access point
AT1
Access point AT2
Access point
TT
Access point
HyperTerminal Session
connected to AT0 parser
(instance # 1) DTE
RTD
Application
Virtual Serial Device
USB0 AT1
USB1 AT2
USB
Channels
USB1 USB0
USIF0
Physical port
USB
Physical port
USIF1
Physical port
USB COM1 COM2
NMEA sentences
and AT commands
G
The AT#PORTCFG=9 connects directly the GPS Access point to the external physical port USB1, no AT
commands (AT$GPSP, AT$GPSNMUN ) are needed to route the NMEA sentences towards USB1 port.
Only for GE910-GNSS, SW version 13.00.xx5
AT#PORTCFG=9 GNSS
AT0 AT1 AT2 TT GPS/NMEA
USB0 X
USB1 X
USIF0 X
USIF1 RTD
Only for GE910-GNSS, SW version 13.00.xx6
AT#PORTCFG=9
AT0 AT1 AT2 TT GPS/NMEA
USB0 X
USB1 X
USB2 N/A N/A N/A N/A N/A
USIF0 X
USIF1 RTD
Tab. 12: #PORTCFG=9
fig. 15: USB1 channel supports only NMEA sentences
AT0
Access point
AT1
Access point AT2
Access point
TT
Access point
HyperTerminal Session
connected to AT0 parser
(instance # 1) DTE
RTD
Application
Virtual Serial Device
USB0 AT1
USB1 only NMEA
USB
Channels
USB1 USB0
USIF0
Physical port
USB
Physical port
USIF1
Physical port
USB COM1 COM2
NMEA sentences
GPS
Access point
G
The GE910 Family modules provide the Python programming language to offer to the user a tool to develop
control scripts in accordance with his communication and hardware needs, see [3]. As shown on fig. 16 the
VSD provides two access points called VHWDTE0 and VHWDTE1. MDM and MDM2 Python modules are
logically connected respectively to the two access points.
It is assumed that the module is using the factory setting4 configuration and USB cable is not plugged in.
Now, power on the module: the factory arrangement of the internal logical connections among physical ports
and “access points” is depicted in fig. 4, and Tab. 3 summarizes the factory ports arrangement. When the
Python script runs the Python instruction import MDM5, the VSD disconnects the USIF0/AT0 logical
connection and establishes the logical connection VHWDTE0/AT0 enabling Python script to access AT0
parser. In the same way, import MDM2 instruction requests to the VSD to establish the logical connection
VHWDTE1/AT1. The fig. 16 shows that USIF0 is disconnected from AT0 parser and cannot be used by an
external device.
Python script can run another Python software module to use the USIF0 port using the instruction import SER
and the access point PYSER. The fig. 17 shows the new connection: the physical port USIF0 is connected to
Python script via PYSER/SER.
The Python software modules MDM, MDM2, and SER use three independent resources: USIF0 physical port,
AT0, and AT1 Access Points. No resources contention can arise among them. As a rule, we can say that the
MDM, MDM2, and SER instructions steal the resources regardless their current owner.
As shown in the next pages there are other Python modules to create logical connection between a physical
port and an Access point. To have detailed information on the software versions supporting different Python
modules refer to document [3]. Here are some figures showing different logical connection configurations.
4 AT#PORTCFG=0, refer to Chapter 3. 5 It is assumed that the reader is familiar with Python language.
G
AT2
Instance # 3
fig. 16: Python & MDM, MDM2 modules
DTE HyperTerminal Session
connected to AT0 parser
(instance # 1)
COM1
RTD
Application
COM2
AT0
Access point
AT1
Instance # 2
AT0
Instance # 1
AT1
Access point
AT2
Access point
TT
Access point
Virtual Serial Device
Python
MDM2 MDM
VHWDTE1 VHWDTE0
User Script
USB
Physical port
USIF0
Physical port
USIF1
Physical port
Trace Utility
G
AT2
Instance # 3
fig. 17: Python & MDM, MDM2, SER modules
DTE HyperTerminal Session
connected to AT0 parser
(instance # 1)
COM1
RTD
Application
COM2
AT0
Access point
AT1
Instance # 2
AT0
Instance # 1
AT1
Access point AT2
Access point
TT
Access point
Virtual Serial Device
Python
MDM SER
VHWDTE1 VHWDTE0
User Script
USB
Physical port
USIF0
Physical port
USIF1
Physical port
MDM2
PYSER
Trace Utility
G
AT2
Instance # 3
In accordance with the installed software version, Python script can run the Python software module to use the
USIF1 port using the instruction import SER2 and the access point PYSER2. The figure below shows the new
connection: the physical port USIF1 is connected to Python script via PYSER2/SER2.
fig. 18: Python & MDM, MDM2, SER, SER2 modules
The Python software modules MDM, MDM2, SER, and SER2 use four independent resources: USIF0, USIF1
physical ports, and AT0, AT1 Access Points. No resources contention can arise among them. As a rule, we
can say that the MDM, MDM2, SER, and SER2 instructions steal the resources regardless their current owner.
DTE HyperTerminal Session
connected to AT0 parser
(instance # 1)
COM1
Connected to Python
script
COM2
AT0
Access point
AT1
Instance # 2
AT0
Instance # 1
AT1
Access point AT2
Access point
TT
Access point
Virtual Serial Device
Python
MDM SER
VHWDTE1 VHWDTE0
User Script
USB
Physical port
USIF0
Physical port
USIF1
Physical port
MDM2
PYSER
Trace Utility
PYSER2
SER2
G
AT2
Instance # 3
In accordance with the installed software version, Python script can run the Python software module to use the
USB0 channel using the instruction import USB0 and the access point PYUSB0. The figure below shows the
new connection: the USB0 channel is connected to Python script via PYUSB0/USB0.
fig. 19: Python & MDM, MDM2, SER, USB0 modules
The Python software modules MDM, MDM2, SER, and USB0 use four independent resources: USIF0
physical port, USB0 channel, and AT0, AT1 Access Points. No resources contention can arise among them.
As a rule, we can say that the MDM, MDM2, SER, and USB0 instructions steal the resources regardless their
current owner.
USB0 connected to Python script
DTE
HyperTerminal Session connected to AT0 parser
(instance # 1)
COM1
RTD
Application
COM2
AT0
Access point
AT1
Instance # 2
AT0
Instance # 1
AT1
Access point
AT2
Access point
TT
Access point
Virtual Serial Device
Python
MDM SER
VHWDTE1 VHWDTE0
User Script
USB
Physical port
USIF0
Physical port
USIF1
Physical port
MDM2
PYSER
Trace Utility
PYUSB0
USB0
USB1 USB0 USB2
Channels
USB
G
AT2
Instance # 3
It is assumed that the user needs to debug a new Python script. The module is using the factory setting
#PORTCFG=0 configuration, refer to Tab. 3. Now, suppose that the Python script runs: import MDM, import
MDM2, import SER and print instructions. The figure below sketches the actions results of the first tree
instructions. Moreover, it shows that the print instruction uses the TT Access point to send the print messages
to the USIF1 port. The RTD application displays on the DTE, in readable format, the trace data received in
binary format from the Trace Utility, and the print Python messages, received from the User Script, in text
format. The Hyper Terminal session can only display the print Python messages received in text format.
fig. 20: Python & MDM, MDM2, SER and print modules
DTE HyperTerminal Session connected to Python
script.
COM1 COM2
RTD Application or
HyperTerminal Session in accordance with the
debugging session needs.
AT0
Access point
AT1
Instance # 2
AT0
Instance # 1
AT1
Access point
AT2
Access point
TT
Access point
Virtual Serial Device
Python
MDM SER
VHWDTE1 VHWDTE0
User Script
pri
nt
: P
yth
on
scr
ipt
inst
ruct
ion
.
Trace Utility
USB
Physical port USIF0
Physical port
USIF1
Physical port
MDM2
PYSER
G
There are two methods to change module ports arrangement in addition to use #PORTCFG:
Plug in/out the USB cable;
Enter the AT+CMUX=06 command.
Here are two examples showing how the user can change ports configuration.
Example 1
Module: its ports configuration is shown on fig. 4 (factory setting).
User action: the user runs on the Windows PC the TELIT Serial Port MUX application so configured:
Virtual Ports COM16÷COM19 logically connected to COM1.
PC: it provides the required Virtual Ports. When the user starts an application (e.g. Hyper
Terminal) connected to one of the three Virtual Ports (the fourth one is spare), TELIT Serial
Port MUX application sends the AT+CMUX=0 command to the module.
Module: in accordance with the received command, the involved AT Parser starts the CMUX protocol.
The module enters the configuration shown on fig. 10.
User action: now, the user connects USB cable.
Module: it enters the configuration shown on fig. 5.
PC: it provides two new virtual “COM” logically connected to the two USB channels. The CMUX
protocol is disabled and the TELIT Serial Port MUX application running on Windows PC is
no more connected to the module, it should be closed. COM1 is ready for new applications.
User action: now, the user disconnects USB cable.
Module: it enters again the configuration shown on fig. 4.
6 TELIT Serial Port MUX application automatically sends the AT+CMUX=0 command to the module, see chapters 4.1, 4.2.
G
Example 2
Module: its port configuration is shown on fig. 4 (factory setting).
User action: the user connects USB cable.
Module: in accordance with the user action, the module enters the configuration shown on fig. 5.
PC: it provides two virtual “COM” required by USB drivers to logically connect the two USBx
channels.
User action: the user runs on the Windows PC the TELIT Serial Port MUX application so configured:
Virtual Ports COM16÷COM19 logically connected to USB1VCOM22.
PC: it provides the required Virtual Ports. When the user starts an application (e.g. Hyper
Terminal) on a Virtual Ports, TELIT Serial Port MUX sends the AT+CMUX=0 command to
the module.
Module: in accordance with the received command, the involved AT Parser starts the CMUX protocol.
The module enters the configuration shown on fig. 12.
User action: now, the user disconnects USB cable.
Module: it enters the configuration shown on fig. 4.
PC: discards the two virtual “COM” logically connected to the two USBx channels. The CMUX
protocol is disabled, TELIT Serial Port MUX application running on Windows PC is no more
connected to the module, and it should be closed.
The two examples show that the last required port configuration overrides the previous one.