nrf9160: LTE + GPS + MQTT - GPS Blocked

RE: nrf9160: LTE + GPS + MQTT - GPS Blocked

Håkon Alseth — Tue, 28 Jun 2022 12:55:14 GMT

Hi Brett,

[quote user="Brett"]The CONFIG_MQTT_KEEPALIVE is set to 1200, so its a bit different. The more confusing part is that there are no GNSS events at all. Usually when its in a BLOCKED state, I still get some events come in - even if its not a FIX.[/quote]

Do you have any asynchronous threads / interrupts that trigger a send() from the application? That will cause the modem to immediately start sending, thus blocking the GNSS from running until you're in idle again.

Do you print the CSCON notification? If so, you should see that the link becomes active if this is the case.

[quote user="Brett"]I have another issue in this project where the mqtt_publish is blocking (it hits the mutex_lock and never comes out), it looks the same as caseID 232209, which you also worked on. Am I best to open a new case to keep the topic of this case consistent, or is it ok to ask that question in here, since it still kind of related ?[/quote]

If this is related to the above scenario, the modem might be trying to send data (if the link quality is bad for instance).

If this is an issue that you are able to reproduce, I would recommend that you open a new case, and attach a application log output + a modem trace showing the issue.

Kind regards,

Håkon

RE: nrf9160: LTE + GPS + MQTT - GPS Blocked

Brett — Tue, 28 Jun 2022 11:38:52 GMT

Hi Håkon

[quote userid="2115" url="~/f/nordic-q-a/88863/nrf9160-lte-gps-mqtt---gps-blocked/374299"]Could this be because of the mqtt keep-alive going active? This is a "ping" to the server to maintain the mqtt connection, which happens every "CONFIG_MQTT_KEEPALIVE".[/quote]

The CONFIG_MQTT_KEEPALIVE is set to 1200, so its a bit different. The more confusing part is that there are no GNSS events at all. Usually when its in a BLOCKED state, I still get some events come in - even if its not a FIX.

I have another issue in this project where the mqtt_publish is blocking (it hits the mutex_lock and never comes out), it looks the same as caseID 232209, which you also worked on. Am I best to open a new case to keep the topic of this case consistent, or is it ok to ask that question in here, since it still kind of related ?

regards
-brett

RE: nrf9160: LTE + GPS + MQTT - GPS Blocked

Håkon Alseth — Mon, 27 Jun 2022 09:11:52 GMT

Hi Brett,

[quote user="Brett"]I have most of this working now, or well enough. The transition times between BlOCKED, UNBLOCKED and transfer are manageable for this testing.[/quote]

I'm glad to hear of this progress!

[quote user="Brett"]However, after about 200->300 seconds it varies, I stop getting any GNSS events. I know, the system is still running as I have a poll on 5seconds and it keeps counting up.

The unit is not moving whilst I am testing, but is there any reason it would go to sleep after X period ?[/quote]

Could this be because of the mqtt keep-alive going active? This is a "ping" to the server to maintain the mqtt connection, which happens every "CONFIG_MQTT_KEEPALIVE".

Depending on the network you're connected to, and its overall routing/firewall rules etc, this can be in the range of 1 minute to tens of minutes. Each network has its own individual limitations on this.

Kind regards,

Håkon

RE: nrf9160: LTE + GPS + MQTT - GPS Blocked

Brett — Fri, 24 Jun 2022 20:30:46 GMT

Hi Håkon,

I have most of this working now, or well enough. The transition times between BlOCKED, UNBLOCKED and transfer are manageable for this testing.

However, after about 200->300 seconds it varies, I stop getting any GNSS events. I know, the system is still running as I have a poll on 5seconds and it keeps counting up.

The unit is not moving whilst I am testing, but is there any reason it would go to sleep after X period ?

I dont have any timers or sleep intervals in my configuration.

regards
-brett

RE: nrf9160: LTE + GPS + MQTT - GPS Blocked

Håkon Alseth — Tue, 21 Jun 2022 14:08:12 GMT

You cannot be in two modes at the same time, there must be a transition in between.

