Meinberg PTP270PEX User manual

MANUAL
PTP270PEX
IEEE 1588 Computer Clock
22nd November 2012
Meinberg Radio Clocks GmbH & Co. KG

Page 0
Table of Contents
1 Impressum 1
2 General information 2
2.1 ContentoftheUSBstick....................................... 2
2.2 Modeofoperation........................................... 2
2.3 FeaturesPTP270PEX......................................... 2
2.4 Pulseandfrequencyoutputs ..................................... 3
2.5 Timecaptureinputs.......................................... 3
2.6 Asynchronousserialport ....................................... 3
2.7 BlockDiagramPTP270PEX ..................................... 4
3 Precision Time Protocol (PTP) / IEEE1588 5
3.1 GeneralInformation.......................................... 5
3.2 Functionality in Master Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3 Functionality in Slave Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.4 PTPv2 IEEE 1588-2008 Conguration Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.4.1 GeneralOptions........................................ 7
3.4.2 NetworkLayer2orLayer3.................................. 7
3.4.3 MulticastorUnicast...................................... 7
3.4.4 Two-SteporOne-Step .................................... 8
3.4.5 End-To-End (E2E) or Peer-To-Peer (P2P) Delay Measurements . . . . . . . . . . . . . . 8
3.4.6 ModeRecommendations ................................... 8
3.4.7 MessageRateSettings .................................... 8
3.4.8 ANNOUNCEMessages .................................... 9
3.4.9 SYNC/FOLLOWUP Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.4.10 (P)DELAY_REQUEST Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.4.11HQFilter ........................................... 10
4 PCI Express (PCIe) 11
5 Mounting and Configuration of the PTP card 12
5.1 Conguring the 9 pin connector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.2 Installing PTP270PEX in your computer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6 Connectors and LEDs in the rear slot cover 13
7 Time codes 14
7.1 Thetimecodegenerator ....................................... 14
7.2 GeneratedTimeCodes ........................................ 14
7.3 IRIGStandardFormat......................................... 15
7.4 AFNORStandardFormat....................................... 16
7.5 Assignment of CF Segment in IEEE1344 Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8 Technical Specifications PTP270PEX 18
8.1 CE-Label................................................ 19
0 Date: 22nd November 2012 PTP270PEX

Page 1
1 Impressum
Meinberg Radio Clocks GmbH & Co. KG
Lange Wand 9, 31812 Bad Pyrmont - Germany
Phone: + 49 (0) 52 81 / 93 09 - 0
Fax: + 49 (0) 52 81 / 93 09 - 30
Internet: http://www.meinberg.de
Mail: [e-mail]
Date: 2010-06-08
PTP270PEX Date: 22nd November 2012 1

