On May 16, 2018, at 15:01, Mark Sims wrote:
>
> 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
On May 16, 2018, at 13:58, Peter Monta wrote:
>
> "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,
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
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 ac
> ... 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 (
