Discussion:
Thunderbolt code phase measurement
(too old to reply)
Mark Sims
2018-05-16 00:27:38 UTC
Permalink
The Trimble Thunderbolt has a message (0x5A) that outputs raw receiver measurement data. One value is "code phase" (along with PRN, sample length, sig level, dopple, and time-of-measurement). This is a single precision floating point number in units of 1/16 of a chip. Does anybody know how to massage this value into either a carrier phase (in cycles) or a pseudorange (in meters). The reported code phase values tend to be in the 1000 ... 10000 range.
_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Magnus Danielson
2018-05-16 06:44:35 UTC
Permalink
Hi Mark,

I have been looking at this myself.

Yes, you need to extend it with the 65-83 ms C/A code multiples, so
Trimble provided a little too raw measures. This is perfectly clear as
you read it.

However, you are armed with the time of week for the message, also,
there is messages so you can acquire the ephimeris data. Using the
ephimeris data of a satellte, the time of week you can calculate the
WGS84 X1. Y1, Z1 position of the satellite, and using the known position
of the receiver in Xu, Yu, Zu, you can trivially calculate the range to
the satellite as it should be. With this, it is trivial to convert it
into time by dividing by speed of light c and by subtracting the
reported pseudorange after converting it to time (divide by
16*1023*1000) you have an estimate of the time-range, so it only remains
to round it up to ms. Once this is done, it is trivial to update it
using the wrapping of 16*1023 that the 0x5A provides.

This way you can extend the pseudo-range measure of 0x5A to produce full
pseudorange measures.

You need more detailed help, or can you parse the ephimeris-data and
calculate it according to GPS-IS-200E?

Cheers,
Magnus
Many thanks Peter for confirming what I suspected. The problem with the Trimble receivers is that requesting the satellite C/A code data can hose up a lot of them. So, I'm stuck with calculating the integer number of milliseconds. How to do that? I do know my position to a few feet.
I have Lady Heather generating RINEX files for the Ublox timing receivers, the NVS-08, the Furuno GT-87, and the Ashtech Z12 (with both L1/L2 data). It would be nice to be able to support the Trimble receivers. With L1 only data I am getting results in the < 200 mm range. The Z12 with L1/L2 data gets me to around 40 mm.
----------------
If you know your position to within 150 kilometers (0.5 ms), you can
dispense with the pseudorange-assembly arithmetic and just use the code
phase directly, after adding in the appropriate integer number of
milliseconds, only one of which will put you within your known
300-kilometer-diameter (1 ms) sphere.
_______________________________________________
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Michael Wouters
2018-05-16 07:19:45 UTC
Permalink
Hello Mark

By "hosing" do you mean that you lose messages for the next second? That
was a problem with the Resolution T too. I wanted to get ephemerides from
the receiver so I ended up minimising lost messages by tracking satellites
as they popped into view, and then requesting an ephemeris after a suitable
wait. This problem went away in the SMT 360.

Regard resolving the ms ambiguity, you could look at the code in mktimetx,
which does just what Magnus D describes.
The code lives at
https://github.com/openttp/openttp/tree/master/software/gpscv/common/process/

Cheers
Michael
Many thanks Peter for confirming what I suspected. The problem with the
Trimble receivers is that requesting the satellite C/A code data can hose
up a lot of them. So, I'm stuck with calculating the integer number of
milliseconds. How to do that? I do know my position to a few feet.
I have Lady Heather generating RINEX files for the Ublox timing receivers,
the NVS-08, the Furuno GT-87, and the Ashtech Z12 (with both L1/L2 data).
It would be nice to be able to support the Trimble receivers. With L1
only data I am getting results in the < 200 mm range. The Z12 with L1/L2
data gets me to around 40 mm.
----------------
If you know your position to within 150 kilometers (0.5 ms), you can
dispense with the pseudorange-assembly arithmetic and just use the code
phase directly, after adding in the appropriate integer number of
milliseconds, only one of which will put you within your known
300-kilometer-diameter (1 ms) sphere.
_______________________________________________
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Peter Monta
2018-05-16 04:58:50 UTC
Permalink
... One value is "code phase" (along with PRN, sample length, sig level,
dopple, and time-of-measurement). This is a single precision floating
point number in units of 1/16 of a chip. Does anybody know how to massage
this value into either a carrier phase (in cycles) or a pseudorange (in
meters). The reported code phase values tend to be in the 1000 ... 10000
range.
"Code phase" represents where you are along the 1023-bit C/A code (each bit
or "chip" of this code lasts ~1 microsecond or ~300 meters). The
scaled-by-16 code phase will thus range from 0 to 16*1023. To get the full
pseudorange, though, suitable for placing into a RINEX file for example,
you need to also add in the integer number of code periods from the
satellite to you. (Another way to put it is that the code phase is the
pseudorange modulo 1 millisecond, the duration of 1023 chips.) Each
pseudorange also contains the as-yet-unknown receiver clock bias---that is
the "pseudo" in "pseudorange".

