低于 1GHz（参考译文帖）(Read Only) - 最近的话题

[参考译文] CC1201：CC1201 调制格式 2-GFSK RX 和 2-FSK TX

admin — Thu, 30 Jul 2026 22:32:01 GMT

Other Parts Discussed in Thread: CC1201

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1669244/cc1201-cc1201-modulation-formats-2-gfsk-rx-and-2-fsk-tx

部件号： CC1201

我一直在开发测试中与 CC1201 合作、我想看看是否有人在使用对讲机的不匹配调制模式时遇到了改进的链路关闭和减少的数据包丢失。似乎当我在 TX 中使用 2-FSK、在 RX 中使用 2-GFSK 时、在监控数据包丢失率时、我名义上将器件之间的连接提高了 1-5%。

例如：

625kSPS 833.33kHz RX 滤波器 BW 189.81kHz 偏差 2-GFSK RX / 2-FSK TX ~1%数据包丢失

625kSPS 833.33kHz RX 滤波器 BW 189.81kHz 偏差 2-GFSK RX / 2-GFSK TX ~5%数据包丢失

625kSPS 833.33kHz RX 滤波器 BW 189.81kHz 偏差 2-FSK RX / 2-FSK TX ~2%数据包丢失

[参考译文] CC1311R3：1.8V 和 3.3V 电源之间的最大传输功率是否存在差异

admin — Thu, 30 Jul 2026 14:17:31 GMT

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1669159/cc1311r3-is-there-a-difference-in-maximum-transmission-power-between-1-8v-and-3-3v-power-supply

部件号： CC1311R3

尊敬的 TI 工程师：

您能否帮助确认 1.8V 和 3.3V 电源之间的最大传输功率是否存在差异？

从数据表中、我们可以得知 VDDR = 1.95V 时的最大输出功率为 14dBm

谢谢、

此致

[参考译文] CC1312R：CC1312R 射频通信：如何实现固定长度通信

admin — Thu, 30 Jul 2026 08:25:29 GMT

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1668995/cc1312r-cc1312r-rf-communication-how-to-implement-fixed-length-communication

器件型号： CC1312R

我们正在努力更大限度地缩短射频通信时间。
作为这项工作的一部分、我们试图通过减小正在传输的数据包的大小来缩短射频通信时间。
我们将使用 TI 提供的标准数据包格式进行射频通信。
我们计划通过消除标准数据包格式中的“长度字段“（即，将其设置为 0 字节）来减小数据包大小。
我们认为、将数据包大小设置为固定长度 (bVarLen=0) 可以消除“长度“字段、因此我们测试了此配置；虽然数据包确实到达接收器、但内容与预期值不匹配。
我们目前正在调查此问题的原因。
接收的值与预期值不同的一个可能原因是发送方未能传输预期值。
我想验证如何在发送方侧配置`Ω pktLen`。
将`Ω pktLen`设置为数据包数据大小是否正确？
对于以下配置 — 前导码：4 字节、同步字：3 字节、有效载荷：5 字节、固定长度通信（长度字段）：0 字节、禁用地址过滤（地址）：0 字节、CRC：2 字节 — 将 pktLen 设置为 14 字节是否正确？

[参考译文] CC1352P：在 11.25kHz 带宽内针对 9600bps 的 CC1352 设置

admin — Tue, 28 Jul 2026 14:28:36 GMT

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1668312/cc1352p-cc1352-settings-for-9600bps-within-11-25khz-bandwidth

器件型号： CC1352P

大家好
我尝试找到适合 9600bps 的 CC1352 设置以适应 12.5kHz 通道。
允许的带宽为 11.25kHz

我预计需要 4GFSK、但我无法确定要设置的设置。

我正在寻找具体的偏差数值。

如果我应用 Carsons 规则与此,我得到:

符号速率= 4800
BW = 2*（Deviation+符号速率）-> BW = VDI/2 — 符号速率= 825kHz
这是正确的吗？

[参考译文] CC1352P7：申请 PCN 和 CC1352P7 器件修订版本更改的说明–CC1352P74T0RGZR

admin — Mon, 27 Jul 2026 21:58:18 GMT

Other Parts Discussed in Thread: CC1352P7

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1667972/cc1352p7-request-for-pcn-and-clarification-of-cc1352p7-device-revision-change-cc1352p74t0rgzr

器件型号： CC1352P7

我们确定了最新发货中收到的 Texas Instruments CC1352P7 器件的顶部标识有所不同。
完整订购器件型号：CC1352P74T0RGZR 先前的器件标识：CC1352 P74 TI 5B8 B【批次追踪代码】新器件标识：CC1352 P74 TI 5C8 C【批次追踪代码】根据 CC1352P7 器件勘误表中提供的器件标识信息、最终字母似乎表示器件修订代码。
我们之前的材料标有修订代码 B、而最新材料标有修订代码 C。您可以将此申请升级至您的产品质量团队和 Texas Instruments FAE 或产品线代表吗？在将该材料发布用于生产之前、我们需要以下信息：
1.确认最终字母 B 和 C 表示不同的器件或器件修订版本。 2.与器件修订版本代码 C 对应的器件 PG 修订版本
3.与此修订版本更改相关的官方 PCN、PCN 编号或其他变更通知。
4.详细比较器件版本 B 和 C
5.更正、修改或保留适用于修订版 C 的修订版 B 器件勘误表公告的确认
6、确认形式、适用性、功能和软件兼容性。
7.确认任何影响的更改： — 器件 ROM 或引导加载程序 — 射频性能和射频修整- PA 输出功率 — 接收器灵敏度-功耗 — ADC 或电源管理行为 — 编程过程- SimpleLink SDK 兼容性 — 制造测试限制或校准要求
8、修订版 C 的鉴定结果或增量鉴定文档。9. 无需客户额外批准即可确认修订版 B 和修订版 C 材料是否可以在同一生产构建中混合。还请确认是否应通过产品变更通知传达此变更。随附之前和新器件标识的照片、以及卷带和运输标签信息。
此致、

