在当今信息时代，共享屏幕软件成为了日常工作与学习中不可或缺的工具，它允许用户通过网络将屏幕内容实时传输给其他人。本文将详细探讨一款基于TCP协议，使用C++和QT框架开发的简单共享屏幕软件。该软件由客户端和服务器端组成，旨在实现高质量且低延迟的屏幕共享功能。 TCP协议是传输控制协议（Transmission Control Protocol）的简称，它是一种面向连接的、可靠的、基于字节流的传输层通信协议。在共享屏幕软件中，TCP协议能够保证数据包传输的顺序和完整性，是保证共享屏幕稳定性的关键。 QT是一个跨平台的应用程序和用户界面框架，使用C++语言开发。QT的网络模块提供了强大的支持，包括TCP套接字的使用，这为开发网络通信应用程序提供了便利。QT同时提供了丰富的图形界面组件，使得制作友好的用户界面成为可能。 在开发基于TCP的共享屏幕软件时，客户端的主要功能是捕获屏幕内容，并将这些内容通过TCP连接发送给服务器端。为了提高效率，客户端通常会进行图像压缩，减少网络传输的数据量，同时会使用高效的编码算法来尽量保持图像质量。此外，客户端还需要处理网络异常、数据重传等问题。 服务器端的主要职责是接收来自客户端的数据，进行解码还原，并将图像内容展示给其他用户。服务器端同样需要高效地处理并发连接，以及在多个客户端间同步共享内容。服务器端还需要提供一定的安全措施，以防止未授权访问。 本项目中的服务器端程序，名为MyShareScreenServer，它是整个共享屏幕系统的核心。服务器端会维护一个连接列表，记录所有活跃的客户端连接，并对数据包进行排序和分发。服务器端还负责管理用户权限，确保只有授权用户能够访问共享屏幕。 对于标签“qt c++ 网络协议 软件/插件”的解读，说明该共享屏幕软件使用了QT框架和C++语言进行开发，同时涉及到网络协议的知识。软件或插件的形式可以使得该共享屏幕程序能够方便地集成到其他应用中，或独立作为一个程序运行。 开发者在设计这款软件时需要考虑很多因素，如跨平台兼容性、网络延迟、编码解码效率、安全性等。为了达到较好的用户体验，软件需要具备直观的操作界面和灵活的设置选项，以适应不同的使用场景和需求。 此外，软件的文档和使用说明也非常重要，它能帮助用户快速理解如何使用软件，以及如何处理可能出现的问题。开发者应该提供详细的API文档，以及示例代码，方便其他开发者进行二次开发或者集成该软件到自己的系统中。 基于TCP的简单共享屏幕软件（c++QT制作）是一个结合了现代网络技术和图形用户界面设计的软件产品。它充分利用了QT框架的跨平台优势和C++的强大性能，通过TCP协议保障了共享过程的稳定性和可靠性。MyShareScreenServer作为服务器端程序，在整个共享过程中扮演着至关重要的角色，确保数据能够高效、安全地传输和展示。这款软件的成功开发，不仅体现了开发者的技术实力，也为远程协作和在线教育等领域提供了有力支持。

DoNotSend-入侵DNS协议 在Windows和Linux上均可使用 DNS协议通常用于询问给定网站的IP地址。 在这里，它用于发送消息和检索其他消息，而不是询问网站IP地址并检索其IP地址。 免责声明 该工具可通过利用DNS协议中的缺陷来发送消息，但也可用于（如指出的那样）从网络中窃取数据。 对于该项目的任何滥用我不承担任何责任。 另请注意，您的ISP最有可能记录您的DNS查询，因此它不是100％匿名的。 设置 Python> = 3.7 Scapy> = 2.4 如果未与scapy一起安装： libpcap的 静脉有时也需要wheel模块 apt install python3-venv python3 -m venv venv/ source venv/bin/activate pip3 install scapy # if it fails because it could

ISO15765-1: 一般信息和用例定义 ISO15765-2: 传输协议和网络层服务 ISO15765-3: 实现统一的诊断服务（UDS CAN） ISO15765-4: 对碳排放相关系统的要求；这里定义了 0x7E0和0x18DA00F1 的ID

