软件工程实训之用。此仓库作为项目源码仓库
问题：雷达上报的数据是十六进制流，包含多目标的 X/Y 坐标、速度等信息，直接看 Hex 码无法理解。
解决：
- 参考《LD2450 串口通信协议 V1.03》，实现了
parseRadarByte状态机，自动识别帧头AA FF 03 00和帧尾55 CC。 - 根据官方坐标计算规范，实现精确的坐标解析：
- 数据格式：低位在前，高位在后
- X坐标计算：
- 最高位为0：负坐标，计算方式为 0-X（即 -X）
- 最高位为1：正坐标，计算方式为 X-2^15（即 X-32768）
- Y坐标计算：一直是正坐标，计算方式为 Y-2^15（即 Y-32768）
- 速度计算：同X坐标，最高位决定正负方向
- 实现了
DATA_PRINT_INTERVAL(3秒) 限流机制，防止高速刷屏导致控制台卡顿，同时保留心跳.提示。
官方数据样例解析：
帧数据：AA FF 03 00 10 01 52 83 00 00 68 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 CC
目标1数据：10 01 52 83 00 00 68 01
- X: 0x0110 = 272, 最高位为0 → 负坐标 → X = 0-272 = -272mm
- Y: 0x8352 = 33618, 最高位为1 → 正坐标 → Y = 33618-32768 = 850mm
- 速度: 0x0000 = 0
- 分辨率: 0x0168 = 360mm
结果：目标位于 (-272mm, 850mm)
另一个样例：
帧数据：AA FF 03 00 BE 8A 47 8E 11 00 68 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 CC
目标1数据：BE 8A 47 8E 11 00 68 01
- X: 0x8ABE = 35518, 最高位为1 → 正坐标 → X = 35518-32768 = 2750mm
- Y: 0x8E47 = 36453, 最高位为1 → 正坐标 → Y = 36453-32768 = 3685mm
- 速度: 0x0011 = 17, 最高位为0 → 负速度 → 速度 = 0-17 = -17cm/s
- 分辨率: 0x0168 = 360mm
结果：目标位于 (2750mm, 3685mm)，向后移动17cm/s
问题：
- 发送指令（如查询版本
ver）后，看不到雷达的反馈，或者反馈是一串看不懂的 Hex。 - 部分指令（如
reboot）发送失败，雷达返回错误码0x0001。
解决：
- 封装协议：实现了
sendRadarPacket函数，自动计算包长、添加帧头FD FC FB FA和帧尾04 03 02 01。 - 智能 ACK 解析：
waitForAck函数不仅检查“成功/失败”，还能根据发送的指令类型（sentCmd），自动将返回的数据负载解析为人类可读的格式（如版本号、MAC地址、当前模式）。 - 时序修复：发现雷达处理状态切换需要时间。在发送
Enable Config后和发送具体指令前，增加了 50ms 的硬延时 (delay(50))，并在这之前清空串口缓冲区，彻底解决了reboot报错的问题。
问题：
- 雷达波特率可能是
256000或115200，写死代码会导致连接失败。 - 核心痛点：ESP32 刷写固件重启时，雷达不会断电，会持续向 ESP32 发送高速数据。这导致 ESP32 启动时缓冲区里全是"半截"的脏数据，导致扫描逻辑（只认帧头）误判为"未连接"。
- 启动流程冗余：之前的实现会在所有波特率下预重启雷达，造成不必要的延迟和雷达状态不稳定。
解决：
- 热重启优化策略：优先尝试256000波特率连接雷达（适用于热重启场景），如果雷达响应则发送重启命令清理状态，等待重启完成后再验证连接；如果失败才回退到自动波特率扫描。
- 智能开机流程：ESP32启动时不再预重启所有波特率，而是先快速检测256000波特率，确认雷达响应后才进行重启操作，避免不必要的雷达重启。
- 系统状态报告：WiFi连接成功后，自动查询并显示完整的系统状态（雷达波特率、WiFi状态、MAC地址、雷达版本/MAC/模式/区域信息），并保存初始配置作为基准。
- 增强预清理：在
setup()开始时，在多个波特率（256000, 115200, 9600, 19200, 38400, 57600）下进行预清理，确保清除所有可能的脏数据。 - 重试机制：
scanBaudRate增加最大重试次数限制（5次），避免无限循环。 - 多重清理策略：
- 串口关闭等待：
Serial1.end()后增加200ms等待 - 多轮缓冲区清理：在
Serial1.begin()后进行两次清理 - 延时等待：额外300ms等待，让雷达的旧数据自然流逝
- 串口关闭等待：
- 调试增强：显示每次扫描接收到的字节数，便于诊断连接问题。
- 简化初始化：波特率扫描成功后直接查询雷达模式，减少冗余操作。
- 双重判定：扫描逻辑优化，不仅识别坐标帧头
AA FF，也识别配置 ACK 帧头FD FC，防止雷达处于静默配置模式时被误判为掉线。 - 调试信息：
clearSerialBuffer函数会报告清理了多少字节，便于调试。
问题：
- 误触
factory（恢复出厂）或baud（改波特率）等危险指令会导致失联。 - 想一边用手机 App 调参，一边看串口反馈，但雷达不会主动上报配置变更。
解决：
- 二次确认机制：对
reboot,factory,baud等指令引入requestAction流程，必须输入yes才能执行。 - 后台静默巡检：利用
lastKnownMode变量，在后台每 15 秒自动查询一次雷达状态。只有当发现状态（如单/多目标模式）发生变化时，才在串口打印[Auto-Check] ALERT，既实现了监控又保持了安静。 - 透传模式：开发了
bridge命令，让 ESP32 变身 USB-TTL 透传工具，方便直接连接官方 PC 上位机进行深度调试。
问题：ESP32启动流程冗余，WiFi连接后缺乏系统状态概览，影响调试和监控效率。
解决：
- 智能启动序列：ESP32启动时优先尝试256000波特率（热重启最常见情况），2秒内检测雷达响应。如果响应则发送重启命令清理状态，等待2秒重启完成后再验证连接；如果失败才执行完整的自动波特率扫描。
- 完整系统报告：WiFi连接成功后，自动生成系统状态报告，包含：
- 雷达通信波特率
- WiFi连接状态和IP地址
- 设备MAC地址
- 雷达固件版本
- 雷达MAC地址
- 当前工作模式（单/多目标）
- 区域配置信息
- 初始配置保存：开机完成后保存当前配置作为基准，用于后续的变更检测。
- 用户友好提示：显示"System ready. Type '?' for help."提示用户系统已就绪。
问题：发送 bleoff 关闭蓝牙显示成功，但手机还能搜到。
解决：
- 确认了 LD2450 的硬件机制——蓝牙配置必须重启生效。代码中添加了专门的提示语
>> NOTICE: Please execute 'reboot'...，引导用户正确操作。
问题：需要实现前端通过服务器远程控制ESP32设备的功能，包括设备重启和模式切换。
解决：
- 指令传递机制：采用"捎带响应"策略，ESP32在数据上报时通过HTTP请求携带指令，服务器在响应中返回待执行指令。
- 指令解析逻辑：在
uploadDataToServer()函数中添加指令解析代码，检查服务器响应中的pending_cmd字段。 - 指令执行映射：支持
REBOOT指令（调用runCmd("Remote Reboot", 0x00A3, NULL, 0)）和SET_MODE指令（根据payload.mode调用相应的雷达配置命令）。 - 兼容性修复：更新ArduinoJson使用方式，使用
respDoc["data"]["pending_cmd"].is<JsonObject>()替代已弃用的containsKey()方法。 - 指令队列：服务器支持指令排队，ESP32每次只执行一个指令，确保执行顺序和可靠性。
问题：WiFi配置硬编码在主代码中，用户难以自定义，且可能导致编译错误（如多重定义）。
解决：
- 创建独立的
wifi/文件夹，包含wifi_config.h、wifi_config.cpp和README.md。 wifi_config.h：声明WiFi常量和函数原型，使用extern避免多重定义。wifi_config.cpp：定义WiFi变量和实现连接函数，用户可轻松修改SSID、密码和服务器URL。- 修复编译错误：通过分离声明和定义，解决了链接时的多重定义问题。
- 用户指导：
wifi/README.md提供详细配置说明和示例。
- [2025-12-31 UTC] WiFi配置模块化：创建独立wifi文件夹，实现用户友好的WiFi配置系统。修复多重定义编译错误，提供详细用户文档。
- [2025-12-31 UTC]
- 开机流程优化：重构ESP32启动序列，优先尝试256000波特率连接雷达（适用于热重启场景）。如果雷达响应，发送重启命令清理状态，等待重启完成后再验证连接；如果失败才回退到自动波特率扫描。WiFi连接成功后，查询并显示完整的系统状态报告（包括雷达波特率、WiFi状态、MAC地址、雷达版本/MAC/模式/区域信息），并保存初始配置。
- 自动检测间隔调整：将后台配置自动检查间隔从10秒增加到15秒，减少对雷达的查询频率，提升系统稳定性。
- 修复raw模式输出卡顿：为raw模式添加1秒限流机制，避免高速数据输出导致串口阻塞和卡顿。X=0代表雷达视角正前方有人，X>0代表左侧，X<0代表右侧。Y代表的距离，恒为正，单位为毫米。
- 优化帮助信息：为串口解析目标输出添加解释，说明Target: [T1 x,y] 表示目标1的X坐标和Y坐标，单位为毫米。
- 修复坐标解析逻辑：根据HLK-LD2450官方规格书完善坐标计算方式。X坐标根据最高位决定正负，Y坐标始终为正坐标（减去32768），速度同样根据最高位决定方向。删除统一的parseCoordinate函数，改为分别处理X、Y、速度坐标，确保符合官方协议定义。
- 优化后端过滤：加强device_sync函数的无效目标过滤逻辑，检查x、y、speed、resolution全为0时才跳过，避免写入无效记录。
- 完善雷达数据解析：修改parseTargetsFromRadarBuf()函数，正确解析速度(speed)和分辨率(resolution)字段，不再硬编码为0。
- 优化数据上传逻辑：设备端检测到为单目标模式（Single Target）时，仅上传T1目标数据，多目标模式下才上传全部3个目标，避免数据库冗余无效目标。
- [2025-12-30 UTC] 板端 ESP32 上电后自动重启雷达，提升初始化可靠性。已在 setup() 末尾插入 runCmd("Reboot Module", 0x00A3, NULL, 0)，无需人工干预，雷达可自动恢复数据上传。
- [2025-12-31 UTC] 优化启动流程：重新设计ESP32启动序列，先在所有可能波特率下预重启雷达确保干净状态，再进行波特率扫描，最后简化初始化流程。减少冗余调试输出，提升启动可靠性。