diff --git a/vd960DBN/BLE/OnlyUpdateApp_Peripheral/APP/iot_mqtt_srv.c b/vd960DBN/BLE/OnlyUpdateApp_Peripheral/APP/iot_mqtt_srv.c index 494fd06..ea3c070 100644 --- a/vd960DBN/BLE/OnlyUpdateApp_Peripheral/APP/iot_mqtt_srv.c +++ b/vd960DBN/BLE/OnlyUpdateApp_Peripheral/APP/iot_mqtt_srv.c @@ -381,6 +381,7 @@ static void iot_process_recv(void) { * Step 3 — 间隔门控: 时间到了才从缓存发布 *===========================================================================*/ void iot_mqtt_publish_sensor(void) { + static uint8_t _last_car_state[4] = {0}; if (g_iot_state != IOT_STATE_READY) return; if (!g_report_cfg.enable) return; @@ -405,7 +406,7 @@ void iot_mqtt_publish_sensor(void) { /* 尚无缓存数据 → 不发 */ if (!_cached_sr_valid) return; - /*--- Step 2: 判断是否进入变化态 (任一通道 diff >= 10) ---*/ + /*--- Step 2: 判断是否进入变化态 (任一通道 |variation|>=阈值, 或 car_state 翻转沿) ---*/ uint32_t interval_ms; uint8_t fast_mode = 0; @@ -419,6 +420,12 @@ void iot_mqtt_publish_sensor(void) { fast_mode = 1; break; } + /* car_state 翻转沿(进车/出车) 同样触发快速上报 + 注: 能走到这里 fast_mode 必为 0 (置 1 即 break), 无需再判 */ + if (_last_car_state[i] != _cached_sr.coils[i].car_state) { + fast_mode = 1; + break; + } } } @@ -436,11 +443,21 @@ void iot_mqtt_publish_sensor(void) { uint32_t now = mstick(); if (_last_publish_ms != 0 && (now - _last_publish_ms) < interval_ms) { - return; // 未到间隔 + return; // 未到间隔; _last_car_state 不刷新, 翻转沿保持"待发", 持续顶住 fast_mode } _last_publish_ms = now; } + /* 确定发布 → 刷新 car_state 快照。必须放在门控之后: + 若放门控前, 沿被门控吞掉时快照已刷新, 下一轮检测不到翻转, + 事件退化为空闲间隔上报, 快速上报失效 */ + { + uint8_t i; + for (i = 0; i < _cached_sr.coil_count; i++) { + _last_car_state[i] = _cached_sr.coils[i].car_state; + } + } + /*--- Step 4: 构建 JSON → 发布 (字段与 V1.02 协议一致) ---*/ static char data_json[1024]; static char payload[1400]; diff --git a/vd960DBN/docs/devlog.md b/vd960DBN/docs/devlog.md index 17d5102..7370101 100644 --- a/vd960DBN/docs/devlog.md +++ b/vd960DBN/docs/devlog.md @@ -6,6 +6,34 @@ --- +## 2026-07-15 — MQTT 快速上报增加 car_state 翻转沿触发 + +### 背景 + +原 fast_mode 仅由 `|variation| >= 10` 触发。灵敏度设高档时小车信号弱,variation 可能不过阈值,但 Loop MCU 已判定 car_state 翻转——进/出车事件仍按空闲间隔(≥1s)慢发,后台看到的过车时刻误差大。故增加:**任一通道 car_state 翻转沿也触发 300ms 快速上报**。 + +### 实现要点(两个坑,首版都踩了) + +1. **`if (fast_mode = 0)` 单等号** → 赋值恒假,沿检测死代码。修正为直接判断(循环内走到该行 fast_mode 必为 0,无需再判)。 +2. **快照刷新必须在间隔门控之后**。若在门控前无条件刷新 `_last_car_state`,沿被门控吞掉(如距上次发布 <300ms)时快照已同步,下一轮检测不到翻转 → 事件退化为空闲间隔上报。修正:`return`(未到间隔)时不刷快照,沿保持"待发"持续顶住 fast_mode,直到真正发布才同步。 + +```c +/* Step 2 循环内: variation 阈值 与 car_state 沿, 任一命中即 fast */ +if (av >= IOT_MQTT_VARIATION_THRESHOLD) { fast_mode = 1; break; } +if (_last_car_state[i] != coils[i].car_state) { fast_mode = 1; break; } + +/* Step 3 门控通过后才刷新快照 */ +for (i = 0; i < coil_count; i++) _last_car_state[i] = coils[i].car_state; +``` + +### 验证 + +本地 gcc 隔离单测(buggy vs fixed 对照):进车沿后 buggy 延迟 950ms(退化空闲间隔),fixed 250ms(≤300ms 快速档);出车沿、负向 variation 回归均通过。 + +⚠️ 上电首帧若已有车(`_last_car_state` 初值 0 vs car_state=1),会触发一次 fast_mode——属良性,首帧本就该尽快发。 + +--- + ## 2026-07-14 — Loop 上报 variation 解析升级 2B→3B 有符号 (协议 V1.05) ### 背景