The additional information comes from the data content of the C/A message,
which has a 20 ms period, a frame structure, and timestamps for the
frames. Hopefully all that is included somewhere in the receiver raw data.

Carrier phase is a different beast altogether and comes from the carrier
tracking loop, not the code tracking loop that gives the code phase. It's
simpler in some sense, because there is none of this burdensome,
complicated pseudorange-assembly process from disparate data sources like
code phase, bit sync, and timestamps; instead it's just a simple phase.
The ambiguity interval is very short, though, which complicates its use in
a navigation solution.

If you know your position to within 150 kilometers (0.5 ms), you can
dispense with the pseudorange-assembly arithmetic and just use the code
phase directly, after adding in the appropriate integer number of
milliseconds, only one of which will put you within your known
300-kilometer-diameter (1 ms) sphere.

Cheers,
Peter
_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
D. Jeff Dionne
2018-05-16 05:48:41 UTC
Permalink
"Code phase" represents where you are along the 1023-bit C/A code (each bit or "chip" of this code lasts ~1 microsecond or ~300 meters). The scaled-by-16 code phase will thus range from 0 to 16*1023. To get the full pseudorange, though, suitable for placing into a RINEX file for example, you need to also add in the integer number of code periods from the satellite to you.
...
If you know your position to within 150 kilometers (0.5 ms), you can dispense with the pseudorange-assembly arithmetic
To put that in code, the assembly of collected Observations might look like this:

raw_time = nav_ms_of_frame(sv);
raw_time += ((double)(1023<<PHASE_BITS)-(double)nd[c].phase)/(double)(1023<<PHASE_BITS);
raw_time += nav_subframe_of_week(sv)*6000.0;
raw_time /= 1000.0;

That pulls all the Observation pieces together to give you a (still uncorrected) transmit time in seconds (taken from working code).
and just use the code phase directly, after adding in the appropriate integer number of milliseconds, only one of which will put you within your known 300-kilometer-diameter (1 ms) sphere.
Oh... that is a very useful simplification when in Over Determined Clock. So long as your time is already accurate to better than 0.5ms, which is no big trick. Seems obvious now, but I hadn't thought of calculating or validating psudoranges that way before, thanks!

J.
Cheers,
Peter
_______________________________________________
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
D. Jeff Dionne
2018-05-16 06:10:59 UTC
Permalink
Many thanks Peter for confirming what I suspected. The problem with the Trimble receivers is that requesting the satellite C/A code data can hose up a lot of them. So, I'm stuck with calculating the integer number of milliseconds. How to do that? I do know my position to a few feet.
You can calculate the location of the SV from it's Ephemeris given the time of the set of Observations.

Another Oh! Can the TBolt be made to send us Ephemeris data? If so, and if it will also give Code Phase, I'd like a simple way to get that in a compact structure and onto our local LAN from the machine running Heather :)

J.
I have Lady Heather generating RINEX files for the Ublox timing receivers, the NVS-08, the Furuno GT-87, and the Ashtech Z12 (with both L1/L2 data). It would be nice to be able to support the Trimble receivers. With L1 only data I am getting results in the < 200 mm range. The Z12 with L1/L2 data gets me to around 40 mm.
----------------
If you know your position to within 150 kilometers (0.5 ms), you can
dispense with the pseudorange-assembly arithmetic and just use the code
phase directly, after adding in the appropriate integer number of
milliseconds, only one of which will put you within your known
300-kilometer-diameter (1 ms) sphere.
_______________________________________________
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Mark Sims
2018-05-16 15:27:11 UTC
Permalink
I was losing messages for up to 4 seconds on some of the receivers (ResT?) so I commented out that message request. I need to go back and do some tests to see which ones are actually affected.

-------------------
Post by Michael Wouters
By "hosing" do you mean that you lose messages for the next second? That
was a problem with the Resolution T too.
_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Loading...