Carsten Andrich said:

All of the timing receivers that I'm familiar with assume a fixed location.

Are you sure the F9T will work while moving?
If so, does it maintain the same accuracy?

--
These are my opinions.  I hate spam.

On 06.08.22 00:50, Hal Murray wrote:

The F9T datasheet [1] specifies the "operational limits" as ≤ 4 g
dynamics, 80 km altitude, and 500 m/s velocity. The time pulse accuracy
(5 ns absolute, 2.5 ns differential) is specified only for "fixed
position mode", so it may degrade when used on the move.

The F9P RTK positioning accuracy does not degrade substantially for
non-stationary use, as far as I can tell without a 20k€ INS groundtruth.
I hope the same applies to the F9T's timing performance. Verifying that
is one of the reasons behind building the prototype.

[1]
https://content.u-blox.com/sites/default/files/ZED-F9T-00B_DataSheet_UBX-18053713.pdf#page=4

I hesitate to post this because I haven't had time to go back and
refresh thoroughly, but I'm not sure how you would apply RTK corrections
to the F9T.

I believe that the "T" models can output RTCM data so can serve as an
RTK base station, but only the "P" models have the built-engine to
receive corrections via UART or USB and do RTK internally.  So without
that, I don't see how you can get corrected time directly from the module.

(I'm assuming that SBAS doesn't count as "RTK" for this purpose.  I've
never experimented with what that would do to the timing output.)

John

On 8/6/22 03:41, Carsten Andrich via time-nuts wrote:

John Ackermann N8UR via time-nuts time-nuts@lists.febo.com writes:

A caution that RTCM can transport two different things:

• pseudorange corrections (with t_0 and rate): typically RTCM2
• carrier phase reference data: typically RTCM3

The first is what as on the old USCG "differential beacons", 100 or 200
bps on roughly 200-300 kHz.

The second in my view is not really "corrections" even though it leads
to more accurate solutions; that's typically called "RTK network" and
loosely "RTK corrections".

I am not clear on the SBAS data format, but I am pretty sure it's
fundamentally pseudorange corrections (gridded model, but still you get
a range correction and probably a t_0 and range rate correction.

It's true that "P" have the code to accept RTCM3 carrier phase reference
data (along with reference station coordinate) and do RTK, which is
fundamentally a double-differenced carrier phase solution.  But one can
do that externally from raw measurements.  Maybe 5 years ago the Emlid
Reach did this with an M8T and rtklib running under an Intel Edison.
There, you'll probably be able to solve for clock error as well as XYZ,
but I do not know if one can practically get clock error and adjust for
it.

I've long heard "don't enable SBAS for timing" claims and I've never
understood the full rationale.  In theory, the observed pseudoranges,
after applying the pseudorange corrections, are then used in a
navigation solution.  Everybody believes that one gets better XYZ out of
that.  Time is trickier, as the reference stations have to steer their
clocks as they get measured pseudoranges to diff with calculated
pseudoranges (from satellite positions from the broadcast ephemeris and
their surveyed ARP, with an antenna model).  But I would expect that the
general reduction of errors would lead to a tighter solution in all 4
unknowns.

So the obvious experiment is to take two indentical receivers, one of
F9P, F9T, M8T, run them on a splitter both with SBAS off and compare
each timepulse to a cesium clock or something, to verify that they
behave the same, and then change so that one has SBAS and the other is
still off and look at that.

Can anyone explain a mechanism for the positions getting better but time
either getting worse or not changing?

Greg N1DAM

Hi Folks,

SBAS is disabled by default for timing applications using F9T.

RTK corrections works only from F9T to F9T.
you need RTCM 7 ( MSM 7) messages. (RTCM 1077 and more)

SAPOS - the German satellite positioning service
sends RTCM 4 (MSM 4) messages. Works fine with F9P  not for F9T.
You will need one F9T Base sending RTCM 7 massages. The Base works as NTRIP caster .
The NTRIP client F9T reseive RTCM 7 data for finding position. The Time Mode of F9T works only if the client not moving.

cheers

Uwe

Gesendet mit der mobilen Mail App

Am 07.08.22 um 01:02 schrieb John Ackermann N8UR via time-nuts

On 8/6/22 23:47, dk4ww@gmx.net wrote:

Thanks for that, Uwe!  I looked at the ZED-F9T Integration Manual
(section 3.1.5).  The info seems to me a bit incomplete, but it says:
"Time mode is a special receiver mode where the position of the receiver
is known and fixed and only
the time and frequency is calculated using all available satellites."

That doesn't reference whether the unit is the master or the slave, so
the assumption is that it applies to both, I guess.  The manual gives
the setup required to set timing mode and enter fixed position, and how
to configure the master to output the necessary messages, but doesn't
provide configuration for the slave.  Presumably it needs to be in (a)
fixed position mode, and (b) have differential corrections turned on
with the correct messages enabled.

There's a proprietary message, RTCM 4072.1, that must be received before
the slave will sync.  I suppose that's u-blox's vendor lock-in.

John

On 8/6/22 20:03, Greg Troxel via time-nuts wrote:

I'll have hardware available to do that testing in hopefully a month or
two, as well as trying the ZED-F9T time sync between two receivers.  I
just need to add those measurements to the chore list...

John

Hi Bill, John, Greg, Uwe,

thanks for chiming in.

On 06.08.22 20:29, John Ackermann N8UR via time-nuts wrote:

While the F9T does not support RTK positioning, it does apparently
utilize the code and carrier phase correction information part of RTK
correction data (RTCM 10403.*) to improve timing accuracy, e.g., by
eliminating atmospheric distortion.

On 07.08.22 02:03, Greg Troxel via time-nuts wrote:

On 07.08.22 05:47, Uwe via time-nuts wrote:

u-blox advise against the use of SBAS for timing [1, 2], because:

On 07.08.22 05:47, Uwe via time-nuts wrote:

That's my plan. One stationary F9T operating in time mode (surveyed,
fixed position; 1D timing solutions) sending MSM7s to the mobile receivers.

Best regards,
Carsten

[1]
https://content.u-blox.com/sites/default/files/ZED-F9T-00B_DataSheet_UBX-18053713.pdf#page=6
[2]
https://content.u-blox.com/sites/default/files/ZED-F9T_IntegrationManual_UBX-21040375.pdf#page=23

On 07.08.22 16:17, John Ackermann N8UR via time-nuts wrote:

If it works anything like the F9P RTKs, which I presume it does, then
time mode is only required for the stationary reference receiver
(sidenote: F9P also supports moving baseline mode with moving reference
receiver). The RTK mobile rovers (here: timing slave receivers) then use
the RTCM correction data from the reference receiver for an RTK fix. For
the F9T timing receiver, I don't see a reason to deviate from that
mechanism.

The F9P also specifies the 4072.0 and 4072.1 messages, but works
without. We reliably use them as rovers fed by a vendor-neutral MSM3s
stream from the German SAPOS system that Uwe mentioned. 4072.0 may be
required for the moving baseline mode I mentioned above. Never tried that.

Best regards,
Carsten