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

[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

[Håkon Alseth]

Hi,

 

Brett said:

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.

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

Brett said:

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.

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

[Torje]

Hey Håkon,

Reading this thread I noticed this:

Håkon Alseth said:

You should only request either eDRX or PSM.

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

[Håkon Alseth]

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

[Brett]

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