• State Verified Answer
  • Replies 4 replies
  • Subscribers 86 subscribers
  • Views 370 views
  • Users 0 members are here
Attachments (2) Download All
Nordic Case Info
  • Case ID: 350759
Options

Fallouts in GNSS reception using AT#XGPS=1,1,1 and mobile networking disabled.

Daniel B. J.

Hi,

We are evaluating the NRF9151 for live tracking purposes. While testing with the nRF9151-DK we noticed the we had tracking fallouts using AT#XGPS=1,1,1 both during driving and stationary tests. So in order to only see how the GNSS itself acts we did testing, where after getting a fix the modem will go into GNSS only mode and disconnect from the mobile network.

With a stationary test we got a great result with 99.77% of GNSS positions arriving at 1s +/- 100ms intervals as expected, though still a few arriving with up to ~4s delay. The stationary test was done outside for more than 3 hours with only a plastic box on top to protect against potential rain.

With a driving test we got a few larger breaks in GNSS positions of more than 40s, though still ~98.65% of GNSS positions arrived at an 1s +/- 100ms interval. The large breaks though are noticeable in our application, where we send a position every 10s. The driving test was done with the modem on the passenger seat, while driving through an area with mostly fields, single story houses, mild tree cover at some roads and no tunnels or bridges. The test took about 45mins and went through the same area twice.

Is this expected performance and would it be expected to improve with an external antenna?

Thanks in advance.

Parents
  • 0

    Hello, 

    Can you please provide more information on what modem FW and version of nRF Connect SDK your are running on your device? An external antenna might improve the performance.

    Are you able to provide some logs from your testing, and what settings are used?

    Kind regards,
    Øyvind

  • 0 in reply to Øyvind

    Hello,

    Sorry we are using AT firmware version 2.02 and nRF Connect SDK v5.2.0, but we used our external application MCU during these tests.

    The setup in terms of AT commands looks like this:
    AT
    AT+CFUN=0 (changed to AT+CFUN=4 in newer implementation of our application firmware)
    AT%XCONNSTAT=0
    AT+CMEE=1
    AT+CEREG=5
    AT%MDMEV=1
    AT+CESQ=1
    AT+CEMODE=2
    AT+CIND=1,1,1
    AT+CSCON=1
    AT+COPS=3,2
    AT+CGEREP=1
    AT%XPOFWARN=0,30
    AT%XSYSTEMMODE=1,0,1,1
    AT+CPSMS=0
    AT+CEDRXS=0
    AT+CGDCONT=0,"IP","APN"
    AT%XCOEX0=1,1,1570,1580
    AT%XMAGPIO=1,1,1,1,7,1574,1577
    AT+CFUN=1

    (wait for network registration)

    AT#XNRFCLOUD=1

    When this is recieved: #XNRFCLOUD: 1,0, we start the GNSS with: AT#XGPS=1,1,1

    When the first valid GNSS position has been received we write AT+CFUN=20 in order to only look at GNSS performance.

    I have the logs for the specific tests, but they where taken through our application MCU using YAT on windows 10. TX is from the application MCU, RX is from the nRF9151:

    nRF9151_GNSS_stationary_test_20250822-093956.lognRF9151_GNSS_driving_test_20250821-110155.log

  • +1 in reply to Daniel B. J.

    Hi,

     

    Ideally, we would want the NMEA strings to look at each individual satellite's output, and thus check the SNR.

    This can be done by setting the log output mode in SLM:

    Still, we can look at the "accuracy" parameter here based on the notified value we get back:

    https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/applications/serial_lte_modem/doc/GNSS_AT_commands.html#unsolicited_notification

    which will give us an indication on the overall accuracy of the returned GPS data.

    This "accuracy" parameter is effectively a sum of "dilution of precision":

    https://en.wikipedia.org/wiki/Dilution_of_precision_(navigation)

     

    You want this number to be as low as possible. If we look at  the numbers while driving, especially the ones where you have gaps, the accuracy parameter is 20 to 50 area:

    (11:22:16.340) #XGPS: 55.841264,12.206062,68.760078,24.440924,22.152363,258.476349,"2025-08-21 09:22:16"
(11:23:51.330) #XGPS: 55.834678,12.174893,49.940460,45.608971,20.690598,272.305969,"2025-08-21 09:23:51"
..
(11:28:03.314) #XGPS: 55.835753,12.189951,48.109840,28.087284,14.759391,66.664894,"2025-08-21 09:28:03"
(11:28:35.326) #XGPS: 55.836433,12.197599,83.675026,48.383675,12.404172,63.467396,"2025-08-21 09:28:35"

     This indicates that satellites are going from tracked->untracked, and the total amount of tracked satellites is less than 4.

    The driving test was done with the modem on the passenger seat, while driving through an area with mostly fields, single story houses, mild tree cover at some roads and no tunnels or bridges.

    I suspect that the placement of the device within the car has a great impact. The view it has present when in the seat is fairly limited towards the windshield itself, as compared to being placed in the windshield.

    Note that newer cars have windows and windshields that can attenuate signals better than older cars.

     

    I would need to look at the NMEA strings in both scenarios, especially the GPGSV, as this holds the SNR for each satellite in view, to confirm this theory.

     

    Kind regards,

    Håkon

Reply
  • +1 in reply to Daniel B. J.

    Hi,

     

    Ideally, we would want the NMEA strings to look at each individual satellite's output, and thus check the SNR.

    This can be done by setting the log output mode in SLM:

    Still, we can look at the "accuracy" parameter here based on the notified value we get back:

    https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/applications/serial_lte_modem/doc/GNSS_AT_commands.html#unsolicited_notification

    which will give us an indication on the overall accuracy of the returned GPS data.

    This "accuracy" parameter is effectively a sum of "dilution of precision":

    https://en.wikipedia.org/wiki/Dilution_of_precision_(navigation)

     

    You want this number to be as low as possible. If we look at  the numbers while driving, especially the ones where you have gaps, the accuracy parameter is 20 to 50 area:

    (11:22:16.340) #XGPS: 55.841264,12.206062,68.760078,24.440924,22.152363,258.476349,"2025-08-21 09:22:16"
(11:23:51.330) #XGPS: 55.834678,12.174893,49.940460,45.608971,20.690598,272.305969,"2025-08-21 09:23:51"
..
(11:28:03.314) #XGPS: 55.835753,12.189951,48.109840,28.087284,14.759391,66.664894,"2025-08-21 09:28:03"
(11:28:35.326) #XGPS: 55.836433,12.197599,83.675026,48.383675,12.404172,63.467396,"2025-08-21 09:28:35"

     This indicates that satellites are going from tracked->untracked, and the total amount of tracked satellites is less than 4.

    The driving test was done with the modem on the passenger seat, while driving through an area with mostly fields, single story houses, mild tree cover at some roads and no tunnels or bridges.

    I suspect that the placement of the device within the car has a great impact. The view it has present when in the seat is fairly limited towards the windshield itself, as compared to being placed in the windshield.

    Note that newer cars have windows and windshields that can attenuate signals better than older cars.

     

    I would need to look at the NMEA strings in both scenarios, especially the GPGSV, as this holds the SNR for each satellite in view, to confirm this theory.

     

    Kind regards,

    Håkon

Children
Related
Terms of service