-m -f ptp4l_master.conf >& ptplog & `
`$ sudo ptp4l -P -2 -H -i enp2s0 -p /dev/ptp1 -m -f ptp4l_master.conf >& ptplog & `
> ***Note:*** In cases where there is more than one PTP device available, specify which one is to be used with the -p argument as shown in the following example usage:
* _Start ptp on KR260 in slave clock mode_
`$ source /usr/bin/start_ptp.sh -s `
> ***Note:*** Ensure to run the ptp master before starting ptp slave as slave fails to sync when the grandmaster clock is not set. The sync takes about 30 seconds to complete.
**Observe Results**
* The file ptplog contains the saved ptp4l output to the file system on KR260. The rms value starts out high and trend downward to a single-digit value showing that the clocks are now in sync.
![i210](../media/i210-ptp.png)
* To see the current status of PTP, run the following command to exit log view when finished.
`tail -f .local/log/ptplog`
#### Network Time Shaper Function (other 802.1Qbv Demo)
This demo allots a time slot for Scheduled Traffic (ST) and Best Effort (BE) traffic and it can be visualized on an oscilloscope. For a cycle time period of 1ms, ST traffic is sent for 700us and BE traffic for 300us. Wireshark on the Linux host workstation listens for packets. On the KR260 board, the application sets up time slots for the traffic classes. Packets are generated in continuous mode for both traffic types. Wireshark monitors the incoming packets for scheduled and best-effort traffic exposed by the TSN IP.
An oscilloscope or Analog Discovery 2 device can also be used to monitor Tlast Tx ST (P7) and Tlast Tx EP (P9) on KR260 board to view the distribution.
Oscilloscope Setup (optional)
* Connect P7 on the Test Pmod of KR260 to Channel1 of the oscilloscope - Tlast Tx ST
* Connect P9 on the Test Pmod of KR260 to Channel2 of the oscilloscope - Tlast Tx EP
* Set up triggers on Channel1 and Channel2 with an OR condition and set the time scale interval to 1 millisecond:
![i210](../media/i210-qbv.png)
* The Analog Discovery 2 can be connected to KR260 using these connections for observing the scheduled traffic:
![i210](../media/i210-osc.png)
* Start Wireshark on the Linux host machine and select I210 interface to see traffic data
`$ wireshark &`
* Start transmitting packets from the KR260 board
`$ source /opt/xilinx/tsn-examples/bin/start_qbv_test.sh -tx`
* The talker on KR260 runs for 30 seconds and exits automatically
**Observe Results**
* The scope shot shows an approximate Scheduled traffic (Channel 1 yellow) and Best Effort traffic (Channel 2 green) distribution.
![i210](../media/i210-osc-results.png)
> ***Note:*** The distribution will not be clean because this is monitoring the data going into the TSN IP before it is scheduled to go out on the Ethernet MAC.
* Observe that there are two sets of packets within the capture, one set with packet length=900, another set with packet length=800.
![i210](../media/i210-wireshark.png)
* Click on a packet with length=900 bytes and observe the vlan ID=10, Priority (PCP/PRI=4) where a packet with PCP=4 indicates it is Scheduled traffic.
![i210](../media/i210-wsn1.png)
* Click on a packet with length=800 bytes and observe the vlan ID=20, Priority (PCP/PRI=1) where a packet with PCP=1 indicates it is Best Effort traffic.
![i210](../media/i210-wsn2.png)
Wireshark trace shows a traffic distribution of 70% Scheduled traffic and 30% Best Effort traffic.
### Communication using RS485
The K26 SOM has the capability to perform as an advanced and highly integrated gateway for legacy industrial networking protocols (those using RS485/Modbus) to more modern industrial networking infrastructure (such as TSN) and this application serves as an example of how to interface to a remote temperature sensor for capturing data. This is analogous to integrating in legacy, but still functional, capital equipment to reduce total replacement costs within factory retrofits and technology upgrades.
#### RS485: Board Setup
* Connect the Pmod RS485 to the PMOD1 expansion connector (J2) of the KR260 carrier board. Be sure to connect this to the bottom row of pins (ones labeled 2,4,6,8,10, and 12) since the module is a 1x6 header connecting to a 2x6 connector on KR260.
![pmod](../media/pmod-temp.png)
* Connect the Temperature sensor and PMOD RS485 using prototyping wire (18 AWG works well) as shown in the following figure:
![pmod](../media/pmod-temp-sch.png)
* Connect a 12 VDC supply to power the RS485 temperature sensor using GND and VIN terminals.
![pmod](../media/pmo-temp-disp.png)
* Connect Power Supply to the 12V PWR DC barrel jack (J12) on the KR260 carrier board.
### RS485 Temperature/Humidity Sensor Demo
In this demo, the pmod-test application probes the temperature sensor connected to Pmod RS485 and displays the captured values on the serial terminal.
* Ensure to load the TSN accelerator/firmware (refer to step-7 'Dynamically load the application package' from Initial setup) using `xmutil loadapp kr260-tsn-rs485pmod` before testing example application. If the firmware is already loaded, ignore this step and proceed.
* Probe sensor via RS485 interface.
Execute binary
```bash
pmod-rs485-test
```
**Observe Results**
The output on the serial terminal should match the value displayed on the seven-segment LED display of the sensor.
![temp](../media/temp-term.png)
> ***Note:*** Occasionally, erroneous values (for example 3276.8) are reported for temperature/humidity sensor data and this is due to error in the sensor itself, which can be ignored and the test reruns to clear the error.
>
> ```
> reg[0]=32768 (0x8000)
> reg[1]=32768 (0x8000)
> Temperature: 3276.8 Deg C
> Humidity: 3276.8 %
> ```
> For reference, here is the register map of the sensor:
> ![tmp](../media/tmp-ref.png)
## Known issues
Following known issues and their remedies that can be encountered and implemented while testing the above application.
* Repeated broadcast on ping
* PTP timeouts with heavy traffic
For the above two issues, refer to the documentation provided under the section "Known issues and troubleshooting" from the AMD TSN solution wiki page [here](https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/25034864/Xilinx+TSN+Solution).
## Next Steps
* [Software Architecture of the Platform](sw_arch_platform.md)
* Go back to the [KR260 design start page](../ros2_multinode_communication_via_tsn_landing)
Copyright© 2023 Advanced Micro Devices, Inc.