1、包含nlink_linktrack_nodeframe1及nlink_linktrack_nodeframe4两种协议解析方法 2、nlink_linktrack_nodeframe1协议可获取6基站以内的一键标定的标签Tag空间坐标数据映射--（） 3、nlink_linktrack_nodeframe4协议可获取6基站以上的自定义排布基站的标签Tag空间坐标数据映射--（） 4、ReadMe文档内包含协议内容及测试输出数据 5、该文件为of框架编写的ofxUwbLinkTrack插件，可以迁移其他C++平台使用

实验内容七：RIP、OSPF动态路由协议 实验目的：配置RIP、OSFP动态路由 实验任务1：RIP路由配置实验 （1） 添加三台2811型号路由器，为每台路由器添加网络接口模块 先关闭路由器电源，电源开关如下图。 ( 实际操作中，为确保电路安全，只有关机后,才可以在路由器中插入新的网络模块卡，类似往计算机中插入网卡。） 在三台路由器上均添加模块NM-2FE2W，拖拽右下角模块到左上方路由器插槽中，如下图所示。（NM-2FE2W有2个 快速以太网接口）。 插入新模块后，再重新开启路由器。 （2） 添加三台PC机，所有设备之间用交叉线连接，配置网络接口IP地址。 按照拓扑图中地址设置， 配置路由器各网络接口IP地址、子网掩码。 配置PC机各网络接口IP地址、子网掩码、默认网关。 （3）分别查看三台路由器的路由表 Router# show ip route 三个路由表中，只显示了每台路由器直接连接的网络地址和接口。 （4）在三台路由器上，分别配置动态RIP路由协议，自动更新路由表。 R1路由器示例： Router>enable Router#config ### 计算机网络实验报告-实验七：RIP、OSPF动态路由协议 #### 实验目的 本次实验旨在深入理解并实践RIP与OSPF这两种动态路由协议的配置过程。通过具体的操作来掌握如何利用这些协议实现网络间的自动路由发现与更新，从而提升网络的灵活性和效率。 #### 实验任务1：RIP路由配置实验 ##### 任务描述 本任务分为五个主要步骤： 1. **添加三台2811型号路由器**，并为它们添加网络接口模块； 2. **添加三台PC机**，并通过交叉线连接所有设备，并配置IP地址； 3. **查看初始路由表**，确认只包含直连网络的信息； 4. **配置RIP动态路由协议**，使路由器能够自动更新路由表； 5. **验证路由表更新情况**，确保所有路由器之间的连通性。 ##### 实验步骤详解 ### 第一步：配置路由器与网络接口 - **准备阶段**：首先关闭所有路由器的电源。这是为了保证在添加新的网络模块时不会出现短路等安全问题。接着，在每个路由器上安装NM-2FE2W模块，该模块提供两个快速以太网接口。安装完毕后，重新开启路由器。 ### 第二步：连接PC机并配置IP地址 - **连接设备**：将三台PC机分别通过交叉线与路由器相连。然后，根据拓扑图的要求，设置各个网络接口的IP地址、子网掩码以及PC机的默认网关。这些设置确保设备能够在各自的子网内通信。 ### 第三步：查看初始路由表 - **检查路由信息**：在每台路由器上执行`Router# show ip route`命令，可以查看当前的路由表。此时，路由表仅包含直连网络的信息。这是因为尚未配置任何动态路由协议。 ### 第四步：配置RIP动态路由协议 - **启动RIP协议**：在路由器R1上，进入配置模式，使用`Router(config)#router rip`命令启动RIP协议。然后，选择版本2(`Router (config-router)#version 2`)以支持无类别域间路由(CIDR)。 - **通告网络**：使用`network`命令告知RIP协议所连接的网络，如`Router (config-router)#network 192.168.1.0`。对于R1来说，需要通告它连接的所有三个网络。 - **禁用自动汇总**：为了避免不必要的路由汇总，可以通过`Router (config-router)#no auto-summary`命令禁用此功能。 - **完成配置**：完成配置后，使用`Router (config-router)#exit`退出配置模式。 ### 第五步：验证路由表更新 - **更新后的路由表**：在每台路由器上再次执行`Router# show ip route`命令，这次应该可以看到所有连接的网络信息，包括通过RIP学习到的远程网络。 - **连通性测试**：通过`ping`命令测试不同子网内的PC机之间的连通性。例如，从PC0尝试ping PC1或PC2，以验证数据包能否成功穿越路由器到达目标。 #### 结论 通过以上步骤，我们不仅成功地配置了RIP动态路由协议，而且还验证了其在网络中的有效性。RIP协议能够自动发现和更新路由信息，极大地简化了网络管理的工作量，并提高了网络的整体性能。此外，还了解了如何通过配置避免自动汇总等问题，进一步增强了网络的稳定性。 #### 扩展思考 除了RIP之外，实验还提到了另一种动态路由协议——OSPF。虽然本次实验未涉及OSPF的具体配置，但可以预见，OSPF作为更高级别的路由协议，在大型网络中具有更为广泛的应用前景。未来的学习过程中，可以进一步探索OSPF的相关知识，包括其区域划分、LSA(Link State Advertisement)机制等，以更好地理解现代网络架构的设计原理和技术细节。

"纯Verilog实现万兆网以太网全功能UDP协议，支持ARP与ping功能，Xilinx平台产品化测试验证稳定可靠",纯Verilog实现万兆网以太网UDP协议，支持ARP与ping功能，Xilinx平台产品化测试稳定可靠。,纯verilog编写实现万兆网以太网完整UDP协议，并支持ARP和ping功能，在xilinx平台已产品化测试，稳定可靠 ,纯Verilog编写;万兆网以太网UDP协议;支持ARP和ping功能;Xilinx平台产品化测试;稳定可靠,纯Verilog实现万兆网以太网UDP协议，支持ARP和ping功能，Xilinx平台稳定可靠

1 Scope 11 2 References 11 3 Terms and definitions 12 4 Abbreviations 14 5 Conventions 17 6 Optical transport network interface structure 18 6.1 Basic signal structure 19 6.1.1 OCh substructure 19 6.1.2 Full functionality OTM n.m (n ≥ 1) structure 19 6.1.3 Reduced functionality OTM nr.m and OTM 0.m structure 20 6.2 Information structure for the OTN interfaces 20 7 Multiplexing/mapping principles and bit rates 24 7.1 Mapping 26 7.2 Wavelength division multiplex 27 7.3 Bit rates and capacity 27 7.4 ODUk Time Division Multiplex 28 8 Optical transport module (OTM n.m, OTM nr.m, OTM 0.m) 30 8.1 OTM with reduced functionality (OTM 0.m, OTM nr.m, OTM-0v.m) 30 8.1.1 OTM 0.m 31 8.1.2 OTM nr.m 31 8.1.2.1 OTM 16r.m 31 8.1.2.2 OTM 32r.m 33 8.1.3 OTM 0v.m Error! Bookmark not defined. 8.2 OTM with full functionality (OTM n.m) 35 9 Physical specification of the ONNI 37 9.1 OTM 0.m 37 9.2 OTM nr.m 37 9.2.1 OTM 16r.m 37 9.2.2 OTM 32r.m 37 9.3 OTM n.m 37 9.3 OTM 0v.m Error! Bookmark not defined. 10 Optical channel (OCh) 37 10.1 OCh with full functionality (OCh) 37 10.2 OCh with reduced functionality (OChr) 38 11 Optical channel transport unit (OTU) 38 11.1 OTUk frame structure 38 11.2 Scrambling 40 12 Optical channel data unit (ODUk) 40 12.1 ODUk frame structure 40 13 Optical channel payload unit (OPUk) 41 14 OTM overhead signal (OOS) 41 15 Overhead description 41 15.1 Types of overhead 43 15.1.1 Optical channel payload unit overhead (OPUk OH) 43 15.1.2 Optical channel data unit overhead (ODUk OH) 43 15.1.3 Optical channel transport unit overhead (OTUk OH) 44 15.1.4 Optical channel non-associated overhead (OCh OH) 44 15.1.5 Optical multiplex section overhead (OMS OH) 44 15.1.6 Optical transmission section overhead (OTS OH) 44 15.1.7 General management communications overhead (COMMS OH) 44 15.2 Trail trace identifier and access point identifier definition 44 15.3 OTS OH description 46 15.3.1 OTS trail trace identifier (TTI) 46 15.3.2 OTS backward defect indication – Payload (BDI-P) 46 15.3.3 OTS backward defect indication – Overhead (BDI-O) 46 15.3.4 OTS payload missing indication (PMI) 46 15.4 OMS OH description 47 15.4.1 OMS forward defect indication – Payload (FDI-P) 47 15.4.2 OMS forward defect indication – Overhead (FDI-O) 47 15.4.3 OMS backward defect indication – Payload (BDI-P) 47 15.4.4 OMS backward defect indication – Overhead (BDI-O) 47 15.4.5 OMS payload missing indication (PMI) 47 15.5 OCh OH description 47 15.5.1 OCh forward defect indication – Payload (FDI-P) 47 15.5.2 OCh forward defect indication – Overhead (FDI-O) 47 15.5.3 OCh open connection indication (OCI) 47 15.6 OTUk/ODUk frame alignment OH description 48 15.6.1 OTUk/ODUk frame alignment overhead location 48 15.6.2 OTUk/ODUk frame alignment overhead definition 48 15.6.2.1 Frame alignment signal (FAS) 48 15.6.2.2 Multiframe alignment signal (MFAS) 48 15.7 OTUk OH description 49 15.7.1 OTUk overhead location 49 15.7.2 OTUk overhead definition 50 15.7.2.1 OTUk section monitoring (SM) overhead 50 15.7.2.1.1 OTUk SM trail trace identifier (TTI) 50 15.7.2.1.2 OTUk SM error detection code (BIP-8) 50 15.7.2.1.3 OTUk SM backward defect indication (BDI) 51 15.7.2.1.4 OTUk SM backward error indication and backward incoming alignment error (BEI/BIAE) 51 15.7.2.1.5 OTUk SM incoming alignment error overhead (IAE) 52 15.7.2.1.6 OTUk SM reserved overhead (RES) 52 15.7.2.2 OTUk general communication channel 0 (GCC0) 52 15.7.2.3 OTUk reserved overhead (RES) 52 15.7.3 OTUkV overhead 52 15.8 ODUk OH description 53 15.8.1 ODUk OH location 53 15.8.2 ODUk OH definition 54 15.8.2.1 ODUk path monitoring (PM) overhead 54 15.8.2.1.1 ODUk PM trail trace identifier (TTI) 54 15.8.2.1.2 ODUk PM error detection code (BIP-8) 54 15.8.2.1.3 ODUk PM backward defect indication (BDI) 55 15.8.2.1.4 ODUk PM backward error indication (BEI) 55 15.8.2.1.5 ODUk PM status (STAT) 56 15.8.2.2 ODUk tandem connection monitoring (TCM) overhead 56 15.8.2.2.1 ODUk TCM trail trace identifier (TTI) 58 15.8.2.2.2 ODUk TCM error detection code (BIP-8) 59 15.8.2.2.3 ODUk TCM backward defect indication (BDI) 59 15.8.2.2.4 ODUk TCM backward error indication (BEI) and backward incoming alignment error (BIAE) 59 15.8.2.2.5 ODUk TCM status (STAT) 60 15.8.2.2.6 TCM overhead field assignment 61 15.8.2.2.7 ODUk tandem connection monitoring activation/deactivation coordination protocol 62 15.8.2.3 ODUk general communication channels (GCC1, GCC2) 62 15.8.2.4 ODUk automatic protection switching and protection communication channel (APS/PCC) 62 15.8.2.5 ODUk fault type and fault location reporting communication channel (FTFL) 63 15.8.2.5.1 Forward/backward fault type indication field 63 15.8.2.5.2 Forward/backward operator identifier field 64 15.8.2.5.3 Forward/backward operator specific field 65 15.8.2.6 ODUk experimental overhead (EXP) 65 15.8.2.7 ODUk reserved overhead (RES) 65 15.9 OPUk OH description 65 15.9.1 OPUk OH location 65 15.9.2 OPUk OH definition 66 15.9.2.1 OPUk payload structure identifier (PSI) 66 15.9.2.1.1 OPUk payload type (PT) 66 15.9.2.2 OPUk mapping specific overhead 67 16 Maintenance signals 67 16.1 OTS maintenance signals 68 16.1.1 OTS payload missing indication (OTS-PMI) 68 16.2 OMS maintenance signals 68 16.2.1 OMS forward defect indication – Payload (OMS-FDI-P) 68 16.2.2 OMS forward defect indication – Overhead (OMS-FDI-O) 68 16.2.3 OMS payload missing indication (OMS-PMI) 68 16.3 OCh maintenance signals 68 16.3.1 OCh forward defect indication – Payload (OCh-FDI-P) 68 16.3.2 OCh forward defect indication – Overhead (OCh-FDI-O) 68 16.3.3 OCh open connection indication (OCh-OCI) 68 16.4 OTUk maintenance signals 68 16.4.1 OTUk alarm indication signal (OTUk-AIS) 68 16.5 ODUk maintenance signals 69 16.5.1 ODUk alarm indication signal (ODUk-AIS) 69 16.5.2 ODUk open connection indication (ODUk-OCI) 69 16.5.3 ODUk locked (ODUk-LCK) 70 16.6 Client maintenance signal 71 16.6.1 Generic AIS for constant bit rate signals 71 17 Mapping of client signals 72 17.1 Mapping of CBR2G5, CBR10G, CBR10G3 and CBR40G signals (e.g., STM-16/64/256, 10GBASE-R) into OPUk 72 17.1.1 Mapping a CBR2G5 signal (e.g., STM-16) into OPU1 74 17.1.2 Mapping a CBR10G signal (e.g., STM-64) into OPU2 75 17.1.3 Mapping a CBR40G signal (e.g. STM-256) into OPU3 75 17.1.4 Mapping a CBR10G3125 signal (e.g., 10GBASE-xR) into OPU2e 76 17.2 Mapping of ATM cell stream into OPUk 76 17.3 Mapping of GFP frames into OPUk 77 17.4 Mapping of test signal into OPUk 78 17.4.1 Mapping of a NULL client into OPUk 78 17.4.2 Mapping of PRBS test signal into OPUk 78 17.5 Mapping of a non-specific client bit stream into OPUk 79 17.5.1 Mapping bit stream with octet timing into OPUk 80 17.5.2 Mapping bit stream without octet timing into OPUk 80 17.6 Mapping of other constant bit-rate signals with justification into OPUk 80 17.7 Mapping a 1000BASE-X and FC-1200 signal via timing transparent transcoding into OPUk 80 17.7.1 Mapping a 1000BASE-X signal into OPU0 81 17.7.2 Mapping a FC-1200 signal into OPU2e 88 18 Concatenation 88 18.1 Virtual concatenation of OPUk 91 18.1.1 Virtual concatenated OPUk (OPUk-Xv, k = 1 .. 3, X = 1 .. 256) 91 18.1.2 OPUk-Xv OH description 92 18.1.2.1 OPUk-Xv OH location 92 18.1.2.2 OPUk-Xv OH definition 93 18.1.2.2.1 OPUk-Xv Payload Structure Identifier (PSI) 93 18.1.2.2.1.1 OPUk-Xv Payload Type (vcPT) 93 18.1.2.2.1.2 OPUk-Xv Payload Structure Identifier Reserved overhead (RES) 94 18.1.2.2.2 OPUk-Xv Virtual Concatenation Overhead (VCOH1/2/3) 94 18.1.2.2.2.1 OPUk-Xv Virtual Concatenation MultiFrame Indicator (MFI1, MFI2) 94 18.1.2.2.2.2 OPUk-Xv Sequence Indicator (SQ) 95 18.1.2.2.2.3 OPUk-Xv LCAS Control Words (CTRL) 95 18.1.2.2.2.4 OPUk-Xv LCAS Member Status Field (MST) 95 18.1.2.2.2.5 OPUk-Xv LCAS Group Identification (GID) 95 18.1.2.2.2.6 OPUk-Xv LCAS Re-Sequence Acknowledge (RS-Ack) 95 18.1.2.2.2.7 OPUk-Xv LCAS Cyclic Redundancy Check (CRC) 96 18.1.2.2.2.8 OPUk-Xv VCOH Reserved Overhead 96 18.1.2.2.3 OPUk Mapping Specific Overhead 96 18.2 Mapping of client signals 96 18.2.1 Mapping of CBR signals (e.g., STM-64/256) into OPUk-4v 96 18.2.1.1 Mapping a CBR10G signal (e.g. STM-64) into OPU1-4v 97 18.2.1.2 Mapping a CBR40G signal (e.g. STM-256) into OPU2-4v 98 18.2.2 Mapping of CBR signals (e.g., STM-256) into OPUk-16v 98 18.2.2.1 Mapping a CBR40G signal (e.g., STM-256) into OPU1-16v 100 18.2.3 Mapping of ATM cell stream into OPUk-Xv 101 18.2.4 Mapping of GFP frames into OPUk-Xv 102 18.2.5 Mapping of test signal into OPUk-Xv 102 18.2.5.1 Mapping of a NULL client into OPUk-Xv 102 18.2.5.2 Mapping of PRBS test signal into OPUk-Xv 103 18.2.6 Mapping of a non-specific client bit stream into OPUk-Xv 104 18.2.6.1 Mapping bit stream with octet timing into OPUk-Xv 105 18.2.6.2 Mapping bit stream without octet timing into OPUk-Xv 105 18.3 LCAS for virtual concatenation 105 19 Mapping ODUj signals into the ODTUjk and ODTU? signals 105 19.1 OPUk Tributary Slot definition 105 19.1.1 OPU2 Tributary Slot allocation 106 19.1.2 OPU3 Tributary Slot allocation 107 19.1.3 OPU4 Tributary Slot allocation 110 19.1.4 OPU1 Tributary Slot allocation 109 19.2 ODTUjk and ODTU? definitions 110 19.2.1 ODTU12 110 19.2.2 ODTU13 110 19.2.3 ODTU23 110 19.2.7 ODTU01 110 19.2.8 ODTU? Error! Bookmark not defined. 19.3 Multiplexing ODTUjk and ODTU? signals into the OPUk 111 19.3.1 ODTU12 mapping into one OPU2 2.5G Tributary Slot 111 19.3.2 ODTU13 mapping into one OPU3 2.5G Tributary Slot 112 19.3.3 ODTU23 mapping into four OPU3 2.5G Tributary Slots 113 19.3.4 ODTU01 mapping into one OPU1 1.25G Tributary Slot 114 19.4 OPUk Multiplex Overhead 115 19.4.1 OPUk Multiplex Structure Identifier (MSI) 118 19.4.1.1 OPU2 Multiplex Structure Identifier (MSI) 119 19.4.1.2 OPU3 Multiplex Structure Identifier (MSI) 119 19.4.1.3 OPU4 Multiplex Structure Identifier (MSI) 120 19.4.1.4 OPU1 Multiplex Structure Identifier (MSI) Error! Bookmark not defined. 19.4.2 OPUk Payload Structure Identifier Reserved overhead (RES) 120 19.4.3 OPUk Multiplex Justification Overhead (JOH) 121 19.4.3.1 Asynchronous Mapping Procedure Error! Bookmark not defined. 19.4.3.2 Asynchronous Generic Mapping Procedure Error! Bookmark not defined. 19.4.4 OPU4 Multi Frame Identifier overhead (OMFI) 121 19.5 Mapping ODUj into ODTUjk 121 19.5.1 Mapping ODU1 into ODTU12 122 19.5.2 Mapping ODU1 into ODTU13 123 19.5.3 Mapping ODU2 into ODTU23 124 19.5.4 Mapping ODU0 into ODTU01 126 ODU0 into OPUk Tributary Slot Mapping Error! Bookmark not defined. 19.6 Mapping ODUj into ODTU

### 3GPP TS 36.300 V10.2.0协议解析 #### 一、概述 3GPP TS 36.300 V10.2.0是3GPP（第三代合作伙伴项目）为Evolved Universal Terrestrial Radio Access (E-UTRA) 和 Evolved Universal Terrestrial Radio Access Network (E-UTRAN)制定的技术规范文档，该版本发布于2010年12月。本文档主要涉及E-UTRA和E-UTRAN的整体描述，特别是第二阶段（Stage 2）的设计和技术细节。 #### 二、关键词解释 - **UMTS**：即通用移动通信系统，是一种3G移动通信技术标准。 - **Stage 2**：指在UMTS标准中的设计阶段，通常涉及系统架构、接口定义等高级别描述。 - **Radio**：在此文中特指无线电接入技术。 - **Architecture**：架构，在这里是指E-UTRA/E-UTRAN系统的整体结构设计。 #### 三、技术规范概览 ##### 1. 范围(Scope) 该文档规定了E-UTRA和E-UTRAN的整体架构及其功能划分。其目标是为未来的开发工作提供指导，并确保与现有UMTS标准的一致性和兼容性。 ##### 2. 引用(References) 文档中引用了一系列相关的技术规范和文档，这些规范和文档为理解本文档提供了必要的背景信息和支持。 ##### 3. 定义、符号和缩写(Definitions, symbols and abbreviations) 文档中定义了一系列术语、符号和缩写，以便清晰地传达技术细节。例如，“E-UTRA”指的是演进型通用陆地无线接入技术，“E-UTRAN”指的是演进型通用陆地无线接入网络。 - **3.1 定义(Definitions)** 这部分定义了与E-UTRA/E-UTRAN相关的关键概念和技术术语，如“用户平面(User plane)”、“控制平面(Control plane)”等。 - **3.2 缩写(Abbreviations)** 包括了一系列重要的缩写词，比如E-UTRA、E-UTRAN、HNB（Home Node B）、HNB-GW（HNB Gateway）等。 ##### 4. 整体架构(Overall architecture) 这部分详细描述了E-UTRA/E-UTRAN的整体架构，包括功能性划分、无线电协议架构等方面。 - **4.1 功能性划分(Functional Split)** 描述了E-UTRAN内部的功能模块划分以及它们之间的交互方式。这种划分对于优化性能和简化网络设计至关重要。 - **4.2 空缺(Void)** 文档中提到的部分空缺部分，可能是由于后续版本会进一步补充或修改的地方。 - **4.3 无线电协议架构(Radio Protocol architecture)** - **4.3.1 用户平面(User plane)** 用户平面处理数据流的传输，包括数据包的封装和解封装、加密等功能。 - **4.3.2 控制平面(Control plane)** 控制平面负责信令消息的传输，管理无线资源，协调网络操作。 - **4.4 同步(Synchronization)** 讨论了E-UTRA/E-UTRAN中的同步机制，确保所有节点之间的时间同步，这对于高效的数据传输至关重要。 - **4.5 IP分片(IP fragmentation)** 提到了IP分片的问题，这是在网络层对大型数据包进行分割以适应不同网络设备的MTU（最大传输单元）限制的过程。 - **4.6 支持HeNBs(Support of HeNBs)** HeNBs是指家庭基站（Home Node Bs），这部分讨论了如何支持小型基站的集成，以增强网络覆盖和服务质量。 #### 四、总结 3GPP TS 36.300 V10.2.0是关于E-UTRA/E-UTRAN的关键技术规范之一，它详细阐述了这些技术的核心架构和设计原则。通过深入研究这份文档，可以更好地理解4G/LTE网络的工作原理和技术细节。此外，该文档还为后续版本的技术发展奠定了基础，并为网络运营商提供了实现标准的一致性指南。

内容概要：本文详细介绍了STM32F1系列单片机的空中升级（OTA）解决方案，采用YModem协议进行固件更新。首先讲解了Bootloader的设计，包括启动时的跳转逻辑、中断向量表偏移以及Flash擦写操作。接着探讨了上位机部分，使用C#实现了YModem协议的文件分块发送，并强调了CRC校验和包序号校验的重要性。最后分享了一些实用的调试技巧和常见问题的解决方案，如波特率选择、内存对齐、Flash擦除等。 适合人群：从事嵌入式开发的技术人员，尤其是熟悉STM32平台并希望掌握空中升级技术的研发人员。 使用场景及目标：适用于需要对STM32F1系列单片机进行远程固件更新的项目，帮助开发者理解和实现基于YModem协议的空中升级方案，提高系统的灵活性和维护性。 其他说明：文中提供了详细的代码示例和配置步骤，便于读者快速上手实践。同时提醒读者注意一些容易忽视的关键点，如波特率设置、Flash擦除方式等，以确保升级过程顺利进行。

### 韦根门禁通讯协议详解 #### 一、前言 Wiegand（韦根）协议是一种专用于门禁控制系统中读卡器与卡片间通信的标准协议，由摩托罗拉公司制定。该协议主要关注于数据传输方式，而非具体的通信速率或数据长度。 #### 二、韦根数据输出的基本概念 韦根数据输出通过两条线实现，分别是DATA0和DATA1，这两条线分别用于传输数字“0”和“1”。 - **传输“0”**：DATA0线上会产生一个负脉冲。 - **传输“1”**：DATA1线上会产生一个负脉冲。 - **脉冲参数**：负脉冲宽度TP为100微妙，周期TW为1600微妙。 #### 三、韦根26位输出格式 韦根26位输出格式是当前应用最为广泛的一种格式，具体结构如下： ``` EXXXXXXXXXXXXXXXXXXXXXXXXO ``` - **格式解释**：前12位为偶校验，接下来12位为实际数据（地区码和卡号），最后12位为奇校验。 - **地区码**：如果地区码为2个字符（8位），则可以设置255个不同的地区码。 - **卡号**：如果卡号为4个字符（16位），则可以设置65536个不同的卡号。 以电子卡为例，假设地区码为01，卡号为0001，则韦根输出为： ``` 10000000100000000000000010 ``` #### 四、韦根26接收 由于韦根协议对接收时间的实时性有较高要求，因此简单的查询方法容易导致数据丢失。为了避免这种情况，推荐使用中断的方式进行接收： - 当DATA0线上检测到0时，应立即触发中断处理程序，以避免因主程序执行其他任务而导致的数据丢失。 - 中断处理程序应在接收到数据后立即更新接收标志位，以便主程序能够及时响应并正确处理数据。 #### 五、韦根接口定义 Wiegand接口通常包含以下三个组成部分： - **DATA0**：通常为绿色线，负责传输数字“0”。 - **DATA1**：通常为白色线，负责传输数字“1”。 - **GND**：通常为黑色线，作为信号地。 安装商在连接读卡器和门禁控制面板时，需要确保这些接口清晰可见。 #### 六、发送程序示例 以下是一个将数组封装成韦根26格式的发送程序示例： ```c void send_wiegand26(uchar *str) { // 数组到韦根包的转换逻辑 uchar datai; static uchar dataone_num; // 计算1的个数 uchar datacheck_temp; // 奇偶校验中间暂存 bit even; // 前12位偶校验 bit odd; // 后12位奇校验 static uchar datawiegand[3]; // 韦根包数据24位 // 端口方向定义 P3M0 = 0x00; // 普通I/O口 P3M1 = 0x00; // 数组到韦根包的转化 wiegand[0] = wiegand[0] | ((*str << 4)); wiegand[0] = wiegand[0] | (*(str + 1) & 0x0f); // 计算前8位1的个数，为偶校验使用 check_temp = 0; for (datai = 0; datai < 8; datai++) { if ((wiegand[0] >> datai) & 0x01) { check_temp++; } } even = (check_temp % 2 == 0); // ...后续的奇校验计算和数据发送过程省略... } ``` 通过上述内容，我们可以了解到韦根门禁通讯协议的基本原理及其在门禁系统中的应用。此外，还提供了韦根26位格式的具体结构及数据传输细节，以及如何通过编程实现数据的发送与接收，为开发人员提供了实用的技术指导。