硬件制作有 CDC 的加入，很多信号不再需要全部集中在同一块板子上，因此蔬菜盒子 v2 的硬件按功能重新拆分。当前设计同时承担两件事：一是完成胎温、CAN、485、4G 等数据采集与转发；二是保留 24V、5V、3.3V 的电源转换和分配能力，为后续把它扩展成小型电源转换平台留余量。本版硬件工程主要由以下几块组成：Base：母板和连接分配板，负责 STM32F407 最小系统板、信号预处理板、电源板、4G 模块、调试接口和外部线束之间的互连。MINSYS：STM32F407ZET6 最小系统板，提供主控、时钟、复位、SWD 调试和基础测试 LED。pre-process：信号预处理板，集中处理胎温 I2C 多路复用、CAN 控制器、CAN 收发保护和 4 个 RS485 输出拉力传感器的数据读取。power：电源板，完成 24V 到 5V、5V 到 3.3V 的 DC-DC 转换，并把各路电源送回母板。I2C-CONVERTER：胎温传感器转接小板，用于把 MLX90640 模块接口转换成统一的 4Pin 线束接口。硬件选型与设计4G远程发送模块目前的选型最终确定为银尔达公司的合宙 Core-Y100M-B 套餐，AT 组件，也就意味着上电后需要依赖 MCU 通过 AT 指令完成模块配置。Core-Y100m 资料链接：https://yinerda.yuque.com/yt1fh6/4gdtu/hpv7ne23txp3lu21银尔达DTU/RTU产品技术售后处理：https://yinerda.yuque.com/yt1fh6/4gdtu/iov6crmokc8ywu4n这些资料已经涵盖该模块的硬件和软件调试说明，代码部分不在这里详细展开。硬件上 4G 模块通过母板上的 7Pin 接口接入，主要信号包括 VIN_5V、VIN_GND、USART1_TX、USART1_RX、PA11、PA12 和 PF7。其中 USART1 用于 AT 指令和数据交互，其余控制脚可按实际固件需求用于上电控制、状态检测或流控。胎温传感器选型完全成熟的胎温传感器价格不菲（￥500+，最高￥2000），自制实属无奈之举。目前的选型为 MLX90640-BAB 红外热成像仪，32 × 24 像素，最快刷新率 1Hz，此时的分辨率为 0.1℃，降低刷新率的话精度可以更高。选型资料：使用MLX90640自制红外热像仪(一)：MLX90640介绍与API库移植-CSDN博客选购的是这个：MLX90640ESF-BAA/BAB 红外测温点阵传感器模块 红外成像/IR热像仪-淘宝网商家说明模块板上已经带 4.7k I2C 上拉电阻，因此传感器转接板不再额外放上拉。主板侧只需要保证总线电平、线序和多路复用通道选择正确。最小系统板——STM32F407ZET6最小系统板使用 STM32F407ZET6 作为主控，外设资源从两组 2 × 20 排针和一组 2 × 20 排针引出，再由母板分配给各个功能板。当前引脚分配里常用外设如下：USART1：4G 模块通信。USART2：预留串口或调试通信。USART3 / I2C2：该组管脚存在复用冲突，原理图中已标注不能同时使用。USART5：与 SPI3 复用相关，实际使用时需要按固件配置确认。SPI1 / SPI3：用于连接 MCP2518FD 等 SPI 外设。I2C1 / I2C2 / I2C3：用于胎温传感器、外设扩展或调试。CAN1 / CAN2：保留 MCU 原生 CAN 资源，和外部 MCP2518FD 扩展 CAN 共同使用。供电方面，核心板只接入 3.3V，不再单独接 5V；3.3V 由底板 DC-DC 提供。每个 VDD 附近按原理图布置 100nF 去耦电容，VDDA 通过 BLM21PG121SN1D 磁珠与数字 3.3V 隔离，并配 1uF 与 100nF 滤波，降低模拟电源噪声。时钟部分包含 8MHz 主晶振和 32.768kHz 低速晶振。BOOT0 通过 10k 下拉，默认从主闪存启动，不适合直接依赖串口下载；BOOT1 对应 PB2，高低电平都可以，建议悬空。复位电路由 10k 上拉、100nF 电容和按键组成，SWD 接口引出 3.3V、GND、SWDIO、SWCLK，方便下载和调试。板上还放置了红、绿两个测试 LED，分别串 1k 电阻到 MCU 控制脚。母板与板间连接——BaseBase 板承担整个系统的连接分配职责，本身尽量少做复杂信号处理，主要把核心板、预处理板、电源板和外部接口可靠地接在一起。核心板的排针信号在 Base 上被重新命名和分组：胎温相关信号按 DA_FL、CK_FL、DA_FR、CK_FR、DA_RL、CK_RL、DA_RR、CK_RR 引出；CAN 信号按 CANA、CANB、CANC、CAN1 分类；SPI 信号分成 SCK_A/MOSI_A/MISO_A/CS_A 和 SCK_B/MOSI_B/MISO_B/CS_B 两组；RS485 拉力传感器总线与 4G 模块各自使用独立连接器。外部供电入口使用 24V 和地输入，电源板输出的 5V、3.3V 和地再回到母板分配给各模块。当前原理图里还预留了 LV_IN+、LV_IN-、LV_、VOUT_5V、VOUT_GND 等低压侧网络，方便后续把这块板扩展成更通用的电源转换和电平支撑平台。CAN信号扩展——MCP2518FDCAN 控制器扩展使用 MCP2518FDTE/SL。它本质上是 SPI 到 CAN FD 控制器的转换芯片，适合在 MCU 原生 CAN 数量不够时扩展更多可控 CAN 通道。当前设计放置两片 MCP2518FD，分别作为 CANA 和 CANB 的控制器：每片 MCP2518FD 使用 40MHz 晶振。与 MCU 之间通过 SPI 通信，信号包括 SCK、MOSI、MISO、CS 和 INT。芯片供电范围支持 2.7V 到 5.5V。当前原理图标注为了缓解 3.3V 供电压力，MCP2518FD 供电使用 5V，但 SPI 侧仍需注意与 MCU 3.3V 逻辑电平兼容。CANA 作为控制器相关 CAN，CANB 作为 CDC 报文相关 CAN。具体命名只服务于线束识别，调试时以实际接线为准。MCP2518FD 后级接 SN65HVD233DR CAN 收发器。系统里共预留四路 CAN 收发：CANA、CANB、CANC 和 CAN1，其中 CANC 面向整车 CAN，CAN1 面向电箱 CAN。每路 CAN 收发器都带 100nF 去耦，RS 脚附近预留电阻用于斜率或模式设置，CANH/CANL 出口前加入共模电感 DLW43SH510XK2L、PESD1CAN ESD 防护和 47pF 到地电容，以提升线束环境下的抗干扰和静电防护能力。终端电阻按实际总线位置决定是否焊接。原理图中针对 CANB 预留了 120Ω 终端，其余通道也需要在整车线束拓扑确认后再决定是否补焊，避免在同一条总线上形成过多终端。胎温传感器I2C 多路信号处理——TCA9548APWRMLX90640 模块地址相同，不能直接并到同一条 I2C 总线上，因此主板使用 TCA9548APWR 做 1 路到 8 路的 I2C 多路复用。MCU 只访问 TCA9548A，再通过软件选择对应通道，分别读取每个轮位的 MLX90640。当前原理图中 A0、A1、A2 全部接地，因此 TCA9548A 地址为 0x70。上游 SDA、SCL 由 4.7k 电阻上拉到 3.3V，芯片旁边放置 100nF 去耦电容。下游实际使用了四组通道，对应四个轮位：SD0/SC0：左前轮胎温。SD1/SC1：右前轮胎温。SD2/SC2：左后轮胎温。SD3/SC3：右后轮胎温。每一路下游 I2C 都串了 22Ω 电阻。这里的 22Ω 主要用于较长线束和电磁环境下的边沿缓和与保护；如果后续实测发现波形过钝、上升沿变慢或通信裕量不足，可以把这组电阻改成 0Ω 进行对比。胎温传感器转接板——I2C-CONVERTERI2C 转接板本身不做信号处理，只负责接口转换。板上同时放置 XD-GX12-4P-M 航插和 2.54mm 1 × 4 母座，四根线序统一为：1: 5V 2: GND 3: SDA 4: SCK这里原理图沿用了 SCK 命名，实际对应 I2C 的 SCL。制作线束时要按功能确认，不要把它和 SPI 的 SCK 混在一起。由于 MLX90640 模块板上已有 4.7k 上拉，转接板保持无源连接即可。4个拉力传感器RS485读取RS485 部分负责读取 4 个带 RS485 输出的拉力传感器。硬件上使用 MAX485ESA(UWM) 完成 MCU 串口电平与差分 A/B 总线之间的转换，通过 UART_485_TX、UART_485_RX 和 DIR 与 MCU 侧连接，传感器侧共用 485_A、485_B 两根差分线接入。4 个拉力传感器挂在同一条 RS485 总线上，软件上需要给每个传感器配置不同地址，再由 MCU 轮询读取。DIR 用于控制 MAX485 收发方向：发送查询帧前切到发送态，发送完成后及时切回接收态，等待对应地址的传感器返回数据。调试时如果出现只有一个传感器能读到、多个传感器同时回复或数据帧粘连，优先检查传感器地址、波特率、校验位和方向切换时序。总线侧预留 120Ω 终端电阻、上下拉偏置电阻和 SM712 防护器件，并配 100nF 电容做局部去耦。终端电阻只应按实际线束拓扑焊在 RS485 总线两端，不能因为有 4 个传感器就每个节点都焊 120Ω，否则总线负载会过重，通信稳定性反而下降。供电平台设计24V转5V24V 到 5V 使用 LM2596S-ADJ。原理图参考成熟模块电路实现，输入端放置 470uF 电解电容和 100nF 高频去耦，开关输出后接 47uH 电感，续流二极管使用 SS34-MS，输出端放置 220uF 电解电容和 100nF 去耦。反馈网络由 3.09k 和 1k 电阻构成，并并联 3.3nF 电容改善环路响应。24V 和 5V 轨分别放置指示 LED，便于上电后快速判断电源链路是否工作。经过多方测试与调整，该路在维持 ±5% 输出电压的情况下，输出电流可达 2.58A，足够当前系统使用。但 LM2596S 在较高压差和较大电流下发热明显，PCB 制作和装配时要优先保证铜皮散热、过孔导热和壳体通风。5V转3.3V5V 到 3.3V 使用 TPS62A02DRLR。原理图中输入端放置 4.7uF 和 100nF 电容，开关节点后接 1uH 电感，输出端使用多颗 22uF、10uF 和 100nF 电容并联，反馈网络由 453k 和 100k 电阻设定输出电压，PG 脚通过 499k 电阻接入。tps62a02-5V转3.3V选型.pdf该芯片方案标注最大负载电流 2A，但系统实测时按当前板载负载，在维持 ±5% 输出电压的情况下输出电流达到 400mA，已经足够给核心板、TCA9548A、CAN 收发器逻辑侧和传感器上拉电平供电。后续如果 3.3V 侧继续增加模块，优先重新核算 3.3V 电流预算和温升。电源板输出通过母板连接器回灌到系统：5V 用于 4G 模块、部分扩展芯片和外设供电；3.3V 用于 MCU、I2C 上拉、CAN 收发器和低压逻辑；所有外设地最终回到 VIN_GND，调试时需要重点检查电源地与信号地的连续性。代码的设计胎温传感器MLX90640单体调试经验记录本节记录的是单个 MLX90640 器件在STM32F103C8T6上的的调试实现，不包含 TCA9548A 多路复用。当前阶段的目标是先验证单个红外阵列传感器的 I2C 通信、官方 API 移植、温度矩阵计算和串口输出链路，确认单器件工作稳定后，再考虑扩展到多传感器方案。硬件与外设配置MLX90640 通过 I2C 与 MCU 通信，模块商家已说明板上带有 4.7k 上拉电阻，因此单体调试时没有额外添加 I2C 上拉。串口调试输出使用 USART1，用于打印 32 × 24 的温度矩阵。为了减少大量文本输出时对主循环的阻塞，USART1_TX 开启 DMA，DMA 通道为 DMA1_Channel4，工作模式为 memory-to-peripheral、normal mode、memory increment enable。CubeMX/CubeIDE 生成代码时需要注意 DMA 初始化顺序：MX_DMA_Init() 要在 MX_USART1_UART_Init() 之前调用。否则 USART 初始化时虽然配置了 DMA 句柄，但 DMA 时钟和中断还没有准备好，后续 HAL_UART_Transmit_DMA() 容易表现异常。官方库初始化流程MLX90640 的初始化依赖官方 API 的 EEPROM 参数提取流程。程序上电后先读取 MLX90640 EEPROM 数据，再调用官方库解析参数。当前单体调试中，初始化成功后输出：MLX90640 initialized如果初始化失败，例如返回 MLX90640 init failed 或官方库错误码，优先检查 I2C 地址、供电、SCL/SDA 接线、I2C 时序和上拉。该阶段不要引入多路复用器逻辑，避免把单器件通信问题和总线切换问题混在一起。完整温度帧计算MLX90640 的 32 × 24 阵列一共 768 个像素，但官方库计算温度时不是一次 I2C 读取就填满全部像素。MLX90640_GetFrameData() 每次读取的是一个 subpage，MLX90640_CalculateTo() 只会根据当前 subpage 更新对应的一半棋盘格像素。因此如果只读取并计算一次就直接输出，会出现隔一个像素为 0.00 的棋盘状结果。这不是 DMA 发送导致的数据损坏，而是温度数组中另一半 subpage 还没有被写入。当前实现采用连续读取并计算两个不同 subpage 的方式，使用 subPageMask 记录 subpage 0 和 subpage 1 是否都已经完成计算；只有两个 subpage 都写入 tempMap[768] 后，才执行坏点修正和矩阵输出。当前主循环的核心顺序为：读取 subpage 0/1 计算当前 subpage 对应像素温度 继续读取直到两个 subpage 都完成 执行 broken/outlier bad pixel correction 按行输出 24 行温度矩阵串口 DMA 输出策略最初如果直接把每个温度值格式化后立即 DMA 发送，会出现报文交叠、缺字、顺序错乱等现象。原因是 DMA 发送是异步过程，发送函数返回时底层仍可能正在读取源缓冲区。如果短时间内复用同一个小 buffer，后一次格式化会覆盖前一次尚未发送完成的数据。当前实现保留原始数据数组不变，仅新增一个 512 字节的行缓冲区。程序先把一整行 32 个温度值格式化到 uartLineBuffer[512]，再调用一次 HAL_UART_Transmit_DMA() 发送整行。UART_SendString() 内部通过 uartTxDone 等待上一笔 DMA 发送完成，并在 HAL_UART_TxCpltCallback() 中置位完成标志。这样既减少了 768 次小包发送的开销，也避免了 DMA 源缓冲被提前覆盖。这个设计的重点是：DMA 只负责降低串口发送阻塞和减少碎片化输出，不能改变 MLX90640 的采样和计算逻辑。温度矩阵必须先由两个 subpage 完整计算得到，再进入发送阶段。当前刷新率与精度取舍目前完整输出一帧温度矩阵大约 1 秒左右，与连续读取两个 subpage、计算 768 点温度、串口输出 24 行文本以及主循环延时有关。降低 MLX90640 刷新率通常可以让单帧噪声更小、画面更稳定，但不会直接消除发射率、环境反射、传感器热稳定和安装视场带来的绝对误差。后续如果需要进一步提高显示稳定性，优先考虑对完整 32 × 24 温度帧做 2 到 4 帧滑动平均，而不是一开始就大幅降低采样频率。对于静态目标，可以降低刷新率并配合平均；对于胎温这类存在动态变化的目标，过低的刷新率会带来明显滞后。基于 TCA9548APWR 的多路复用调试本节记录四个 MLX90640 通过 TCA9548APWR 接入同一条 I2C 总线后的调试过程。四个 MLX90640 模块的器件地址均为 0x33，无法直接并联访问，因此使用 TCA9548A 作为上游多路复用器。TCA9548A 的 A0、A1、A2 均接地，地址固定为 0x70；当前使用通道 0 到通道 3，对应四个轮位传感器。软件上通道选择不再传入通道掩码，而是传入通道号 0 到 3，由底层写入 1 << channel 到 TCA9548A。这样可以避免把 0x01/0x02/0x04/0x08 误认为通道编号，也方便后续按传感器序号维护通道映射。每次访问 MLX90640 前先选择对应 TCA 通道，再按官方 MLX90640 API 完成 EEPROM 参数读取、帧数据读取和温度计算。调试初期曾出现 TCA9548A 全地址扫描均无响应、I2C 总线忙、初始化失败等现象。实际排查中发现，问题不一定来自地址设置本身，而可能来自下游模块供电、上拉网络和总线状态。四个 MLX90640 同时供电时，普通电脑 USB 口供电余量不足，容易造成下游器件状态异常；断电重上电后通信恢复，说明电源裕量和上电时序对该系统影响明显。最终硬件侧应保证 5V 供电能力足够，3.3V 上拉电平稳定，且 TCA9548A 上下游 SDA/SCL 没有被任一模块长期拉低。软件恢复机制采用保守策略：上电后执行一次 I2C 总线恢复，之后仅在连续多次出现忙或超时后再恢复总线，避免正常运行中因为偶发 busy 判断而频繁复位总线。恢复动作包括临时释放 I2C 外设、用 GPIO 开漏方式给 SCL 输出若干脉冲、产生 STOP 条件，再重新初始化 I2C。这个策略可以处理上电阶段的总线卡死，同时减少运行时对正常采样的打断。多路版本稳定运行后，主要瓶颈转移到 I2C 总线负载。四个 MLX90640 需要轮询读取 EEPROM、状态寄存器、像素 RAM 和辅助数据，若 I2C 仍使用 100kHz standard mode，总线占用会很高，表现为输出卡顿、帧间隔变长，甚至触发恢复逻辑。将 I2C 调整为 fast mode 后，通信明显顺滑，说明卡顿主要来自总线吞吐压力，而不是单个传感器失效。在 fast mode 基础上，进一步引入 I2C1_RX DMA。CubeMX/CubeIDE 中 I2C1 RX 使用 DMA1_Channel7，normal mode、peripheral-to-memory、memory increment enable，并开启 DMA1_Channel7_IRQn。代码中 MLX90640_I2CRead() 保持对上层同步返回，但底层每个读取分块使用 HAL_I2C_Mem_Read_DMA() 启动传输，再通过 HAL_I2C_MemRxCpltCallback() 和 HAL_I2C_ErrorCallback() 等待完成或错误。这样不改变官方 MLX90640 API 的调用方式，也不改变温度帧计算逻辑，只降低大块 I2C 读操作对 CPU 的占用。采样频率调试中验证了一个重要结论：不要直接修改官方 MLX90640_API.c，应优先通过官方提供的 MLX90640_SetRefreshRate() 接口设置刷新率。按照当前参考文档，MLX90640_SetRefreshRate(0) 对应约 1Hz 测量速率，参数 0 到 7 分别对应 0.5、1、2、4、8、16、32、64Hz。实际工程中将刷新率宏定义为 MLX90640_REF_1HZ，并调用 MLX90640_SetRefreshRate(MLX90640_ADDR, MLX90640_REF_1HZ)。若后续发现不同 API 版本的参数映射存在差异，应优先以手头官方例程和实测输出节奏为准，不在库文件中直接修补位操作。当前可工作的组合为：TCA9548A 地址 0x70，四路 MLX90640 地址均为 0x33，I2C fast mode，I2C1_RX DMA 负责大块读数据，USART1_TX DMA 负责按行输出温度矩阵。该组合已经验证比纯轮询 I2C 更顺滑，且不会改变上层 MLX90640 官方 API 的使用边界。2+2 结构：两路标准CAN+两路CANFD解析实现——MCP2518FD当前代码采用的是典型的“2+2”结构：两路由 STM32F407 原生 bxCAN 外设承担，两路由外接的 MCP2518FD 经 SPI 承担。这里的“CANFD”更准确地说是“具备 CAN FD 控制器能力的外设接口”，但在当前固件实现中，业务层统一按标准帧处理，FD 报文能力只在抽象层和底层驱动中预留，没有进入上层业务解码流程。当前四路总线在代码中的职责划分如下：CAN1：整车 CANB，对应整车状态、轮边电机状态、IMU、IVT/FS 能量计等报文。CAN2：电池箱 CAN，对应电池包扩展帧、单体电压、温度、状态量等报文。SPI1 + MCP2518FD：控制器 CANA，当前由 Task06 负责轮询与解码，服务电机控制器相关报文。SPI3 + MCP2518FD：当前规划为 CDC（半主动电磁阻尼悬架）监视总线，建议保持只监听、不主动发控制报文。代码层面的分层非常明确，建议后续也保持这种边界：can.c：仅负责 STM32 原生 CAN1/CAN2 的初始化、滤波器、发送和中断收包。mcp2518fd.c/.h：仅负责 MCP2518FD 芯片级寄存器、RAM、FIFO、SPI 读写，不承载业务语义。fdcan.c/.h：历史命名保留为 fdcan，但在 F407 上它本质只是“SPI-CAN 抽象层”，负责把 mcp2518fd 的原始帧包装成统一的 FDCAN_StdFrame_t。can_decode.c/.h：真正的报文业务解码层，所有邮箱 ID、字节拼接、物理量换算、轮位映射、IVT/FS 判源等都应集中在这里。telemetry_data.c/.h：统一数据缓存层，所有任务最终都往这里写，publish 只从这里读。这种设计的最大价值是：底层通信方式和上层业务解码解耦。后续如果更换 CAN 控制器、修改 SPI 引脚、增加一条新的 MCP2518FD 链路，理想情况下只应改 mcp2518fd/fdcan/freertos 的接线和轮询部分，不应改动 publish、protobuf 和业务变量。在当前实现中，原生 CAN 和 MCP2518 的接入方式并不相同：原生 CAN 走中断。HAL_CAN_RxFifo0MsgPendingCallback() 与 HAL_CAN2_RxFifo0MsgPendingCallback() 在中断里只做“收帧 + 入队”，避免在中断上下文里做复杂解码。MCP2518 走轮询。Task06 周期性调用 FDCAN_Poll()，读取 SPI1/CANA 的 FIFO 帧后直接完成控制器报文解码；Task07 作为 SPI3/CDC 的独立监听任务，负责只读监视，并将最近一帧写入 g_CDCInfo，不并入电池箱链路。这意味着原生 CAN、SPI1/CANA 和 SPI3/CDC 在进入业务解码层之前，都应当先被归一化成统一的帧结构，再由各自任务决定是否直接解码或入队：CAN_Msg_Queue_t ├─ can_channel ├─ msg_id ├─ msg_data[8] ├─ dlc └─ is_ext_id因此，后续新增标准 CAN 报文时，优先考虑的不是“它来自 bxCAN 还是 MCP2518FD”，而是“它属于哪个业务网络，由哪个任务或 can_channel 进入哪个解码函数”。当前 CANA 已经明确归属于 Task06，不再并入 Task02。MCP2518FD 当前初始化流程位于 mcp2518fd.c，其关键步骤包括：SPI 片选拉高并复位芯片；切入 configuration mode；等待晶振 ready；初始化 ECC 和 RAM；配置 nominal bit timing；建立 RX FIFO / TX FIFO；配置 filter 0 全通到 RX FIFO；切回 normal mode。当前配置策略是“保守优先”：FIFO 大小固定、经典 CAN 优先、滤波器先全部放开，保证移植和联调阶段先能稳定收包，再逐步缩窄过滤条件。对于车队日常维护来说，这种策略虽然不够极致，但更利于快速定位问题。需要特别说明的是：fdcan.h 文件头已经写明，这个模块名只是历史保留名，不代表当前 MCU 真有原生 FDCAN 外设。后续任何人维护本工程时，都应把 fdcan.c 理解为“外置 MCP2518FD 的统一抽象层”，而不是 STM32G4/H7 系列那种硬件 FDCAN 驱动。在业务解码层，当前 can_decode.c 已经形成三条明确入口：CAN_DecodeVehicleCanbMessage()：整车 CANBCAN_DecodeBatteryBoxMessage()：电池箱 CANCAN_DecodeControllerCanaMessage()：控制器 CANA后续若继续完善 CDC CAN 这一路，推荐仍然遵守同样模式：先在 can.h 增加物理含义明确的邮箱宏，再在 can_decode.c 完善专属解码入口，不要把新的业务解码混写回 can.c 或 fdcan.c。悬架传感器——基于RS485总线实现的数据读取RS485 相关代码目前属于“硬件链路打通、软件框架预留”的状态。也就是说，任务、串口、使能脚、数据入口都已经安排好了，但具体传感器协议解析还没有像 CAN 那样完全落到业务层。当前 RS485 侧的代码结构如下：USART2：作为 RS485 串口口径。EN 引脚：用于 485 芯片方向/使能控制，该引脚在 Task05 启动时被初始化到默认状态。Task05_ParseRs485Message()：预留的协议解析入口。Peripheral_Rx_Frame_t：通用外设接收帧封装，用于承接字节流或未来的完整帧。当前 StartTask05() 的实现是最小可运行版：循环从 USART2 逐字节读取数据，然后把每个字节封装进 Peripheral_Rx_Frame_t 送到 Task05_ParseRs485Message()。这个设计的优点是入口已经稳定，后续只需要替换解析逻辑，不需要再改任务调度结构。但也正因为当前实现是逐字节喂入，所以后续如果正式接入悬架拉力/位移类传感器，建议在 Task05_ParseRs485Message() 内部增加完整的状态机，而不要在任务外层直接拼帧。推荐结构如下：byte stream -> frame state machine -> address check / length check / crc check -> physical conversion -> write telemetry_data -> optional publish / debug建议的状态机字段至少包括：当前解析状态（等待帧头 / 收集中 / 校验中）当前缓冲长度目标传感器地址预期数据长度超时计数如果后续 4 个 RS485 传感器共线工作，务必把“查询”和“解析”分开设计：查询调度由一个上层轮询器完成，决定当前向哪个地址发请求；Task05_ParseRs485Message() 只负责解析返回帧，不负责决定轮询顺序。这样做有两个好处：轮询周期、超时策略、重发策略可以独立调整；单体协议解析函数可以单独复用到离线测试工具中。当前代码里还没有出现完整的 RS485 数据落地结构，因此后续建议沿用现有架构，新建一个明确的悬架数据缓存结构放入 telemetry_data.h，例如：Suspension_InfoDef ├─ sensor_valid_mask ├─ load_raw[4] ├─ load_converted[4] ├─ last_error[4] └─ frame_counter[4]然后遵循与 CAN 完全一致的模式：Task05 负责收字节流；Task05_ParseRs485Message() 负责协议解码；解码结果写入 telemetry_data；publish.c 决定是否对外发布。不要让 Task05 直接去拼 protobuf，也不要让 publish.c 去碰协议字节。协议层和对外发布层一旦混在一起，后续更换传感器型号时维护成本会非常高。4G传输——基于protobuf的MQTT订阅当前 MCU 侧的 4G 发送链路，应当理解为“protobuf 序列化 + UART1 发送”，而不是“MCU 内部完整 MQTT 协议栈”。这点对后续维护非常重要。也就是说，MCU 当前承担的职责只有三层：从 telemetry_data 中取出已经解码好的业务数据；通过 nanopb（pb_encode.c/pb_common.c 及生成的 fsae_telemetry.pb.c/.h）序列化为 protobuf；用项目自定义帧头包一层，再经 USART1 送给 4G 模块。publish.c 是这一层的绝对核心，建议把它视为“MCU 对外遥测协议网关”。当前它承担四类工作：调度发布周期：fast / medium / slow将内部缓存映射到 protobuf 结构体调用 pb_encode() 完成编码通过 HAL_UART_Transmit() 发送自定义帧当前定义的 Topic 如下：fast_telemetrybms_summaryvehicle_statebms_detailthermal_summary其中 Publish_Process() 只负责“何时把某个 topic 入队”，真正的编码和串口发送由 Publish_TxTaskStep() 负责执行。这样做的好处是把“调度”和“发送”拆开，避免主调度逻辑因为一次编码或串口忙而失控。当前完整链路如下：decode result in telemetry_data -> Publish_Process() decides topics -> myQueue04 stores PublishQueueItem_t -> Publish_TxTaskStep() dequeues one topic -> Publish_Map...() fills protobuf structs -> pb_encode() -> Publish_SendFrame() -> USART1 -> 4G module这里还需要强调一个你已经明确修改过的设计点：当前 publish 路径不再依赖额外的 485 使能脚控制，发送就是直接走 USART1。因此以后更换 4G 模块时，只要模块仍然接受 UART 数据，就优先保持 publish.c 不动，把 AT 配置、联网、MQTT 上线等控制逻辑留在模块初始化或外部网关侧。当前 MCU 自定义发送帧格式为：MAGIC0 MAGIC1 topic_len payload_len_l payload_len_h topic_name payload也就是说，4G 模块或上位机侧如果要继续兼容当前固件，不能只会解 protobuf，还必须先识别这层自定义外包头。在 protobuf 映射策略上，当前工程遵循“业务缓存优先、发布视图后映射”的思路。例如：CAN 解码先写入 g_CANB_LoopData电池箱解码先写入 g_BatteryInfo热成像先写入 g_MLX90640_Framepublish.c 最后再把它们组装成 TelemetryFrame / VehicleState / ThermalSummary这种架构的最大好处是：协议变化与业务逻辑分离。以后如果 MQTT topic 命名改了、protobuf 字段改了、上位机要求某些字段删掉或换单位，只需要主要改 publish.c 和生成后的 protobuf 文件，不需要把底层传感器采集链路全部重写。当前 fsae_telemetry.pb.h/.c 是生成文件，不建议手改。推荐维护方式是：修改 .proto 源文件；重新生成 .pb.h/.pb.c；再修正 publish.c 中的字段映射。后续若新增一个全新的 4G 发布内容，优先顺序建议如下：先判断是否属于现有 topic；若现有 topic 能承载，就只在 protobuf 结构中补字段；只有当数据节奏、订阅对象、体量差异都明显不同时，才新增 topic。不要轻易为每一种新传感器都开一个独立 topic，否则后续云端订阅关系、带宽占用、版本兼容都会迅速失控。基于FreeRTOS多线程数据采集架构当前固件的 FreeRTOS 结构已经从“单点轮询式工程”演进成了“多任务 + 队列 + 统一缓存”的采集框架。这部分是整套系统后续继续扩展的基础。当前任务划分如下：defaultTask：系统主调度任务，执行 Publish_Process()、Publish_TxTaskStep()、调试串口输出和状态灯翻转。Task02：处理 myQueue02，仅负责整车 CANB 解码入口。Task03：处理 myQueue03，负责电池箱 CAN 解码入口。Task04：热成像采集与摘要生成任务。Task05：RS485 入口任务。Task06：SPI1 + MCP2518FD 轮询与 CANA 解码任务。Task07：SPI3 + MCP2518FD 轮询与 CDC 监视任务。Task08：USART1 发送任务。Task09：CAN1 发送任务。对应的队列设计如下：myQueue01：USART1 发送队列myQueue02：CAN1 收到的整车 CANB 业务帧队列myQueue03：当前主要承接 CAN2 的电池箱业务帧队列myQueue04：publish topic 队列myQueue05：CAN1 发送队列task01DebugQueue：调试日志队列这套设计的核心思想是：采集、解码、缓存、发布四层分离。ISR / poll -> queue -> parser / decoder task -> telemetry_data cache -> publish scheduler -> encode / transmit这种结构相比“哪里收到数据就在哪里直接处理并发送”的老办法，有几个非常现实的优势：中断时间短，不容易因为大量运算拖垮总线接收；各传感器和总线的节奏彼此解耦；上层发布策略可独立演进；任何一路新功能都能找到明确的接入位置。当前任务之间最重要的约定是：只有解码层写缓存，只有发布层读缓存对外发包。例如：Task02/Task03/Task06 当前已经稳定写入 g_CANB_LoopData / g_BatteryInfoTask07 当前作为 CDC 监视入口存在，已经写入独立的 g_CDCInfo 通用缓存；后续若明确 CDC 报文语义，再在该缓存基础上补充协议专属字段，而不是复用电池箱或整车缓存Task04 最终写 g_MLX90640_Framepublish.c 只读取这些全局缓存，不反向影响采集过程当前没有为这些全局缓存额外加锁，原因是本工程默认采用“单写多读、最新值覆盖”的实时遥测思路，而不是“每一帧都要绝对一致快照”的事务性思路。对于遥测系统来说，这样的取舍通常是合理的，但后续如果引入大块复合结构并要求一致性极高，可以再考虑快照拷贝或临界区保护。调试链路也值得单独记录。当前系统区分了两种“发”：调试输出：走 task01DebugQueue -> huart3业务发布：走 myQueue04 / myQueue01 -> huart1这样可以避免调试信息污染正式对外数据口，也避免发布链路阻塞时把调试一起拖死。热成像任务 Task04 是现阶段多任务设计最完整的一个示例。它做了这些事：顺序轮询 4 个传感器；对每个就绪传感器执行完整采样；输出调试矩阵和摘要；生成 CANB 摘要报文；所有传感器一轮采集后，统一触发一次 thermal_summary publish。这说明当前工程已经不再是“采一帧就立刻到处发”，而是开始出现“任务内部聚合后再发布”的设计风格。这种风格非常适合以后继续做复杂传感器融合。对未来维护者来说，判断一个新功能该放在哪个任务里，可以按下面这个简单原则：如果它是“原生 CAN 中断收包”，放到 Task02/Task03 的既有链路里；如果它是“SPI 外接控制器轮询收包并且业务上独立于原生 CAN”，优先放到 Task06/Task07；如果它是“I2C 主动轮询采集”，优先仿照 Task04；如果它是“串口字节流协议”，优先仿照 Task05；如果它只是“已有缓存的另一种对外表达”，只改 publish.c，不要新开采集任务。功能新增与代码维护提要功能新增——增加任务独立运行，增加队列实现信息传输当前工程的新增功能方式，推荐尽量遵守“任务独立、数据入队、缓存归一、发布分离”的思路，而不要回退到“一个函数里全部做完”的写法。只要继续坚持这一原则，后续无论是再加一条 CAN、再加一类传感器，还是更换 4G 模块，都不会把整个工程拖进不可维护状态。推荐的新增流程如下：先明确数据来源属于哪一类外设：CAN、SPI-CAN、I2C、RS485、UART 直连等；再决定它应该进入哪个任务，或者是否需要新建一个任务；为该功能设计专属数据缓存结构，放入 telemetry_data.h；在采集/解码层写入缓存，不直接发布；在 publish.c 中决定是否对外发布、如何发布。对于“是否要新建任务”，建议不要机械地追求一个模块一个任务，而是看它是否具备独立节奏和独立阻塞特征。以下情况通常值得新建任务：需要主动轮询；访问周期明显不同于已有任务；采集耗时较长；容易因为超时或重试阻塞别的链路。以下情况则优先复用现有任务：只是同一条 CAN 总线上的新增邮箱；只是同一 topic 中新增几个字段；只是已有缓存结构的补充量。当前队列设计已经给了一个比较健康的参考：任何“外设入口”和“业务出口”之间都至少隔着一层队列。这样做的意义不只是代码好看，而是能降低阻塞传染。比如某一路解析突然变慢，最先积压的是它自己的队列，而不是整个系统所有采集入口一起卡住。需要提醒的是，队列化设计也带来两个维护要求：队列元素必须足够小、足够稳定，不要把超大结构反复拷贝进队列；队列深度要按最坏突发情况估算，而不是按“平时差不多够用”估算。当前工程已经做得比较好的一点是：CAN 队列里传的只是 CAN_Msg_Queue_t，publish 队列里传的只是 PublishQueueItem_t，真正的大对象仍然放在全局缓存区。这种做法建议保留，不要把完整 protobuf 结构体之类的大块对象直接塞进 FreeRTOS 队列。如果以后需要新增一个周期性后台任务，推荐模板如下：StartTaskXX() { init once for (;;) { read or poll parse update telemetry_data optionally queue publish topic osDelay(period) } }其中最重要的一条经验是：先让任务稳定采集，再决定怎么发。很多功能设计阶段最容易犯的错误，是一边写采集一边塞发布，结果最后既难调试，也难验证链路边界。新增传感器建议基于RS485总线进行新增如果未来继续新增基于 RS485 的传感器，建议优先复用当前的串口和任务框架，而不是重新新建第二套串口协议工程。比较推荐的落地步骤如下：明确新传感器协议格式：地址、功能码、数据区、校验方式；判断它能否和现有 4 个传感器共总线；在 Task05_ParseRs485Message() 内增加独立解析分支；在 telemetry_data.h 中新增对应缓存结构；根据需求再决定是否进入 publish.c。对于 RS485 新传感器，最容易出问题的地方不是代码，而是总线组织方式。接入前应先确认：波特率是否一致；地址是否唯一；校验方式是否一致；供电和地参考是否稳定；终端电阻是否只有总线两端存在。代码上建议始终坚持“一种协议一个解析器”的原则。即便都走 RS485，也不要把不同型号传感器的字节解析硬塞进同一个 if-else 巨兽里。可以采用：RS485 dispatcher -> protocol A parser -> protocol B parser -> protocol C parser如果未来确实会混挂多种 RS485 设备，建议在 telemetry_data.h 中把悬架类、拉力类、位移类等缓存结构分开，不要用一个大而混杂的结构把所有 RS485 设备揉在一起。通信方式相同，不代表业务含义相同。另外，若后续需要通过 RS485 主动发送配置命令或标定指令，也建议新增“RS485 发送函数 + 请求调度器”，而不要让解析函数反向直接控制发送。这样职责边界更清晰，也更容易做超时重发。基于I2C总线进行新增I2C 新增设备时，首先要判断它属于哪一类：与 MLX90640 一样，需要通过 TCA9548A 走多路复用；直接挂在主 I2C 总线上；地址固定且可能与现有器件冲突；需要 DMA 大块读取，还是只需小寄存器轮询。如果是“单地址、低频、小数据量”的器件，优先不要复制 MLX90640 那一整套复杂框架。可以采用更轻量的设计：TaskXX poll -> HAL_I2C_Mem_Read / Write -> decode register values -> write telemetry_data如果是“同地址多器件并联”，那就应优先复用 TCA9548A_SelectChannel() 这一套通道选择逻辑，而不是重新写一套新的 I2C 复用方案。此时建议新增一层设备驱动文件，例如：new_sensor_i2c.c/.hnew_sensor_app.c/.h其中：*_i2c.c 只做寄存器访问；*_app.c 只做初始化、采样、物理量处理；任务层只负责调度。这样做的好处是，底层驱动将来可以单独移植到别的 MCU 或离线测试工程，而不会和 FreeRTOS 调度耦合在一起。对于新增 I2C 设备，最容易忽视的维护点是“是否真的需要 DMA”。当前 MLX90640 使用 DMA，是因为它读 EEPROM 和 Frame RAM 的数据块大、访问频繁、总线负担重。普通小型 I2C 传感器如果也强行上 DMA，复杂度会上去，但收益可能很小。建议只有在以下场景再考虑 DMA：数据块明显大于普通寄存器读写；采样频率较高；CPU 已明显被 I2C 轮询占用。如果以后新增的 I2C 传感器也需要在 publish 中上报，同样建议坚持当前模式：先写 telemetry_data，再由 publish.c 做统一 topic 映射，而不是让传感器驱动直接接触 protobuf。DBC文件的覆写与4G相关文件的更新覆写这部分是后续最容易“改完能跑，但别人完全不知道改了什么”的区域，因此建议形成固定维护顺序。如果发生 CAN 协议变更，通常至少会牵涉四层内容：协议来源文件：DBC、赛会协议文档、手写 md 说明；MCU 侧邮箱定义：can.h；MCU 侧解码逻辑：can_decode.c；对外发布映射：publish.c 与 protobuf 文件。比较推荐的改动顺序是：先更新协议文档 / DBC -> 再更新 can.h 中的 ID 宏和名字 -> 再更新 can_decode.c 中的字节解析 -> 再更新 telemetry_data 里的缓存字段 -> 最后更新 publish.c / protobuf不要反过来先改 publish.c，否则经常会出现“想发一个字段，但底层还没真正解出来”的情况。邮箱命名方面，当前工程已经从参考工程里那种 APP_DEBUG2、APP_DEBUG5 一类偏历史残留的名字，逐步改成了更有物理意义的命名方式，例如“四轮实际扭矩”“电机温度”“热成像摘要 FL/FR/RL/RR”。后续继续修改 DBC 时，建议坚持这一原则：邮箱宏名优先反映物理意义，而不是历史调试名字。对于 4G 相关文件，当前工程分成两类：协议定义文件：fsae_telemetry.pb.h/.c 及其源 .protoMCU 发送逻辑文件：publish.c/.h如果新增字段但不新增 topic，通常要做的是：修改 .proto重新生成 .pb.h/.pb.c在 publish.c 中填新字段与上位机或云端订阅端同步更新解析逻辑如果新增 topic，则除了上面几步外，还要额外更新：PublishTopic_tPublish_Process() 的调度策略Publish_GetTopicName()Publish_EncodeTopicPayload()并同步确认云端是否需要新增订阅或转发规则。建议以后每次改动 DBC 或 protobuf 时，都在本文档或配套变更记录中至少补三条信息：修改日期修改人影响范围（MCU / 4G / 上位机 / 云端）这样做看起来繁琐，但会极大减轻后续联调时“到底是谁先改了协议”的扯皮成本。另外，如果今后你准备把“协议变更通知”做成真正的自动化流程，技术上最适合挂钩的位置其实不是 MCU，而是版本管理和文档仓库。也就是说，真正该自动推送的，不是固件运行时发现协议变了，而是 DBC / .proto / 对接文档被提交修改时，就由仓库侧自动通知相关成员。对未来的希望在更新对接文件的时候能不能说一声，我什么都不知道，就发现通信协议天翻地覆了，我需要一个能自动推送的功能，不然真的会一直蒙在鼓里
截止目前，嘉立创 PCB 免费券每月刷新一次，每次至少可以领取两张。方法 1： 手机小程序微信搜索嘉立创小程序，进入。点击底部菜单的我的点击优惠券点击底部领PCB免费打样券。如果一直卡死，可以试下另外一个入口（在后文）。下滑，点击领取领取后出现如下图界面代表领到了一般的 PCB（仅PCB ）优惠券。还有另外一种比较稀有的券，PCB+SMT 优惠券（仅优惠 smt）。下图为传说中的稀有券，抽到的几率很小，能省去不少钱（ smt 加工费）。附：另外一个入口：进入小程序首页，点击左上角 PCB：点击免费打样券：方法 2：网页端进入嘉立创客户中心优惠券界面，点击注册，使用微信注册，登录后点击 优惠券中心 下的 PCB 免费券。下滑看到 PCB+SMT 喷锡免费券·领券专区 区域，点击领取，点击确认领取，然后微信扫码确认。之后会跳出下图，代表领到了一般的 PCB（仅PCB ）优惠券。还有另外一种比较稀有的券，PCB+SMT 优惠券（仅优惠 smt）。
电池箱规则 - 模组与机械结构部分一、核心定义EV 5.1 定义EV 5.1.3 驱动系统电池箱 (TS Accumulator)：所有用于储存整个驱动系统所需电能的单体电池。EV 5.1.4 驱动系统电池箱箱体 (TS Accumulator Container, TSAC)：装有驱动系统电池的箱体本身。EV 5.1.5 驱动系统电池模组 (TS Accumulator Segments)：驱动系统电池的子模块。电池模组是电池的子模块，将电池分为子模块是为了减小操作的危险性。二、电池技术路线禁止性条款（EV 5.2）EV 5.2.1 禁止使用熔盐电池和热电池。EV 5.2.2 禁止使用燃料电池。三、模组基础参数要求（EV 5.3.2）每个电池模组必须：最大电压不超过 120 VDC最大能量不超过 6 MJ（1.67 kWh），能量计算方法见 EV 5.1.2（单体能量：单体最大电压乘以标称容量）最大重量不超过 12 kg四、材料标准（T 1.3）T 1.3.1 阻燃材料——符合下面标准之一的材料a) UL94-V0; b) FAR 25; c) 泡沫材料仅限使用：UL94HF-1 和 UL94VTM-0; d) 厚度 0.5-0.7 mm 的铝板。[备注] 材料厚度应满足标准要求的最低厚度，提供证明材料后可使用等价标准的材料。T 1.3.2 绝缘材料——符合下面标准之一的材料a) UL;[备注] 提供证明材料后可使用等价标准的材料。五、电池箱总体结构要求电芯封装要求（EV 5.3.1） 所有储存驱动系统能量的电芯或超级电容都要做成电池模组，并置于电池箱中。安装位置要求（EV 5.5.1） 所有电池箱都必须在车架基本结构之内，或满足 T4.4.1 表格要求的附加结构之内，且不可高于侧防撞结构顶面。见 T4.27 或 T4.38。防撞保护要求（EV 5.5.2） 电池箱必须受到保护以防止受到侧面或背部的冲击，实现保护功能所采取的结构要符合 T4.4。电池箱不能是该防撞结构的一部分。结构材料要求（EV 5.5.3） 制作电池箱体的材料以及所有结构部件必须满足 T1.3。除金属材料和连续纤维增强层压材料外，所有计算均必须在环境温度为 60°C 的条件下进行。箱体厚度要求（EV 5.5.5） 电池箱必须按照下述结构用钢片（板）或者铝片（板）造型：电池箱底部必须采用至少 1.25 mm 厚的钢或者 3.2 mm 厚的铝；电池箱外围垂直侧面（前、后、左、右）、内部隔板及电池箱盖必须采用至少 0.9 mm 厚的钢或者 2.3 mm 的铝。允许使用其他材料，但必须根据规则 T4.5 开具材料等同性证明（复合材料参照 EV5.5.6）。等同性证明材料必须在 SES 中加以证明。当使用了替代材料时，其测试样品必须在比赛的电气检查中加以展示。复合材料电池箱要求（EV 5.5.6 / T 4.8.3）从层压板圆周剪切强度测试以及三点弯曲测试中获得的数据必须被用来证明电池箱可以提供足够的强度；每一个附着点需要用至少 2 mm 厚的钢制支撑板。可以使用（符合最小材料等效要求的）等价替代材料；SES 中必须有相关的计算检验及物理实验的测试结果；复合结构抗弯刚度（EI）必须使用 SES 中的工具和公式计算；侧防撞结构、前隔板和 TSAC 不允许使用实际几何计算。只有当平板的等效抗弯刚度超过最低要求（T 4.4.1）的 60% 时，才可考虑平板的实际几何形状和曲率。箱体连接要求（EV 5.5.7） 电池箱底板与侧板的连接方式必须为焊接、粘接和使用紧固件（一种或多种）。开孔限制要求（EV 5.5.16） 电池箱内部以及外部只允许有为线束进出、通风设备、冷却或紧固件而打的孔，且开孔面积不能超过表面积的 25%。电池箱体必须始终满足尤其是结构要求在内的所有规则。电池箱外部的孔必须按照 EV4.5 要求的方法进行密封。用于冷却和连接的冷却管道的开口不得对着车手和手推车操作员，即使二者之间有防火墙。通风系统要求（EV 5.5.18） 任何可能排放爆炸性气体的电池箱必须具有通风系统，以防止排出的气体达到爆炸性浓度。六、模组安装与内部结构规则模组分隔要求（EV 5.5.8 / EV 5.5.9 / EV 5.4.6）电池箱内必须使用垂直隔板分隔电池模组，隔板高度不得低于电池箱高度的75%。每个电池模组之间必须使用 合适的刚性阻燃材料（见 T 1.3） 实现绝缘，防止内部短路或工具掉落产生电弧。电池箱中每一个电池组之间必须使用 绝缘阻燃材料（见 T 1.3） 进行隔离。密封与泄压要求（EV 5.5.19） 任何完全密封的电池模组都必须设计压力释放阀门，防止电池箱内产生高气压。维护插头要求（EV 5.4.4） 电池箱内所有模组正负极需可通过维护插头分离，维护插头需满足：拆装无需工具表面绝缘，防额外电气连接主动锁紧，防意外松动仅可通过设计结构连接可清晰分辨通断，禁止电子控制开关。七、力学与固定规则整体力学要求（EV 5.5.10） 电池箱、电池箱固定及单体固定需满足：纵向（前后）承受 40g侧向（左右）承受 40g垂直方向（上下）承受 20g计算/测试需记录在 SES 中。软包电池固定（EV 5.5.11 / EV 5.5.12） 软包电池单体的纵向、侧向和垂直方向都必须被牢固固定；极耳不得承受机械载荷，也不得压入电池本体。每个电池单体的剪切应力不得超过 0.05 MPa，压缩应力不得超过 1.0 MPa。若未进行应力分析，则最多只能将8 个软包电池直接堆叠（没有刚性固定隔板分隔）。紧固件要求（EV 5.5.13） 电池箱内及安装用紧固件需满足 T 11；内部非结构件用电气非导电材料紧固件可豁免。安装固定支架要求（EV 5.5.15） 电池箱与车体基本结构之间的固定支架必须使用至少 1.6 mm 厚的钢或 4 mm 厚的铝。支架上必须有角板以承受弯曲载荷。每个连接处（包括支撑板、固定板及内部嵌入物）在任何方向都必须能够承受 20 kN 的力。替代车架电池箱受力规则（M4.8）M4.8.1 在分析时，电池箱结构的受力施加在模块或单体电池重心的位置。其受力大小为（该模块/单体的质量）乘以（规则要求的）加速度。M4.8.2 对于将电池与驾驶员通过等效于侧边防撞结构隔开的电池箱分析，采用以下的加速度工况： a) 车辆纵向方向 20 g（前后都需要）； b) 车辆侧向方向 20 g（左右都需要）； c) 车辆垂直方向 20 g（上下都需要）。M4.8.3 对于通过侧边防撞结构将驾驶员与电池箱分离的车架/单体壳结构，必须使用一个直径与电池箱的宽度或高度二者的最小值相等的碰撞检测圆来检测。M4.8.4 边界条件：约束位移 (x,y,z)，但对于主环与前环两侧底部节点的旋转不加以约束。八、相关文档与检查要求SES 文档要求（EV 5.5.4 / T 4.9.2 / T 4.9.10）电池箱设计、计算、测试需记录在 SES 中，包含使用的材料、图纸、照片、紧固件位置、模组重量、电芯与模组位置等信息。所有车队须提交一份结构等同性表格（SES），对于电车，必须包括 TSAC 和它们的连接点。如果在车架基本结构和牵引系统蓄电池壳中使用了复合材料，SES 必须包括：材料种类、织物的重量、树脂种类、纤维方向、层数、核心材料、铺层方式、胶膜类型、三点弯曲和剪切实验数据。检查要求（EV 5.3.5）技术检查时电池箱需可开盖，可从赛车拆卸，拆卸后仍满足规则要求。当使用了替代材料时，其测试样品必须在比赛的电气检查中加以展示。九、运输与存放要求移动电池单体/模组，仅可装入不完全封闭的电池箱内移动。备用电芯需存放在阻燃绝缘容器中，牢固固定并按 EV 5.3.7 (车号、大学名称和电气安全员（ESO）电话号码必须在每个电池箱盖上以至少 25 mm 高的无衬线字体显示和书写。字符必须清晰可见，并置于高对比度背景下。) 标记；备用电池箱/模组需装在标记容器中，技术检查时出示。(EV 5.3.3)
电池箱规则 - 电气与操作管理部分一、电气配置规则箱体绝缘要求（EV 5.4.1） 电池箱体为导电材料时，电池单体及模组正负极需用符合最大驱动系统电压的绝缘材料与箱壁隔离。内部电气部件配置（EV 5.4.3） 除了不可或缺的器件外，电池箱中不得包含低压系统。例外包括：电池箱隔离继电器 (AIRs)驱动系统 DC/DC 转换器电池管理系统 (AMS)绝缘检测装置 (IMD)TSAL 绿灯相关电路冷却风扇熔断器与继电器要求（EV 5.4.2） 每个电池箱中都至少有一个熔断器（见 EV3.2.7）和两个电池隔离继电器 (AIRs，见 EV5.6)。电气部件隔离要求（EV 5.5.14） 电池箱隔离继电器 (AIRs) 和主熔断器（见 EV3.2.7）必须用绝缘阻燃材料（见 T 1.3）与电池箱的其他部分隔离。在这种情况下，空气不被认为是合适的绝缘材料。电池箱内电缆要求（EV 5.4.7） 电池箱内所用的电缆，不论是低压系统还是驱动系统的一部分，都必须满足：EV 4.5.2 额定电压大于等于最大驱动系统电压EV 4.5.3 额定温度不低于 85 °CEV 4.5.5 尺寸满足持续电流需求 用于符合 EV 5.8.7 目的（AMS 输入电路）的电缆除外。数据记录仪安装规则（EV 4.6）EV 4.6.3 数据记录仪禁止安装在电池箱内。EV 4.6.4 数据记录仪必须安装在最负侧的电池箱隔离继电器（AIRs）和逆变器之间，且所有驱动系统的电流都必须流经它。EV 4.6.5 电压检测线必须被直接连接到最正侧的 AIRs 靠近车辆一侧。只能使用保险丝作为过流保护。EV 4.6.6 数据记录仪必须由低压系统主开关直接供电。二、电池箱隔离继电器 (AIRs) 规则（EV 5.6）EV 5.6.1 每个电池箱中都必须至少有两个电池箱隔离继电器。EV 5.6.2 电池箱隔离继电器必须断开电池两极。如果这些继电器处于断开状态，电池箱外就不应有高压存在。继电器的输入、输出端必须满足电气隔离（见 EV1.2.1）。EV 5.6.3 电池箱隔离继电器必须为 " 常开 " 型，机械式继电器，禁止使用固态式继电器。三、预充回路规则（EV 5.7）EV 5.7.1 需要设计电路保证在闭合第二个电池箱隔离继电器之前，中间回路电容的电压值达到了电池箱电压的 95%。因此中间回路电容的电压必须被测量。EV 5.7.2 预充回路必须使用机械式常开继电器。所有预充电电流都必须经过这个继电器。四、电池管理系统 (AMS) 规则（EV 5.8）EV 5.8.1 当低压系统处于激活状态或者驱动系统电池箱连接到充电机时，每个电池箱都必须被 AMS 监控。EV 5.8.2 每个电池箱都必须包含其完整的 AMS，包括其自身以及驱动电池箱隔离继电器 (AIRs) 和预充继电器（见 EV5.7.2）部分，见 EV6.1。EV 5.8.3 AMS 必须持续监测：每一块电池单体的电压；驱动系统的电流；电池典型点的温度；若所用电池为锂电池，则电池管理系统要监测至少 30 % 的电池温度，并且被监测的电池要在电池箱内均匀分布。EV 5.8.4 电池温度必须在能够代表电池最高温度的位置进行测量。所使用的传感器必须与电池的极耳直接接触，或者沿大电流路径（见 EV 1.2.2）方向距离小于 10 毫米，且远离与相应母线直接接触的端子。车队应通过有效的螺栓压接或导热胶粘接等方法对温度传感器进行固定，并在 ESF（见 EV 9）中说明传感器安装位置和方式的合理性。EV 5.8.5 必须保证电池温度低于电池参数表中规定的温度范围和 60 °C 中较小的一个。EV 5.8.6 如果电压、温度和电流数据超过规则或者说明书限制达到如下时间，电池管理系统必须通过安全回路关闭驱动系统：电压和电流数据超限 500 ms；温度超限 1 s。精确度和传感器噪声必须被考虑到阈值设定中。EV 5.8.7 AMS 电池电压测量和温度测量的输入电路（包含电缆、接插件和过流保护器件等）以及分布式 AMS 从机的电源电压的额定值可以低于最大 TS 电压。EV 5.8.8 当且仅当电池管理系统断开了安全回路时，那么，需要点亮驾驶员座舱中的 AMS 指示灯。AMS 指示灯必须：颜色红色；在强烈阳光照射下清晰可见；明显标有 "AMS" 字样；保持发亮状态直至错误状态被手动重置（见 EV 6.1.6）。控制该指示灯的信号属于系统关键信号，需满足 T 12.10。EV 5.8.9 电池管理系统信号属于系统关键信号，需符合 T 12.10。EV 5.8.3 所述的监测信号丢失将导致安全回路断开。EV 5.8.10 技术检查时必须能够断开 EV 5.8.3 所述的监测信号，并单独触发各部分故障。温度测量和电压测量断开任意一个即可触发报警。EV 5.8.11 电池管理系统必须能够读取并显示所有监测的值（见 EV 5.8.2），可通过连接笔记本电脑或显示屏到 AMS 来观察和检验。五、电压指示器规则（EV 5.4.8 / 5.4.9 / 5.4.10）EV 5.4.8 每个电池箱都必须有一个明显的指示器，可以是电压表或红色 LED 指示灯。如果使用红色指示灯，要求在电池箱隔离继电器输出端电压高于 60 VDC 或驱动系统最大电压值的一半（取较低值）时长亮，且在强光下清晰可见。EV 5.4.9 指示器必须：无论电池箱插接件是否连接始终清晰可见；有清楚的 " 电压指示器 " 或 "Voltage Indicator" 的标识。EV 5.4.10 指示器必须采用硬件电子电路，无需软件控制，直接且仅由车辆侧的驱动系统供电，并且即使驱动系统电池箱与低压系统断开连接或从车辆上移除，该指示器也必须始终工作。六、标识与标签规则电池箱标识（EV 5.3.7） 车号、大学名称和电气安全员 (ESO) 电话号码必须在每个电池箱盖上以至少 25 mm 高的无衬线字体显示和书写。字符必须清晰可见，并置于高对比度背景下。高压警示标识（EV 5.5.17） 每个电池箱都必须贴有：一个边长至少为 100 mm 的三角形标签（符合 ISO7010-W012 标准）。标签样式为黄底、黑色闪电；"Always Energized" 的文字标识；当电压高于 60 VDC 或 50 VAC RMS 的标签还必须有 " 高压 " 或 "High Voltage" 的文字标识。七、电池箱作业安全规则（EV 8.2）打开电池箱，或在电池箱上的作业，必须遵守以下要求：只允许在充电区的给定位置进行必须有电气安全员 (ESO) 在场必须使用恰当的绝缘工具和设备所有参与的车队成员，必须佩戴带侧边防护的安全眼镜和合格的安全手套必须至少有一名不直接参与电池箱作业，但能随时协助处理紧急情况的车队成员在场打开电池箱作业时，电池模组必须用维护插头分开八、充电规则（EV 8.3）在比赛地点，必须有一个单独的充电区域。对驱动系统电池箱的充电只被允许在这个区域进行。充电时，电池必须从车上取下，放置到电池箱手推车，见 EV 8.4。充电期间，电池箱必须贴有一个包含以下信息的标签：车队名称、电气安全员 (ESO) 电话号（见 EV 5.3.7）。EV 8.3.4 在充电区域，不允许进行磨削、钻孔等操作。EV 8.3.5 充电期间，必须至少有一名熟知充电过程的车队成员待在电池旁边。九、电池箱运输与手推车规则（EV 8.4）在赛场运输电池箱必须使用电池箱手推车，手推车必须满足：至少有四个轮子必须有刹车，这个刹车当且仅当有人推动把手或进行类似操作时才能被推动刹车必须能在电池箱手推车满载时起到停车作用松开刹车时可以被轻松推动必须能承载住电池箱的重量必须提供垂直防火墙，以在移动手推车时保护人员。防火墙必须与手推车具有相同的宽度，从手推车的最低点开始，并至少比手推车把手和电池箱高 30 cm运输过程中，电池箱必须机械固定在手推车上电池箱不能比手推车还突出操作手推车的过程中，一定要保护电池箱免受到震动和冲击，例如通过使用充气轮胎手推车防火墙上必须要有 EV5.3.7 所述的标签，且标签离地高度不能超过 1.3m手推车满载的占地面积不能超过 1200 mm×800 mm。如果电池箱大于这个面积，赛前工作人员可以进行额外批准。十、IMD 与接地测量规则IMD 连接规则（EV 6.4.5） IMD 模块整车接地测量线必须有一条接电池箱，另一条回路应连接主环。每一条回路应相互独立，使用不同的导体，均能承受驱动系统最高电压。这些接地测量线中的任何一处出现开路都必须导致安全回路断开。接地测量点要求（EV 4.7.8） 在驱动系统测量点旁边必须安装一个 LVS 接地测量点，且满足：连接到 LVS 地上4 mm 带绝缘覆盖物的香蕉插座颜色黑色标记为 "GND"十一、驱动系统线缆通用规则（EV 4.5）绝缘要求（EV 4.5.1 / 4.5.2）EV 4.5.1 驱动系统的所有部件，尤其是通电导线、触体等都要用绝缘材料或盖子隔离起来防止操作人员和车手误触。当驱动系统覆盖物安装好后，任何驱动系统连接点都将使用直径 6 mm，长 100 mm 的绝缘检测探针进行测试。EV 4.5.2 必须使用额定电压大于等于最大驱动系统电压的绝缘材料，禁止只使用绝缘胶带或者橡胶类涂料进行绝缘。温度、防潮与载流要求（EV 4.5.3 / 4.5.4 / 4.5.5）EV 4.5.3 驱动系统电线、连接器和绝缘材料的额定温度必须适宜预期的环境温度，但最低不能低于 85 °C。EV 4.5.4 驱动系统部件和壳体需要防潮，以应对下雨、雾气和水坑（需通过淋雨测试）。EV 4.5.5 驱动系统中所用的所有电缆、接线端子及其它导体都必须采用合适的尺寸满足驱动系统持续电流需求。必须能够清楚地确定并证明每根驱动系统电缆的线规、额定温度和额定绝缘电压。可以使用方均根（RMS）或平均电流的方式计算驱动系统持续电流和参赛期间预期的最大电流使用的时间来确定导体尺寸。防护与固定要求（EV 4.5.6 / 4.5.7 / 4.5.8 / 4.5.9）EV 4.5.6 所有驱动系统电线必须使用专业标准制造并配有合适尺寸的导体及接线端子，此外还需考虑足够的应力消除及防止振动松脱等。EV 4.5.7 驱动系统电缆要被保护起来以防旋转或运动部件造成的损伤，不能位于可能被刮破损坏的地方。EV 4.5.8 所有处于电气外壳防护外的驱动系统电线必须使用单独的橙色绝缘导线管包裹或使用橙色的屏蔽线。导线管至少两端固定，线缆必须能够承受 200 N 的力并且线缆尾端不卷曲、过度拉紧。EV 4.5.9 所有屏蔽线的屏蔽层必须接地。连接器与互锁要求（EV 4.5.10 / 4.5.13）EV 4.5.10 所有不在壳体内的驱动系统连接器都必须有一个连接到安全回路中的互锁回路。不能仅为了不使用互锁回路而使用外壳。EV 4.5.13 驱动系统外壳外的高压连接器应该被设计成不能以设计意图之外的方式连接。连接与锁紧要求（EV 4.5.11 / 4.5.12 / 4.5.14 / 4.5.15 / 4.5.16）EV 4.5.11 所有的驱动系统连接点都要设计得使电流通过确定的导体，如铜、铝等。不能用螺栓作为重要的导体。EV 4.5.12 所有的驱动系统的电气连接点都不得包含可压缩的材料，如堆叠的塑料，也不允许在驱动系统电气连接点使用上述材料制成的紧固件。允许使用满足 FR-4 标准的玻纤板。EV 4.5.14 所有驱动系统的高压电流路径上的电气连接点（包括螺栓、螺母和其他紧固件）都必须使用能耐高温的主动锁紧机构防止意外松脱，例如使用防松螺母，详见 T 11.2。汽车级产品如逆变器可以豁免使用主动锁紧机构。EV 4.5.15 车队需要能够在车检中展示主动锁紧。对于不可目视的连接，必须提供合适的照片进行证明。EV 4.5.16 高压大电流电路上的锡焊连接必须同时满足：在 PCB 上焊接；连接的设备不是电池单体或线缆；设备有额外的机械结构防止松脱。十二、其他关联规则接地要求（EV 3.1.2） 赛车的导电部件对 LVS 地的电阻必须小于 300 mΩ（测量电流 1 A）并且接地线能够持续承载驱动系统电池箱主熔断器至少 10 % 的额定电流。部件定位要求（EV 4.4）除了规则 EV4.4.3 中允许的范围外，所有驱动系统部件都要在防滚架保护包络面之内，见 T4.3.2。所有离地间隙小于 350 mm 的驱动部件必须根据 T4.27 和 T4.28 或 T4.38 的结构防止侧面碰撞或其他碰撞。充电机要求EV 7.1.2 暴露的导电部件和电池箱箱体必须连接到保护地 (PE)。EV 7.1.6 充电机必须包括一个最小直径为 24 mm 的推入式急停开关。EV 7.1.7 充电时，绝缘检测装置（IMD）必须正常工作且能够断开充电机。EV 7.1.9 充电机必须包含驱动系统电压测量点。高压测量点必须连接至充电机的高压输出口。系统关键信号规则（T 12.10）AMS、AIRs 控制信号均属系统关键信号 (SCS)，任何单点故障（如短路、开路）均须导致系统进入安全状态。电池管理系统信号属于系统关键信号，需符合 T 12.10。安全回路关联规则（EV 6.1）AIRs 线圈受安全回路直接控制，安全回路包括 BMS、IMD、BSPD、惯性开关等，任何一环断开必须切断 AIRs。EV 6.1.5 如果安全回路断开，则驱动系统必须通过断开所有电池箱隔离继电器和预充继电器来断开驱动系统，并且驱动系统电压必须在安全回路断开 5 s 内降至 60 VDC 或 50 VAC RMS 以下。所有动力电池电流必须立刻停止。拆卸要求（EV 5.3.6） 每个电池箱必须可从赛车上拆卸。当电池箱从车上拆下后，仍然符合规则要求而无需安装额外的部件。可以使用空连接器或类似物来恢复系统的隔离，见 EV4.5。
当前这台能量计已执行 python "IVT\\pcan_ivt_tool.py" setup-intel。阅读本文时，结果通道请按“0~7 已配置为 cyclic + little-endian”理解，不再按出厂默认大端理解。当前配置摘要：I/U1/U2/U3/T/W/As/Wh 全部启用，DB1 = 0x42，周期分别为 20/60/60/60/100/30/30/30 ms。1. 型号对应信息IVT-S-500-U3-I-CAN1-12/24 含义如下：500：额定电流量程 500 AU3：带 3 路电压测量通道I：带隔离CAN1：有板载 CAN 终端电阻12/24：典型 12V / 24V 供电结合设备识别响应 DEVICE_ID，该型号在协议上的固定特征应为：Device-type = IVT-SI-nominal = 500 AVoltage channels = 3Feature = I（Isolation）Communication type = CAN1（with termination）Nominal supply = 12/24V2. 物理层 / 总线参数2.1 CAN 类型CAN 2.0A标准帧，11-bit CAN ID2.2 波特率可选：250 kbit/s500 kbit/s（默认）1 Mbit/s3. 默认 CAN ID 与报文总览3.1 默认 CAN ID报文名默认 CAN IDDLC说明IVT_Msg_Command0x4118命令报文，SET/GETIVT_Msg_Debug0x5108内部使用IVT_Msg_Response0x5118对 SET/GET 的响应IVT_Msg_Result_I0x5216电流结果IVT_Msg_Result_U10x5226电压 1 结果IVT_Msg_Result_U20x5236电压 2 结果IVT_Msg_Result_U30x5246电压 3 结果IVT_Msg_Result_T0x5256温度结果IVT_Msg_Result_W0x5266功率结果IVT_Msg_Result_As0x5276电量计数 AsIVT_Msg_Result_Wh0x5286能量计数 Wh3.2 字节序默认值默认：Big Endian可配置为 Little Endian3.3 命令规则未定义字节在命令报文中必须填 0x00响应报文中未用字节通常返回 0x00连续命令发送间隔不得快于 2 ms，或者等待对应响应后再发一般响应最迟应在对应命令后的 500 ms 内出现在总线上；特殊命令另有说明4. 多路复用 MUX 规则所有报文通过 DB0（Muxbyte） 区分类型。 高 4 bit 表示大类，低 4 bit 表示具体子类型或通道。规则如下：DB0 范围含义0x0n结果报文0x1nSet CAN ID0x2nSet config result0x3nSet commands0x4nGet error/log data0x5nGet CAN ID0x6nGet config result0x7nGet commands0x8nResponse on error/log data0x9nResponse on CAN ID0xAnResponse on config result0xBnResponse on set/get commands0xFF非法/不允许命令响应5. 默认输出配置（与这款 U3 型号直接相关）默认测量/输出配置如下：通道 n信号默认模式默认周期最小周期说明0CurrentCyclic20 ms1 ms输出周期=测量周期1U1Cyclic60 ms3 ms与 U1~U3 配置相关2U2Cyclic60 ms3 ms与 U1~U3 配置相关3U3Cyclic60 ms3 ms与 U1~U3 配置相关4TDisable100 ms1 ms固定 100ms5P(WU1)Disable30 ms1 ms功率=I×U16Q(As)Disable30 ms1 ms电流积分7ΔE(WhU1)Disable30 ms1 ms能量=I×U1补充默认参数：OC Threshold(+/-)：OffOC Reset Threshold(+/-)：Off6. 结果报文格式（最重要）所有结果报文（0x521~0x528）数据格式相同，DLC=6：Byte信号说明DB0MuxID0x00~0x07，表示结果类型DB1 低4位IVT_MsgCount每通道独立循环计数器 0x0~0xFDB1 高4位IVT_Result_state状态位DB2~DB5IVT_Resultname4 字节有符号 long 值6.1 MuxID 定义MuxID结果名单位0x00IVT_Msg_Result_I1 mA0x01IVT_Msg_Result_U11 mV0x02IVT_Msg_Result_U21 mV0x03IVT_Msg_Result_U31 mV0x04IVT_Msg_Result_T0.1 °C0x05IVT_Msg_Result_W1 W0x06IVT_Msg_Result_As1 As0x07IVT_Msg_Result_Wh1 Wh6.2 状态位定义（DB1 高 4 位）bit0：OCS 为 true（过流开关状态）bit1：该结果超规格范围 / 精度降低 / 测量错误bit2：任意结果存在 measurement-errorbit3：任意结果存在 system-error，传感器功能不再保证说明：即使未开启 measurement / system error bit mask 上报，bit2/bit3 仍可能因 CRC 错误置位bit2 还可能因 Vref error 置位6.3 数据解析示例默认大端示例：DB0=0x01DB1=0x05DB2~DB5=00 00 88 B8表示：Result_U1状态位=0MsgCount=5数值=0x000088B8 = 35000 mV = 35.000 V6.4 数值字段类型DB2~DB5 为结果值字段所有结果统一按 signed long（32-bit 有符号整数） 解释字节序由对应通道配置决定：默认 Big Endian，可改为 Little Endian7. 结合本型号的关键测量含义对 IVT-S-500-U3-I-CAN1-12/24：电流额定量程：±500 A电流结果单位：1 mA电压量程：±1000 VU1/U2/U3 结果单位：1 mV温度结果单位：0.1 °C功率结果：I × U1能量 / 电量计数也都以 U1 作为功率参考电压通道8. CAN ID 设置命令8.1 命令格式：Set CAN ID通过 IVT_Msg_Command（默认 0x411）发送，DLC=8。DB含义DB00x10~0x17 / 0x1D / 0x1F，指明要修改哪个报文的 CAN IDDB1目标 11-bit CAN ID 高字节DB2目标 11-bit CAN ID 低字节DB3~DB632-bit 序列号DB7未定义，置 0对应关系：0x10 = Result_I0x11 = Result_U10x12 = Result_U20x13 = Result_U30x14 = Result_T0x15 = Result_W0x16 = Result_As0x17 = Result_Wh0x1D = Command0x1F = Response限制：只能在 Stop 模式下配置9. 结果通道配置命令（模式、周期、字节序、符号）9.1 命令格式：Set Config ResultDB0 = 0x2n，其中 n 为通道号：0x20 = I0x21 = U10x22 = U20x23 = U30x24 = T0x25 = W0x26 = As0x27 = WhDB含义DB00x2nDB1 低4位模式DB1 高4位配置标志DB2~DB3周期/触发延时，单位 msDB1 低4位：模式0x0 = disabled0x1 = triggered0x2 = cyclic runningDB1 高4位：配置标志bit4：预留bit5：0 = 不在 IVT_Result_state bit2/bit3 中上报测量/系统错误掩码（默认）1 = 在 IVT_Result_state bit2/bit3 中上报bit6：0 = Big Endian（默认）1 = Little Endianbit7：0 = 符号不变（默认）1 = 符号翻转（+/- 互换）DB2~DB3输出周期 / 测量周期 / 触发延时，单位 ms0x0000 被忽略Trigger delay 从 1 ms 开始限制：只能在 Stop 模式下配置bit5 是全局设置，最后一次配置决定全局行为10. 运行控制与普通命令10.1 Reset Error / LogdataDB0 = 0x30DB值说明DB10x00Reset Measurement ErrorDB10x01Reset System ErrorDB10x02Reset Logdata Since ResetDB20x00全部计数清零DB20x01..0xFF清指定项DB3~DB6序列号32-bit serial限制：仅 Stop 模式响应至少在 +1200 ms 后返回10.2 TriggerDB0 = 0x31 DB1~DB2 为通道位图：bit0 = Ibit1 = U1bit2 = U2bit3 = U3bit4 = Tbit5 = Wbit6 = Asbit7 = Wh限制：仅 Run 模式可用10.3 StoreDB0 = 0x32将以下配置写入非易失存储器：测量配置过流阈值启动模式CAN ID波特率限制：存储完成以前不允许其他命令响应时间最多约 1000 ms仅 Stop 模式10.4 START_OC_TESTDB0 = 0x33 DB1~DB2 = OC 信号持续时间（ms） 限制：仅 Stop 模式10.5 SET_MODEDB0 = 0x34DB值说明DB10x00当前模式 StopDB10x01当前模式 RunDB20x00上电默认 StopDB20x01上电默认 RunDB3~DB4访问级别代码预留说明：Mode 指整个传感器工作模式，不是单个结果通道Stop 和 Run 均可读取10.6 过流阈值0x35 = 正方向过流阈值0x36 = 负方向过流阈值格式：DB1~DB2 = Set threshold，单位 1A，0=offDB3~DB4 = Reset threshold，单位 1A，0=off限制：仅 Stop 模式10.7 重启相关0x3A = Restart to configured bitrateDB1=0x08 → 250kDB1=0x04 → 500kDB1=0x02 → 1000k0x3D = Restart to default0x3F = Restart说明：重启命令会导致 Reset Watchdog 类错误复位0x3A 执行前会自动保存当前 bitrate，因此可能额外增加最多约 1 s 的重启时间0x3A/0x3D 仅 Stop 模式0x3F Stop/Run 均可11. Get 类命令11.1 获取测量错误 0x40DB1：0x00 = 获取错误位图0x01~0x0F = 获取对应错误计数器测量错误类型包括：ADC interruptADC channel1 overflow / underflowADC channel2 overflow / underflowVref errorCurrent implausible I1-I2Thermal EMF correctionI1 open circuitU1/U2/U3 open circuitntc-h / ntc-l open circuitcalibration data invalid11.2 获取系统错误 0x41DB1：0x00 = 获取位图0x01~0x10 = 获取某项错误计数系统错误包括：Code CRCParameter CRCCAN receive/transmit dataovertemp / undertemppower failuresystem clocksystem initconfigurationinternal ADC / EEPROM / ADC ClockReset illegal opcode / Watchdog / EMC 等11.3 获取总日志 0x4211.4 获取复位后日志 0x43可获取：Ah overall / charge / dischargeWh overall / charge / dischargeruntime overall各通道 within/outside specified limits 运行时间正/负方向 overcurrent 激活时间I/U1/U2/U3/T 的最大最小值11.5 获取 CAN ID 0x50~0x57 / 0x5D / 0x5F与 Set CAN ID 对应，用序列号定位设备。11.6 获取配置 0x60~0x670x60 = I0x61 = U10x62 = U20x63 = U30x64 = T0x65 = W0x66 = As0x67 = Wh11.7 其他 GET 命令0x73 GET_OC_TESTTIME0x74 GET_MODE0x75 GET_THRESHOLD_POS0x76 GET_THRESHOLD_NEG0x79 GET_DEVICE_ID0x7A GET_SW_VERSION0x7B GET_SERIAL_NUMBER0x7C GET_ARTICLE_NUMBER12. 响应报文定义所有响应默认发到 IVT_Msg_Response = 0x511，DLC=8，DB0 为响应类型。12.1 错误/日志响应0x80 = measurement errors response0x81 = system errors response0x82 = overall logdata response0x83 = logdata since reset response12.2 CAN ID 响应0x90~0x97 / 0x9D / 0x9F 分别对应 I/U1/U2/U3/T/W/As/Wh/Command/Response 的 CAN ID 响应。12.3 配置响应0xA0~0xA7 对应 I/U1/U2/U3/T/W/As/Wh 的配置响应。 格式与 Set Config Result 一致。12.4 命令响应0xB0 Reset Error/Logdata 响应0xB1 Trigger 响应0xB2 Store 响应0xB3 OC Test 响应0xB4 Mode 响应0xB5 Threshold_Pos 响应0xB6 Threshold_Neg 响应0xB9 Device_ID 响应0xBA SW_VERSION 响应0xBB SERIAL_NUMBER 响应0xBC ARTICLE_NUMBER 响应12.5 非法命令响应DB0 = 0xFFDB1 = 无效命令的 MUX ID13. 该型号的 DEVICE_ID 应如何识别对 IVT-S-500-U3-I-CAN1-12/24，GET_DEVICE_ID (0x79) 的响应 0xB9 中应表现为：Byte含义期望值DB1Device-type0x02（IVT-S）DB2I-nominal/160x1F（500A）DB3 高4位I-nominal%160x4（500A）DB3 低4位电压通道数0x3（3 路）DB4Feature0x03（Isolation）DB5Communication type0x01（CAN1，有终端）DB6供电0x01（12/24V）14. 上电启动报文设备上电完成内部自检后，会发送 Alive message：DB0 = 0xBFDB1~DB2 = Command IDDB3~DB6 = Serial number含义： 设备启动完成，已经可以通信。15. 常用配置流程：启用 4~7 并将 0~7 设为小端目标：启用默认关闭的 T / W / As / Wh（通道 4~7）将结果通道 0~7 统一配置为 cyclic + little-endianSTORE 后重启验证，确保掉电保持前提：命令发到 0x411，响应在 0x511全部配置命令仅能在 Stop 模式 下执行连续命令间隔不少于 2 ms，或等待上一条响应后再发命令帧未定义字节填 0x0015.1 配置目标值通道信号DB0DB1周期0I0x200x4200 14 = 20 ms1U10x210x4200 3C = 60 ms2U20x220x4200 3C = 60 ms3U30x230x4200 3C = 60 ms4T0x240x4200 64 = 100 ms5W0x250x4200 1E = 30 ms6As0x260x4200 1E = 30 ms7Wh0x270x4200 1E = 30 ms其中 DB1 = 0x42 表示：低 4 位 0x2：cyclic runningbit6 = 1：Little Endianbit5 = 0：不额外上报 measurement/system error maskbit7 = 0：符号不翻转15.2 命令顺序切到 Stop若只想临时进入 Stop，且保持上电默认仍为 Run：34 00 01 00 00 00 00 00若希望上电默认也改为 Stop：34 00 00 00 00 00 00 00期望响应：DB0 = 0xB4依次配置 8 个结果通道：20 42 00 14 00 00 00 00 21 42 00 3C 00 00 00 00 22 42 00 3C 00 00 00 00 23 42 00 3C 00 00 00 00 24 42 00 64 00 00 00 00 25 42 00 1E 00 00 00 00 26 42 00 1E 00 00 00 00 27 42 00 1E 00 00 00 00每条配置的期望响应：0xA0~0xA7 分别对应 I/U1/U2/U3/T/W/As/Wh第一次读回验证：60 00 00 00 00 00 00 00 61 00 00 00 00 00 00 00 62 00 00 00 00 00 00 00 63 00 00 00 00 00 00 00 64 00 00 00 00 00 00 00 65 00 00 00 00 00 00 00 66 00 00 00 00 00 00 00 67 00 00 00 00 00 00 00读回检查：响应为 0xA0~0xA7DB1 应为 0x42周期应分别为 0014 / 003C / 003C / 003C / 0064 / 001E / 001E / 001E保存到非易失存储器：32 00 00 00 00 00 00 00期望响应：DB0 = 0xB2完成前不要发送其他命令，最长约 1000 ms重启：3F 00 00 00 00 00 00 00重启后等待 Alive message：DB0 = 0xBF第二次读回验证：再次发送 0x60~0x67若配置仍一致，说明 STORE 已生效，掉电后可保持15.3 结果报文验证重启后应看到以下结果开始周期发送：0x521 I0x522 U10x523 U20x524 U30x525 T0x526 W0x527 As0x528 Wh验证要点：0x525~0x528 出现，说明默认关闭的 4~7 已启用DB2~DB5 需按 Little Endian 解释例如 U1 收到 DB2~DB5 = B8 88 00 00，应解析为 0x000088B8 = 35000 mV = 35.000 V15.4 关键说明字节序配置是按结果通道分别设置，不是全局一次性切换它只影响结果报文 DB2~DB5 的数值解析，不改变命令/响应报文格式SET_MODE (0x34) 的 DB2 会同时修改“上电默认模式”，配置时不要误写
软件：CANdb+ editor。CAN 通讯 DBC 中的 Message / Signal 是什么在 CAN 通讯里，DBC 是一种“描述 CAN 报文含义”的数据库文件格式。 它本身不传输数据，它的作用是告诉工具和工程师：一条 CAN 报文的 message 是什么这条报文里每一段 bit 对应哪个 signal这些原始 bit 怎么换算成真实物理值可以把它理解成：CAN 帧 = 一包 8 字节或更多字节的数据DBC message = 对这包数据的“定义”DBC signal = 这包数据里面某一段 bit 的“字段定义”下面分层详细解释。1. Message 是什么在 DBC 里，message 对应一条 CAN 报文定义。 它描述的是：报文 ID报文名DLC（数据长度）发送节点这条报文里包含哪些 signal典型 DBC 片段：BO_ 256 VehicleStatus: 8 VCU SG_ VehicleSpeed : 0|16@1+ (0.01,0) [0|250] "km/h" ECU SG_ Gear : 16|4@1+ (1,0) [0|15] "" ECU SG_ BrakePedal : 20|8@1+ (0.4,0) [0|100] "%" ECU这表示：BO_ 256 VehicleStatus: 8 VCUmessage ID = 256（十进制）message name = VehicleStatus长度 = 8 字节发送者 = VCUmessage 可以理解成一个“结构体容器”。2. Signal 是什么signal 是 message 里的一个数据字段。 也就是 CAN 数据区中某几位 bit 的定义。例如上面的 VehicleStatus message 里有 3 个 signal：VehicleSpeedGearBrakePedal每个 signal 通常包含这些信息：起始位 start bit长度 length字节序 byte order符号类型 signed/unsigned缩放系数 factor偏移量 offset物理范围 min|max单位 unit接收节点3. Signal 定义格式怎么读以这一行举例：SG_ VehicleSpeed : 0|16@1+ (0.01,0) [0|250] "km/h" ECU拆开看：SG_ VehicleSpeed：signal 名称是 VehicleSpeed0|16：从 bit 0 开始，长度 16 bit@1+1 表示 Intel 格式（小端，little-endian）+ 表示 无符号(0.01,0)factor = 0.01offset = 0[0|250]：物理值范围是 0 到 250"km/h"：单位 km/hECU：接收节点4. Message 和 Signal 的关系关系非常简单：一个 message 里可以有多个 signal一个 signal 必须隶属于某个 message类比成内存结构：struct VehicleStatus { uint16_t VehicleSpeed; uint8_t Gear : 4; uint8_t BrakePedal; };只是 DBC 不是按 C 语言字段对齐来定义，而是直接按 bit 位定义。5. CAN 原始值和物理值的关系signal 最核心的计算公式是：PhysicalValue = RawValue × Factor + Offset其中：RawValue：从报文 bit 中解析出的原始整数Factor：缩放系数Offset：偏移量PhysicalValue：真实物理值6. 一个完整计算例子例 1：车速信号DBC：SG_ VehicleSpeed : 0|16@1+ (0.01,0) [0|250] "km/h"报文数据前 2 字节假设为：Byte0 = 0x10 Byte1 = 0x27因为这是 Intel 小端，16 bit 原始值拼接方式是：Raw = Byte0 + (Byte1 << 8) = 0x10 + (0x27 << 8) = 0x10 + 0x2700 = 0x2710 = 10000换算物理值：Physical = 10000 × 0.01 + 0 = 100.00所以：VehicleSpeed = 100 km/h7. Factor 和 Offset 为什么存在因为 CAN 报文里传的是整数 bit，不直接传浮点物理量。例如真实速度 100.23 km/h，不会直接以 IEEE754 浮点发出去，而通常会转成整数：Raw = (Physical - Offset) / Factor比如 factor = 0.01：Raw = 100.23 / 0.01 = 10023发送端把 10023 放到 16 bit 里，接收端再按公式还原。这样做的优点：节省带宽便于 MCU 处理提高兼容性便于控制精度8. 反向计算：物理值转 CAN 原始值公式反过来：RawValue = (PhysicalValue - Offset) / Factor例 2：温度信号DBC：SG_ Temperature : 32|8@1+ (1,-40) [-40|215] "degC"如果真实温度是 35°C：Raw = (35 - (-40)) / 1 = 75所以 CAN 中存的是：Raw = 75 = 0x4B接收端解析后：Physical = 75 × 1 + (-40) = 359. Signed 和 Unsigned 的区别DBC 中 + 表示无符号，- 表示有符号。例如：SG_ MotorTorque : 8|12@1- (0.5,0) [-1024|1023.5] "Nm"这里 @1- 表示：Intel 小端有符号数如果 12 bit 原始数据最高位为符号位，需要按补码解释。例 3：12 bit 有符号值假设读出的 12 bit 原始 bit 模式为：1111 0011 0000这是 12 位补码。先判断最高位为 1，所以它是负数。 把它转成十进制：无符号值：0b111100110000 = 388812 bit 有符号范围：-2048 ~ 2047所以真实 raw 值为：RawSigned = 3888 - 4096 = -208若 factor = 0.5，offset = 0：Physical = -208 × 0.5 = -104 Nm10. Start Bit 和 Length 怎么理解startBit|length例如：SG_ Gear : 16|4@1+表示：从第 16 位开始长度 4 bit如果 message 有 8 字节，共 64 位，则 bit 编号通常从 0 到 63。11. Intel 和 Motorola 的区别这是 DBC 里最容易混淆的部分。@1 = Intel = little-endian@0 = Motorola = big-endian它们的差别不只是“字节顺序”，还影响 start bit 的定义方式和跨字节取值方式。11.1 Intel（小端）特征：低字节放低地址signal 的低位通常在起始 bit多字节数值拼接时，低字节在前例如 16 bit 值 0x1234 存到两个字节里：Byte0 = 0x34 Byte1 = 0x12解析：Raw = Byte0 + (Byte1 << 8)11.2 Motorola（大端）特征：高字节在前DBC 中 start bit 的数法和 Intel 不同跨字节信号更容易看错例如：SG_ EngineSpeed : 8|16@0+ (0.125,0) [0|8000] "rpm"这里不能直接用 Intel 的拼接思路。 Motorola 下要按 bit 在网络中的顺序 取出，再组合成数值。12. Intel 详细取值方法假设数据 8 字节：Byte0 Byte1 Byte2 Byte3 Byte4 Byte5 Byte6 Byte7若有：SG_ Speed : 0|16@1+那么：bit 0~7 在 Byte0bit 8~15 在 Byte1raw 值：Raw = Byte0 + (Byte1 << 8)若：SG_ X : 12|12@1+则它跨越 Byte1 和 Byte2：bit 12~15 是 Byte1 的高 4 位bit 16~23 是 Byte2 的低 8 位可以等价理解为先把整个数据区按 little-endian 连成一个整数，再右移和掩码：Raw = (Data >> startBit) & ((1 << length) - 1)这个方法对 Intel 很好用。例 4：Intel 跨字节计算数据：Byte0 = 0x00 Byte1 = 0xBC Byte2 = 0x0A信号：SG_ X : 12|12@1+ (1,0)先把低字节在前组成整体：Data = 0x0ABC00右移 12 位：Data >> 12 = 0x0AB掩码 12 bit：Raw = 0x0AB = 171物理值若 factor = 1，则：Physical = 17113. Motorola 详细取值方法Motorola 在 DBC 中更复杂。 核心点：start bit 表示信号的 最高有效位 位置信号向“右边”扩展，但跨字节时会跳到下一个字节的高位继续常见 bit 排列（每字节从 bit7 到 bit0）：Byte0: 7 6 5 4 3 2 1 0 Byte1: 15 14 13 12 11 10 9 8 ...很多工具对 Motorola 的视觉显示会不同，但本质上是按网络位序取。例 5：Motorola 16 bit假设：SG_ Y : 15|16@0+ (1,0)数据：Byte0 = 0x12 Byte1 = 0x34则通常解析为：Raw = 0x1234 = 4660而不是 Intel 的 0x3412。14. 为什么很多人会算错主要有 4 个原因：把 Intel 和 Motorola 混了把 start bit 当成字节内固定方向，没考虑 DBC 定义有符号数没按补码处理忘了 factor / offset所以工程上常见做法不是手算每一位，而是：明确字节序明确起始位定义先求 raw再换算 physical15. 多路复用信号（Multiplexed Signal）有些 message 中，不是所有 signal 都同时有效。 这时会有一个 mux signal 决定后面字段含义。例如：BO_ 512 Control: 8 ECU SG_ Mode M : 0|4@1+ (1,0) [0|15] "" ECU SG_ SpeedCmd m0 : 8|16@1+ (0.1,0) [0|300] "km/h" ECU SG_ TorqueCmd m1 : 8|16@1+ (0.5,0) [0|500] "Nm" ECU含义：Mode 是 multiplexor当 Mode = 0 时，bit 8~23 表示 SpeedCmd当 Mode = 1 时，bit 8~23 表示 TorqueCmd同一段 bit 在不同模式下含义不同。16. 枚举值（Value Table）有些 signal 不是连续物理量，而是状态码。例如：SG_ GearState : 24|3@1+ (1,0) [0|7] "" ECU VAL_ 256 GearState 0 "Invalid" 1 "P" 2 "R" 3 "N" 4 "D";表示：raw = 1 -> Praw = 2 -> Rraw = 3 -> Nraw = 4 -> D这类 signal 虽然也有 raw 值，但常用于离散状态解释。17. 一个完整报文综合计算假设 DBC：BO_ 256 VehicleStatus: 8 VCU SG_ VehicleSpeed : 0|16@1+ (0.01,0) [0|250] "km/h" ECU SG_ Gear : 16|4@1+ (1,0) [0|15] "" ECU SG_ BrakePedal : 20|8@1+ (0.4,0) [0|100] "%" ECU SG_ Temp : 32|8@1+ (1,-40) [-40|215] "degC" ECU收到数据：Byte0 = 0x10 Byte1 = 0x27 Byte2 = 0x53 Byte3 = 0x00 Byte4 = 0x4B可依次解析：VehicleSpeedraw = 0x2710 = 10000physical = 10000 × 0.01 = 100 km/hGearByte2 = 0x53 = 0101 0011bbit 16~19 为低 4 位，可得 Gear = 3BrakePedalbit 20~27 跨 Byte2 和 Byte3按 Intel 方式取 raw 后，再乘以 0.4Tempraw = 0x4B = 75physical = 75 - 40 = 35 degC18. 实际使用建议在工程里分析 DBC 时，推荐固定按下面顺序处理：先看 message：确认 ID、长度、发送节点再看 signal：确认起始位、长度、字节序、正负号先求 raw 值再套 physical = raw × factor + offset如果是枚举量，再查 VAL_如果是 multiplexed message，先看 mux signal19. 一句话总结Message：一整条 CAN 报文定义Signal：报文中的一个字段定义DBC：告诉你“这些 bit 代表什么，以及怎么算成工程量”如果只记一个公式，就记这个：PhysicalValue = RawValue × Factor + Offset
https://blog.csdn.net/weixin_59334478/article/details/138559113Intel格式 (小端模式，@1)：LSB在低字节的低位，MSB在高字节的高位。Motorola格式 (大端模式，@0)：LSB在高字节的低位，MSB在低字节的高位Motorola 格式下，信号的高位字节（MSB）放在低地址，低位字节（LSB）放在高地址，与 Intel 格式相反。Motorola 的 StartBit 指的是信号的最高有效位 (MSB) 在数据帧中的位置，而 Intel（小端）格式的 StartBit 则指的是信号的最低有效位 (LSB) 的位置。（部分工具（如 CANdb++ 图形界面）可能统一以 LSB 作为起始位显示，但在 DBC 文本文件的底层定义中，Motorola 格式的 StartBit 始终指向信号的 MSB 位置。）bit start reflects the position of least-significant bit。LSB/MSB 只是权重，不代表物理顺序1. 基础概念：字节序与位序在 CAN 协议的 8 字节数据场中，我们定义：Byte 0 是低地址字节，Byte 7 是高地址字节。每个字节内，Bit 0 是最低有效位（LSB），Bit 7 是最高有效位（MSB）。2. Intel 格式 (Little Endian / 小端模式)Intel 格式是 STM32 等多数 ARM 内核单片机在内存中存储数据的原生方式。核心特点低字节对应低地址：信号的最低有效位（LSB）存储在起始字节（低索引字节）中。跨字节增长方向：当一个信号跨越多个字节时，高位部分向 字节索引增加 的方向排列（即从 Byte 4 向 Byte 5 延伸）。位排序：位索引从低向高排列，逻辑连续。结合图片解析观察图片中的黄色高亮部分，假设这里定义的是一个 12 bit 的温度信号：数据流为 00 00 00 00 06 40 00 00。Byte 4 值为 0x06 ($0000\_0110_2$)。Byte 5 值为 0x40 ($0100\_0000_2$)。图中标记 lsb 在 Byte 4，msb 在 Byte 5。若按 Intel 格式定义该信号，且信号长度为 12 bit，则原始值取这 2 个字节拼接后的 低 12 bit： $$Raw\_Value = ((Byte\_5 \ll 8) | Byte\_4) \& 0x0FFF = ((0x40 \ll 8) | 0x06) \& 0x0FFF = 0x006$$原始十进制值为 $6$。假设该信号的物理量定义如下：Factor = 0.1Offset = -40Unit = °C则物理值为： $$Physical\_Value = (Raw\_Value \times Factor) + Offset = (6 \times 0.1) - 40 = -39.4\,^{\circ}C$$3. Motorola 格式 (Big Endian / 大端模式)Motorola 格式常用于欧洲汽车制造商（如 Bosch、矢量控制单元）以及一些传统的 ECU 协议。核心特点高字节对应低地址：信号的最高有效位（MSB）存储在起始字节（低索引字节）中。跨字节增长方向：当信号跨越多个字节时，信号的高位在低索引字节，低位在高索引字节。填充方式：在矩阵图中，信号通常呈现“向左下角”或“由高地址向低位”延伸的趋势。结合图片解析若图片中的数据采用 Motorola 格式解析，并且同样定义为一个 12 bit 的温度信号：起始字节（高位）是 Byte 4，后续字节（低位）是 Byte 5。先按 Motorola 顺序拼接： $$Combined = (Byte\_4 \ll 8) | Byte\_5 = (0x06 \ll 8) | 0x40 = 0x0640$$若该 12 bit 信号占用拼接结果的低 12 bit，则： $$Raw\_Value = Combined \& 0x0FFF = 0x640$$原始十进制值为 $1600$。继续使用相同的物理量定义：Factor = 0.1Offset = -40Unit = °C则物理值为： $$Physical\_Value = (1600 \times 0.1) - 40 = 120\,^{\circ}C$$4. Intel 与 Motorola 的直观对比下表对比了一个信号在 CAN 数据矩阵中的分布差异：特性Intel (Little Endian)Motorola (Big Endian)LSB (最低位)位于起始字节位于结束字节MSB (最高位)位于结束字节位于起始字节STM32 处理直接结构体映射或强制类型转换需要使用 __REV16 或位移进行字节交换DBC 文件定义常用格式，逻辑较直观需特别注意起始位的定义（通常指 MSB）5. 在 STM32 与 FSAE 开发中的应用建议5.1 STM32 代码实现 (以 Intel 为例)在 STM32 中接收到 CAN_RxHeaderTypeDef 的数据后，如果是从 Byte 4 开始的 12 bit 传感器信号，并且带有 Factor、Offset 和单位：uint8_t rxData[8]; // 存储接收到的 CAN 数据 uint16_t raw_value; float physical_value; // 例：Factor = 0.1f, Offset = -40.0f, Unit = degC // Intel 格式：先按小端拼接，再取低 12 bit raw_value = ((uint16_t)(rxData[5] << 8) | rxData[4]) & 0x0FFF; physical_value = raw_value * 0.1f - 40.0f; // Motorola 格式：先按大端拼接，再取低 12 bit raw_value = ((uint16_t)(rxData[4] << 8) | rxData[5]) & 0x0FFF; physical_value = raw_value * 0.1f - 40.0f;5.2 FSAE 调试要点传感器一致性：在配置如 Motec、Haltech 或自定义 STM32 节点时，必须统一全车的协议格式。建议全车统一使用 Intel，因为这与 C 语言在 ARM 上的存储逻辑一致。DBC 导出：如果你使用 CANdb++ 或其他工具编写 DBC 文件，务必检查每个 Signal 的 Byte Order 属性。注意偏移量 (Offset) 和缩放比例 (Factor)：在解析完原始值（例如 12 bit 的 $0x006$ 或 $0x640$）后，还需根据协议转换物理量： $$Physical\_Value = (Raw\_Value \times Factor) + Offset$$
一、原理介绍NAS 是一种网络存储设备，部署在一个网络环境（局域网）下，使得同处一个局域网的用户可以访问、存储和获取所需文件资料。如果不在 NAS 的局域网环境下，则需要通过内网穿透，实现外网 IP（相对于 NAS 局域网）对 NAS 的访问。我们目前使用的内网穿透软件为 Zerotier。账号：members密码：Bitfsae20210809二、局域网（LAN）环境下的使用在车队负一层工作室，连接到 WiFi BITFSAE 即可与 NAS 处于同一个 LAN。1. 方法一打开资源管理器，点击左侧栏的“网络”，或在地址栏输入 \\BITFSAE_NAS，即可找到 NAS。点击进入后输入账号密码即可。2. 方法二在浏览器（推荐 Chrome 或 Edge）地址栏输入 192.168.1.104:5000，进入 NAS 登录界面后输入账号密码。三、非 LAN 环境下的使用未连接到 WiFi BITFSAE 时，目前非 LAN 环境下仅在校园网内体验较好。1. 下载 Zerotier进入 Zerotier 官网下载：https://www.zerotier.com/2. 打开 Zerotier下载完成后，打开 Zerotier。打开后通常不会弹出主窗口，需要到右下角任务栏中找到 Zerotier 图标。3. 加入虚拟局域网右键 Zerotier 图标，点击 Join new network...。在弹出的窗口中输入以下网络 ID：233ccaac275dd996这是 Zerotier 为 NAS 创建的虚拟局域网 ID。4. 确认连接成功输入 ID 后，如果该 ID 前面出现对勾，说明已经连接到 LAN。5. 登录 NAS连接成功后，在浏览器中输入：https://192.168.196.3:5000即可进入 NAS 登录界面。四、备注上述方法主要以 Windows 系统为例，Mac 操作逻辑类似。非局域网环境目前仅限校园网环境（比如宿舍）体验较好。在校园网以外的网络环境下（比如家里或手机热点），目前连接速度会非常慢。即使在车队以外的校园网环境下，当前也可能存在加载较慢的情况。Zerotier 可能会设置为开机自启动。
示例 ：您好！我是北京理工大学纯电动方程式赛车队（BITFSAE）的 XXX申请型号：XXX 一套，并希望能提供该型号的 XXX 。大学生方程式（Formula Student）是全球顶尖的工程教育平台。若能获赠样品，我们将把 XXXXX 列为车队 2026 赛季赞助商之一，并在官网及社交媒体（如微信公众号）进行展示。感谢贵司对中国工程教育和赛车事业的支持。期待您的回复，非常感谢！如果对方无法直接给免费样品，可以退而求其次申请“2026 赛季长期借用”，赛季结束后归还或续约。回信要简洁凝练，但要保持礼貌和诚恳。赞助商手册在车队官网。有时需要附上：电话和收货地址。邮箱使用：[XXX@bitfsae.com] 或 [XXX@bit.edu.cn]。
写作入口链接地址登录控制台https://p0li.space/admin/网站首页https://p0li.space/打开登录控制台并登录。左上角菜单点击“撰写文章”。选择分类、填写正文、发布或保存草稿。选择分类注意选择正确分类，应为 BITFSAE 下的分类。如需新增分类，联系 我。正文规范正文使用 Markdown 格式。支持公式，行内公式与块级公式都可直接使用 $ 或 $$ 包裹。可先在 Obsidian、Typora 等 Markdown 编辑器中编辑，再复制到正文框。Markdown 基础语法请自行参考通用教程。公式示例：行内公式：$E = mc^2$ 块级公式： $$ \int_a^b f(x) \, dx $$图片使用图片统一使用图床链接。推荐写法：![图片标题](https://img.p0li.space/img/20260402xxxx.png)如需配置 PicGo，联系 我。或使用车队共用电脑上的 PicGo。支持在图片标题中追加尺寸参数（竖线后面）：![图片标题|300](https://img.p0li.space/img/20260402xxxx.png) # 宽度 300px ![图片标题|50%](https://img.p0li.space/img/20260402xxxx.png) # 宽度 50% ![图片标题|300x200](https://img.p0li.space/img/20260402xxxx.png) # 宽 300px，高 200px注意：尺寸参数写在 [] 内部的标题后面，使用英文竖线 | 分隔。PicGo 上传下载并安装 PicGo：https://molunerfinn.com/PicGo/联系网站管理员获取腾讯云 COS 配置。在 PicGo 中配置腾讯云 COS 图床。拖拽或粘贴图片上传。将自动复制的图床链接粘贴到 Markdown 中。图片建议格式优先使用 .jpg 或 .webp。文件大小尽量控制在 500KB 以内，不要超过 1MB。压缩可使用 https://docsmall.com/image-compress。链接写法站内文章链接推荐优先使用相对路径，迁移域名时更省事。[这篇文章值得继续看](/post/123.html) [关于页面](/page/about.html) [跳到评论区](/post/123.html#comments)也支持同域绝对地址：[这篇文章值得继续看](https://p0li.space/post/123.html)其他代码块支持语法高亮和复制按钮。文章自定义字段 description 会优先作为摘要展示。