Hi,
For nRF9160, configured for GPS plus LTE: What version of nRF Connect SDK supports GPS+LTE in eDRX mode? Also, are there any plans to provide modem support for GPS+LTE for situations where neither PSM nor eDRX mode is supported by the network provider (without the firmware needing to configure modem for LTE only, then disconnect, then configure modem for GPS only, then switch back to LTE only)?
Thanks
Hi!
What version of nRF Connect SDK supports GPS+LTE in eDRX mode?
This functionality is actually implemented in the modem FW. It looks like this has been supported since MFW v1.1.0, so you can use NCS v.1.1.0 and up. We recommend using the latest version of NCS and MFW.
I don't know of any plans to support GPS+LTE without PSM or eDRX, but I will double-check and get back to you, just to be sure.
Best regards,
Heidi
I received an answer with regard to your second question.
In scenarios where eDRX and PSM are not available, the GPS can be configured to have prioritized access to the radio resources. This is currently supported in NCS by using the priority member in the gps_config struct that's used when starting the GPS (nrf/include/drivers/gps.h#L148).
An example of its use can be found in the A-GPS sample in NCS (see nrf/samples/nrf9160/agps/src/main.c#L59)
When the flag is set, the modem will provide longer time windows to the GNSS engine where it can access the radio without interruptions. This should increase the likelihood of getting a fix without PSM and eDRX.
Hi Heidi,
Thanks for the feedback. I have a few follow-up questions.
So in the scenario you described - where eDRX ad PSM are not available, the modem is configured for GPS+LTE, and GPS is configured in the gps_config struct to have prioritized access to the radio resources:
1. Does the GPS still need to wait for the RRC state to switch from RRC-Connected mode to RR-Idle mode before the GPS can access the modem? In other words, does the prioritized GPS only have priority over LTE (and GPS access) during RR-Idle mode, and not during RRC-Connected mode?
2. You mentioned the modem provides longer time windows for the GNSS engine to access the radio without interruptions. Please elaborate. Which time windows are you referring to and what is being done by the modem to make those windows longer? Please reference specific LTE terminology so I can know specifically what is happening. Are you referring to the I-DRX (RRC-Idle mode DRX) Cycles? Does this mean the modem is not monitoring some of the Paging Frames for paging messages? Does it provide the longer time windows in a deterministic manner?
3. Could you please provide some AT modem commands we can issue (for instances when we are not granted PSM or eDRX by the network) that will allow us to determine how often we can expect to be able to get a time window for getting new GPS PVT data?
Thanks!
Hi!
I've forwarded your follow-up questions to our GPS/LTE experts and I'll get back to you with a reply shortly.
Best regards,
Heidi
Hi!
Here is the reply from one of or GPS experts.
We won't talk about the details around modem domain implementations like "time windows". It's not that relevant, because people will understand that we are using the same radio resources for both, i.e. there must be some kind of time-based co-existence control for this.
1. The GNSS API can be used to temporarily raise the GPS priority over some LTE (RRC) idle mode functionality. GPS is not possible when in LTE (RRC) connected mode, so there is no need to wait until the modem is in idle before a GPS fix is requested because a request can only proceed after the device is released from connected mode. It might still be a good idea from a GPS standpoint, as there is the possibility to have some additional time for the GPS before the LTE idle mode procedures begin after the connection release.
2. Priority can be used to help the GPS get into a state where it does not require long continuous times to be able to produce fixes anymore. The modem will miss some LTE paging occasions when the GPS priority has been configured, but there are measures taken so that the paging occasions won't be missed for no reason and not too often, hence it is not possible to say exactly when those are missed.
One example use-case where the ability to produce GPS fixes without the long LTE sleep times of eDRX/PSM will be blocked because the ephemeris is outdated. By setting this temporary priority for the GPS over some LTE idle mode functionalities, the GPS will get enough time to download the ephemeris when we know that it should be able to do it -> LTE pages can be missed for a few tens of seconds.
There are no problems with LTE idle mode behavior if there are no device use-cases that would start from DL data. In other devices, it is naturally more safe to use if priority usage can be designed so that it will not overlap with use-cases that start from DL data.
3. The unsolicited result code +CEDRXP shows whether eDRX is allowed to be used. You can enable this by setting +CEDRXS=2. Also using the read command %XMONITOR.
The unsolicited result code +CEREG shows whether PSM is allowed to be used. If there is a valid value in the <Active-Time> parameter, then PSM can be used.
Be aware that the standard +CEREG only shows the PSM sleep time (<Periodic-TAU>) if the network isn't using the extended timer (T3412 versus T3412ext). If extended periodic TAU is being used, that value can be read using %XMONITOR.
This information is partly available via the GNSS API as well. There is a parameter that indicates whether the GPS fix was not possible due to the LTE functionality blocking the GPS. This temporary priority for GPS could help to get a fix in those scenarios.
