-``examples/pppos_client`` simple client which reads some module properties and switches to the data mode to connect to a public mqtt broker.
-``examples/modem_console`` is an example to exercise all possible module commands in a console application.
-``examples/ap_to_pppos`` this example focuses on the network connectivity of the esp-modem and provides a WiFi AP that forwards packets (and uses NAT) to and from the PPPoS connection.
Modem devices could work in multiple different modes, esp-modem library
uses these states to describe them:
- Standard modes:
- Command mode -- This mode is used for sending AT commands
- Data or PPP mode -- This mode is used for data communication (to create PPPoS tunnel between the device and the library)
- Multiplexing modes:
- CMUX mode -- This mode creates two virtual channels and uses one for sending AT commands and the other one for data communication.
- DUAL mode -- This mode uses two physical channels the same way as CMUX. This mode is supported only by certain devices, usually with USB interface.
- Manual CMUX modes -- These modes are designed for applications to have better control over CMUX mode transitions. It allows setting up the virtual channels,
switching between channels, transitioning between data and command modes for each channel separately, and exiting the CMUX.
Switching between common modes
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The diagram below depicts allowed transitions between the most common modes
::
+---------+ +---------+
| COMMAND |<-->| DATA |
+---------+ +---------+
^
|
v
+-------+
| CMUX |
+-------+
Note that it is possible to switch from any mode to the "UNDEF" mode and vice-versa.
Switching between manual modes
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The diagram below depicts allowed transitions between manual CMUX modes
Note that transitioning between "MANUAL_DATA" and "MANUAL_CMD" switches the secondary terminal (dedicated to PPP session) and could be used for recovering data communication if PPP session gets dropped.
There are certain typical issues you might experience when working with esp_modem. This section elaborates on these problems and offers workarounds.
When using UART terminal, you might find running OTA over https quite unstable, exhibiting frequent UART buffer overflows.
The reason for that is that ESP32's UART is interrupt driven, so while performing computational extensive tasks with TLS session,
we need to timely interrupt to process incoming data. Here'are few suggestions to mitigate the impact:
* Move UART ISR to IRAM
* Increase internal UART rx buffer size
* Increase UART terminal task priority
* Use UART flow control
If none of the above helps, you can check the test ``target_ota``, which performs OTA in two steps -- first read the data, then pass the data to mbedTLS. See the test ``README.md`` for more details.
Potential issues when using CMUX mode and these devices:
