Sub-1G收发芯片在安防与三表场景的选型实战：GDS3260实测与关键参数拆解

这几年陆陆续续帮客户做过不少无线产品选型，感触最深的一点是：Sub-1G收发芯片在安防和三表（水表、电表、燃气表）这类场景里，几乎是绕不开的选择。前两天有个做无线门磁的朋友拿了一颗GDS3260的样片让我帮忙评估，说想在报警按钮和门磁上用，问我这颗芯片行不行、稳不稳。我花了一周时间把手册、模块、实测都过了一遍，把选型思路和踩坑记录整理出来，给正在做Sub-1G方案的朋友一个参考，也顺便聊聊这类产品选型时真正该盯住的几个关键点。

1. 为什么安防和三表场景都在往Sub-1G迁移：链路预算这笔账先算清楚

1.1 2.4G的穿墙劣势不是玄学，是物理定律

先说结论：Sub-1G在同等发射功率下传得更远、穿墙能力更强，这不是厂商宣传话术，而是由无线传播的基本规律决定的。频率越高，自由空间路径损耗越大，建筑结构对高频信号的吸收和反射也更强。2.4G波长约12.5厘米，433MHz波长约69厘米，波长差了五倍多，绕射能力自然天差地别。拐角、楼道、楼梯井这些位置，高频信号基本只能靠反射和散射，穿透难度高；而较低频率可以贴着边缘绕过去，这就是为什么Sub-1G在现场表现往往比2.4G从容得多。

用自由空间损耗公式粗算一下，L = 32.4 + 20lg(f) + 20lg(d)，以100米距离为例，433MHz算出来约65.2dB，2.4G约80.1dB，差了近15dB。这15dB意味着什么？在接收灵敏度相同的情况下，有效通信距离会差出去好几倍。当然有人会说2.4G可以做Mesh、做跳频，但这些机制在安防和三表场景里很难落地：终端数量大、电池供电、成本敏感，你不可能让每个传感器节点都保持常听状态去做Mesh维护。Sub-1G的点对多点拓扑简单直接，一个集中器带几百个节点，才是这类场景的上限解。

1.2 433/470MHz频段的典型链路预算估算

以GDS3260工作在433MHz为例，我们算一笔典型链路预算。假设发射功率+20dBm（即100毫瓦），接收灵敏度-125dBm（GFSK、1.2kbps、误码率1e-3条件），系统总链路预算约为20减去（-125）等于145dB。扣除天线增益、连接损耗、墙体穿透和衰落余量之后，还能给路径损耗留出大约120到130dB的空间。

反推一下，130dB的路径损耗在433MHz对应约7公里开阔地理论值，但实际有地面反射、树叶遮挡、天线效率、多径衰落，能稳定跑到几百米到一两公里已经是很不错的表现。穿墙场景下，每堵20厘米以上混凝土墙引入的损耗约10到15dB，穿三堵墙就耗掉40dB左右，剩下约90dB余量，在城市楼宇内覆盖一层甚至隔两层楼仍然可行。

这里有个容易被新人忽略的点：灵敏度指标对应的数据速率不同，结果完全不同。GDS3260在1.2kbps时能做到约-125dBm，但到50kbps时可能只有-115dBm左右。链路预算必须按实际使用的速率来算，不能拿手册最大灵敏度的数字直接套进高吞吐的配置里，否则覆盖评估会虚高一大截。

1.3 安防和三表终端的共性拓扑

为什么把安防和三表放在一起讨论？因为这两类产品的无线通信需求高度相似：终端节点极多，每个节点只上报少量数据；位置分散在楼宇、园区、地下空间；绝大多数时刻需要休眠，只在事件触发或定时抄表时醒来；整机的电池寿命要求以年为单位；通信不追求高吞吐，而是追求可靠性和低功耗。

从组网形态看，大多是星型网络。安防常见的是报警主机带几十到两百个探测器，三表常见的是集中器带几十到几百只水电气表。两者都要处理同一个核心矛盾：节点随时可能同时醒来，如何在有限信道里完成大量短帧的可靠传输，同时把碰撞概率压到最低。这决定了选型时不光要看射频芯片本身的灵敏度、功率，还要关心它的前导码检测、RSSI评估、发射完成中断、自动重传这些外围机制是否顺手。

2. GDS3260核心参数拆解：射频性能、低功耗机制与开发接口

2.1 射频链路参数：灵敏度、发射功率、抗干扰能力

先给结论性参数。GDS3260是一颗单芯片Sub-1G收发器，工作频段覆盖390到470MHz和740到960MHz两个区间，也就是说433、470、868、915这几个主流ISM频段都能用。调制方式支持GFSK、FSK、MSK、ASK和OOK，数据速率从0.1kbps到300kbps可配，基本覆盖安防和三表常见的低速窄带需求。

接收灵敏度实测下来，在433MHz、GFSK、1.2kbps下能做到约-125dBm，和同级别主流收发芯片处于同一水位。发射功率从-20dBm到+20dBm可调，步进约1dB。发射+20dBm时433MHz的电流约95mA，868MHz约105mA，这个功耗水平正常，毕竟100毫瓦的射频功率本身就需要不小的PA电流，天线匹配效率也会直接影响PA实际功耗。

抗干扰能力方面，GDS3260内置了AGC、AFC和RSSI测量。尤其AFC，在低成本无源晶振环境下特别有用，晶振的初始误差和温度漂移都可以在接收端做自动修正，能省掉不少整机成本。RSSI可以在0到127档之间读取接收信号强度，用于CCA信道评估和信号质量诊断，这个功能在后面的协议设计里会反复用到。

2.2 低功耗设计：从0.5uA睡眠电流到快速启动

做电池供电产品，低功耗是选型的硬指标。GDS3260的深睡电流典型值在0.5uA上下，属于不保留寄存器状态的深度睡眠模式。如果需要保留部分配置寄存器状态，电流会略有上升，规划整机休眠电流时要留出余量，不要把芯片手册值直接当成整机目标值。

更重要的是唤醒速度。GDS3260从深睡到RX就绪的时间大约在1.2ms级别，从睡眠到TX发射完成一个完整帧的启动时间类似。这个数字看似不起眼，在周期唤醒型产品里直接决定占空比设计。举个例子，一只燃气表每60秒醒来一次接收集抄下行指令，每次只听20ms，RX占空比是20/60000约等于0.03%，这部分电量折合一年也就几毫安时，相当理想。反过来，如果芯片唤醒要几百毫秒，占空比就会跳到百分之几，电池寿命立刻崩掉。

低功耗唤醒的另一个机制是RSSI门限唤醒。节点可以配置一个RSSI阈值，当信道上有超过阈值的信号出现时才触发中断唤醒主控MCU，这比纯粹定时唤醒响应更快，适合安防里门磁、人体探测器这类事件型设备。实际用下来，这套机制配合事件型上报能显著降低平均功耗。

2.3 开发接口与数据包格式：SPI控制与GDO中断

GDS3260的外围接口是标准4线SPI，搭配CSN、SCLK、MISO、MOSI，以及GDO0、GDO1、GDO2三个通用数字输出引脚。GDO可以配置成多种用途，比如前导码检测、同步字检测、RX数据包接收完成、TX发射完成、FIFO水平中断、RSSI采样完成等。这些中断信号直接连接到MCU外部中断引脚，可以避免MCU在睡眠状态反复被SPI轮询，这是低功耗设计的关键。

芯片内置了收发FIFO和完整的数据包引擎。工作在包模式时，可以自动完成前导码、同步字、CRC16的添加和校验，支持白化、交织、曼彻斯特编码，还支持AES-128硬件加密。从软件角度看，收发一个数据包的流程比直接模式省很多事，MCU只需要配置好包长和内容，写FIFO，然后等GDO中断就行。

我习惯把初始化流程分成三步：第一步配置频率和调制参数；第二步配置数据包格式，包括前导码长度、同步字、CRC和加密选项；第三步配置GDO中断映射和发射功率。建议开发初期就把这三个环节做成独立接口函数，后面调试不同速率和频段时只改参数，不用反复理代码，效率会高很多。

3. 安防场景选型要点：报警类设备最怕的丢包和误报

3.1 无线门磁与紧急按钮：休眠唤醒型和事件型工作模式

安防产品里数量最大的是无线门磁和紧急按钮，它们共同的特点是平时完全静默，只在门开合或按钮被按下时发出一个很短的报警帧。这类设备用GDS3260时，我一般建议采用事件唤醒加发送确认的工作模式：MCU平时跑最低功耗状态，门磁传感器触发后拉高MCU中断，MCU启动GDS3260完成初始化并发送一个带包序号、设备ID和时间戳的报警帧，然后等待主机端回ACK，收到ACK后立刻重新进入休眠。

这里有个容易被忽略的细节：报警帧的数据速率不要追求太高，一般1.2k到10kbps就够用。速率越低，接收灵敏度越高，链路预算越大，对穿墙越有利。门磁通常位于门窗边缘，离报警主机可能隔着两到三堵墙，低速率配置能明显提高报警成功率。实测中我用1.2kbps和50kbps各跑过上百次开关门，低速配置的失败重传次数明显更少。

紧急按钮稍有不同，它比门磁更强调实时性，用户按下去之后希望几秒内完成上报和确认，而且不允许漏报。务实的做法是发送端做三次自动重发，帧与帧之间随机延时几毫秒，配合报警主机的并发监听。这套机制在GDS3260上实现不复杂，利用发射完成中断和软件定时器就能完成，但要注意重发间隔不要太短，否则网络里多个按钮同时报警时碰撞率会急剧上升。

3.2 周界探测器与报警主机：多节点并发与通信协议重传

从Demo板跑到项目落地，报警主机这边的压力比终端大得多。一个主机可能同时接几十个探测器，某个区域发生入侵时可能多个探测器同时触发，这时信道上是并发的小帧风暴。如果每个探测器都无脑重发，很容易互相踩踏，导致主机收包成功率下降，严重时引发误报和漏报连锁反应。

所以我在探测器软件里一定会做三件事：发送前CCA信道空闲评估、随机退避、重发次数限制。CCA是指在发之前先通过GDS3260的RSSI读一下信道，如果已经有人占用就延迟发送；随机退避是让所有节点不会在同一时刻再次尝试；重发次数限制在3到5次，避免节点在严重冲突时无限重发耗尽电池。这套机制虽然简单，却能把并发场景下的收包成功率从百分之六七十拉到95%以上，收益非常直接。

报警主机端的射频配置也有讲究。探测器分布在远近不同位置，有的在30米外穿过两堵墙，信号很弱，有的就在隔壁房间，信号极强。主机的AGC和RSSI自动量程管理要开启，避免近端强信号导致接收饱和、远端弱信号被淹没。GDS3260的AGC表现中规中矩，打开后实测近端0米和远端150米交替通信都能保持一致的误码表现，这对安防报警这种可靠性要求极高的场景非常重要。

3.3 安全设计：AES-128加密与抗重放攻击

安防场景还有一个容易被忽视的刚需：安全性。门磁和报警按钮都是通过无线发送的，如果不做加密和抗重放，别人拿一套简易接收设备就能伪造报警帧，甚至实现开窗不报警这种攻击。GDS3260内置AES-128硬件加密，可以在链路层直接加密数据包，省掉软件实现加密的算力和功耗开销。

