Masterclock
GMR
User
Manual
v2
–
2016.12
61
ptpTimescale
–
true,
the
current
timescale
is
the
PTP
default,
TAI
time.
false,
another
timescale
is
being
used
(such
as
UTC).
timeSource
–
the
GMR
products
support
the
following
time
source
values.
Non
‐
GMR
products
may
have
additional
values.
GPS
–
GPS/GNSS
satellite
time
PTP
–
Precision
Time
Protocol
NTP
–
Network
Time
Protocol
OTHER
–
time
code
reader,
NMEA,
NENA,
etc.
INTERNAL_OSCILLATOR
–
internal
oscillator
The
following
can
be
modified:
currentUtcOffset
–
offset
in
seconds
to
UTS
time.
currentUtcOffsetValid
–
true,
currentUtcOffset
offset
value
is
valid
and
can
be
used.
false,
currentUtcOffset
is
invalid
and
cannot
be
used.
leap59
–
true,
a
leap
second
is
pending.
false,
no
leap
second
is
pending.
leap61
‐
true,
a
leap
second
is
pending.
false,
no
leap
second
is
pending.
5)
portDS,
Port
Data
Set
Select
which
member
to
modify
(1
‐
6),
’x’
to
go
back
up
a
level,
‘?’
for
help
The
following
cannot
be
modified:
portIdentity
–
port
identity
portState
–
master
(device
is
the
grandmaster),
slave
(device
is
a
slave
to
the
grandmaster),
passive
(device
is
not
synchronizing
to
the
grandmaster
and
can
become
the
grandmaster).
peerMeanPathDelay
–
only
used
when
P2P
is
enabled.
versionNumber
–
PTP
version
number,
always
2
for
GMR
products.
The
following
can
be
modified:
logAnnounceInterval
–
mean
time
interval
between
Announce
messages.
Used
in
the
selection
of
the
grandmaster.
The
value
is
logarithm
to
the
base
2.
A
negative
value
is
a
fractional
second.
Recommended
value
is
1,
range
0
to
4.
announceReceiptTimeout
–
timeout
in
seconds
for
the
receipt
of
the
announce
message.
Must
be
greater
than
the
logAnnounceInterval
(in
seconds).
logSyncInterval
–
interval
used
to
send
Sync
messages
from
the
grandmaster.
The
value
is
logarithm
to
the
base
2.
A
negative
value
is
a
fractional
second.
Recommended
value
is
1,
range
0
to
4.
delayMechanism
‐
Delay
Mechanism
is
the
method
used
to
calculate
the
network
path
delays.
All
devices
on
the
network
must
use
the
same
delay
mechanism
(even
if
they
are
in
different
PTP
domains).
End
To
End
(E2E)
only
requires
the
master
and
slave
to
support
PTP.
It
does
not
require
the
network
infrastructure
to
support
PTP.
If
the
intervening
infrastructure
of
the
local
network
does
not
support
PTP,
accuracies
of
20
‐
100
microseconds
can
typically
be
achieved.
If
the
intervening
network
devices
does
support
E2E
PTP
(ie.
a
transparent
clock)
sub
‐
microsecond
accuracies
can
be
achieved.
Peer
To
Peer
(P2P)
reduces
the
overall
network
traffic
and
can