http_client network error on thingy91

[rupcar]

Hello,

I am trying to use http requests on Thingy91 and therefore I tried with the sample from zephyr/samples/net/sockets/http_client.

I can build the project without any problem but when I try to run it, I get the following error when I open a putty terminal:

I did not change anything in the code, and I was supposing it was not a network problem since I activated my SIM card and I can run the asset_tracker and see the data in nrFcloud without any issue.

I am using the nrfConnectSDK 2.0.0, and the SIM is from twilio.

Best regards,

C

[Albrecht Markus Schellenberger]

Thanks for the logs, Carole :-)

rupcar said:

I am not really familiar with all that, and did not find much help online.It seems like it might be an unstable connection during the call to getAddrInfo() but what I don't really get is why it is still working half of the time.I'm using a Twilio SIM in Switzerland and I though it was supposed to have great connection.

The nRF9160 has two cores: the application core and the modem core. The application core is where the HTTPS Client is located, while the modem core has its own firmware image which kind of acts as a “black box”, meaning that it is not accessible from the outside.  

However, there is an API available that enables both cores communicating with each other. Referring to the modem library architecture documentation in case you are interested. In general, the application and modem talk to each other using AT commands.  In case of HTTPS Client sample, it uses the LTE link controller library instead, which basically is a wrapper for the most commonly used AT commands. Using this library increases readability during development, but AT commands can also be used directly if preferred. 

rupcar said:

Here is when it works:

What I can see from the first log is that the modem initially establishes a network connection: 

2022-07-15T08:07:07.405Z DEBUG modem << [00:04:09.730,438] [0m<dbg> lte_lc: at_handler_cereg: +CEREG notification: +CEREG: 2,"0FC8","0114E209",7 

Which it successfully does a couple of seconds later:

2022-07-15T08:07:13.051Z DEBUG modem << [00:04:15.380,981] [0m<dbg> lte_lc: at_handler_cereg: +CEREG notification: +CEREG: 5,"0FC8","0114E209",7,,,"11100000","11100000" 

Referring to the network registration status notification AT command for more insights.

rupcar said:

And here is what I get when it does not work with error 115:

In second log, modem does exactly the same thing: 

2022-07-15T08:03:41.923Z DEBUG modem << [00:00:44.243,011] [0m<dbg> lte_lc: at_handler_cereg: +CEREG notification: +CEREG: 2,"0FC8","0114E209",7 

2022-07-15T08:03:46.055Z DEBUG modem << [00:00:48.357,788] [0m<dbg> lte_lc: at_handler_cereg: +CEREG notification: +CEREG: 5,"0FC8","0114E209",7,,,"11100000","11100000" 

But loses the connection almost right away: 

2022-07-15T08:03:46.071Z DEBUG modem << [00:00:48.414,428] [0m<dbg> lte_lc: at_handler_cereg: +CEREG notification: +CEREG: 2,"0FC8","0114E209",7 

Why that happens, is hard to tell without any more input. But my first thought here would be that the signal quality might be insufficient. The Thingy:91 does not have the same signal power capacity compared to the nRF9160 DK, due to its antenna design. This makes it even more relevant for the Thingy:91 to be placed in an environment where good signal coverage can be expected. How does the environment your Thingy:91 is placed in look like? 

rupcar said:

And here with error 116:

Regarding the third log, there I assume that you have restarted the application? Because it looks like that the modem did not shut down as it is supposed to, which might have created this warning: 

2022-07-15T08:25:01.871Z DEBUG modem << [00:22:04.605,346] [0m<dbg> lte_lc: init_and_config: The library is already initialized and configured[0m 

However, modem still tries to establish a network connection: 

2022-07-15T08:26:13.851Z DEBUG modem << [00:23:16.201,904] [0m<dbg> lte_lc: at_handler_cereg: +CEREG notification: +CEREG: 2,"0FC8","0114E209",7 

But the application itself just moves on with the DNS lookup before modem had a chance to finish the connection attempt. That is in a way is expected, since the sample had a valid reason to leave the blocking lte_lc_init_and_connect() function (already initialised). Now even though the behaviour is correct, the outcome itself will be wrong ;-)

Regards, 

Markus 

[rupcar]

Thanks a lot for the explanation! It makes more sense to me now.

I tried at home and at work and I had similar results. At home it's a new building with pretty thick walls, but I tried outside and it did not change much.

For the 3rd log, it surprised me as well because I did not touch it at all during the call, so I did not restart it. My code is in a while loop so I try connection several time and the error 116 always comes in that form, even though I am just letting it run without doing anything on it.

Do you hava any clue how to be sure it is not already initialize to avoid this error ?

Carole