Page 2 2 General information
2 General information
The module PTP270PEX acts as a slave device in IEEE 1588-2008 (PTPv2) compatible networks and can be used
to synchronize the computer`s system time to the PTP time received from a grandmaster clock like LANTIME
M600/GPS/PTP.
The integrated single board computer (SBC) is running the PTP stack and provides a PCI Express interface
that is compatible with other Meinberg PCIe devices. In this way the board PTP270PEX can be operated by
using the standard Meinberg driver package and there is no need to run a PTP software on the computer.
PTP270PEX can not be used as a standard network interface card.
2.1 Content of the USB stick
The included USB stick contains a driver program that keeps the computer`s system time synchronous to the
received IEEE 1588 time. If the delivered stick doesn't include a driver program for the operating system used, it
can be downloaded from:
http://www.meinberg.de/german/sw/
On the USB stick there is a le called "readme.txt", which helps installing the driver correctly.
2.2 Mode of operation
The on-board Time Stamp Unit (TSU) integrated in a FPGA (Field Programmable Gate Array, programmable
logic device), monitors the data trac on the MII-interface between the PHYceiver (physical connection to the
network) and the Ethernet controller (MAC) of PTP270PEX. If a valid PTP packet is detected, the TSU takes
a time stamp that is read out by the single board computer running the PTP stack.
After decoding a valid time information from a PTP Master, the system sets it`s own PTP seconds and nanosec-
onds accordingly. The PTP oset calculated by the PTP driver software of the single board computer is used for
adjustment of the master oscillator of PTP270PEX.
2.3 Features PTP270PEX
The module PTP270PEX provides a high precision time base (TCXO or OCXO) with multiple outputs for 10MHz,
PPS and IRIG, synchronized by a PTP IEEE 1588 grandmaster reference clock. Three user congurable outputs
for 1 PPS, 10 MHz and unmodulated time code (IRIG) can be set up. Also two capture inputs are integrated to
get high precision time stamps of external events. A simplied LINUX operating system is installed on the single
board computers ash disk.
2 Date: 22nd November 2012 PTP270PEX

2.4 Pulse and frequency outputs Page 3
2.4 Pulse and frequency outputs
The pulse generator of PTP270PEX contains three independent channels (PPO0, PPO1, PPO2). These TTL
outputs can be mapped to pins at the 9-pin connector at the rear slot cover by using a DIL switch. The pulse
outputs are able to provide a pulse per second (PPS) or a 10MHz standard frequency. They are congured by
the monitor program.
2.5 Time capture inputs
The board provides two time capture inputs called User Capture 0 and 1 (CAP0 and CAP1) which can be mapped
to pins at the 9 pin connector at the rear panel. These inputs can be used to measure asynchronous time events.
A falling TTL slope at one of these inputs lets the microprocessor save the current real time in its capture buer.
From the buer, an ASCII string per capture event can be transmitted via COM1 or displayed using the monitoring
program. The capture buer can hold more than 500 events, so either a burst of events with intervals down to
less than 1.5 msec can be recorded or a continuous stream of events at a lower rate depending on the transmission
speed of COM1 can be measured. The format of the output string is described in the technical specications at
the end of this document. If the capture buer is full a message "** capture buer full" is transmitted, if the
interval between two captures is too short the warning "** capture overrun" is being sent via COM1.
2.6 Asynchronous serial port
An asynchronous serial interface (RS232) COM0 is available to the user via a submin-D connector in the rear
panel slot cover. In the default mode of operation, the serial output is disabled until the module has synchronized
it`s internal time base to a PTP Grandmaster. However, it can be congured to be enabled immediately after
power-up. The monitoring program can be used to setup transmission speed, framing and mode of operation of
the serial interface. It can be congured to transmit either time strings (once per second, once per minute, or on
request with ASCII ? only), or to transmit capture strings (automatically when available, or on request). The
format of the output strings is ASCII, see the technical specications at the end of this document for details.
PTP270PEX Date: 22nd November 2012 3

Page 4 2 General information
2.7 Block Diagram PTP270PEX
PCI Express
Interface
time stamp unit
(TSU)
MAC
FPGA
PHY
RJ45
with
magnetics
input signals time capture,...
output signals signal generator
PCI Express Bus
register set
single board
computer (SBC)
running PTP stack
microcontroller
reference oscillator
O(T)CXO
Tx Rx CLK
16-bit local bus
MII interface
Host bus USB
PCI-IntTSU-Int
MAC-Int
4 Date: 22nd November 2012 PTP270PEX

Page 5
3 Precision Time Protocol (PTP) / IEEE1588
Precision Time Protocol (PTP or IEEE 1588) is a time synchronization protocol that oers sub-microsecond ac-
curacy over a standard Ethernet connection. This accuracy can be achieved by adding a hardware timestamping
unit to the network ports that are used for PTP time synchronization. The timestamping unit captures the exact
time when a PTP synchronization packet is sent or received. These timestamps are then taken into account to
compensate for transfer delays introduced by the Ethernet network.
In PTP networks there is only one recognized active source of time, referred to as the Grandmaster Clock.
If two or more Grandmaster Clocks exist in a single network, an algorithm dened in the PTP standard is used to
determine which one is the best source of time. This Best Master Clock algorithm must be implemented on
every PTP/IEEE1588 compliant system to insure that all clients (Slave Clocks) will select the same Grandmas-
ter. The remaining deselected Grandmaster Clocks will step back and enter a passive mode, meaning that they
do not send synchronization packets as long as that is being done by the designated Grandmaster.
The existing network infrastructure components play a big role in a PTP network and directly inuence the
level of accuracy that can be achieved by the clients. Asymmetric network connections degrade the accuracy,
therefore classic layer 2 and 3 Ethernet switches with their store and forward technology are not suitable for
PTP networks and should be avoided. With activating the HQ-Filter (see chapter HQ-Filter) the Jitter can be
eliminated. Simple Ethernet hubs with xed pass-through times are not a problem. In large networks, special
switches with built-in PTP functionality help to maintain high accuracy even over several subnets and longer
distances. These components act as "Boundary Clocks" (BC) or "Transparent Clocks" (TC). They compensate
their internal packet processing times by using timestamping units on each port. When acting as a Boundary
Clock, they synchronize to the Grandmaster clock, and in turn act as a Master to the other subnets they are
connected to. When acting as a Transparent Clock, then the "residence time" of the Masters' Sync-Packet is
measured and added to the packet as a correction value. Internally the PTP timescale TAI (see chapter Timescale
in Global Parameters).
3.1 General Information
The internal PTP card acts as a network interface card (10/100MBit) with an integrated hardware time stamp
unit to obtain time stamps in PTP compatible networks. In conjunction with a single board computer running
the PTP protocol stack and a reference time source (PTP master only) the module is capable of building a PTP
Master or Slave system:
10/100MBit
LAN
Network Interface Card
PTP Time Stamp Unit
Single Board Computer
PTP Protocol Stack
Reference Time Source
GPS Receiver
PTP Master System only
USB
PPS10MHz
PTP270PEX Date: 22nd November 2012 5

