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.

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.

On May 16, 2018, at 15:01, Mark Sims holrum@hotmail.com wrote:

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.

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
1610231000) 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

On 05/16/2018 08:01 AM, Mark Sims wrote:

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

On Wed, 16 May 2018 at 4:02 pm, Mark Sims holrum@hotmail.com wrote: