XMONITOR

[vkbakken]

%XMONITOR seems to report <reg_status> set to 1 or 5 even though the device has lost connection to the base station - for instance by being moved out of range. Mobility is not well supported by NB-IOT for instance - but it is strange that the network registration status is not better upated.

I find it hard to understand that the modem consider itself registered even though it is not and data transmission is failing.

It leaves it very difficult for the user to gracefully handle that network has been lost. Moreso since open/close/send/recv only report -1 upon an error...

So:

1. Is it correct that XMONITOR should report 1 or 5 even when network is lost?

2. How can one safely query the modem that it is operating correctly? IE can perform data transmission

 

[Håkon Alseth]

Hi,

Mobility is not well supported by NB-IOT for instance

This is correct: https://www.emnify.com/blog/7-topics-that-iot-device-manufacturers-need-to-consider-before-using-cellular-narrowband

 

I find it hard to understand that the modem consider itself registered even though it is not and data transmission is failing.

 I agree with you. I have reported this internally, to unify this through a handler, for instance by subscribing to CEREG updates from the modem to ensure that the application is alerted if this happens.

 

Is it correct that XMONITOR should report 1 or 5 even when network is lost?

 1 and 5 are both connected, just with "roaming" or "home network" - ie: a carrier SIM or a generic roaming SIM:

https://infocenter.nordicsemi.com/topic/ref_at_commands/REF/at_commands/nw_service/xmonitor_set.html

This is the same as reported by CEREG.

Other values than 1 or 5 indicates that the connection is not active.

 

How can one safely query the modem that it is operating correctly? IE can perform data transmission

Checking CEREG / XMONITOR should provide these details, but there's no functionality now to register this in a good way through at_cmd (or helper libraries), unfortunately.

 

Kind regards,

Håkon 

[vkbakken]

Håkon,

I guess what becomes a rather big issue is that it seems that once state 1 or 5 has been retained once - they are sticky. Meaning if I take the nrf91 design in my car and I drive so that I am sure the base station is lost - XMONITOR retains the status of 1 and 5...in this case for no good reason.

It also means that when I send data through the socket API (being out of range) there is no "notice" from the bsdlibrary that something was not OK. Meaning you can open a socket, write to the socket without a hitch. The only real way to figure if something went wrong is to poll nrf_read in a non-blocking manner for a while, decide to timeout - and use that to say I must have lost my signal for then to reboot the system...

As you can see this leads to some quite hairy programming to know that you are out of range. I am very happy with nb-iot's limitation of not being able to move. But I am rather unsattisfied with how I get to check network status.

There simply has  to be a deterministic and modem centric way to know that my connection was broken. CEREG is not updated either - so it seems to me that if the modem does one successful connection to a base station it takes the status of 1 or 5 and that becomes sticky.

Håkon, could you be so kind to see if this is the way the modem handles the CEREG status? And two - is there a way to get a "proper" network status as in I am connected/I am not connected?

Thanks in advance,

-Vemund

[Håkon Alseth]

vkbakken said:

I guess what becomes a rather big issue is that it seems that once state 1 or 5 has been retained once - they are sticky. Meaning if I take the nrf91 design in my car and I drive so that I am sure the base station is lost - XMONITOR retains the status of 1 and 5...in this case for no good reason.

 XMONITOR does not update the status to be out of range/coverage (4) ?

Does CEREG also report the same issue? Note that the first byte reported by CEREG is the notification level, while the second is the link status:

https://infocenter.nordicsemi.com/topic/ref_at_commands/REF/at_commands/nw_service/cereg_read.html?cp=2_1_6_8_1

vkbakken said:

It also means that when I send data through the socket API (being out of range) there is no "notice" from the bsdlibrary that something was not OK. Meaning you can open a socket, write to the socket without a hitch. The only real way to figure if something went wrong is to poll nrf_read in a non-blocking manner for a while, decide to timeout - and use that to say I must have lost my signal for then to reboot the system...

You should get a errno stating timeout or connection issues. I agree that the current solution, as its not event based on when you get a CEREG update, isn't optimal or requires more logic to recover from. I have reported this internally as an issue.

vkbakken said:

As you can see this leads to some quite hairy programming to know that you are out of range. I am very happy with nb-iot's limitation of not being able to move. But I am rather unsattisfied with how I get to check network status.

 Agree with your observations.

vkbakken said:

There simply has  to be a deterministic and modem centric way to know that my connection was broken. CEREG is not updated either - so it seems to me that if the modem does one successful connection to a base station it takes the status of 1 or 5 and that becomes sticky.

 Could you try using the at_client to see if this behavior is equal there as well? This one will register CEREG as a notification and print it in the case there is a change in status from the tower.

vkbakken said:

Håkon, could you be so kind to see if this is the way the modem handles the CEREG status? And two - is there a way to get a "proper" network status as in I am connected/I am not connected?

 Do you have any logs showing the issue?

If CEREG also reports 1 or 5, always, then make sure that you are on the latest modem firmware first, then you could provide a modem trace?

 

Kind regards,

Håkon