• State Not Answered
  • Replies 1 reply
  • Subscribers 75 subscribers
  • Views 282 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 248011
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Understanding of GPS fix_interval and fix_retry

Siyou

Hi，

We want to confirm the effect of GPS fix_interval and fix_retry, so we start GPS with parameter fix_interval=10s, and fix_retry=30s, then get the result as the following log.

/**@brief Defines the interval between each fix in seconds.
 * @details The default interval is 1 second. 0 denotes a single fix.
 */
typedef uint16_t nrf_gnss_fix_interval_t;


/**@brief Defines how long (in seconds) the receiver should try to get a fix.
 * @details The default retry wait time is 60 seconds before it gives up.
            0 denotes an infinite limit.
 */
typedef uint16_t nrf_gnss_fix_retry_t;

1, In my understanding, the fix_interval is the interval between each fix, so the received fix data's timestamp difference of each fix should greater than or equal to this fix_interval, right? But in our test(see below log), the fix data's interval has no association to fix_interval: sometime the fix data's interval is 1s but not 10s(fix_interval)

2, How to understand fix_retry? we think it is the time period of satellite searching, when the search time is more than the fix_retry, the satellite searching should stop, but it also was not meet with our test result(as below log): the atellite searching has not gave up more than 30s(fix_retry)?