Page 6 3 Precision Time Protocol (PTP) / IEEE1588
The Time Stamp Unit, integrated in an FPGA (Field Programmable Gate Array, a programmable logic device),
checks the data trac on the MII-interface between the PHY receiver (physical connection to the network) and
the Ethernet controller (MAC) on the PTP module. If a valid PTP packet is detected, the time stamp unit takes
a time stamp of that packet which is read by a single board computer (SBC) running the PTP software. The
conguration and status trac between the PTP board and main SBC is done over a USB connection.
3.2 Functionality in Master Systems
10/100MBit
LAN
10 Mhz from GPS
RJ45 with
magnetics
and LEDs
PHYceiver MAC
controller USB hub
FPGA
microcontroller
with integrated
progr. memory
10M/activity
100M/activity
Rx/Tx
MII interface USB
USB 1.1
to computer
module
Time Stamp Unit PTP Master
FPGA
configuration
memory
PPS from GPS
control
adr/data
control
data
USB
After power up, the module accepts the absolute time information (PTP seconds) of a reference time source
(GPS reference clock) only once, and the PTP nanoseconds are set to zero. If the oscillator frequency of the
reference time source has reached its nominal value, the nanoseconds are reset again. This procedure leads to a
maximum deviation of 20 nsec of the pulse per second (1PPS) of the PTP Master compared to the 1PPS of the
GPS reference clock. The reference clock of the PTP board's time stamp unit (50 MHz) is derived from the GPS
disciplined oscillator of the reference time source using a PLL (Phase Locked Loop) of the FPGA. The achieves
a direct coupling of the time stamp unit to the GPS system.
3.3 Functionality in Slave Systems
10/100MBit
LAN
10 MHz
PPS
programmable
outputs
modulated
time code
RJ45 with
magnetics
and LEDs
PHYceiver MAC
controller USB hub
status LEDs
driver
circuits
FPGA
filter and
driver circuit oscillator DAC
microcontroller
with integrated
progr. memory
FPGA
configuration
memory
10M/activity
100M/activity
Rx/Tx
MII interface
USB
USB
data control
control
control
voltage
PWM time code
clock
adr/data
control
USB 1.1
to computer
module
clock
status
Time Stamp Unit PTP Slave
After decoding valid time information from a PTP Master, the system sets its own PTP seconds and nanoseconds
accordingly. The PTP oset calculated by the PTP driver software of the single board computer is used to adjust
the master oscillator of the TSU-USB. This allows the PTP Slave to generate very high accuracy output signals
(10 MHz/1PPS/IRIG).
6 Date: 22nd November 2012 PTP270PEX

3.4 PTPv2 IEEE 1588-2008 Conguration Guide Page 7
3.4 PTPv2 IEEE 1588-2008 Configuration Guide
Setting up all devices in a PTP synchronization infrastructure is one of the most important parts in a network
time synchronization project. The settings of the involved Grandmaster clocks as the source of time and the end
devices (Slaves) have to match in order to allow them to synchronize and avoid problems later, when the PTP
infrastructure is deployed to production environments. In addition to that, the use of PTP aware network infras-
tructure components, namely network switches, introduces another set of parameters that have to be harmonized
with the masters and slaves in a PTP setup.
It is therefore very important to start with making decisions how the to-be-installed PTP synchronization so-
lution should operate, e.g. should the communication between the devices be based on multicast or unicast
network trac or how often should the masters send SYNC messages to the slaves.
This chapter lists the most important options and their implications on a synchronization environment in general.
A detailed explanation of the conguration settings within the LANTIME conguration interfaces can be found
later within this documentation.
3.4.1 General Options
The following general mode options have to be decided before deploying the infrastructure:
1) Layer 2 (Ethernet) or Layer 3 (UDP/IPv4) connections
2) Multicast or Unicast
3) Two-Step or One-Step Operation
4) End-to-End or Peer-to-Peer Delay Mechanism
The above options need to be dened for the whole setup, if devices do not stick to the same settings, they will
not be able to establish a working synchronization link.
3.4.2 Network Layer 2 or Layer 3
PTP/IEEE 1588-2008 oers a number of so-called mappings on dierent network communication layers. For
Meinberg products you can choose between running PTP over IEEE 802.3 Ethernet connections (network Layer
2) or UDP/IPv4 connections (Layer 3).
Layer 3 is the recommended mode, because it works in most environments. For Layer 2 mode the network
needs to be able to provide Ethernet connections between master and slave devices, which is often not the case
when your network is divided into dierent network segments and you have no layer 2 routing capabilities in your
network infrastructure.
The only benet of using Layer 2 mode would be a reduced trac load, because the transmitted network frames
do not need to include the IP and UDP header, saving 28 bytes per PTP packet/frame. Due to the fact that PTP
is a low trac protocol (when compared to other protocols), the reduced bandwidth consumption only plays a
role when low-bandwidth network links (e.g. 2Mbit/s) have to be used or in pay-per-trac scenarios, for example
over leased-line connections.
3.4.3 Multicast or Unicast
The initial version of PTP (IEEE 1588-2002 also known as PTPv1) was a multicast-only protocol. Multicast
mode has the great advantage that the master clock needs to send only one SYNC packet to a Multicast address
and it is received by all slave devices that listen to that multicast address.
In version 2 of the protocol (IEEE 1588-2008) the unicast mode was introduced in addition to the multicast
mode. In unicast mode, the master has to send one packet each to every slave device, requiring much more CPU
performance on the master and producing orders of magnitudes more trac.
On the other hand, some switches might block multicast trac, so that in certain environments, Unicast mode
has to be used.
PTP270PEX Date: 22nd November 2012 7

Page 8 3 Precision Time Protocol (PTP) / IEEE1588
3.4.4 Two-Step or One-Step
The PTP protocol requires the master to periodically send SYNC messages to the slave devices. The hardware time
stamping approach of PTP requires that the master records the exact time when such a SYNC packet is going on
the network wire and needs to communicate this time stamp to the slaves. This can be achieved by either sending
this time stamp in a separate packet (a so-called FOLLOW-UP message) or by directly manipulating the outgo-
ing SYNC message, writing the hardware time stamp directly into the packet just before it leaves the network port.
At the time of delivery of this product, Meinberg devices support only the former approach, called Two-Step
(because two packets are required).
3.4.5 End-To-End (E2E) or Peer-To-Peer (P2P) Delay Measurements
In addition to receiving the SYNC/FOLLOWUP messages a PTP slave device needs to be able to measure the
network delay, i.e. the time it took the SYNC message to traverse the network path between the master and
the slave. This delay is required to correct the received time information accordingly and it is measured by the
slave in a congured interval (more about the message intervals later). A delay measurement is performed by
sending a so-called DELAY_REQUEST to the master which timestamps it and returns the timestamp in a DE-
LAY_RESPONSE message.
IEEE 1588-2008 oers two dierent mechanisms for performing the delay measurements. A slave can either
measure the delay all the way to the master, this is called End-To-End (or E2E in short) or to its direct network
neighbors (which would in almost all cases be a switch  or two in a redundant setup), using the Peer-To-Peer
delay measurement mechanism (P2P). The delay measurements of all links between the master and the slave are
then added and accumulated while a SYNC packet is traversing the network.
The advantage of this method is that it can dramatically reduce the degradation of accuracy after topology
changes. For example: in a redundant network ring topology the network delay will be aected when the ring
breaks open and network trac needs to be redirected and ows into the other direction. A PTP slave in a sync
infrastructure using E2E would in this case apply the wrong delay correction calculations until it performs the
next delay measurement (and nds out that the network path delay has changed). The same scenario in a P2P
setup would see much less time error, because the delay of all changed network links were already available.
The drawback: the P2P approach requires that all involved PTP devices and all switches support this mech-
anism. A switch/hub without P2P support would in the best case simply pass the so-called PDELAY messages
through and as a result degrade the accuracy of the delay measurements. In the worst case it would block/drop
the PDELAY messages completely, which eectively would result in no delay measurements at all.
So, E2E is the only available choice if you are running PTP trac through non-PTP-aware switches. It is a
reasonable choice if you are not using redundant network topologies or can accept that the delay measurements
are wrong for a certain amount of time.
3.4.6 Mode Recommendations
Meinberg recommends to set up your PTP infrastructure to use Layer 3, Multicast, Two-Step and End-To-
End Delay measurements if that is possible. This will provide the largest possible compatibility and reduces
interoperability problems.
3.4.7 Message Rate Settings
The decision between the dierent general mode options is mainly dictated on the network environment in which
the PTP infrastructure is installed.
In addition to the mode selection, a number of intervals for certain types of PTP network messages needs to be
dened. In most cases, the default values as dened in the standard are a safe bet, but there are applications and
scenarios where a custom message rate is required.
A possible example is a situation where the PTP infrastructure is integrated within an environment with high
network load. In this case, the PTP packets can be aected by the eect of packet delay variation (PDV). An
increase of the PTP message rate(s) can avoid synchronization problems due to packet queuing within non-PTP
compliant switches which might cause false measurements. At higher rates, these false measurements can be
detected and corrected faster as compared to lower rates at the cost of increased trac.
8 Date: 22nd November 2012 PTP270PEX