[参考译文] CC1312R：CC1312R：power_idleFunc

admin — Mon, 27 Jul 2026 00:55:16 GMT

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1667580/cc1312r-cc1312r-power_idlefunc

器件型号： CC1312R

我正在使用我之前作为基础收到的示例代码、`在 Δ V Power_idleFunc ()`期间发生 1mA 电流消耗的问题。

我使用的是 LAUNCHXL-CC1312R1。
将代码配置为进入待机模式并仅通过按下按钮唤醒、
在大约三天的时间内未观察到异常电流 (1mA)。

现在、我正在修改代码以使计时器模块保持激活状态后进行进一步的测试。

一段时间
以来、我一直想知道有一种现象：从计时器中断启动到中断实际触发、大约需要 340ms。
我已经通过使用示波器监测端口 TP1 (DIO28) 和 TP2 (DIO27) 来专门验证了这一点。
这种行为是否可以解释？ 我将提供实际代码。
请告诉我、我在如何初始化或停止计时器时是否有任何错误。

sleepTest1.zip

[参考译文] CC1352R：查找 libclang_rt.builtins.a 源文件

admin — Mon, 20 Jul 2026 15:01:20 GMT

Other Parts Discussed in Thread: CC1352R

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1665851/cc1352r-locating-libclang_rt-builtins-a-source-files

器件型号： CC1352R

我正在开发使用 CC1352R 的产品。
对于我使用的 SDK 版本：simplelink_cc13xx_cc26xx_SDK_8_30_01_01
CCS 版本：12.8.1

我的工程在 SDK 捆绑的以下 llvm clang 库中进行链接：

TI\ccs1281\ccs\tools\compiler\cti-cgt-armllvm_3.2.LTS \lib\clang/15.0.7/lib/armv7em-ti-none-eabihf/libclang_RT.builtins.a

在.map 文件中包括以下文件/对象：
udivmoddi4.S、aeabi_uldivmod.S、 aeabi_memset.S、aeabi_memcpy.S 、 aeabi_DIV0.c

由于产品的认证级别、我想直接链接它们、而不是链接包含这些对象的库...
您能否将我指向 GitHub 和/或发送这些文件的位置？

[参考译文] CC1200：CC1200 进入 RX_FIFO_ERROR

admin — Fri, 17 Jul 2026 22:31:09 GMT

Other Parts Discussed in Thread: CC1200

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1665509/cc1200-cc1200-entering-rx_fifo_error

部件号： CC1200

您好：

我注意到有时 CC1200 会进入 RX_FIFO_ERROR 状态。检查 MODEM_STATUS1 字节确认这是由 RXFIFO_OVERFLOW 引起的。

我正在使用 CRC_OK GPIO 信号触发从 FIFO 中读取 (CRC_AUTOFLUSH = 1)、来自该 FIFO 的数据包内容似乎正常。从我注意到的 fifo 中读取所有完整的数据包后立即读取 NUM_RXBYTES、有时 fifo 中有 128 个字节。这始终是自前一个 NUM_RXBYTES 读取以来从 0 或较少字节数跳转。

此外、这种行为仅在无线传输有数据包时发生。

感谢您提供有关调试此问题的任何帮助

更新：我注释了我的代码中与 CAN 总线传输相关的不同部分、这会停止该行为。我猜是以某种方式阻止微控制器耗尽 FIFO 吗？

[参考译文] AM3358：使用 AM335x RGMII 的 DP83867：通过 MDIO 检测到 PHY、但载波保持 0 /无链路

admin — Thu, 16 Jul 2026 13:44:17 GMT

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1665016/am3358-dp83867-with-am335x-rgmii-phy-detected-over-mdio-but-carrier-remains-0-no-link

部件号： AM3358

TI 团队大家好、

我们将在 RGMII 内部延迟模式下使用 TI DP83867 以太网 PHY 启动一个定制 AM335x 电路板。 Linux 通过 MDIO 正确检测到 PHY、但以太网链路永远不会出现。

硬件和软件上下文：

处理器：AM335x
PHY：TI DP83867
接口：RGMII
PHY 地址：0
内核：Linux 6.1.46 自定义 BuildRoot

以太网器件树设置基于有效的 BeagleBone Green Eco 设计。相关设置包括：

phy-mode = "rgmii-id"
ti,rx-internal-delay = <0x09>
ti,tx-internal-delay = <0x09>
ti,fifo-depth = <0x03>
ti,min-output-impedance
ti,dp83867-rxctrl-strap-quirk
PHY reg/address = 0

Linux 日志：

davinci_mdio 4a101000.mdio: phy[0]: device 4a101000.mdio:00, driver TI DP83867
cpsw-switch 4a100000.switch: initialized
cpsw-switch 4a100000.switch: Detected MACID = 84:bb:26:cb:9b:14
cpsw-switch 4a100000.switch: starting ndev. mode: dual_mac
TI DP83867 4a101000.mdio:00: attached PHY driver (mii_bus:phy_addr=4a101000.mdio:00, irq=POLL)

接口保持此状态：

eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP>
carrier = 0
operstate = down

dmesg 中没有“Link is up“消息。

使用 phytool 观察 PHY 寄存器：

BMCR register 0x0 = 0x1140
BMSR register 0x1 = 0x7949
PHY ID register 0x2 = 0x2000
PHY ID register 0x3 = 0xa231
ANAR register 0x4 = 0x01e1
ANLPAR register 0x5 = 0x0000
1000BASE-T control register 0x9 = 0x0300
1000BASE-T status register 0xA = 0x0000

我们还禁用 1000BASE-T 广播并仅测试了 10/100 操作。

Register 0x9 changed from 0x0300 to 0x0000
Register 0x4 remained 0x01e1
carrier still remained 0
ANLPAR register 0x5 still remained 0x0000

因此、即使 10/100 链路也无法完成。

硬件检查已完成：

PHY 电源轨正常。

VDDIO is about 3.3 V
VDDA is about 2.5 V
VDD is about 1.0 V

释放 PHY 复位。

RESET_N is about 3.3 V

存在晶体和时钟。

XI/XO are about 25 MHz

RBIAS 最初为 12k Ω。我们将其更改为 11k Ω、1%。链路行为没有变化。通电时的 RBIAS 引脚电压约为 1.0V

RX_CTRL 串联电阻器缺失。我们暂时短接或填充该路径以进行测试、但链路行为没有变化。

未使用 PHY 中断。 Linux 报告 IRQ=POLL。

已检查 RJ45/MagJack 对映射。

同一电缆和开关端口可与也使用 DP83867 的 BeagleBone Green Eco 板配合使用。

在定制电路板上、我们可以在带有示波器的 PHY 和 MagJack 端看到活动或脉冲、但链路仍然没有完成。

集成 MagJack 信息：

原理图/BOM 参考看起来是 Abracon ARJM11A1-502-JJ-EW2。

定制电路板上实际安装的器件标识看起来是 Abroron ARJM11B1-8054BEW2。它可能来自 ARJM11B1-805-AB-EW2 系列。

这是一款具有磁性元件和 LED 的集成式 RJ45 MagJack。

已检查 RJ45/MagJack 对映射、但我们仍然不确定 MagJack 共用、VCC 或中心抽头连接是否正确可与 DP83867 配合使用。

问题：

由于通过 MDIO 检测 PHY 并连接 Linux 驱动程序、但 ANLPAR 为 0x0000 且载波仍然为 0、因此我们接下来应该重点关注哪些 DP83867 硬件区域？
我们是否应读取特定的 DP83867 自举引脚或寄存器、以确认 PHY 处于正确的 RGMII 模式、而不是处于测试模式、断电模式或隔离模式？
对于 DP83867、INT_PWDN 上拉缺失或弱是否仍无法进行 MDIO 检测、但仍会妨碍可靠的链路完成？ INT_PWDN 网络在没有外部上拉电阻器的情况下测量约 2.45V 的电压。
对于集成式 Abroron MagJack、是安全还是需要从 PHY 模拟电源对任何 MagJack 公共、VCC 或中心抽头引脚进行偏置？或者、这些引脚应该只遵循 MagJack 供应商的参考电路吗？
MagJack 型号不匹配、尤其是不同的内部共模或中心抽头引脚分配、是否会导致出现以下症状：通过 MDIO 检测到 DP83867、但未收到链路伙伴能力？
如果要调试 DP83867 上的无载波或无链路问题、TI 会建议执行哪些额外的 PHY 寄存器转储？

谢谢你

[参考译文] CC1312R7：Wi-SUN 欧洲自适应电源控制

admin — Wed, 15 Jul 2026 19:09:57 GMT

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1664689/cc1312r7-wi-sun-europe-adaptive-power-control

器件型号： CC1312R7

我们需要通过 ETSI EN 300 220 的认证

根据 Wi-SUN FAN 规范 (20210201-FANWG-FANTPS-1.1v10)、Wi-SUN 器件需要支持自适应电源控制 (APC)。 TI Stack（从 SDK 8.33 开始）是否对此提供任何支持？

应用是否可以检测它跳转到的频率并根据需要向 Mac 层发送设置的电源命令？

我是否需要启用其他 otpions 才能获得欧盟认证？

[参考译文] CC1352P7：蓝牙和 Wi-SUN

admin — Tue, 14 Jul 2026 12:39:28 GMT

Other Parts Discussed in Thread: LP-CC1312R7, CC1312R7, CC1352P7

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1664116/cc1352p7-bluetooth-and-wi-sun

器件型号： CC1352P7
主题中讨论的其他器件： CC1312R7、

只是想知道,可以蓝牙和 wi-sun 同时工作,还是我必须停止双广告之前,我启用 wi-sun 开始广播. 找不到是否有针对此问题提出的 TT、所以我在这里提出了

非常感谢

Roshan

[参考译文] CC1312R：CC1312R 上支持无线 M-Bus、用于日本 920MHz 频带

admin — Tue, 14 Jul 2026 08:31:56 GMT

Other Parts Discussed in Thread: CC1312R

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1663993/cc1312r-wireless-m-bus-support-on-cc1312r-for-japanese-920-mhz-band

器件型号： CC1312R

尊敬的专家：

我们正在评估用于日本智能计量应用的 CC1312R。

根据 TI 文档、无线 M-Bus 堆栈支持欧洲 868MHz、433MHz 和 169MHz 频带。我们找不到有关日本 920MHz 频段操作的信息。

您能否澄清以下几点？

1.是否可以将 TI 无线 M-Bus 堆栈 (OMS v4.1.2) 配置为在 CC1312R 上的日本 920MHz 频段中运行？

2.如果开箱即用不支持 920MHz 操作:

-是否有任何推荐的迁移路径?

-现有的无线 M-Bus 堆栈源/框架是否可以作为一个起点被重复使用?

3.在 920MHz 频段中运行是否只需要更改射频参数,或者是否存在阻止此类迁移的协议/堆栈限制?

4. TI 或 Stackforce 是否曾在标准 868/433/IEEE 169MHz 频带以外的频带上支持或评估过无线 M-Bus 实施？

5.是否有任何基于 CC1312R/CC1312P 且已获得在日本 920MHz 频带运行的无线电认证的 TI 参考设计、评估板、模块或客户设计？

6.如果客户想要在认证前评估日本的 CC1312R/CC1312P、TI 是否有关于评估板的使用和地区法规要求的任何建议？

我们的客户对日本的逐表读数感兴趣、并考虑将无线 M-Bus 作为候选协议之一。

最好的注意、

IBUKI ENDO

[参考译文] CC1352P7：连接时 BLE 栈崩溃

admin — Mon, 13 Jul 2026 10:22:59 GMT

Other Parts Discussed in Thread: CC1352P, CC1352P7, SYSCONFIG

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1663600/cc1352p7-ble-stack-crash-upon-connect

器件型号： CC1352P7
主题中讨论的其他部分： CC1352P、 SysConfig

您好、

e 已将我们的设计从 CC1352P 迁移到 CC1352P7。

基于 CC1352P 的原始器件正常运行、包括 BLE 广播和配对。

在基于 CC1352P7 的新器件上、BLE 广播按预期运行。但是、当 BLE 连接或配对开始时、器件会崩溃。

基于调试、崩溃发生在内部 llReplaceRxBuffers()。遗憾的是、的源代码 ble.c 不可用、因此难以进行进一步调查。

我们使用的是 SimpleLink SDK 版本 6.10.0.29。该产品已经投入大规模生产、因此目前无法升级到更新的 SDK。

请找到随附的 .map 文件以供参考。

llReplaceRxBuffers () 0x00044764ble.c366：1

llSetupConnRxDataEntryQueue() 0x00032D8Eble.c869：5

lll Adv_Task 连接 () 0x000082B8ll_Adv_End_Causes.c677:5

LL_ProcessEvent() 0x0000F062ll.c1339：5

OSAL_RUN_SYSTEM () 0x0001E3C4osal.c1778：5

OSAL_START_SYSTEM () 0x000474F6osal.c1494：5

STACK_MAIN () 0x000405F0osal_iCall_ble.c277：3

iCall_taskEntry () 0x00050318icall.c518：3

_memset_w () 0x1002DB9C

llSetupConnRxDataEntryQueue() 0x00032D8Fble.c869：5

_memset_w () 0x2000CE60

llSetupConnRxDataEntryQueue() 0x00032D8Fble.c869：5

0x000568D4

[参考译文] CC113L：OOK 不工作

admin — Mon, 13 Jul 2026 09:39:06 GMT

Other Parts Discussed in Thread: CC113L, CC1354P10, CC1101

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1663568/cc113l-ook-not-working

部件号： CC113L
主题中讨论的其他器件： TEST2、 CC1354P10

尊敬的 Champs：

我尝试将 OOK 消息从 LP-EM-CC1354P10-1 传输到定制 CC113L 定制板。为 433MHz。我知道这不是 LP 设计为最佳工作的频率。但这次测试不需要很长的距离。这些电路板在桌子上彼此非常靠近。

2 个 LP-EM-CC1354P10-1 电路板在测试中运行良好。 1 个发射、1 个接收。同样在 433MHz。但 CC113L 定制电路板无法收到任何消息。我在 CC113L 中检查了 RSSI 值。当发送器 (LP-EM-CC1354P10-1) 发送数据时、该参数最高可达–50dBm。停止传输时、CC113L RSSI 恢复到–90dBm。所以我想它可以检测到即将到来的无线电信号、但我不知道为什么它不能给出任何输出消息。

下面是 CC113L 的寄存器设置。 SmartRF Studio 7 生成的软件。由 MSPM0 MCU 写入 CC113L、并进行了验证。

我有一些问题需要您的帮助来解决：

上述测试案例是否可行？（LP-EM-CC1354P10-1 将 OOK 消息发送到 433MHz 处的 CC113L 定制板）
如果是、我应该检查/更改什么以使连接正常工作？

CC113L 设置：

IOCFG2 [0x00]= 0x29

IOCFG1 [0x01]= 0x2E

IOCFG0 [0x02]= 0x06

FIFOTHR [0x03]= 0x47

SYNC1 [0x04]= 0xD3

SYNC0 [0x05]= 0x91

PKTLEN [0x06]= 0xFF

PKT1L1 [0x07]= 0x04

PKTCTRL0 [0x08]= 0x05

地址 [0x09]= 0x00

CHANNR [0x0A]= 0x00

FSCTRL1 [0x0B]= 0x06

FSCTRL0 [0x0C]= 0x00

FREQ2 [0x0D]= 0x10

FREQ1 [0x0E]= 0xB0

FREQ0 [0x0F]= 0x71

MDMCFG4 [0x10]= 0xF7

MDMCFG3 [0x11]= 0x83

MDMCFG2 [0x12]= 0x3B

MDMCFG1 [0x13]= 0x00

MDMCFG0 [0x14]= 0x00

DEVIATN [0x15]= 0x15

MCSM2 [0x16]= 0x07

MCSM1 [0x17]= 0x30

MCSM0 [0x18]= 0x18

FOCCFG [0x19]= 0x16

BSCFG [0x1A]= 0x6C

AGCCTRL2 [0x1B]= 0x03

AGCCTRL1 [0x1C]= 0x40

AGCCTRL0 [0x1D]= 0x91

FREND1 [0x21]= 0x56

FSCAL3 [0x23]= 0xEF

FSCAL2 [0x24]= 0x2B

FSCAL1 [0x25]= 0x19

FSCAL0 [0x26]= 0x1F

TEST2 [0x2C]= 0x81

TEST1 [0x2D]= 0x35

TEST0 [0x2E]= 0x09

PARTNUM [0x30]= 0x00

版本 [0x31]= 0x18

MARCSTAT [0x35]= 0x0D

PKTSTAT [0x38]= 0x60

RXBYTES [0x3B]= 0x00

Tx 板的 CC1354P10 设置

smartrf_settings.h

smartrf_settings.c

此致、

Kien

[参考译文] LP-CC1312R7：100 个节点的内存使用情况

admin — Fri, 10 Jul 2026 08:52:15 GMT

Other Parts Discussed in Thread: LP-CC1312R7, CC1314R10, CC1312R7, SYSCONFIG

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1663138/lp-cc1312r7-memory-usage-with-a-100-nodes

器件型号： LP-CC1312R7
主题中讨论的其他器件： CC1314R10、 CC1312R7、 SysConfig

嗨、目前我使用的是 LP-CC1312R7、它具有 144kb 的 ram 和 704kb 的 flash、我们想测试一个具有 100 个节点路由器的边界路由器、是足够的 ram 来支持这些数量的节点。我已经检查了随 TI SDK 提供的边界路由器的示例固件。它已经使用了 96 %的 RAM ,我甚至没有任何连接到它。只是试图对是否升级到更高的内存版本进行欺骗。

[参考译文] CC1354P10：CC1354P10 的电压电源域

admin — Thu, 09 Jul 2026 11:21:11 GMT

Other Parts Discussed in Thread: CC1354P10, CC2640R2F

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1662776/cc1354p10-voltage-supply-domains-of-cc1354p10

部件号： CC1354P10
主题： CC2640R2F 中讨论的其他器件

大家好、E2E 专家：

我们将 cc1354p10 用于产品设计、并希望了解 vdds/vdds2/vdds3 的电压域、如 cc2640r2f 规范中所规定的那样。如下图所示。

此致、

公务员制度委员会

[参考译文] CC1312R：待机模式持续时间

admin — Thu, 09 Jul 2026 00:25:44 GMT

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1662556/cc1312r-standby-mode-duration

器件型号： CC1312R

我正在使用 simplelink_cc13xx_cc26xx 电源驱动器实现待机模式功能。
在设计为仅通过外部 IRQ 唤醒的应用中、如果没有接收到外部 IRQ、器件是否会无限期地保持待机模式（超低功耗状态）？
在待机模式的持续时间方面是否有任何限制？
我还在另一个线程中检查这一点、但我面临一个问题、即 1mA 电流在特定时间段内流动 — 这可能是与时间相关的因素造成的吗？

[参考译文] CC1352P7：在 CC1352P7 上同时运行 Sub-1GHz + Thread + Zigbee 的可行性

admin — Wed, 08 Jul 2026 09:14:14 GMT

Other Parts Discussed in Thread: CC1352P7, CC1354P10

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1662295/cc1352p7-feasibility-of-running-sub-1-ghz-thread-zigbee-concurrently-on-cc1352p7

器件型号： CC1352P7
主题中讨论的其他器件： CC1354P10

您好 TI 社区、

我们正在评估我们的一款产品的 CC1352P7、希望了解在单个应用中同时运行以下无线协议是否可行：

Sub-1GHz 专有应用
Thread（RCP 或完整线程器件）
Zigbee（RCP 或终端器件/协调器，取决于用例）

我们的目标是在同一 CC1352P7 器件上同时激活所有三个协议栈。

我们希望您能就以下问题提供指导：

在技术上是否可以在 CC1352P7 上的单一应用中同时运行 Sub-1GHz + Thread + Zigbee？
CC1352P7 上的可用闪存和 RAM 是否支持这种协议栈组合？如果不够、那么哪个变体更适合？
在实现此类解决方案时、是否有任何参考示例或推荐的软件架构？
预期的限制或权衡是什么（例如，射频调度，时序，存储器使用情况或协议性能）？
如果此配置不受支持、建议的方法是什么？例如、其中一个协议是否应该在单独的器件上实现为 RCP？

我们的应用要求同时提供所有三个无线接口、因此我们希望在最终确定硬件架构之前了解可行性。

感谢您的支持。我们期待着您的建议。
Hiren Bhuva.

[参考译文] CC1101：尽管 GDO0 中断生效并确认发送器正常工作、但 CC1101 RX FIFO 始终为空 (RXBYTES=0)

admin — Wed, 08 Jul 2026 06:57:23 GMT

Other Parts Discussed in Thread: CC1101

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1662224/cc1101-cc1101-rx-fifo-always-empty-rxbytes-0-although-gdo0-interrupt-is-asserted-and-transmitter-is-confirmed-working

部件号： CC1101

您好 TI 支持部门、

我正在处理一个大学项目、该项目使用两个连接到 CC1101 分线模块的 ESP32 DevKit V1 电路板。

已使用 RTL-SDR 验证发送器、并且射频突发已在 433.92MHz 处正确传输。

在接收器上：

MARCSTATE = 0x0D（RX 状态）
重复将 GDO0 中断置为有效
RXBYTES 始终报告 0
ReceiveData() 始终返回长度 0

由于 GDO0 指示数据包活动、而 RX FIFO 保持空、因此我想了解在什么寄存器级条件下可能会发生这种行为。

具体来说：

在没有任何字节进入 RX FIFO 的情况下、GDO0 是否可以置为有效？
这是否是由同步字检测、CRC 抑制、IOCFG 配置或电气噪声引起的？
为了区分错误的 GDO0 事件和有效数据包接收、我接下来应该检查哪些状态寄存器？

我可以根据需要提供完整的寄存器配置、初始化代码、SmartRF 设置、接线照片和串行日志。

谢谢你。

[参考译文] CC1352P7：有关 CC1352P7 微控制器的闪存电源故障保护机制的问题

admin — Tue, 07 Jul 2026 09:15:03 GMT

Other Parts Discussed in Thread: CC1352P7, UNIFLASH, CC1352P, CCSTUDIO

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1661847/cc1352p7-the-question-about-the-flash-power-fail-protection-mechanism-of-the-cc1352p7-microcontroller

器件型号： CC1352P7
主题中讨论的其他器件： UNIFLASH、 CC1352P、 CCSTUDIO

您好：

我需要重现一个问题、即在闪存写入或擦除过程中发生电源故障、然后进行上电复位后、微控制器在读取特定闪存区域时会重新启动。我可以确认、在闪存写入或擦除过程中成功发生了电源故障。我使用数字电源定期切断电源、电源故障的持续时间是随机的、以确保不会在同一时间发生。但是、目前我只复制了数据错误、而不是重新启动问题。我成功地重新启动的唯一情况是写入未擦除的区域。

我想问的是：如何重现这种情况？此外、CC1352P7 微控制器是否具有任何相关的闪存保护或验证机制？我在手册中找不到此信息。

[参考译文] CC1352P7：如何配置模式 2？

admin — Tue, 07 Jul 2026 06:21:42 GMT

Other Parts Discussed in Thread: CC1352P

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1661774/cc1352p7-how-to-configure-mode-2

器件型号： CC1352P7
主题中讨论的其他器件： CC1352P

您好、

在以下配置中、无法看到发送频谱；将.formatConf.nSwBits 从 0x40 修改为 0x20、CC1352P 接收器无法触发 RF_Callback 函数。

// CMD_PROP_RADIO_DIV_SETUP_PA
RFC_CMD_PROP_RADIO_DIV_SETUP_PA_t RF_cmdPropRadioDivSetup =
｛
  .commandNo = 0x3807、
  .status = 0x0000、
  .pNextOp = 0、
  .StartTime = 0x00000000、
  .startTrigger.triggerType = 0x0、
  .startTrigger.bEnaCmd = 0x0、
  .startTrigger.triggerNo = 0x0、
  .startTrigger.pastTrig = 0x0、
  .condition.rule = 0x1、
  .condition.nSkip = 0x0、
  .modulation.modType = 0x1、        // 2-GFSK
  .modulation.deviation = 0xA、       // 10 * 250Hz = 2500Hz = 2.5kHz（偏差 StepSz=0）
  .modulation.deviationStepSz = 0x0、   // 250Hz 步长
  .symbolRate.prescale = 0xF、
  .symbolRATE.rateWord = 0x199A、      //≈10 ksym/s
  .symbolRate.decimMode = 0x0、
  rxBw = 0x46、              // 12.2kHz
  前导码 Conf.nPreamBytes = 2、       // M = 2
  前导码 Conf.前导码模式= 0x1、
  .formatConf.nSwBits = 0x40、       // 64 位同步字
  .formatConf.bBitReversal = 0x0、     // LSB 在前（同步字）
  .formatConf.bMsbFirst = 0x1、       //有效载荷 MSB 优先
  .formatConf.fecMode = 0x8、        //模式 2 FEC
  .formatConf.whitenMode = 0x2、      // PN9、无字节反转
  .config.frontEndMode = 0x0、
  config.biasMode = 0x1、
  .config.analogCfgMode = 0x0、
  config.bNoFsPowerUp = 0x0、
  .config.bSynthNarrowBand = 0x0、
  .txPower = 0x762E、            // 5dBm（根据需要调节）
  .pRegOverride = pOverrides、
  .centerFreq = 0x0960、          // 2400MHz
  .intFreq = 0x8000、
  .loDivider = 0x00、
  .pRegOverrideTxStd = 0、
  .pRegOverrideTx20 = 0
}；

// CMD_FS
RFC_CMD_FS_t RF_cmdFs =
｛
  .commandNo = 0x0803、
  .status = 0x0000、
  .pNextOp = 0、
  .StartTime = 0x00000000、
  .startTrigger.triggerType = 0x0、
  .startTrigger.bEnaCmd = 0x0、
  .startTrigger.triggerNo = 0x0、
  .startTrigger.pastTrig = 0x0、
  .condition.rule = 0x1、
  .condition.nSkip = 0x0、
  .frequency = 0x0960、
  fractFreq = 0x0000、
  synthConf.bTxMode = 0x0、
  synthConf.refFreq = 0x0、
  ._dummy0 = 0x00、
  ._dummy1 = 0x00、
  ._dummy2 = 0x00、
  ._dummy3 = 0x0000
}；

// CMD_PROP_RX（标准数据包格式，无标头）
RFC_CMD_PROP_RX_t RF_cmdPropRx =
｛
  .commandNo = 0x3802、
  .status = 0x0000、
  .pNextOp = 0、
  .StartTime = 0x00000000、
  .startTrigger.triggerType = 0x0、
  .startTrigger.bEnaCmd = 0x0、
  .startTrigger.triggerNo = 0x0、
  .startTrigger.pastTrig = 0x0、
  .condition.rule = 0x1、
  .condition.nSkip = 0x0、
  .pktConf.bFsOff = 0x0、
  .pktConf.brepeatOk = 0x0、
  .pktConf.brepeatNok = 0x0、
  .pktConf.bUseCrc = 0x1、
  .pktConf.bVarLen = 0x0、         //固定长度
  .pktConf.bChkAddress = 0x0、
  .pktConf.endType = 0x0、
  .pktConf.filterOp = 0x0、
  rxConf.bAutoFlushIgnored = 0x0、
  .rxConf.bAutoFlushCrcErr = 0x0、
  .rxConf.bIncludeHdr = 0x0、        //无标头
  .rxConf.bIncludeCrc = 0x0、
  .rxConf.bAppendRssi = 0x0、
  .rxConf.bAppendTimestamp = 0x0、
  .rxConf.bAppendStatus = 0x1、
  .syncWord = 0x333C3C333CC3CCCCULL、   //新的正常同步字（64 位）
  .maxPktLen = 20、             //根据实际有效负载修改
  .address0 = 0xAA、
  .address1 = 0xBB
  .endTrigger.triggerType = 0x1、
  .endTrigger.bEnaCmd = 0x0、
  .endTrigger.triggerNo = 0x0、
  .endTrigger.pastTrig = 0x0、
  .EndTime = 0x00000000、
  .pQueue = 0、
  .pOutput = 0
}；

// CMD_PROP_TX
RFC_CMD_PROP_TX_t RF_cmdPropTx =
｛
  .commandNo = 0x3801、
  .status = 0x0000、
  .pNextOp = 0、
  .StartTime = 0x00000000、
  .startTrigger.triggerType = 0x0、
  .startTrigger.bEnaCmd = 0x0、
  .startTrigger.triggerNo = 0x0、
  .startTrigger.pastTrig = 0x0、
  .condition.rule = 0x1、
  .condition.nSkip = 0x0、
  .pktConf.bFsOff = 0x0、
  .pktConf.bUseCrc = 0x1、
  .pktConf.bVarLen = 0x0、
  .pktLen = 20、              //根据实际有效负载修改
  .syncWord = 0x333C3C333CC3CCULL、
  .ppkt = 0
}；

最好的考虑。

[参考译文] CC1310：使用闪存编程器时、引导加载程序编程无法正常工作 2.

admin — Mon, 06 Jul 2026 14:50:13 GMT

Other Parts Discussed in Thread: CC1310, UNIFLASH

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1661573/cc1310-bootloader-programming-not-working-using-uniflash-while-it-does-work-when-using-flash-programmer-2

器件型号： CC1310
Thread 中讨论的其他器件： UNIFLASH

您好、

我需要使用 cc1310 引导加载程序编程功能。

但是、无论我尝试通过 UART 使用引导加载程序进行编程、都无法与 UniFlash 配合使用。

当使用闪存编程器 2 执行完全相同的过程时、它会按预期运行。

问题是我主要使用 Linux、因为闪存编程器 2 没有 Linux 版本、所以我需要使用 uniflash 来对引导加载程序进行编程。

从 uniflash 输出。

2026年7月6日、4：19：41 PM][info] Cortex-M3_0：CC1310F128（引导加载程序）  
2026年7月6日、4：19：41 PM][info] Cortex-M3_0：自动波特检测成功！
[Ping、4：19：41 PM][info] Cortex-M3_0：目标成功接收到 2026年7月6日 命令！
[MCU 2026年7月6日、4：19：42 PM]【错误】Cortex-M3_0：[ERROR_MESS]Erase main 失败！ 已返回 NACK！
[CORTEX 2026年7月6日、4：19：42 PM]【错误】Cortex-M3_0：[ERROR_MESS]Process is Failed ！

如果未选择闪存擦除：
2026年7月6日、4：24：07 PM] [info] Cortex-M3_0：CC1310F128（引导加载程序）
2026年7月6日、4：24：07 PM] [info] Cortex-M3_0：自动波特检测成功！
[PING、4：24：07 PM] [info] Cortex-M3_0：目标已成功接收到 2026年7月6日 命令！
[IRC, 2026年7月6日 4:24:08 PM] 【错误】Cortex-M3_0:[ERROR_MESS]Download command to address: 0x0 with programming size: 0x1000 is failed ！ 已返回 NACK！
[CORTEX 2026年7月6日、4：24：08 PM] 【错误】Cortex-M3_0：[ERROR_MESS]Programming is Failed！
[Cortex 2026年7月6日、4：24：08 PM] 【错误】Cortex-M3_0：[ERROR_MESS]Process is failed！

[参考译文] CC1354P10：动态更改绑定管理器配置

admin — Mon, 06 Jul 2026 14:43:03 GMT

Other Parts Discussed in Thread: SYSCONFIG

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1661570/cc1354p10-change-bond-manager-configuration-dynamically

部件号： CC1354P10
主题： SysConfig 中讨论的其他器件

您好：

我有一位客户询问是否有办法动态更改不同 IO 功能支持的绑定管理器配对配置？

他们尝试使用 GAPBond-Parameter() 函数并调用 Mgr_Set Peripheral_init()、但这两种方法似乎都导致设备出现硬故障。

这里的操作码和 IO 功能应该允许动态更改：

TI BLE5-Stack API 文档：GAP 绑定管理器参数

TI BLE5-Stack API 文档：GAP 绑定管理器 I/O 功能

对于如何正确调用该 API 有任何建议？

Munan

[参考译文] smartrf-Studio-7：4FSK 再次…

admin — Mon, 06 Jul 2026 07:06:03 GMT

Other Parts Discussed in Thread: CC1314R10, CC1312R7, LAUNCHXL-CC1312R1

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1661347/smartrf-studio-7-4fsk-again

器件型号： smartrf-Studio-7
主题中讨论的其他器件： CC1312R7、 LAUNCHXL-CC1312R1

我正尝试提高基于 CC1314 的设计的吞吐量。现在它在 1.4Mbps、2GFSK 下达到最大值、其中我可以获得合理的性能（对于速度）。

我尝试使用 SmartRF Studio 验证 PHY、但仅能达到较低的速度。

设置：

两台装有 SmartRF Studio 的笔记本电脑。两个自己的无线电。两者均连接 XDS110 和 5 引脚 CJTAG。

1) 从 50kbps /dev 25kc /100kbps rxbw 示例开始。

2) 修改 1245MHz 的频率、并将 LO 更改为 0x04。

3) 验证零错误 2FSK。

4) 将 FEC-format 更改为 9、启用 4-FSK。将偏差减小至 8kHz (1/25kHz)

5) 使用无限数量的数据包进行测试。 PER = 17.5%、BER = 0.1%（对我来说似乎很奇怪，–64dBm RSSI）

6) 将速率设置为 200kbps、偏差设置为 33kHz、将 RXfilt 设置为 310kHz。

7) 进行上述测试、PER = 4.7%、BER = 0.03%

8) 将速率设置为 400kbaud、偏差设置为 66kHz、将 RXfilt 设置为 621kHz。

9) 如上所述测试、PER = 0.4%、BER =……

10) 将速率设置为 600kbaud、偏差 100kHz、RXbw 设置为 1241kHz

11) 如上所述进行测试、未收到任何数据包。

12) 用连续接收进行测试,以将数据包显示为 RSSI 指示,显示间隔为 12mS 的数据包,并且仅使用较短的持续时间,表示 TX 在这种速率下出现错误行为。这是否符合预期、我是否应该将其解释为主机（笔记本电脑）/ Windows 问题、而不是 CC1314 问题？

我已经用标准同步字和 0xd75f55df 尝试了这一点、我已经理解这是一个仅使用+/- 3 调制符号的同步字、但没有区别。

最后：

2FSK 按预期工作、但速率最高仅为 1.4Mbps、我有用于 1.5、1.6 等的 PHY、其设置根据“FM/FSK 规则“进行缩放、并且调整了 RXbw、但不能超过 1.4Mbps。这是我们自己的代码、目前正在单独进行调查。尝试使用另一个工具达到更高的速率、SmartRF Studio 似乎无法达到 400kbps 以上。

我相信我们已阅读所有支持文档。

[参考译文] CC1101：335MHz 上的 CC1101 只能在使用 315MHz 参考硬件的通道 168 上工作

admin — Fri, 03 Jul 2026 15:23:18 GMT

Other Parts Discussed in Thread: CC1101

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1661151/cc1101-cc1101-at-335-mhz-works-only-up-to-channel-168-using-315-mhz-reference-hardware

部件号： CC1101

尊敬的 TI 团队：

我将 CC1101 与 26MHz 晶体配合使用。我的硬件基于 CC1101 数据表中的 315MHz 参考设计（相同的 PCB 布局和匹配网络）。

我将频率寄存器更改为在 335MHz 下运行、无线电最初工作正常。但是、我发现了以下问题：

从通道 0 到通道 168 的通信正常工作。
在通道 168 之后、通信完全停止 (TX 和 RX)。
如果我回到低于 168 的频道、通信将再次工作。

我想知道：

315MHz 匹配网络能否在 335MHz 可靠地使用、或者是否需要修改射频匹配网络？
该行为是否由射频匹配网络引起、或者它更可能与频率合成器、信道间隔或校准设置有关？
在 335MHz 下运行 CC1101 时、即使它在支持的 300–348MHz 频带内、是否存在任何已知的限制？
从 315MHz 迁移到 335MHz 时、是否建议进行任何寄存器更改（FREQ2/FREQ1/FREQ0 除外）？

我的当前设置：

设备：CC1101
Crystal：26MHz
硬件：315MHz 参考设计
工作频率：335MHz
问题：信道 168 之后通信停止

如有任何指导或建议、将不胜感激。

谢谢你。
哈斯特