GPS current consumption abnormal

[Siyou]

Hi

We found abnormal current waveform when running GPS as 120s fix interval and 10s fix retry.

As below pic, the first plus is A-GPS seraching, from second plus is the fix current, but you can see the second fix(third plus) has followed a very wide(it is far beyond 10s fix retry) current plus, what's the reason of this current plus?

[Håkon Alseth]

Hi,

 

Could that be a TAU or any other communication towards the LTE network? Hard to say, as a TX peak might be "averaged out", and the RX current of the GPS operation is very similar to the RX current on LTE.

How often do you see this spike?

What is your PSM settings that the network gives you? You can read those out using function "lte_lc_psm_get()"

 

As below pic, the first plus is A-GPS seraching

Note that every time you send a packet over LTE, you exit PSM, and stay in RRC idle for a given period (different from network-to-network, usually around 60 seconds), before entering PSM successfully again. During this time, the GPS socket is blocked. A AGPS session should be longer than just a few seconds, unless you turn off the LTE link afterwards.

 

Could you share what your application is doing on the LTE part?

 

Kind regards,

Håkon

  

[Siyou]

Håkon Alseth said:

How often do you see this spike?

What is your PSM settings that the network gives you? You can read those out using function "lte_lc_psm_get()"

In our testing, the GPS current pulse is about 50mA but the LTE current pulse is less than 40mA, as the picture in the first post, the LTE is disabled and all the pulses are GPS current consumption. After the third fix, the abnormal pulse's width is about 1 minute, what is the root cause of the abnormal current? from debug log, the GPS reported postion fixes every 1 second during the 1 minute abnormal current period, before or after that abnormal period, postion fix report interval was the configured 120s.

-------------------------------------------------------------------------------------------------------------------------------

In the second post, the purpose is to show the evidence that GPS could not get fix anymore if we start LTE after the first GPS fix. You can see the second pulse(about 30s wide and 35mA high) is the LTE searching and connecting current consumption, then LTE will enter into eDRX(AT+CEDRXS=2,4,"1000"). Our test result is:

1, If we start/activate LTE after the first GPS fix, the subsequent GPS fix attempts will be failed, GPS will no longer to get new GPS fix;

2, If we start/activate LTE after the fourth or the fifth GPS fix, then the GPS could work well with LTE concurrently.

[Håkon Alseth]

Hi,

 

Siyou said:

In our testing, the GPS current pulse is about 50mA but the LTE current pulse is less than 40mA, as the picture in the first post, the LTE is disabled and all the pulses are GPS current consumption

 Disabled (CFUN=4 / CFUN=0) or in PSM/eDRX mode?

 

Siyou said:

is the LTE searching and connecting current consumption, then LTE will enter into eDRX(AT+CEDRXS=2,4,"1000").

 When entering eDRX or PSM, you have a small period where the radio is listening before successfully entering the mode you requested. That period is normally 60 seconds, but as mentioned; It may vary from network-to-network.

In cases where you for instance; fetch AGPS data, then immediately afterwards start the GPS, you are then blocked by the LTE connection for a given period before the GPS successfully starts sampling.

 

Can you share what you are doing in firmware, so that I get a better overview?

 

Kind regards,

Håkon

[Siyou]

Hi,

Let me clarify my operations as below:

Start LTE: AT+CFUN=21
Stop LTE: AT+CFUN=20
Enable GPS: AT+CFUN=31
Disable GPS: AT+CFUN=30

Håkon Alseth said:

Disabled (CFUN=4 / CFUN=0) or in PSM/eDRX mode?

In 1st picture, the current pulse under marker m1 is the current consumption from start GPS to the first postion fix. The detail operations are as below:

Enable GPS --> received NRF_GNSS_AGPS_DATA_ID --> suspend GPS by NRF_SO_GNSS_STOP --> start LTE and wait untill connected --> start SUPL session --> downlaod SUPL data is finished --> stop LTE -->resume GPS by NRF_SO_GNSS_START --> searching satellites and get postion fix --> GPS fix --> GPS interval --> GPS fix....

The 2nd to 4th pictures were testing the concurrent of GPS and LTE, so the operations were same as 1st picture with additional operation to start LTE after A-GPS get first fix. That is:
Enable GPS --> received NRF_GNSS_AGPS_DATA_ID --> suspend GPS by NRF_SO_GNSS_STOP --> start LTE and wait untill connected --> start SUPL session --> downlaod SUPL data is finished --> stop LTE -->resume GPS by NRF_SO_GNSS_START --> searching satellites and get postion fix --> start LTE --> connected to LTE network and enter into eDRX --> GPS fix --> GPS interval --> GPS fix....
You can see the 2nd current pulse(about 30s wide) is device to search, connect to LTE network and then enter into eDRX, and after connected to nwk, there is no any further send/recive packet operation in LTE nwk, so all the subsequent pulses(from 3rd pulse) are the current of GPS fix retry, and all the fix retry were timeout/failed. (Note: the issue only happened when GPS fix interval is 120s or 60s, will not happen if GPS fix interval is 1s and fix retry is 0)

Q1, In picture1, what's the reason of the 1 minute wide abnormal current pulse?

Q2, According to the picture2~4, why the GPS could not get fix anymore after started LTE network? 

[Håkon Alseth]

Hi,

 

The 3 screenshots you posted:

 

This looks like 60 sec, ~20 sec timeout, corresponding to what you set.

This one as well, where it waits until it gets a fix.

  

This also looks spot on per your configuration (120 / 60 sec)

 

The initial current profile does not fully match your settings:

It looks like there is a sequence that is occurring after the 3rd GPS retry.

 

Q1: Can you please share exactly how the firmware is setting up this sequence?

Q2: Which ncs version are you using? and which modem FW is used?

Q3: On the 3rd current pulse, what happens after the GPS socket is started again? Does the firmware do anything towards the modem at this point, like writing to CFUN register?

It would help to see code to get a better overview here.

 

Kind regards,

Håkon

[Siyou]

With further test, we found the unable fix issue is only happened when measuring nRF9160 current(powered by external power supply), there is no issue when it works with on-board power supply. Please close this ticket, thanks!