3.4 PTPv2 IEEE 1588-2008 Conguration Guide Page 9
The message rates for the following message types can be changed:
1) ANNOUNCE messages
2) SYNC/FOLLOWUP messages
3) (P)DELAY_REQUEST messages
3.4.8 ANNOUNCE Messages
These PTP messages are used to inform the PTP network participants about existing and available master clock
devices. They include a number of values that indicate the potential synchronization accuracy.
The procedure used to decide which of the available devices (that could become masters) is selected is called the
best master clock algorithm (BMCA). The values that are used in this BMCA are read from the ANNOUNCE
messages that potential masters send out periodically.
The rate at which these messages are sent out are directly aecting the time that is required by a slave de-
vice to select a master and to switch to a dierent master in case the selected one fails.
Multiple devices can simultaneously transmit ANNOUNCE messages during periods in which no master has
been selected (yet). This happens for example when a PTP network is powered up, i.e. all devices are starting
to work at the same time. In this case all devices that consider themselves (based on their conguration and
status) being capable of providing synchronization to all the other PTP devices will start to send out ANNOUNCE
messages. They will receive the other candidates' ANNOUNCE messages as well and perform the BMCA. If they
determine that another candidate is more suitable to become the master clock, they stop sending ANNOUNCE
messages and either become slave devices or go into "PASSIVE" mode, waiting for the selected master to stop
sending ANNOUNCE messages. This is determined to be the case when no ANNOUNCE message is received
within 3 ANNOUNCE message intervals.
As an example, if the ANNOUNCE interval has been congured to be 2 seconds (one message every 2 sec-
onds, the default value), the master is considered to have failed when no message has been received for 6 seconds.
In order to choose a master (a backup master clock or the primary one during initialization) the devices re-
quire to receive at least two consecutive ANNOUNCE messages. Continuing our example, it would take the 6
seconds to determine that the current master has failed and another 4 seconds to select the new one. That
means an ANNOUNCE interval of 2 seconds translates into at least 10 seconds of switching time and 4 seconds
of initial master clock selection time. So, choosing a shorter ANNOUNCE message interval will allow a faster
switching to a backup master clock, but it can lead to false positives when the chosen interval is too short for
the network environment.
3.4.9 SYNC/FOLLOWUP Messages
The selected master clock sends out SYNC (and, in Two-Step environments, the corresponding FOLLOWUP)
messages in a congured interval. This interval (default value is one SYNC/FOLLOWUP packet every second)
determines how often the slave devices receive synchronization data that allows them to adjust their internal
clocks in order to follow the master clock time. Between receiving two SYNC messages, a slave clock runs free
with the stability determined by its own internal time base, for example a crystal oscillator. One important factor
for deciding on the SYNC interval is the stability of this oscillator. A very good oscillator requires a lower SYNC
message rate than a cheaper, low-accuracy model. On the other hand you directly aect the required network
bandwidth by changing the SYNC interval.
For Meinberg slave devices, the default one-SYNC-every-second setting is more than enough to achieve the
highest possible synchronization accuracy.
3.4.10 (P)DELAY REQUEST Messages
As explained in the General Mode Options chapter (see the End-To-End or Peer-to-Peer section), the delay
measurements are an important factor for achieving the required accuracy. Especially in E2E mode, the network
path delay measurements play a crucial part in the synchronization process. Per default, the slaves will perform
delay measurements every 8 seconds, resulting in sending and receiving one packet. This can be increased in case
the network path delay variation in the network is relatively large (i.e. the time it takes for the SYNC message
PTP270PEX Date: 22nd November 2012 9

Page 10 3 Precision Time Protocol (PTP) / IEEE1588
to reach the slave varies a lot) or the slave devices have to tightly follow the master and adjust their time base
(oscillator) very often due to its instability.
Meinberg slave devices will limit the eect of an outdated path delay measurement by using lters and opti-
mized PLL algorithms. This avoids that a clock jumps around and basically monitors the time dierence to the
master clock carefully for a certain amount of time before adjusting its own clock. With a low cost time base this
is not possible, because the instability (i.e. temperature-dependent drift and overall short term stability/aging
eects) and therefore these slaves would require to perform as many delay measurements and receive as many
SYNC/FOLLOWUP messages as possible.
For P2P mode the delay request interval is not as critical, simply because the delay variation on a single-hop link
(i.e. from your slave device to its switch) is very stable and does not change dramatically in typical environments.
Current rmware versions of Meinberg Grandmaster clocks (V5.32a and older) do not oer changing the De-
lay message rate in Multicast mode, it is xed to one delay request every 8 seconds. Since this is actually a value
that is transmitted in the DELAY_RESPONSE message as a maximum value, the slave devices are not allowed
to perform delay measurements more often.
3.4.11 HQ Filter
If you use non PTP aware switches in a network where PTP should be used then the timing accuracy of the oset
depends on the characteristic of the switches. Non PTP switches will cause time jitters (due to non deterministic
delays in each path direction) in PTP measurement. In this section, the term "jitter" is used to describe the
maximum deviation of the measured osets around a certain mean value. This time jitter of standard non-PTP
compliant switches can be in the range of 100 ns up to 10000 ns. When using routers this jitter can be even
higher. To reduce this time jitter the HQ lter can be activated to achieve a better PTP slave synchronization
quality. With Layer2 switches the accuracy can be achieved in the range of submicro seconds. Also Jitter caused
by high network load and faulty measurements will be eliminated
Functionality
After activating the HQ-Filter some PTP measurements will be done rst without controlling the timing of the
PTP slave. This phase will be indicated by an extra hint "init" in the current status of the PTP slave. During
this phase the maximum jitter of the PTP oset, the path delay and the current drift of the internal oscillator
will be calculated by statistical methods. The only lter parameter which can be set by the user is the es-
timated accuracy which will set the maximum expected range of the incoming time jitter. All input values
that are out of this range will be dropped. The maximum jitter of the input will be updated continuously during
normal operation. By default estimated accuracy will be set to 1s to determine the maximum jitter automatically.
PDSC
PDSC means "Path Delay Step Compensation". The PDSC feature tries to eliminate jumps of the PTP path
delay, so that there will be no eect on the timing accuracy. Such a jump of the PTP path delay (which should
be usually constant) will be caused by changing the topology of the PTP network which could happen in SDH
networks for example. The change of the PTP path delay is only detected, if the step is larger than the measured
time jitter. This feature is an extension of the HQ-Filter and therefore the HQ-Filter has to be activated.
10 Date: 22nd November 2012 PTP270PEX

