st31ny
commented
2 years ago I have invested some time to debug the issue and actually got all three SIM cards working. However, I am not sure if I fully understand the problem.
- Apparently, my issue has to do with the used PDP context identification cid that is fixed to "1" in the current implementation in in TinyGSM. Using my Telekom SIM I queried the actual set configuration using
sendAT(GF("+CGDCONT?")); waitResponse();:AT+CGDCONT?
+CGDCONT: 1,"IP","internet.telekom","0.0.0.0",0,0,0,0 +CGDCONT: 2,"IPV4V6","ims","0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0",0,0,0,0 +CGDCONT: 3,"IPV4V6","","0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0",0,0,0,1
So, there seems to be an automatic second entry "ims" (which is used for VoLTE). I asked a Telekom technician to check for my connection and he confirmed that my device tries to send data using the "ims" APN.
2. When I set *cid* to "2" in TinyGSM's `gprsConnectImpl()` it immediately started working. However, a *cid* of "2" does not work anymore with my Vodafone SIM. I experimented with `CGACT` to disable all PDP contexts except one without success.
3. My next attempt was to delete the unnecessary PDP contexts. So I reverted TinyGSM to 0.11.5 and issued some extra AT commands before calling `gprsConnect()`:modem.sendAT(GF("+CGDCONT=1"));
modem.waitResponse();
modem.sendAT(GF("+CGDCONT=2"));
modem.waitResponse();
modem.sendAT(GF("+CGDCONT=3"));
modem.waitResponse();
modem.gprsConnect("internet.telekom");
Afterwards, the Telekom SIM actually works, but not at the first attempt. So, I need to clear the PDP contexts, try to connect with `gprsConnect()` (which fails), call `restart()` (`init()` is not enough!) and then go through the entire connection setup process again. Only deletions seem to be affected by this quirk — changing an APN becomes effective immediately, without a `restart()`.
-------
**Conclusions**
Based on my observation I come to these conclusions (which might be flawed or incomplete):
* For Telekom SIM, if a PDP context with `cid==2` is present, it is used, no matter if it was deactivated with `AT+CGACT`.
* With a Telekom SIM, a PDP context with `cid==2` with APN "ims" is created automatically. This APN is for VoLTE only and does not work for GPRS although connection is possible and an IP address is assigned.
* For Vodafone SIM, PDP context with `cid==1` is always used, even if deactivated. I never got Vodafone working with `cid==2`.
* I didn't do the same intense testing with O2 but believe that it's similar to Telekom.
* The PDP context is stored persistently in the modem (not in the SIM, I tested with different Telekom/Vodafone SIMs and different modems) and sometimes (?) updated when adding a new SIM.
* By deleting the PDP context with `cid==2`, Telekom (and presumably O2) can be forced to use the PDP context with `cid==1`.
* The deletion of a PDP context only takes effect after calling `restart()`.
---------------
**Workaround**
This is my current workaround that I can implement solely in application code (no change to TinyGSM itself required):
* Use `modem.restart("1234")` instead of `modem.init("1234")`.
* Call `modem.setNetworkMode()` and `modem.waitForNetwork()` as usual.
* Delete all PDP contexts by calling `modem.sendAT("+CGDCONT={cid}"); modem.waitResponse();` for all relevant *cid* (I call it for 1 to 24, including).
* Try to connect to GPRS as usual by calling `modem.gprsConnect()`. If that fails, go back to the beginning (i.e., start over with a `modem.restart()`).
---------------
While I have a functioning workaround, this behavior is a bit bewildering — and I have no idea how this could be hacked into TinyGSM itself reasonably. I might have missed a crucial point; maybe somebody can explain better what's going on.
If I can help to investigate this any further, please let me know!
star297
agilly
Robbyjoe1110
[x] I have read the Troubleshooting section of the ReadMe
What type of issues is this?
[ ] Request to support a new module
[ ] Bug or problem compiling the library [x] Bug or issue with library functionality (ie, sending data over TCP/IP) [ ] Question or request for help
What are you working with?
Modem: SIMCOM SIM7600E-H SIM7600M22_V1.1 Main processor board: ESP32 TinyGSM version: 0.11.5 Code: MqttClient, adapted slightly
Scenario, steps to reproduce
I am testing with the MqttClient example with the three major network providers in the region (Germany: Telekom, Vodafone, O2/Telefonica). All have equally good LTE coverage at my place and I am using an external antenna.
I tested all SIM cards with my phone and used the same APN/username/password settings that actually worked with LTE on my phone.
The hardware itself covers almost all bands used by the providers here.
Expected result
Connection should work equally with all three providers.
Actual result
Connection works perfectly with Vodafone. After less than 20 s after boot the first MQTT packet is delivered successfully to the server.
With Telekom, the device can register in the network (AT+CGREG returns status 1 "registered"), open a GPRS connection (AT+NETOPEN returns 0) and even gets an IP address. So it seams that everything works just fine until I try to actually open a TCP stream. This always aborts with a timeout (AT+CIPOPEN returns error code 10 "timeout"). I even increased the default timeout of 15 s to 75 s without success. In the working case with Vodafone above, connecting to the server and doing the MQTT login handshake takes less than 400 ms.
With O2/Telefonica, I can still connect to the network (AT+CGREG returns status 1 "registered"), however, opening a GPRS connection fails (AT+NETOPEN returns ERROR).
Debug and AT command log
See log of my attempt with Telekom, redacted for privacy.
Do you have any ideas how I can debug this issue further? Thank you very much for your help.