我把 100 条本地 LoRa 监听记录交给 Ling，想搞清楚现场到底飞着什么信号

Ling-3.0-flash-VL 视觉语言模型 · 本地数据实测

不是让模型替我判断无线链路好坏，而是看它能否把一小段原始监听数据整理成真正可用的数据分析线索。

先说我的问题

LoRa 监听记录攒起来以后，最难受的往往不是没有数据，而是字段太多：centerFreq、bandwidth、sf、cr、crcEnable、level、length、tag、unifiedId……逐行看，基本看不出现场到底有几类信号、哪些配置稳定、哪些记录值得回看。

我从本地 primary_monitor_record 导出了前 100 条记录为 TXT，交给 Ling 在终端里读取和统计。我的要求很简单：先核对数据，再找模式；没有字段定义的地方，不准猜。

模型先做了哪些事

• 读取全部 100 条记录，检查字段和空值；
• 把 captureTime 毫秒时间戳换算为北京时间；
• 统计频点、带宽字段值、SF、CR、CRC、设备标识和参数组合；
• 筛出罕见组合和时间间隔异常的记录；
• 列出这份监听表无法回答的问题。

先把数字核对清楚

我没有直接相信模型的首版汇总，而是回到原始 TXT 用 Python 重算了一遍数据分析结果，逐项核对模型输出的数字。下面这些数字以原始 100 条为准。

这 100 条里有什么规律

样本全部出现在同一个中心频点 470900000。真正有区分度的字段是 bandwidth、sf、cr、crcEnable 和 unifiedId。

前三种组合合计 94 条。这至少说明在这 58.94 秒的样本窗口里，监听到的配置不是随机散落的，而是高度集中在少数几类参数上。

模型给我的价值，不是替我下结论

Ling 最有用的地方，是把原始表快速变成了下一轮排查的清单：主导的参数组合是什么、哪些组合只出现一次、哪些字段没有变化、应该去哪几条记录回看。

比如 level 全是 -1，length 全是 0。模型没有把它们直接说成无信号、空包或接收失败——这才是正确的边界。没有字段定义，这些值可能是状态码、占位值或尚未填充的数据，不能靠猜。

这份数据不能证明什么

下一轮我会补什么

下一次采集准备补上 RSSI、SNR、IRQ 状态、接收结果、设备发送序号，以及设备/协议版本。这样才可以进一步判断：罕见组合到底是另一类合法配置、监听端解析差异，还是实际链路问题。

最后的感受

对这 100 条结构化样本，语言模型的价值不是替代统计，而是先充当”筛选和归因助手”：把频点、带宽、SF、编码率、CRC、RSSI、时间戳等字段放到同一语境里，快速找出异常组合、重复模式和值得回看的包，少走一遍人工翻表。

如果接入 VL（视觉语言模型），它还能读懂频谱图、瀑布图、抓包界面截图和设备现场照片，并把”图上某段突发信号”与”表中某批数据包”对应起来。例如发现某个频点出现密集能量条带，同时 CRC 失败率升高、SF 或带宽发生切换，就能优先提示可能存在干扰、参数不匹配或设备状态变化。

但 VL 模型看的是图像表象，语言模型做的是关联和解释；最终的包数、统计比例、字段定义、LoRa 参数含义，以及”为什么丢包/为什么 CRC 异常”的结论，仍必须回到原始抓包、芯片/协议文档和现场复现来确认。模型适合缩小排查范围，不适合替你盖棺定论。

例如接入视觉语言模型处理图像时，仍要先用 Python 处理数据核对字段，再决定哪段信号值得人工回看，这个流程里模型只负责筛选。

原文信息

作者：前滩涨超（@qtdevlop），基金研究博主

原文地址：