Page 11
4 PCI Express (PCIe)
The main technical inovation of PCI Express is a serial data transmission compared to the parallel interfaces of
other computer bus systems like ISA, PCI and PCI-X.
PCI Express denes a serial point-to-point connection, the so-called Link:
Selectable Width
Device A Device B
Ref. Clock Ref. Clock
The data transfer within a Link is done via Lanes, representing one wire pair for sending and one wire pair for
receiving data:
TX
Logic D+
Component A Component B
D+
VBIAS
VBIAS
D-
D-
RX
Logic
RX
Logic
TX
Logic
This design leads to a full duplex connection clocked with 2.5 GHz capable of transfering a data volume of 250
MB/s per lane in each direction. Higher bandwith is implemented by using multiple lanes silmutaneously. A PCI
Express x16 slot for example uses sixteen lanes providing a data volume of 4 GB/s. For comparison: when using
conventional PCI the maximum data transfer rate is 133 MB/s, PCI-X allows 1 GB/s but only in one direction
respectively. A PCIe expansion board (x1 like Meinberg GPS receivers for example) can always be used in slots
with a higher lane width (x4, x8, x16):
Interoperability
Slot x1 x4 x8 x16
Card
x1 Yes Yes Yes Yes
x4 No Yes Yes Yes
x8 No No Yes Yes
X16 No No No Yes
One of the strong points of PCI Express is the 100% software compatibility to the well known PCI bus, leading
to a fast spreading. The computer and the operating system are seeing the more powerfull PCIe bus just as the
convetional PCI bus without any software update.
PTP270PEX Date: 22nd November 2012 11