我做项目时会坚持三件事：一是用AES-128对数据payload做加密，密钥由设备唯一ID和项目级密钥派生出来；二是每个报警帧带单调递增的序列号，接收端维护滑动窗口，丢弃序列号过旧的包；三是关键设备ID用CRC或MAC校验保护，防止被篡改。同步字本身可以做成私有序列，增加被盲扫到的概率。

这三层设计在GDS3260上都有硬件或软件基础。AES加密是内置的，序列号校验是数据包引擎里CRC之外的附加逻辑，实现成本不高。虽然实际产品因为成本压力经常简化安全设计，但我每次都会建议客户至少保留AES加密和序列号校验，否则一套安防系统连最基本的防伪造能力都没有，真出事会很被动。

4. 三表抄表场景选型：电池寿命、金属环境与并发上报才是真考题

4.1 水电气表的使用环境与频段选择差异

三表指的是水表、电表、燃气表，虽然都叫表，环境差异却极大。水表最常见的位置是楼道地下管井、水表箱，外壳可能是塑料或金属，井盖常常是铁质。燃气表几乎都会装在金属外壳内，表体本身又往往贴着金属燃气管线，天线周围全是导体，环境最恶劣。电表则安装在强电箱、配电柜里，附近有220伏甚至380伏线路，工频干扰大，电流回路瞬间的辐射噪声才是最难处理的。

频段选择上，433MHz在很多地方使用成熟，设备共存问题相对小；470MHz部分区域用于电力集抄，做电表产品要特别注意邻道占用；868和915MHz更多出现在出口项目里，覆盖面积比433稍小一点，但天线尺寸短、模块可以做得更紧凑。GDS3260同时覆盖这几个频段的实用价值在于，同一套硬件方案改几个配置寄存器就能切换频段，对ODM厂商复用设计很有意义。

这里必须强调一句：三表产品的天线周围环境，往往比射频芯片本身的参数更能决定通信效果。在金属燃气表箱里，再好的芯片也救不了被导体压死的天线。所以做三表产品，结构设计初期就要把天线净空和外壳材质纳入评估，不要等硬件做完了再回头改壳子。

4.2 电池十年寿命的账：睡眠电流和占空比的分配

三表行业对电池寿命的要求已经卷到十年以上，很多项目直接按一次锂电池或两节ER18505电池的容量上限来设计。GDS3260这类收发芯片在系统里的耗电占比其实不算高，真正决定寿命的是整机平均电流。以一只每天抄表两次、每次上报一次的表为例，假设每天总活跃通信时间不超过一秒，平均电流由三部分组成：休眠期静态漏电、醒来后MCU和射频工作电流、定时唤醒的边际开销。

我习惯用月为单位做粗算：整机正常工作的平均电流如果能控制在50uA以内，一颗容量2000mAh的锂电池按80%可用率计算，理论寿命只有3到4年。要支撑8到10年，平均电流必须压到20uA以下，这意味着射频芯片的休眠电流、唤醒后的快速启动时间、发送后快速关断这几项都要逐一优化。

具体到GDS3260，0.5uA的深睡电流在整机静态里是可以接受的，但MCU选型也要同步低功耗，别让MCU休眠模式下的微安级电流成为大头。发送一个50字节的帧，+20dBm、10kbps，空中时间约40ms，平均电流约80mA，等效下来一次发送折合约0.9mAs。加上每60秒一次的下行监听窗口，一个月累计也就几十mAs，整体可控。真正的坑在于频繁的周期唤醒没有合理调度，导致射频反复重启、MCU反复处理中断，平均电流悄悄翻好几倍。

4.3 一台集中器带几百只表：如何处理好并发上报

集中器带表的规模，少则几十只，多则五百只以上。每天定时的集中抄表时刻，几乎所有的表都会在同一段时间醒来，这时信道上的并发压力非常真实。GDS3260这类单信道窄带收发芯片，同时刻只能有一个节点成功发送，冲突处理全靠上层协议。

我的工程建议是分层错峰：集中器在下行广播里携带时间偏移，让每只表根据自身编号计算不同的上报时间，把几百只表错开到比如30分钟内均匀分布，实际吞吐压力会被大幅稀释。GDS3260的RSSI可以帮助终端做CCA，发送前先看看信道忙不忙。在规模较大的集抄项目里，很多人会主动采用更低速率如1.2kbps，虽然单帧空中时间变长，但灵敏度更高、误码率更低，整体成功率反而上升。

如果节点规模特别大，或者需要支持实时在线，就要考虑伪随机时隙或ALOHA重传机制。好在GDS3260的包引擎支持自动CRC、自动收发，重发逻辑虽然在MCU实现，但底层机制已经省掉大量开发量。核心思路是让每个节点有意识地避开，而不是指望射频芯片自己解决碰撞，这才是大规模集抄稳定性的基石。

4.4 协议选择：私有协议与开放标准的取舍

三表抄表协议是个聊不完的话题。有些团队喜欢自组一套简单的帧格式，设备ID加功能码加数据加CRC，开发快、调试直观，但后续扩展和跨厂商兼容会有麻烦。有些则坚持用开放标准协议，海外水气表常用无线M-Bus的思路，国内一些集抄项目也参考标准帧结构。

从芯片能力看，GDS3260支持到300kbps的数据速率，开放标准协议的低速模式默认在19.2kbps左右，完全覆盖。我更推荐在有明确开放平台要求的项目里直接挂标准协议栈，而不是自己做私有协议。虽然前期要多写一些协议解释代码，但后面接集中器、跟其他厂商设备互连时的成本会低很多。

私有协议也不是一无是处，尤其当网关侧多种传感器上报、报警数据、远程控制指令混跑一张网时，自组协议更容易按业务切分帧类型。务实的做法是：物理层和链路层通信用芯片的包模式打好底，统一帧封装，应用层协议放给上层自己订，这样既保留灵活性，又不会把标准化空间完全堵死。

5. 选型路上最容易被忽略的五件事：天线、晶振、匹配网络、Layout与实测

5.1 天线选型与净空区要求

再好的收发芯片，天线匹配没做好也白搭。GDS3260的射频输出按参考设计做外部匹配网络，把输出阻抗调整到50欧姆，然后接天线。天线形式要根据外壳尺寸来：体积允许时，433MHz可以用弹簧天线或SMA鞭状天线；体积受限时只能做PCB天线，但天线效率会大打折扣，带宽变窄，金属结构靠近时失谐非常明显。

我的建议是：空间允许时优先用尺寸充足的外置弹簧天线；空间紧张时至少保证天线远离金属外壳和密集走线区，净空区尽量留足。所谓净空区，就是天线周围不要有地铜、不要有密集信号线、不要有金属支架，通常至少需要几十毫米见方的干净区域。这个要求在中低端产品里经常被工艺结构挤掉，现场表现就会差很多。

测试天线的底线指标是反射损耗S11，要求在工作频段内小于-10dB。开发阶段一定要用网络分析仪实际看S11曲线，不要只凭模块天线座到天线的线长猜匹配是否到位。天线失配时想靠软件调功率补偿回来，基本是补不回来的。

5.2 晶振精度与AFC配置

GDS3260需要外部提供参考时钟源，通常用无源晶体做低成本方案，或者用TCXO做高精度方案。无源晶体的优点是便宜、功耗低，缺点是频率误差受温度影响较大，特别是在零下20度到零上60度整机工作范围里，误差可能达到几十个ppm。

在433MHz频段，1ppm的频率误差换算到载波大约433Hz。如果不做AFC，发射机和接收机之间的频偏会导致灵敏度明显下降。GDS3260的AFC功能可以自动修正频偏，我在实际项目中会强制开启AFC，并且把AFC评估窗口设在前导码期间，这样可以在同步字接收前把频偏修正完。

