From code phase and intCodePhase to pseudorange

0 votes

Hello all,

I believe that there is a way to calculate pseudorange (T_rx - T_tx) by using values reported in RXM-MEASX. T_rx is time of reception at the receiver, and T_tx is time when satellite has sent the signal. Values of interest are intCodePhase and codePhase. These are reported also by mobile devices during emergency call positioning over control plane in the LTE network. So called ue-assisted positioning. These same values are reported over LPP protocol. But I cannot understand how to use intCodePhase and codePhase to get pseudorange. What I really want it the time when signal was transmitted by a satellite. I see that u-blox device definitely can calculate pseudorange but there is no explanation how it does that. The time of transmission is needed to calculate position of satellite at the time when signal was sent and that is used later to calculate a position estimate of the mobile device.

In the 2G network wholeChips and fractionalChips are reported over RRLP, which represent same values but in different units (chips). These are also present in RXM-MEASX.

If there is someone here who can explain to me how to use intCodePhase and codePhase to calculate pseduorange I would be forever grateful.



I have seen a message from helge (, but I hope that his conclusion is not correct.

by dunja asked Nov 3, 2018
Thank you clive1,
I am really grateful on all your comments. I will keep you posted if/when I solve my problem and have some better understanding how code phase and integer code phase that are reported by u-blox, and also by mobile devices over LPP protocol, suppose to be used when calculating pseudorange.
I've discussed this a little with u-Blox staff, and it is going to be hard to reconstitute things with this data.

I'm not exactly sure how this data gets furnished to the telco, and what/how they process it from there. I think you need to find someone with a telco infrastructure perspective to demonstrate the end-to-end mechanics of this, and perhaps how it is compared/contrasted  with equivalent tower(s) data to arrive at a position of the users handset. Perhaps there is some localized Inverse-DGPS and triangulation at play.
From the doppler perspective, and the tower(s) being bolted to the ground, I suspect there is the potential to develop a trajectory vector for a moving handset, or resolve a static position with an alternate point-of-view of the sky.
Thanks again clive1,
I really appreciate your  effort and it is really useful information for me. This actually confirms what I suspected: it is impossible to calculate pseudomeasurements straight forward from codePhase and integerCodePhase. I will work on a solution and post here what I did to get a correct position estimate, without using pseudomeasurements directly. What I don't understand is why people from 3GPP decided to do things so complicated. There is in RRLP one optional parameter called tsv_1, but usually it is not available so good solution cannot be dependent on its presence. Here come info from the standard
--from 3GPP TS 44.031 version 10.0.0 Release 10----
Delta TOW: This field is only applicable for MS-Assisted A-GPS. This field specifies the difference in milliseconds between the GPS TOW reported in the GPS Measurement Information Element and the millisecond part of the SV time tsv_1 of the first SV in the list reported from the MS. Figure A.1 shows an example of Delta TOW calculation. The Delta TOW is defined as Delta TOW = GPS TOW - fix(tsv_1)
where fix() denotes rounding to the nearest integer towards zero. The estimation of tsv_1 which forms the basis for the calculation of Delta TOW is vulnerable to millisecond ambiguities. Therefore the MS shall only report this field when it is confident that the correct millisecond event has been recovered.
Well if GPS/GNSS is working properly at the handset, it should be able to tell the tower exactly where it thinks it is. The tower should be able to push ephemeris it is holding/tracking locally too to help the receiver jump start a search/solution.

We get into the weeds here because they can get rawer data from the receiver in low signal situations and in the absence of ephemeris a lot quicker, and you've got governmental edicts forcing the telco's to get an estimated position as it pushes an emergency call into the network. The position can get better resolved as the call progresses, but that's a whole other nightmare in the dispatch infrastructure.

The standard likely has to accommodate a whole bunch of different GPS/GNSS chipsets with a whole bunch of divergent implementations. Honestly furnishing the network with 8-10 pseudo-range/flight-times from visible satellites and a milli-second estimation of time should be sufficient, and not generate a whole lot of data.
0 votes
Seems to have been answered via comments.
by grumpy answered Nov 20, 2018
I am not sure what you mean, but if you ask me this question was not even close to some useful answer. I did made some progress since the last post by clive1, I did find an answer in book by Frank Van Diggelen "A-GPS Assisted GPS, GNSS, and SBAS". Frank actually coined the method as "Coarse Time Navigation" and invented unique method to calculate the full pseudoranges from sub-millisecond pseudoranges reported by UEs and also solve the integer millisecond rollover problem. I am currently working on implementation so I wanted to verify that everything is working correctly before I post my answer here. But now I am sharing my findings in the case someone else is interested.
website banner