• State Not Answered
  • Replies 13 replies
  • Subscribers 75 subscribers
  • Views 3473 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 290490
Options

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

Parents Reply
  • 0 in reply to Håkon Alseth

    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

Children
  • 0 in reply to Brett

    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

  • 0 in reply to Håkon Alseth

    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

  • 0 in reply to Brett

    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

  • 0 in reply to Håkon Alseth

    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

  • 0 in reply to Brett

    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

Related
Terms of service