BG95: XTRA feature questions

IoT Modules
1

Hello,

I’m trying to reduce the time to first fix on the BG95 by using the XTRA feature. Although it basically works as described in the GNSS application note I’ve got several questions regarding QGPSXTRATIME that, I think, are not answered in the application note or in the forum explicitly.

Firmware Version: “BG95M3LAR02A04_01.002.01.002”

  1. I observed that even when AT+CCLK returns a valid and (as far as i can tell) correct timestamp, the XTRA time still is unset. So is the RTC not used as “automatic time source” for XTRA (with PSM enabled)?

  2. I observed that right after a power cycle or when the BG95 was shut down QGPSXTRATIME always contains a (as far as i can tell) correct XTRA time. Could the reason be that during startup the XTRA time is updated from network? In contrast to this, when waking up from PSM QGPSXTRATIME is always unset. This is rather unfortunate, as we use PSM a lot. Is there an issue with QGPSXTRATIME when PSM is used?

  3. When PSM is used and QGPSXTRATIME is unset initially (as described in 3.) QGPSXTRATIME seems to be updated automatically right, when a RMC sentence that contains a timestamp is output on the GNSS UART. Is this just by accident or is the GNSS time used as “automatic time source” for XTRA?

  4. Are there any additional “automatic time sources” for XTRA?

If you need more information or something is unclear im happy to provide further information.

Best regards,
Sebastian

2

Is there something not clear with the question? I’d be happy to provide further information if necessary.

3

@Isaac.Wang-Q maybe you got some information?

4

I don’t have a specific answer to your case, but I found the whole XTRA download and related timestamp management in the BG95 buggy and obscure.
I faced similar problems and I ended up with my own procedure. That allows me also to retrieve the timestamp to be used in my device. My procedure is:
-register to network
-try to get a timestamp from AT+QLTS. If that fails use 2 different qntp servers with AT+QNTP commands. Notice that QNTP command can take a lot of time…
-query XTRA timestamp. If any of the preceeding steps succeeded then usually also QGPSXTRATIME will be set correctly. Else, try to inject one of the timestamps above. Notice: the timestamp you inject must be extremely precise (so you have to compensate for potential delays in your code), I experienced that if it’s off by some seconds the fix will be more difficult.

Probably not the best in terms of efficiency, but extra safe.

5

Hello,

we currently are waiting for a cellular network registration before GNSS is enabled. This most of the time seems to set QGPSXTRATIME implicitly.

6

From my experience, after registration the module runs some kind of AT+QLTS under the hood. The operator is not always willing to give you the timestamp (no idea why), so if that fails also QGPSXTRATIME does not work. If you run it explicitly you can see if that fails and maybe try another source like qntp.