00> [00:00:17.585,205] <inf> agps: AGPS is not enabled.
00> [00:00:17.598,571] <inf> agps: GPS started
00> [00:00:17.626,831] <inf> agps: Tracking:0 Using:0 Unhealthy:0, since last fix 0s
00> [00:00:18.624,786] <inf> agps: Tracking:2 Using:0 Unhealthy:0, since last fix 1s
00> [00:00:19.625,335] <inf> agps: Tracking:3 Using:0 Unhealthy:0, since last fix 2s
00> [00:00:20.625,000] <inf> agps: Tracking:3 Using:0 Unhealthy:0, since last fix 3s
00> [00:00:21.624,572] <inf> agps: Tracking:3 Using:0 Unhealthy:0, since last fix 4s
00> [00:00:22.625,305] <inf> agps: Tracking:3 Using:0 Unhealthy:0, since last fix 5s
00> [00:00:23.625,823] <inf> agps: Tracking:3 Using:0 Unhealthy:0, since last fix 6s
00> [00:00:24.625,610] <inf> agps: Tracking:3 Using:0 Unhealthy:0, since last fix 7s
00> [00:00:25.625,030] <inf> agps: Tracking:4 Using:0 Unhealthy:0, since last fix 8s
00> [00:00:26.625,823] <inf> agps: Tracking:4 Using:0 Unhealthy:0, since last fix 9s
00> [00:00:27.625,793] <inf> agps: Tracking:4 Using:0 Unhealthy:0, since last fix 10s
00> [00:00:28.626,098] <inf> agps: Tracking:4 Using:0 Unhealthy:0, since last fix 11s
00> [00:00:29.626,281] <inf> agps: Tracking:5 Using:0 Unhealthy:0, since last fix 12s
00> [00:00:30.625,793] <inf> agps: Tracking:5 Using:0 Unhealthy:0, since last fix 13s
00> [00:00:31.626,556] <inf> agps: Tracking:5 Using:0 Unhealthy:0, since last fix 14s
00> [00:00:32.626,037] <inf> agps: Tracking:6 Using:0 Unhealthy:0, since last fix 15s
00> [00:00:33.626,525] <inf> agps: Tracking:6 Using:0 Unhealthy:0, since last fix 16s
00> [00:00:34.627,105] <inf> agps: Tracking:7 Using:0 Unhealthy:0, since last fix 17s
00> [00:00:35.627,899] <inf> agps: Tracking:7 Using:0 Unhealthy:0, since last fix 18s
00> [00:00:36.626,953] <inf> agps: Tracking:7 Using:0 Unhealthy:0, since last fix 19s
00> [00:00:37.627,929] <inf> agps: Tracking:7 Using:0 Unhealthy:0, since last fix 20s
00> [00:00:38.627,990] <inf> agps: Tracking:7 Using:0 Unhealthy:0, since last fix 21s
00> [00:00:39.627,777] <inf> agps: Tracking:7 Using:0 Unhealthy:0, since last fix 22s
00> [00:00:40.636,657] <inf> agps: Tracking:7 Using:3 Unhealthy:0, since last fix 23s
00> [00:00:41.633,361] <inf> agps: Tracking:7 Using:3 Unhealthy:0, since last fix 24s
00> [00:00:42.633,880] <inf> agps: Tracking:7 Using:3 Unhealthy:0, since last fix 25s
00> [00:00:43.632,965] <inf> agps: Tracking:7 Using:3 Unhealthy:0, since last fix 26s
00> [00:00:44.633,911] <inf> agps: Tracking:7 Using:3 Unhealthy:0, since last fix 27s
00> [00:00:45.633,941] <inf> agps: Tracking:7 Using:3 Unhealthy:0, since last fix 28s
00> [00:00:46.633,300] <inf> agps: Tracking:7 Using:3 Unhealthy:0, since last fix 29s
00> [00:00:47.633,850] <inf> agps: Tracking:7 Using:3 Unhealthy:0, since last fix 30s
00> [00:00:48.633,544] <inf> agps: Tracking:7 Using:3 Unhealthy:0, since last fix 31s
00> [00:00:49.633,361] <inf> agps: Tracking:7 Using:3 Unhealthy:0, since last fix 32s
00> [00:00:50.633,941] <inf> agps: Tracking:7 Using:3 Unhealthy:0, since last fix 33s
00> [00:00:51.634,521] <inf> agps: Tracking:7 Using:3 Unhealthy:0, since last fix 34s
00> [00:00:52.633,911] <inf> agps: Tracking:7 Using:3 Unhealthy:0, since last fix 35s
00> [00:00:53.633,544] <inf> agps: Tracking:7 Using:3 Unhealthy:0, since last fix 36s
00> [00:00:54.634,094] <inf> agps: Tracking:7 Using:3 Unhealthy:0, since last fix 37s
00> [00:00:55.634,185] <inf> agps: Tracking:7 Using:3 Unhealthy:0, since last fix 38s
00> [00:00:56.633,483] <inf> agps: Tracking:7 Using:3 Unhealthy:0, since last fix 39s
00> [00:00:57.634,368] <inf> agps: Tracking:7 Using:3 Unhealthy:0, since last fix 40s
00> [00:00:58.656,921] <inf> agps: GPS first position fix: TTFF 41 sec
00> [00:00:58.657,196] <inf> agps: 20200417085719.077,31.290483,121.440186
00> [00:01:08.699,401] <inf> agps: 20200417085729.115,31.290409,121.440039
00> [00:01:18.698,974] <inf> agps: 20200417085739.115,31.290383,121.440061
00> [00:01:28.698,577] <inf> agps: 20200417085749.115,31.290383,121.440081
00> [00:01:29.697,174] <inf> agps: 20200417085750.115,31.290375,121.440085
00> [00:01:30.696,594] <inf> agps: 20200417085751.115,31.290380,121.440088
00> [00:01:31.695,983] <inf> agps: 20200417085752.115,31.290385,121.440090
00> [00:01:32.696,014] <inf> agps: 20200417085753.115,31.290387,121.440095
00> [00:01:33.697,387] <inf> agps: 20200417085754.115,31.290391,121.440100
00> [00:01:34.697,662] <inf> agps: 20200417085755.115,31.290393,121.440097
00> [00:01:35.696,075] <inf> agps: 20200417085756.115,31.290396,121.440094
00> [00:01:36.696,746] <inf> agps: 20200417085757.115,31.290399,121.440089
00> [00:01:37.697,418] <inf> agps: 20200417085758.115,31.290398,121.440089
00> [00:01:38.696,716] <inf> agps: 20200417085759.115,31.290401,121.440084
00> [00:01:39.696,716] <inf> agps: 20200417085800.115,31.290402,121.440080
00> [00:01:40.696,807] <inf> agps: 20200417085801.115,31.290406,121.440077
00> [00:01:41.696,075] <inf> agps: 20200417085802.115,31.290407,121.440072
00> [00:01:42.697,326] <inf> agps: 20200417085803.115,31.290407,121.440067
00> [00:01:43.696,685] <inf> agps: 20200417085804.115,31.290407,121.440069
00> [00:01:44.696,289] <inf> agps: 20200417085805.115,31.290407,121.440068
00> [00:01:45.696,441] <inf> agps: 20200417085806.115,31.290407,121.440066
00> [00:01:46.698,394] <inf> agps: 20200417085807.115,31.290407,121.440062
00> [00:01:47.616,485] <inf> agps: GPS stopped

