[time-nuts] Re: GPSDO/GNSSDO project: STM32G4 + u-blox ZED-F9T + TDC7200

[Carsten Andrich]

On 07.08.22 16:17, John Ackermann N8UR via time-nuts wrote:
> On 8/6/22 23:47, dk4ww at gmx.net wrote:
>
>> RTK corrections works only from F9T to F9T.
>> you need RTCM 7 ( MSM 7) messages. (RTCM 1077 and more)
>
> 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.

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.


> 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.

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