用TCXO时，虽然成本上升，但频率稳定性好，尤其适合多通道跳频或者多台设备密集共存的项目。选型逻辑其实很直接：单频点低速通信用无源晶振配AFC足够；多频点、跳频、高速率，用TCXO更省心，能省掉很多现场排查频偏的精力。

5.3 匹配网络和前端滤波：别光抄参考设计

参考设计里的匹配网络参数，是厂商在特定测试板上测出来的，实际产品不可能原封不动照搬。GDS3260发射端在+20dBm功率下，谐波需要靠外部低通滤波器压住，否则整机测发射谐波时很容易超标。大多数方案会在匹配网络里串联一个LC低通，或者在PA输出后加外部滤波器。

匹配网络调试顺序我一般是：先用网络分析仪把输出调到50欧姆附近，再用频谱仪看发射功率和杂散，最后做接收灵敏度全链路测试。如果发射功率上不去、接收灵敏度又差，多半是匹配网络失谐；如果单单发射正常但接收差，要考虑前端滤波器的插入损耗是不是太大，以及匹配网络是否偏向了发射端。

这些工作看起来繁琐，却是整机和模块质量的真正分水岭。所以选型时要格外看重厂商是否提供完整的参考设计、S参数和PCB封装库，而不只是参数表漂不漂亮。打样之前把参考设计吃透，后面会少走很多弯路。

5.4 PCB Layout的地平面与电源去耦

Sub-1G射频部分对PCB布局要求没有2.4G那么苛刻，但也绝不是随便布线就能跑通。GDS3260的QFN封装底部有暴露焊盘，这个焊盘必须良好接地到主地平面，射频走线尽量短而直，避免穿过数字时钟区域。天线馈线附近不要走SPI、I2C、UART这些高速走线，以免数字噪声耦合进射频通路。

电源去耦方面，射频功放瞬间电流接近100mA，如果电源线内阻偏大、去耦电容离引脚太远，发射瞬间的电压跌落会导致发射功率波动和杂散恶化。我习惯在电源引脚附近放一组100nF陶瓷电容加10uF钽电容，模拟地和射频地单点连接。晶振底下铺地，不要走其他信号线，减小杂散耦合。

对新手，建议第一次打板直接抄芯片原厂参考设计的布局和叠层，不要自己做创新分区。等射频指标全部正常，再考虑优化布局和压缩尺寸，否则一旦调不通，很难区分是芯片问题还是Layout问题，排查成本非常高。

5.5 低功耗测试方法：电流曲线比万用表更可靠

最后说低功耗测试。很多人调试低功耗产品时拿万用表量平均电流，这是一种极其不可靠的方式。射频芯片工作时的电流是脉冲式的，休眠时0.5uA、发射时最高接近100mA，万用表的积分式读数会把这种动态电流平滑掉，测出来的数值完全不能反映峰值和持续时间。

正确做法是使用电流探头或者低端电阻并联示波器，抓取完整的电流波形。我会把整个设备的工作周期分成几个阶段：休眠、MCU唤醒、射频初始化、前导码发送、数据帧发送、等待ACK、关闭RF、重新进入休眠。每个阶段的电流和时间都单独看，哪一段耗时异常长或电流异常高，一眼就能发现。

另外还要用频谱仪配合验证射频实际发射时间，因为软件设置的发送时长和硬件实际占用的信道时间可能不一致，这个差异直接影响整机平均电流和信道占用率。我遇到过某客户软件里做了三次重发，但没有管理好重发之间的复位流程，MCU每次都从完整复位跑起，单次事件处理时间从预期的20ms膨胀到400ms，电池寿命直接腰斩，这类问题只有电流曲线才能暴露出来。

6. 竞品对比与实测数据：GDS3260到底处于什么水平

6.1 几张参数表看完定位

为了更有参考价值，我把几款常见的Sub-1G收发芯片放在一个表里对比。注意对比只代表典型值，实际性能和PCB布局、天线、温度都有关，大家看参数时不要只盯绝对值，要看是否符合自己产品场景的权重。