Parents
  • 0

    Hello,

     

    1, In my understanding, the fix_interval is the interval between each fix, so the received fix data's timestamp difference of each fix should greater than or equal to this fix_interval, right? But in our test(see below log), the fix data's interval has no association to fix_interval: sometime the fix data's interval is 1s but not 10s(fix_interval)

     

    Fix interval parameter controls the time between GNSS receiver starts. It also controls whether the GNSS receiver is stopped after a valid PVT estimate. The fix interval parameter determines the mode of navigation. There are three different navigation modes available: single-fix, continuous, and periodic.

    Single-fix navigation mode is engaged by setting the fix interval to 0. In this mode once a valid PVT estimate is produced, the GNSS receiver is turned off indefinitely. It will not resume navigation without explicit actions by the application processor. To do another single-fix, the application processor can restart the single-fix navigation mode by sending Control Request with start command. Even though the first valid PVT estimate causes the GNSS receiver to be turned off, internally it remains in started state as there has not been a stop command canceling the previous start command. Therefore, to re-configure, the application processor must stop the GNSS receiver by sending Control Request before re-configuring by sending Configuration Set Requests.

    Continuous navigation mode is engaged by setting fix interval to 1. In this mode the GNSS receiver continues producing fixes at 1 Hz rate without any time limit.

    Periodic navigation mode is engaged by setting the fix interval to value other than zero or one. In this mode the GNSS receiver is turned off after each valid PVT estimate, and turned back on periodically after each fix interval has passed.

     

    2, How to understand fix_retry? we think it is the time period of satellite searching, when the search time is more than the fix_retry, the satellite searching should stop, but it also was not meet with our test result(as below log): the atellite searching has not gave up more than 30s(fix_retry)?

     

    Fix retry parameter controls the maximum time the GNSS receiver is allowed to run while trying to produce a valid PVT estimate. If the fix retry time is non-zero, the GNSS receiver is turned off after the fix retry time is up regardless of whether a valid PVT estimate was produced or not. If fix retry parameter is set to zero, the GNSS receiver is allowed to run indefinitely until a valid PVT estimate is produced.
    I hope this was informative.
Reply
  • 0

    Hello,

     

    1, In my understanding, the fix_interval is the interval between each fix, so the received fix data's timestamp difference of each fix should greater than or equal to this fix_interval, right? But in our test(see below log), the fix data's interval has no association to fix_interval: sometime the fix data's interval is 1s but not 10s(fix_interval)

     

    Fix interval parameter controls the time between GNSS receiver starts. It also controls whether the GNSS receiver is stopped after a valid PVT estimate. The fix interval parameter determines the mode of navigation. There are three different navigation modes available: single-fix, continuous, and periodic.

    Single-fix navigation mode is engaged by setting the fix interval to 0. In this mode once a valid PVT estimate is produced, the GNSS receiver is turned off indefinitely. It will not resume navigation without explicit actions by the application processor. To do another single-fix, the application processor can restart the single-fix navigation mode by sending Control Request with start command. Even though the first valid PVT estimate causes the GNSS receiver to be turned off, internally it remains in started state as there has not been a stop command canceling the previous start command. Therefore, to re-configure, the application processor must stop the GNSS receiver by sending Control Request before re-configuring by sending Configuration Set Requests.

    Continuous navigation mode is engaged by setting fix interval to 1. In this mode the GNSS receiver continues producing fixes at 1 Hz rate without any time limit.

    Periodic navigation mode is engaged by setting the fix interval to value other than zero or one. In this mode the GNSS receiver is turned off after each valid PVT estimate, and turned back on periodically after each fix interval has passed.

     

    2, How to understand fix_retry? we think it is the time period of satellite searching, when the search time is more than the fix_retry, the satellite searching should stop, but it also was not meet with our test result(as below log): the atellite searching has not gave up more than 30s(fix_retry)?

     

    Fix retry parameter controls the maximum time the GNSS receiver is allowed to run while trying to produce a valid PVT estimate. If the fix retry time is non-zero, the GNSS receiver is turned off after the fix retry time is up regardless of whether a valid PVT estimate was produced or not. If fix retry parameter is set to zero, the GNSS receiver is allowed to run indefinitely until a valid PVT estimate is produced.
    I hope this was informative.
Children
No Data
Related
Terms of service