Page 12 5 Mounting and Conguration of the PTP card
5 Mounting and Configuration of the PTP card
5.1 Configuring the 9 pin connector
By default only the signals needed for a serial RS232
port are mapped to the pins of the connector. Whenever
one of the additional signals shall be used, the signal
must be mapped to a pin by putting the appropriate
lever of the DIL switch in the ON position. The table
below shows the pin assignments for the connector and
the DIL switch lever assigned to each of the signals.
Care must be taken when mapping a signal to Pin 1,
Pin 4 or Pin 7 of the connector, because one of two
dierent signals can be mapped to these Pins. Only
one switch may be put in the ON position in this case:
Pin 1: DIL 1 or DIL 8 ON
Pin 4: DIL 5 or DIL 10 ON
Pin 7: DIL 3 or DIL 7 ON
Those signals which do not have a lever of the DIL switch assigned are always available at the connector:
D-SUB Pin Signal Signal level DIL-switch

1 VCC out +5V 1
1 PPO0 out RS232 8
2 RxD in (res.) RS232 -
3 TxD out (res.) RS232 -
4 PPO1 out TTL 5
4 10MHz out TTL 10
5 GND - -
6 CAP0 in TTL 2
7 CAP1 in TTL 3
7 IRIG DC out TTL into 50 Ohm 7
8 PPO0 out TTL 4
9 PPO2 out TTL 9
5.2 Installing PTP270PEX in your computer
Every PCI Express board is a plug&play board. After power-up, the computer's BIOS assigns resources like I/O
ports and interrupt numbers to the board, the user does not need to take care of the assignments. The programs
shipped with the board retrieve the settings from the BIOS.
The computer has to be turned o and its case must be opened. The PTP270PEX can be installed in any
PCI Express slot not used yet. The rear plane must be removed before the board can be plugged in carefully. The
computers case should be closed again and after the computer has been restarted, the monitor software can be
run in order to check the conguration of the PTP card.
12 Date: 22nd November 2012 PTP270PEX

Page 13
6 Connectors and LEDs in the rear slot cover
RDY ENB
MST
The RJ45 network connector, four status LEDs and a
9 pin sub D connector can be found in the rear slot
cover (see gure). The LEDs integrated into the RJ45
connector signal the link speed and activity of a net-
work connection. The bicolor LED "RDY" changes
from red to green when the system is ready to operate
after power up. The green LED "ENB" is switched on
whenever the module is synchronized by a IEEE 1588
master device and the ouput signals are enabled. The
LED "RX" ashes whenever an incoming PTP packet
is detected and the LED "TX" ashes whenever an
outgoing PTP packet is detected by the Time Stamp
Unit.
The 9 pin sub D connector is wired to the PTP270PEX's
serial port COM0. Pin assignment can be seen in the
chapter "Conguring the 9 pin connector". This port
can not be used as serial port for the computer. In-
stead, it is used to make some signal inputs and outputs
available.
A DIL switch on the board can be used to wire
some TTL inputs or outputs (0..5V) to some con-
nector pins. In this case, absolute care must be
taken if another device is connected to the port,
because voltage levels of -12V through +12V (as
commonly used with RS-232 ports) at TTL inputs
or outputs may damage the module.
See chapter "Conguring the 9 pin connector".
PTP270PEX Date: 22nd November 2012 13

