we are sending data to our cloud platform every few seconds via the NB-IoT network and we noticed that we do not receive any CESQ or SNR notifications when we are connected AND transferring the data. We receive the CESQ and SNR only after going from CFUN=0 to CFUN=1 and getting connected to the network.
When we don't start the data transmissions, we receive both CESQ and SNR notifications when the value changes. However, after starting the data transmission, signal notifications won't appear again. Furthermore, when we try to manually poll the value with AT+CESQ its value is static until the modem stops operating. What could be the cause? We are using NCS 1.3 and modem firmware 1.2.
do you have any code that I could try to reproduce the issue with?
our colleague wrote an example code that you can inspect. Link for the download: /cfs-file/__key/communityserver-discussions-components-files/4/coap_5F00_client.zip
Below is also a screenshot with the output of the program: /resized-image/__size/1040x800/__key/communityserver-discussions-components-files/4/8231.screen.png
You can clearly see, that we will get notifications only after modem goes to the Idle state.
We have also noticed, that in the example provided, the send will block the execution after couple of iterations (approx. 15). Could you please check what is causing this behavior?
Thanks, I will try to debug this and find out what's going on.
Have you tried using the bsdlib socket interface instead of the AT host? Just disable the AT host library in prj.conf (CONFIG_AT_HOST_LIBRARY=n) and use this API instead.
did you try the code we provided? It is based on your example of a CoAP client. And of course, we do not use CONFIG_AT_HOST_LIBRARY=y internally and it doesn't solve the situation. The CONFIG_AT_HOST_LIBRARY=y is in the attached code only because it is in the prj.conf of the original example from Nordic.
Could you please try to inspect the code and tell us why it is not possible to receive the notifications? We have no idea what could be wrong.
Hakon, I would like also to remind you of the other issue we discovered. In the example we provided, the send command will freeze the program after a few iterations and we don't know why. It is probably needed to inspect the modem and bsdlib trace.
Lukáš said:We have also noticed, that in the example provided, the send will block the execution after couple of iterations (approx. 15). Could you please check what is causing this behavior?
Yes, I needed to make some modifications to the project you sent because I'm on a different network than you. It freezes for me after sending 13 times, so it seems to be consistent with what you're seeing. The best thing to do is probably analyze what is happening in the modem, so if you could take a trace that would be nice. Refer to this document for a description of how to do it.
Hakon, let's split this into two issues if you don't mind.
1) Firstly, we do not receive the CESQ notifications as we stated in the original description. Did you inspect the modified example code we provided? CONFIG_AT_HOST_LIBRARY=y is not the issue and you should be able to reproduce it easily. For convenience, we also provide modem trace when we don't receive the CESQ notifications.
2) The example code freezes after a few iterations when we use blocking send function from bsdlib. We have now tried to reproduce the issue and it just started working out of the blue (same code). Could you please confirm whether it really froze for you after 13 iterations? If yes, could you please try to catch the trace yourself and inspect it?
I don't really understand why the same code froze multiple times 10 days ago and now it works without any code changes, library updates, etc. We are really frustrated because we don't know whether it has anything to do with the network or the modem. We are using NB-IoT Vodafone's network in the Czech Republic.