nrf9160: LTE + GPS + MQTT - GPS Blocked

[Brett]

Hi,

I am trying to understand either the timing or feature I am missing with respect to LTE, GPS and MQTT.  I have read a number of posts and questions on a similar topic, but didnt find what I was doing wrong.

I have a 9160DK which connects fine to LTE and MQTT or LTE and GPS but I cant get all 3 to connect.

When I have LTE and MQTT connected, the GPS stays in NRF_MODEM_GNSS_EVT_BLOCKED state and never gets UNBLOCKED. But when I have LTE and GPS only (no MQTT) it gets UNBLOCKED in a few seconds. I can only think that the MQTT is keeping the LTE connection open or busy such that LTE never goes into PSM.

When setting up the modem, I believe I am setting PSM with the following commands, and dont get any errors:
```
lte_lc_init();
lte_lc_psm_req(true);
lte_lc_edrx_req(true);
lte_lc_connect();
```

Output of CPSMS, indicates to me it is in PSM.
```
AT+CPSMS? : +CPSMS: 1,,,"00000011","00100001"
```

After the LTE is connected/setup, I call the following sequence without error (error checking is in the code, removed from the post)

nrf_modem_gnss_init();
nrf_modem_gnss_event_handler_set(gnss_event_handler)
nrf_modem_gnss_nmea_mask_set(NRF_MODEM_GNSS_NMEA_RMC_MASK |
    NRF_MODEM_GNSS_NMEA_GGA_MASK |
    NRF_MODEM_GNSS_NMEA_GLL_MASK |
    NRF_MODEM_GNSS_NMEA_GSA_MASK |
    NRF_MODEM_GNSS_NMEA_GSV_MASK)
    nrf_modem_gnss_fix_retry_set(0)
    nrf_modem_gnss_fix_interval_set(1)
    nrf_modem_gnss_start()

For testing purposes, If I have a while (1) {}, after the above,  it will connect to LTE and GPS and all works fine.

But the goal of the project is to send GPS and ANT+ data to an MQTT broker, so after the LTE + GPS setup above, I have;

mqtt_client_init( client );
… set up the broker details - as per mqtt_simple example …
mqtt_connect( &client );

MQTT connects and I can send a sample string to the broker, so I know that is all working - connectivity etc…

But, if I have MQTT connected, it never connects to GPS, its GPS stays in a BLOCKED state

I have an external modem connected and its outside. I know there is no issues with the physical setup, because as soon as I dont connect to the broker it all works fine.

Q: Do I need to set the modem differently ?

Q: Do I need to disconnect from MQTT for GPS to work and then reconnect when I want to send any data ?

Q: Am I missing a setting on the MQTT setup/config so it allows the LTE go into PSM mode ?

regards

-brett

[Håkon Alseth]

Hi,

 

AT+CPSMS? : +CPSMS: 1,,,"00000011","00100001"

These are your requested TAU and active time, as per the documentation:

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

 

I see that you request 30 minutes TAU and 1 minute active time(001 = 1 minute, 00001 = times one). I can recommend that you request a lower active time, as this will significantly reduce the time for the GPS to be able to run successfully.

if you have a mqtt keep alive of 1 minute, you'll always be blocked by the LTE network with your current timing values.

 

PS: to view the PSM/eDRX settings applied to your link, you should issue the XMONITOR AT command:

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

 

lte_lc_psm_req(true);
lte_lc_edrx_req(true);

You should only request either eDRX or PSM.

Q: Do I need to set the modem differently ?

Q: Do I need to disconnect from MQTT for GPS to work and then reconnect when I want to send any data ?

Q: Am I missing a setting on the MQTT setup/config so it allows the LTE go into PSM mode ?

You should register and await for the CSCON notification to see if the LTE link is idle or not:

https://infocenter.nordicsemi.com/topic/ref_at_commands/REF/at_commands/packet_domain/cscon_set.html?cp=2_1_6_16_0

 

This is also available through the lte_lc event handler as this event:

https://github.com/nrfconnect/sdk-nrf/blob/v1.9.1/samples/nrf9160/udp/src/main.c#L78

 

Then start the GPS when the lte link is in idle mode.

 

Kind regards,

Håkon

[Brett]

Hi Håkon,

Thanks for the reply, a couple of follow up questions:

Is there a reason the following commands all give a different answer, are they all looking at different components of the LTE connection?

Query:

AT+CPSMS? : +CPSMS: 1,,,"00000011","00100001"

AT%XMONITOR : %XMONITOR: 1,"Telstra@","Telstra@","50501","3012",7,28,"0829550D",66,9410,36,22,"","00011110","11100000","01001110"

lte_lc_psm_get( &tau, &active_timer );

returns: TAU: -1 , Active_timer: 60

Set:

If I want to change the TAU and RAT values I was looking to use:
lte_lc_psm_param_set( ), or

should I use at_cmd_write()

regards

-brett

[Håkon Alseth]

Hi,

 

Brett said:

If I want to change the TAU and RAT values I was looking to use:
lte_lc_psm_param_set( ), or

should I use at_cmd_write()

The first is a helper function to set the PSM parameters, while the second is a generic AT command write. Both can be used for setting preferred PSM TAU/ActiveTime.

 

