Thales' cellular IoT products business is now part of Telit Cinterion, find out more.

You are here

Performance issues with BGS5 during Connector.open() when no connection can be made | Telit Cinterion IoT Developer Community

October 1, 2018 - 4:57pm, 5866 views

Hi,

I would like to state up front that during normal scenario's, my BGS5 modem behaves as expected. It connects to the GSM network, and periodically sends data to a central server, using a TCP connection created using Connector.open(). On the device that has the BGS5 modem, there is another module (MCU) that is reachable from the Java Application running on the BGS5. This integration also works fine under normal conditions. There are a bunch of threads running on this device that all gather information, or perform some actions, side by side.

This is my device:

ATI1

Cinterion
BGS5
REVISION 01.100
A-REVISION 00.000.21

I would now like to go into details about what is going wrong:

When the modem is not capable of creating a connection (because there is bad coverage) the modem, and the Java Application running on top of it, seems to be locking up/freezing. As a result, all threads of the java application seem to be locking/freezing, until the Connector.open() method throws an exception, 60 seconds later (the Exception is typically: "java.io.IOException: Profile could not be activated").  Let me be explicit: all threads (even those that have nothing do to with networking) are halted until the Connector.open() method finishes.

This causes a lot of timing problems with the other threads, and even some crashes in the MCU that does not know how to handle the java-application-free.

This situation can be replicated for me by having two threads running. 

  1. A thread that prints a value every second.
  2. A thread that tries to open a Connection using Connector.open("socket://[Server]:[Port];bearer_type=gprs;access_point=[APN];username=[APNUSERNAME];password=[APNPASSWORD]")

To simulate the network problems, you could issue the command AT+COPS=2, to deregister GPRS. You should now see that the first thread that prints a value be halted, until the Connector.open method ***** out.

Is this known behavior? If so, is there a workaround? I need to be able to have all my concurrent threads operating normally, without them freezing whenever I have a connection issue (which would be happening unpredictably).