You can be in PSM, break it to enter eDRX for a given time period, and then go back to PSM, but you cannot request both at once.

Kind regards,

Håkon

RE: nrf9160: LTE + GPS + MQTT - GPS Blocked

Torje — Tue, 21 Jun 2022 13:19:36 GMT

Hey Håkon,

Reading this thread I noticed this:

[quote userid="2115" url="~/f/nordic-q-a/88863/nrf9160-lte-gps-mqtt---gps-blocked/372132"]You should only request either eDRX or PSM.[/quote]

Would you kindly elaborate on this? I recall having read that both can be used, but I might be mistaken. I would greatly appreciate a thorough explanation, thank you!

- Torje

RE: nrf9160: LTE + GPS + MQTT - GPS Blocked

Håkon Alseth — Fri, 17 Jun 2022 11:44:47 GMT

Hi,

[quote user="Brett"]

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.

[/quote]

Yes, this is correct. The timing parameters read out with XMONITOR is your current link parameters.

[quote user="Brett"]

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.

[/quote]

The required paging period before you enter PSM is a set value, depending on what network you're connected to. In one of my local network it is 10 seconds of paging, but in the other its 60 seconds. This means that you're in RRC idle for this amount of time before the link enters PSM mode.

Once you then enter PSM mode, the active time for the PSM will start.

Example:

Paging, also named RRC idle: 60 seconds (Note that this varies from network to network!)

PSM Active Timer: 16 seconds

This means that after a successful MQTT send/receive (actually a TCP transaction), you'll have to wait in total 60+16=76 seconds before you have successfully entered PSM TAU (ie. the lte link is completely idle).

What modem firmware do you use? Newer v1.3.x modems can use the GPS in other idle modes, as described in the modem firmware .zip release notes:

- Improvement for GNSS tracking and satellite search functionality during LTE mode. GNSS is now able
  to search and track satellites while modem is searching LTE network and cells.

Kind regards,

Håkon

RE: nrf9160: LTE + GPS + MQTT - GPS Blocked

Brett — Fri, 17 Jun 2022 10:13:43 GMT

Hi Håkon,

[quote userid="2115" url="~/f/nordic-q-a/88863/nrf9160-lte-gps-mqtt---gps-blocked/372931#372931"]

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.

[/quote]

OK I think I get it.

[quote userid="2115" url="~/f/nordic-q-a/88863/nrf9160-lte-gps-mqtt---gps-blocked/372931#372931"]

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.

[/quote]

regards
-brett

RE: nrf9160: LTE + GPS + MQTT - GPS Blocked

Håkon Alseth — Fri, 17 Jun 2022 07:25:47 GMT

Hi,

[quote user="Brett"]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[/quote]

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.

[quote user="Brett"]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 ?[/quote]

Can you please verify your timing of the MQTT link?

Kind regards,

Håkon

RE: nrf9160: LTE + GPS + MQTT - GPS Blocked

Brett — Fri, 17 Jun 2022 06:53:02 GMT

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

RE: nrf9160: LTE + GPS + MQTT - GPS Blocked

Håkon Alseth — Tue, 14 Jun 2022 12:43:18 GMT

Hi,

[quote user="Brett"]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()[/quote]

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.

[quote user="Brett"]Is there a reason the following commands all give a different answer, are they all looking at different components of the LTE connection?[/quote]

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).

[quote user="Brett"]

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

[/quote]

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

RE: nrf9160: LTE + GPS + MQTT - GPS Blocked

Brett — Tue, 14 Jun 2022 09:15:35 GMT

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

RE: nrf9160: LTE + GPS + MQTT - GPS Blocked

Håkon Alseth — Mon, 13 Jun 2022 12:07:01 GMT

Hi,

[quote user=""]AT+CPSMS? : +CPSMS: 1,,,"00000011","00100001"[/quote]

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

[quote user=""]lte_lc_psm_req(true);
lte_lc_edrx_req(true);[/quote]

You should only request either eDRX or PSM.

[quote user=""]

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 ?

[/quote]

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