[ACELL05] SMS messages not sent and/or include the AT Command

[aliphys]

As part of the library test for the Arduino_Cellular library, I (in Sweden 🇸🇪 ) have not been able to consistently send SMS messages, even when both the cellular HTTP(S) connectivity is achieved and the SIM card (Telenor and Lyca Mobile) is able to send messages from my phone.

Replication of this issue has been challenging, since @t-wojo in the US 🇺🇸 and @martab1994 in Italy 🇮🇹 have not had the same issues. @WolfRorDev however has had issues, showing that this is not a one-off problem.

Using this sketch, I was able to consistently (ish) display the following:

• Dropped SMS messages
• AT command AT+CMGS="+467xxxxxxxx" included in the SMS message

Screenshot from phone, displaying the text messages recieved

Diagnosis

Given that the modem interpreted the AT command as part of the text message, it is possible that the AT command for setting the board into text mode is not registered prior to sending the text by sendSMS(). Merging #15 may fix this, by doing the following before calling the AT+CMGS command:

• Forcing the modem to go into text mode modem.sendAT("+CMGF=1");
• Waiting for a response

[aliphys]

SMS messages not being sent reliably has been replicated in Sweden 🇸🇪 by @i-herrera

[aliphys]

TLDR

• Web functionality works OK across all SIM cards.
• In Sweden, only Telenor is able to send SMS messages
• Even with improvements given in Fix sendSMS function #15 the problems brought up in this issue still persist.

Details

With #21 merged, there still is an intermittent problem which seems hard to reproduce consistently. In summary, I can share the following observations at this stage:

• ⚡ Variations in power supply is ruled out as a cause. I am using a lab PeakTech 6225 A power supply, set to 5.00 V constant voltage output. The Power supply can output up to 5A, yet even in a worst case scenario the board would consume 3A peak. Since the power supply is linear, the noise level is very low. Probing with the oscilloscope showed minimal changes during the whole process. According to the display the max current draw does not go over 300mA when sending messages. Normal current value is about 100mA.
  • 
• 🌐 For all SIM cards tested (Telenor, Comviq, Telia and ThingsMobile), it is possible to access web features (e.g. with the HTTPSClient.ino sketch). Image shows output of the HTTPSClient.ino sketch with the Portenta C33, PRO 4G EMEA and ThingsMobile SIM card.
  • .
• 🥇 On the Telenor network, we can send SMS messages...
  • 
• 📡 ... however

  • even with the fix provided by Fix sendSMS function #15 sometimes messages are dropped and/or the AT commands are included inside the SMS message.

    • 
    • 

  • Only Telenor is able to send messages. This is in spite of the fact that (a) other SIM cards can connect to the cellular network, (b) are able to receive/send SMS messages on other devices and (c) all can utilize HTTP connectivity.

• As a representative example, the ThingsMobile - a network operator specifically designed for use with IoT devices - does show records of sending over 50 SMS messages. The SIM card is charged. However, the SMS messages are not sent. Therefore, this could be an operator issue, beyond the device itself. This corresponds to the Response: 1 value received from the TinyGSM wrapper.
  • 
  • MID-GLOBAL-C33-002-SMS-Volume Serial Monitor Output with ThingsMobile SIM card

    ---------
    Test Scenario ID: MID-GLOBAL-C33-002-SMS-Volume
    ---------
    Connecting to network...
    SIM Status: 1
    Waiting for network registration...
    No APN specified, not connecting to GPRS
    Connected!
    ---
    Test Case ID: MID-GLOBAL-C33-002-SMS-Volume-01
    Send 1 text...
    Single Text
    Response: 0
    ---
    Test Case ID: MID-GLOBAL-C33-001-Example-SendSMS-02
    Send 3 texts...
    Response: 0
    1/3 texts
    Response: 0
    2/3 texts
    Response: 1
    3/3 texts
    ---
    Test Case ID: MID-GLOBAL-C33-001-Example-SendSMS-03
    Send 10 texts...
    Response: 1
    1/10 texts
    Response: 1
    2/10 texts
    Response: 1
    3/10 texts
    Response: 1
    4/10 texts
    Response: 1
    5/10 texts
    Response: 1
    6/10 texts
    Response: 1
    7/10 texts
    Response: 1
    8/10 texts
    Response: 1
    9/10 texts
    Response: 0
    10/10 texts
    ---------
    End of Test Scenario ID: MID-GLOBAL-C33-002-SMS-Volume
    ---------
    

Diagnosis

• While power consumption can be a big issue (due to the high spikes caused by the cellular radio as explained by @t-wojo here), the possibility of this being a contributing factor is minimal since we used a lab power supply.
• Given that even with ideal conditions and the SMS message is sent - the text message can include the AT command, it might be worth a look to see how the AT commands are configured on the modem.
• Ensuring that the text mode is correctly applied to messages sent from the Portenta C33/H7 to the PRO 4G module may help with ensuring that other SIM cards are also able to transmit SMS messages. Especially, since the SMS messages are indeed billed as observed from the ThingsMobile dashboard.

✨ Thanks @pedromsousalima for helping troubleshoot the issue

[alrvid]

That's an interesting combination of observations.

As far as I know, Telenor and Comviq (a Tele2 brand) uses equipment from the same supplier for their 4G networks, while Telia uses equipment from a completely different supplier, and ThingsMobile is some kind of MVNO that can run over all the major operator's networks depending on the situation. So, Telenor working and Comviq not working might point to some kind of configuration difference in their networks. They could have different setups for filtering of things like invalid characters, or detection of what they think are otherwise malformed messages intended as some kind of attack. As far as I know, the billing function for SMS is hooked into the earliest part of the processing chain (they want you to pay for sending malformed messages, spamming, etc), so that can explain why the messages were billed without ever appearing on the receiving end. This also points to the fact that the messages are probably regarded as invalid somehow by the operator - they are probably sent malformed, and therefore first billed, and then dropped to protect the network and the receiver.