Brett said:

Is there a reason the following commands all give a different answer, are they all looking at different components of the LTE connection?

You have to differentiate between what you request, and what the network applies.

You can request 10 minute TAU, but the network will most likely change this to its own defined minimum level (could be 30, could be 60 minutes or higher for that matter).

 

Brett said:

AT%XMONITOR : %XMONITOR: 1,"Telstra@","Telstra@","50501","3012",7,28,"0829550D",66,9410,36,22,"","00011110","11100000","01001110"

lte_lc_psm_get( &tau, &active_timer );

returns: TAU: -1 , Active_timer: 60

Try changing the active timer, which is currently set at 1 minute, via the CONFIG_LTE_PSM_REQ_RAT="00000001"

This can be 2 seconds (or even disabled, as the network will have a hard-coded timing wise paging before entering PSM)

 

Kind regards,

Håkon

[Brett]

Hi Håkon,

Thanks.

I am getting closer, but still unsure as to why the difference in responses and what the real value is.

Your suggestion of setting the CONFIG_LTE_PSM_REQ_RAT value did have an impact,with the following results:

AT+CPSMS? : +CPSMS: 1,,,"00000011","00000001"
AT%XMONITOR : %XMONITOR: 1,"Telstra@","Telstra@","50501","3012",7,28,"0829550D",66,9410,41,25,"","00001000","11100000","01000111"
TAU: -1
Active_timer: 16

Again they all appear to show something different, so what is the actual Active timer that is going to be used ?  Which one do I trust ?  I imagine its the AT command as its matches what I asked to be set, if so, what are the other values

AT?CPSMS = 00000001 = 2seconds * 1 = 2 seconds
XMONITOR = 11100000 = Timer deactivate ? or is it one of the other fields - either way none of match hte AT command above
lte_lc_psm_get = 16

I am now in a situation where I can get the NRF_MODEM_GNSS_EVT_UNBLOCKED state - so I can now get things moving forward.

Do you have a pointer to a document which defines best practices (or bad practices) in working with LTE, GPS and MQTT.  Specifically around timers and data transfer. 
EG: Batch GPS at a rate of 1 transfer per 30 seconds or dont ever set an LTE active timer to less than X seconds or make sure you do something with MQTT or you will always see problems ?

I have looked at the GPS and MQTT examples - but I am looking for some specific details on do's and dont's

regards

-brett

[Håkon Alseth]

Hi,

 

Brett said:

Again they all appear to show something different, so what is the actual Active timer that is going to be used ?  Which one do I trust ?  I imagine its the AT command as its matches what I asked to be set, if so, what are the other values

You have to remember that it is the network that takes all the decisions here.

AT+CPSMS is what you, as the nRF, request to the network (ie. your wanted configuration).

XMONITOR reports back what the network sets.

 

XMONITOR shows the actual applied configuration.

Brett said:

EG: Batch GPS at a rate of 1 transfer per 30 seconds or dont ever set an LTE active timer to less than X seconds or make sure you do something with MQTT or you will always see problems ?

Can you please verify your timing of the MQTT link?

As per your example: If you send every 30 seconds, the GPS will highly likely always be blocked by the LTE network, as it takes a bit of time before you enter PSM again. Each network has a required paging period, usually in the order of seconds to minute, to ensure that services like SMS etc. is polled.

 

Kind regards,

Håkon

[Brett]

Hi Håkon,

Håkon Alseth said:

You have to remember that it is the network that takes all the decisions here.

AT+CPSMS is what you, as the nRF, request to the network (ie. your wanted configuration).

XMONITOR reports back what the network sets.

OK I think I get it. 

Even when you query with AT+CPSMS?, the response is not from the network, its what you requested.  The actual value is retrieved only by use the XMONITOR command.  Is that correct ?
A little confusing for me after reading the docs, but no problems.

Håkon Alseth said:

Can you please verify your timing of the MQTT link?

As per your example: If you send every 30 seconds, the GPS will highly likely always be blocked by the LTE network, as it takes a bit of time before you enter PSM again. Each network has a required paging period, usually in the order of seconds to minute, to ensure that services like SMS etc. is polled.

Thats really the question from me to you :) What should I be setting them to, or what is the best practice ?

A little background might help give some context.

Although testing on the 9160DK, I will be deploying on the thingy91.

I am building a unit that will receive  bicycle power data on the 52840 (ANT+), transfer over UART to the 9160  and then transmit to an MQTT broker. At the same time the 9160 will capture GPS data and transmit to the same broker. This doesnt have to be real time, but near real-time would be nice - a delay in transmission of up to 60 seconds is ok, but shorter is better. I plan on caching the data in a queue until its time to send and will then batch transmit.

Therefore, I am not sure what timers to set, do I go with an active of 2 seconds it will go into PSM mode faster, then GPS get more bandwidth?  I am assuming the data transfer will be pretty small, its basic telemetry data so transmission should be a second or 2.  Therefore, once sent, PSM mode should kick in pretty quick - and repeat.

Or is there something that I am completely missing here?

MQTT keepalive is set to 1200, but I dont see keepalive as an issue, because there will be enough data being sent, so it should never drop out - if it does, I have a poll/input/ping setup when time gets close.

regards
-brett