This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

GPS Position Fix interval

Hi,

I need some help in explaining the GPS behaviour I am observing. In the following figures the GPS current draw is depicted.

For the specific scenario the position fix interval is set to 15min (900 sec).

What I observed is that the GPS started outputting positions fixes at about 12min (1 position fix per second),

it then stopped and gave another position fix on the 15min interval.

In the 2 hours scenario I am currently examining, this pattern is observed many times. As a result the GPS gave 596 position fixes instead of 8.

I guess that this pattern has an impact on the energy consumption.

In the figure below you can see the full 2 hours capture.

Please advise, is this behaviour expected?

Is there any wrong configuration that I may have done?

Kind regards,

Panagiotis.

Parents
  • Hi,

     

    1. What is the modem fw version you're using?

    2. Can you share your exact socket options for the GNSS socket?

     

    Kind regards,

    Håkon

  • Hi Hakon,

    1. I have recently updated to 1.2.1 (now I see there is 1.2.2).
      Is there any command that I could add to my code in order to print the modem firmware during boot and hence I can have it on my debugging logs?

    2. In the following figure you can see my programming sequence

      where : 
      1. CONFIG_GPS_PSM_MODE=0
      2. CONFIG_GPS_FIX_RETRY=0
      3. CONFIG_GPS_FIX_INTERVAL=900
      4. CONFIG_GPS_ELEVATION_MASK=5
      5. CONFIG_GPS_GNSS_MASK=31

    3. My board version is 0.8.3.

    Thank you in advance.

    Kind regards,

    Panos.

  • Hi Hakon, 

    Thank you for your reply!!!!

    In the following figure you can see the behaviour of the GPS for both the "modified" (in green) and the "original" (in red) version of the "samples/nrf9160/gps" example. In both cases we get the same behaviour.

    I am also attaching gps.zip file with the source code, where in line 143 of the main.c file you can find my modifications. 

    What is not clear to me, is why the GPS started outputting position fixes before the interval of the 900 sec has been elapsed. I would expect that after the first position fix it would wait 900 sec before the next position fix. 

    Thank you for your time and your support.

    Kind regards,

    Panos.

  • Hi Panos,

     

    Thank you very much for confirming your settings. I see the same behavior as you, where there's approx. 2 minutes after the initial 15 minutes has passed, the GPS takes another fix. I'm checking internally to get a better overview of what happens here. I will get back to you again soon

     

    Kind regards,

    Håkon

  • Hi Panos,

     

    Sorry for the delayed answer.

    The spikes are indeed expected from a modem point-of-view, and are scheduled downloads of ephemerides and almanac, but it looks like we do not mention this properly in the documentation part. I will create an internal issue on this documentation issue.

    Here's the answer from our R&D group:

    When the GNSS receiver has determined that it needs to download ephemerides or almanacs from the broadcast, the fix interval and fix retry parameters are ignored. The estimated download time window takes precedence over the normal on/off scheduling.

    So, regardless of the fix interval, GNSS will try to download almanacs for all satellites. Each scheduled download takes about one minute and those are done every 12,5 minutes. Usually, 13 cycles are needed to download all almanacs. When GNSS has fresh almanacs for all satellites, the scheduled downloads are stopped and GNSS should respect the set fix interval. New almanacs will be automatically downloaded every three days to keep the almanacs always fresh.

    There's no way to disable scheduled downloads in periodic mode when GNSS is running all the time. However, it is possible to prevent scheduled downloads by starting GNSS whenever a fix is needed and stopping it right after the fix.

     

    In general, since we have done improvements on the GPS in mfw v1.2.2, we recommend that you upgrade to this version.

     

    Kind regards,

    Håkon

  • Hi Håkon,

    thank you for your response!!!!

    I have a few more questions.

    1. During the ephemerides and almanacs downloading the GPS outputted position fixes, is this normal? Is there any configuration option for avoiding position fixes during ephemerides/almanacs downloading? (It was a little bit misleading for me).

    2. Would that lead to always cold starting the GPS?
      There's no way to disable scheduled downloads in periodic mode when GNSS is running all the time. However, it is possible to prevent scheduled downloads by starting GNSS whenever a fix is needed and stopping it right after the fix.

    3. I guess that when AGPS/libsupl is enabled, the ephemerides and almanacs are downloaded using the LTE modem. Ephemerides and almanacs are downloaded once, after the chip has booted, and they are refreshed periodically every three days (again via LTE). Is that true?

    Kind regards,

    Panos.

  • Hi Panos,

     

    Panagiotis Galiatsatos said:
    During the ephemerides and almanacs downloading the GPS outputted position fixes, is this normal? Is there any configuration option for avoiding position fixes during ephemerides/almanacs downloading? (It was a little bit misleading for me).

    Yes, this is unfortunately the case. I would recommend that you setup a dedicated thread for gps polling if you plan to use this mode.

    Panagiotis Galiatsatos said:
    Would that lead to always cold starting the GPS?

    Stopping it doesn't always lead to a cold start, unless you close the socket and re-open it again with a delete_mask set (or you reboot the nRF).

    The almanac will be stored after a while, and the ephemerides are only valid for up to 4 hours (and depending on "where in this time-span" you downloaded them from the GPS). It will not be a fully cold start, but the ephemerides might have to be refreshed if hours have gone by since the last gps-fix.

    Panagiotis Galiatsatos said:
    I guess that when AGPS/libsupl is enabled, the ephemerides and almanacs are downloaded using the LTE modem. Ephemerides and almanacs are downloaded once, after the chip has booted, and they are refreshed periodically every three days (again via LTE). Is that true?

     Almanac is valid for a long time, but ephemerides needs to be refreshed. If you plan to use AGPS/libsupl, it might be beneficial to download these when you're active on the LTE network (ie: sending or receiving)

     

    Kind regards,

    Håkon

Reply
  • Hi Panos,

     

    Panagiotis Galiatsatos said:
    During the ephemerides and almanacs downloading the GPS outputted position fixes, is this normal? Is there any configuration option for avoiding position fixes during ephemerides/almanacs downloading? (It was a little bit misleading for me).

    Yes, this is unfortunately the case. I would recommend that you setup a dedicated thread for gps polling if you plan to use this mode.

    Panagiotis Galiatsatos said:
    Would that lead to always cold starting the GPS?

    Stopping it doesn't always lead to a cold start, unless you close the socket and re-open it again with a delete_mask set (or you reboot the nRF).

    The almanac will be stored after a while, and the ephemerides are only valid for up to 4 hours (and depending on "where in this time-span" you downloaded them from the GPS). It will not be a fully cold start, but the ephemerides might have to be refreshed if hours have gone by since the last gps-fix.

    Panagiotis Galiatsatos said:
    I guess that when AGPS/libsupl is enabled, the ephemerides and almanacs are downloaded using the LTE modem. Ephemerides and almanacs are downloaded once, after the chip has booted, and they are refreshed periodically every three days (again via LTE). Is that true?

     Almanac is valid for a long time, but ephemerides needs to be refreshed. If you plan to use AGPS/libsupl, it might be beneficial to download these when you're active on the LTE network (ie: sending or receiving)

     

    Kind regards,

    Håkon

Children
No Data
Related