Page 14 7 Time codes
7 Time codes
The transmission of coded timing signals began to take on widespread importance in the early 1950s. Especially
the US missile and space programs were the forces behind the development of these time codes, which were used
for the correlation of data. The denition of time code formats was completely arbitrary and left to the individual
ideas of each design engineer. Hundreds of dierent time codes were formed, some of which were standardized
by the Inter Range Instrumentation Group (IRIG) in the early 60s.
Except these IRIG Time Codes other formats, like NASA36, XR3 or 2137, are still in use. The board PTP270PEX
however generates the IRIG-B, AFNOR NFS 87-500 code as well as IEEE1344 code which is an IRIG-B123 coded
extended by information for time zone, leap second and date. If desired other formats are available.
7.1 The time code generator
The board PTP270PEX generates unmodulated timecodes which are transmitted by modulating the pulse dura-
tion of a DC-signal (TTL in case of PTP270PEX), see chapter IRIG standard format for details.
Transmission of the time code is synchronized to the PPS (pulse per second) derived from synchronization
to the IEEE 1588 grandmaster.
The modulated pulses have the following durations:

a) binary 0 : 2 msec
b) binary 1 : 5 msec
c) position-identier : 8 msec
7.2 Generated Time Codes
The board PTP270PEX is capable of generating the following unmodulated timecodes:
a) B002: 100 pps, DCLS signal, no carrier
BCD time-of-year
c) B003: 100 pps, DCLS signal, no carrier
BCD time-of-year, SBS time-of-day
e) AFNOR: Code according to NFS-87500, 100 pps, wave signal,
1kHz carrier frequency, BCD time-of-year, complete date,
SBS time-of-day, Signal level according to NFS-87500
f) IEEE1344: Code according to IEEE1344-1995, 100 pps, AM sine wave signal,
1kHz carrier frequency, BCD time-of-year, SBS time-of-day,
IEEE1344 extensions for date, timezone, daylight saving and
leap second in control functions (CF) segment.
(also see table 'Assignment of CF segment in IEEE1344 mode')
14 Date: 22nd November 2012 PTP270PEX

7.3 IRIG Standard Format Page 15
7.3 IRIG Standard Format
PTP270PEX Date: 22nd November 2012 15

Page 16 7 Time codes
7.4 AFNOR Standard Format
16 Date: 22nd November 2012 PTP270PEX

7.5 Assignment of CF Segment in IEEE1344 Code Page 17
7.5 Assignment of CF Segment in IEEE1344 Code
Bit No. Designation Description
49 Position Identier P5
50 Year BCD encoded 1
51 Year BCD encoded 2 low nibble of BCD encoded year
52 Year BCD encoded 4
53 Year BCD encoded 8
54 empty, always zero
55 Year BCD encoded 10
56 Year BCD encoded 20 high nibble of BCD encoded year
57 Year BCD encoded 40
58 Year BCD encoded 80
59 Position Identier P6
60 LSP - Leap Second Pending set up to 59s before LS insertion
61 LS - Leap Second 0 = add leap second, 1 = delete leap second 1.)
62 DSP - Daylight Saving Pending set up to 59s before daylight saving changeover
63 DST - Daylight Saving Time set during daylight saving time
64 Timezone Oset Sign sign of TZ oset 0 = '+', 1 = '-'
65 TZ Oset binary encoded 1
66 TZ Oset binary encoded 2 Oset from IRIG time to UTC time.
67 TZ Oset binary encoded 4 Encoded IRIG time plus TZ Oset equals UTC at all times!
68 TZ Oset binary encoded 8
69 Position Identier P7
70 TZ Oset 0.5 hour set if additional half hour oset
71 TFOM Time gure of merit
72 TFOM Time gure of merit time gure of merit represents approximated clock error. 2.)
73 TFOM Time gure of merit 0x00 = clock locked, 0x0F = clock failed
74 TFOM Time gure of merit
75 PARITY parity on all preceding bits incl. IRIG-B time
1.) current rmware does not support leap deletion of leap seconds
2.) TFOM is cleared, when clock is synchronized rst after power up. see chapter Selection of generated timecode
PTP270PEX Date: 22nd November 2012 17