单看这张表，CC1310是集成MCU的方案，做小型节点时可以省一颗主控，但+14dBm的最大发射功率在远距离穿墙场景下略显吃力。SI4438和CMT2300A在低功耗和发射功耗上有优势，GDS3260则在灵敏度和发射功率上表现均衡，尤其适合安防这类需要长距离加高可靠覆盖的节点。

我不太建议只按表格做一票定生死的选型。真正影响成败的是SDK质量、厂商支持响应、供应链稳定性、参考设计完整度，以及功耗和性能在温度、湿度、老化之后的偏移。GDS3260给我的印象是性价比和开发效率取向的选择，技术文档和参考案例都比较贴近实际项目，适合中小团队快速落地。

6.2 实测覆盖与穿墙能力数据

这次评估我搭了一套最简单的实测环境：节点端用GDS3260模块，1.2kbps、GFSK、+20dBm、433MHz，接收端同样用GDS3260模块加弹簧天线。测试地点是一栋六层框架结构民居，节点放在一楼楼道角落，接收端分别在开阔地、隔一堵墙、隔两堵墙、隔三层楼板四种条件下测试。

开阔地直射场景，实际通信距离能稳定到800米左右，再远就开始出现明显丢包。隔一堵砖混墙，距离收缩到约200米还能稳定收包。隔两堵墙，150米左右可以收包但丢包率开始上升。最差的是节点放在地下室、主机在三楼，中间穿越三层楼板和若干管道层，只有部分时刻能收到，需要设备靠近窗边或使用外置天线才可靠。

这个数据说明了一个经常被低估的事实：实际建筑环境中，楼板和墙体的损耗远比比自由空间公式估算的严重，尤其当墙体里有钢筋网、管线或者保温层时，效果差异巨大。所以我会坚持要求客户在选型阶段提供现场环境照片或实测点位，而不是拍脑袋承诺一个覆盖距离。

6.3 我的选型结论和配置代码参考

综合看下来，GDS3260在安防、三表场景中的定位很清晰：一颗性能均衡、开发成本低、上手快的Sub-1G收发芯片，适合不想被SoC方案MCU资源绑死、又有一定射频调试能力的团队。如果项目对体积极其敏感，集成MCU的SoC方案可能更划算；如果追求极致超长寿命低功耗，一些在深睡电流和RX电流上做极端优化的芯片也可以考虑。但绝大多数安防和三表节点，GDS3260这个规格足够，而且留出了不错的链路余量。

最后附上我在GDS3260上常用的初始化配置参考，433MHz、10kbps、GFSK、+20dBm，可以直接套到工程里跑通再调：

// 伪代码，按实际SDK接口调整 rf_reset(); rf_set_frequency(433920000); // 433.92MHz rf_set_power_level(20); // +20dBm rf_set_modulation(MOD_GFSK, 10000); // GFSK 10kbps rf_set_rx_bw(50 * KHZ); // 接收带宽与当前速率匹配 rf_set_packet_format(PACKET_MODE, 50);// 包模式，50字节轻包 rf_set_preamble(4); // 4字节前导码 rf_set_sync_word(0x2DD4); // 私有同步字 rf_enable_afc(1); // 开启AFC自动频率校正 rf_enable_crc(CRC_16); rf_set_gdo_mapping(GDO0, RX_PACKET_DONE); rf_set_gdo_mapping(GDO1, TX_PACKET_DONE);

每次在现场收包之后，记得把RSSI寄存器数值打出来存日志，双向收包的信号强度数据是后续定位覆盖问题最可靠的第一手资料。我每次做完一个Sub-1G项目都会把现场RSSI日志保留下来，下次同类项目选型和天线改动时直接拿来对照，省掉大量重复测试。希望这篇选型体感和踩坑记录能帮上正在做类似产品的朋友。