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 <[email protected]> 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 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. > _______________________________________________ > time-nuts mailing list -- [email protected] > To unsubscribe, go to > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
