there's no example available, but setting up the mux mode is very easy. Just call the gmMuxOpen() function after the gmInit() function. The GMLIB will take care that a subsequent call to gmPPPGPRSOpen() will use a different channel than a subsequent call to e.g. gmSendSMSText().

Thank you for the example, it works correctly.However I need to understand two things.The first is that, in the endless loop of GM01Ex_02 example, the instructions to determine if the PPP connection is broken, no longer work:

both gmDCDstate (for DCD direct pin reading) that PPP_Client_GetStatus function, return the status of LINK LOST so the loop ends immediately. Only by eliminating them, I can mantain a PPP connection and also manage the SMS. How can I get the information about the connection status since these functions are no longer valid if the MUX is enabled?

The second question concerns the baud rate. The setting with gmWriteBaudRate(460800UL) applies to the PPP while the MUX function sets to 115200 all AT commands (eg. SMS)?How are the PPP and the AT commands associated with the two muxed serial channels and what is the respective baud rate?

sorry, the information that the DCD line is always inactive during MUX mode is missing in the documentation.

You have to call gmPPPGetClientStatus(), instead of PPP_Client_GetStatus() to get the PPP state. The reason for this is that the MUX mode will not use the built-in RTOS PPP client. The MUX mode installs an own PPP client driver. You will see this in the interface list of the "ipcfg" shell command. The gmPPPGetClientStatus() takes care that the proper PPP client is asked about the state, regardless whether MUX is used or not.

The function gmWriteBaudRate() should be used before the MUX mode is setup. The selected baud rate is the rate to communicate with the modem in general. The default baud rate is 115200. For the GM02 it makes sense to increase this baud rate, cause otherwise you will not benefit from a possible faster UMTS connection.

In MUX mode all data that is sent/received to/from the modem is packaged in frames with channel information. Basically, there are two channels used. One channel for AT commands and another channel for the data (PPP). This means that the PPP client will sent and receive data on one channel, whereas further AT commands can still be send on the other channel, e.g. for receiving/sending SMS or checking the RSSI, etc.

So if I set 460800 baud (before invoking MUX), the exchange of the two channels is achieved with the MUX working at that general speed, but only the channel for AT commands simulates a 115200 serial port?This my doubt comes from the fact that the MUX function prints (in Telnet windows) the creation of a mux channel with 115200 speed. This refers only to the AT command channel, while the PPP data channel uses the full 480400 connection (apart from the overhead of multiplexing and the load of any sporadic AT commands simulated at 115200)?I understand correctly?

To close the connection (eg. to restart modem after a problem or LINK loss) gmMuxClose must be executed between gmPPPGPRSClose and gmDeInit or is not necessary because included in gmDeinit?

if gmDebugMessages is set to 1, then the gmMuxOpen() function will print the message "Activating MUX with <baudrate> bit/s" to the console. If you have set the baud rate to 460800 with gmWriteBaudRate(), I would expect that this message will also report the 460800 baud rate.

Yes, gmDenit() will call gmMuxClose() internally, if it has not been called by the user.