一条农业物联网上行，为什么可以带着多条天线接收元数据

农业物联网日志里，一条上行消息的下方可能列着多组接收信息。The Things Stack官方API将ApplicationUplink中的rx_metadata定义为一个列表，保存收到这条消息的各网关、各天线的元数据。[1] 因而，列表出现多个条目，首先说明的是接收记录的组织方式。

这一结构可以从外到内读：外层是上行消息，里面的rx_metadata是接收元数据列表，列表中的每项则是一个RxMetadata。官方定义进一步明确，每个收到消息的天线对应一个这样的条目。[1][2] 多个接收对象的信息，可以共同附在同一条上行下面，而无需把每个条目先改写成一次新的田间采样。

接收条目还保留了两个层次的标识。gateway_ids对应网关身份，antenna_index对应天线索引。二者放在一起，使读者能够继续分清“哪个网关”和“该网关的哪个天线”。这里的天线索引只是接口字段说明，本文没有查询任何农场网关或安装记录，也不从索引推断设备型号与布设位置。

可以用一个明确自拟的情形说明计数差异：假设同一消息由甲网关的两根天线、乙网关的一根天线收到，按该定义形成的是三个天线接收条目，涉及两个网关。这不是本文抓取到的真实日志，也不表示设备测了三次土壤湿度；它只是把文档所说“每个天线一个条目”的关系展开。

时间字段同样带有所在层次。ApplicationUplink顶层的received_at，文档解释为Network Server收到消息的服务器时间；RxMetadata内部的received_at，则是Gateway Server收到消息的时刻。[1][2] 两处名称相同，所指的接收组件却不同。阅读文件时保留字段所处的对象，才能知道正在讨论哪一个环节。

RxMetadata另外还有名为time的字段。原定义将它联系到传输结束时刻，由网关提供，并明确说准确度未定义。[2] 这项时间与前述服务器接收时间具有不同的来源说明。本文没有据两个值相减计算链路延迟，也没有把任意接收时刻补作传感器实际测量的时刻。

这两份页面是接口定义，首次发布日期未确认，示例中的空对象和默认时间也不是农场实测数据。本文采用ApplicationUplink、RxMetadata和UplinkMessage的相关定义及邻接文字，不执行代码、不设置无线参数或控制设备。对于已有农业环境日志，先保留一条上行、多个天线接收条目以及各字段的接收组件，能够让消息内容和接收证据各自保持清楚的层次。