chore: fix over-redacted parts of docs

README.md

@@ -83,7 +83,7 @@ uv run diag-master --reference diag_master/config/sample.yml
 # The diag-worker needs to run privileged so that it can communicate with local Unix domain 
 # sockets and read the journal of services running with elevated privileges
 # See notes below.
-sudo uv run diag-worker --ptp4l-units ptp4l@eno1 ptp4l@***REMOVED***
+sudo uv run diag-worker --ptp4l-units ptp4l@eno1 ptp4l@enp2s0
 ```
 
 > **Note:** To run `uv` privileged, it needs to be installed system-wide. If `sudo uv` does not

docs/design.md

@@ -183,7 +183,7 @@ different naming schemes:
 - **System Clock IDs**: Human-readable names like `my_host.sys`
 - **Interface IDs**: Network interface identifiers, e.g. `my_host.eno1`
 - **Linux Clock Device IDs**: Device names like `my_host.ptp0` (`/dev/ptp0`)
-- **Sensor IDs**: Frame IDs used by sensors, e.g. `sensor@lidar/***REMOVED***`
+- **Sensor IDs**: Frame IDs used by sensors, e.g. `sensor@lidar/top`
 
 When an alias update is received, the graph combines all nodes representing the same clock and
 updates all references to use the most human-readable identifier.

docs/img/ptp_architectures.drawio

@@ -380,7 +380,7 @@
             </root>
         </mxGraphModel>
     </diagram>
-    <diagram name="HW PTP: Multi Instance" id="cO4wmtFd20AO2***REMOVED***VCHB4">
+    <diagram name="HW PTP: Multi Instance" id="cO4wmtFd20AO2x2VCHB4">
         <mxGraphModel dx="790" dy="744" grid="1" gridSize="10" guides="1" tooltips="1" connect="1" arrows="1" fold="1" page="1" pageScale="1" pageWidth="1169" pageHeight="827" math="0" shadow="0">
             <root>
                 <mxCell id="3KCXKD-GZWqmIw55cJkT-0"/>

docs/index.md

@@ -13,7 +13,7 @@ Takes the **pain** out of **p**recision time synchroniz**a**t**i**o**n**.
 ## :fontawesome-solid-signs-post: First Steps
 
 * [PTP Architecture Guide](ptp-architecture-guide.md) - Set up PTP in a distributed system
-* [Integrators' Guide](integrators-guide.md) - Set up SYNC.TOOLING for a ***REMOVED*** based system
+* [Integrators' Guide](integrators-guide.md) - Set up SYNC.TOOLING in a vehicle
 * [Installation Guide](installation.md) - Install SYNC.TOOLING manually
 * [Usage Guide](usage.md) - Configure SYNC.TOOLING for your system
 

docs/installation.md

@@ -6,7 +6,7 @@ software components necessary:
    `diag-master`
 
 !!! tip
-    If you are an integrator, or using ***REMOVED***, please refer to the
+    If you are an integrator, or want to set up SYNC.TOOLING in a vehicle, please refer to the
     [Integrators Guide](integrators-guide.md) for automated setup instructions.
 
 --8<-- "README.md:installation"
@@ -129,7 +129,8 @@ ros2 bag record /sync_diag/graph_updates
 ```
 
 The expected data rate is about `1 kB/s` per `ptp4l`, `phc2sys` or sensor instance.
-For an architecture like ***REMOVED*** gen2, this results in a data rate of about `14 kB/s`.
+Even for large architectures with many ECUs and sensors, the data rate stays in the low
+10s of `kB/s` range.
 
 The bag can be replayed at a later time on any machine with only a `diag-master` running:
 

docs/ptp-architecture-guide.md

@@ -272,11 +272,8 @@ located in `/usr/share/doc/linuxptp/configs/`.
 
 !!! bug
     Do not run gPTP or Automotive PTP on network links with more than two participants,
-    as this will lead to synchronization faults.
-
-As a case study, ***REMOVED*** gen2 is using a switch that does not support gPTP, so it was necessary
-to configure the switch to forward PTP traffic in a way that simulates many 1-to-1 links.
-See [***REMOVED*** gen2 PTP troubleshooting](https://tier4.atlassian.net/wiki/x/jIAvwg) for details.
+    as this will lead to synchronization faults. If e.g. you want to sync four sensors with
+    gPTP from one ECU, the ECU needs four separate network interfaces, each supporting gPTP.
 
 ### ECU PTP Architecture
 

docs/usage.md

@@ -153,7 +153,8 @@ ros2 bag record /sync_diag/graph_updates
 ```
 
 The expected data rate is about `1 kB/s` per `ptp4l`, `phc2sys` or sensor instance.
-For an architecture like ***REMOVED*** gen2, this results in a data rate of about `14 kB/s`.
+Even for large architectures with many ECUs and sensors, the data rate stays in the low
+10s of `kB/s` range.
 
 The bag can be replayed at a later time on any machine with only a `diag-master` running: