工具与软件：
尊敬的 TI 团队：
我正在使用具有高速模式 PHY (4Mbps)的 CC1310、并且注意到一些奇怪的行为。 具体来说、我们已在915MHz FHSS 频带中实施-927MHz 方案、我发现接收无线电 CC1310正在侦听并成功解码来自发射无线电 CC1310的数据包、尽管这些数据包在信道外相当多、但不仅在相邻信道中、而且以4.25MHz 间隔也是如此。
我们的 FHSS 方案通道分离为250kHz、我们现在意识到这一点很不足；当使用4Mbps 8-FSK PHY 时、我们需要(根据卡森规则) 2 x (偏差+符号速率)=> 2.666MHz (我不知道4Mbps 8-FSK PHY 的偏差)。 这就解释了为什么接收无线电在"相邻"信道(例如 TXR = 915.25MHz、RXR = 915.5MHz)中对信号进行解码、因为这些信道实际上并不相邻、但重叠了可能超过80%+-信号带宽 比250kHz (！)的信道间隔宽度大一个数量级。 然而、光谱仍然不像我们预期的那样-我预计有8个等距的小叶/峰、以载波为中心(例如915.25MHz)。
此外、接收器能够完美地解码掉4.25MHz 之外的信号(这种频率折返或滤波器之一内发生混叠吗？)、以及任意几个"通道"(即任一侧+/- 500kHz)、频谱 似乎有很大的漂移(> 1MHz)、就像 PLL 未锁定一样。
我已经尝试通过以下命令让 TxOperation RF_postCmd 在 Synth 丢失或无法建立锁定时通知我：
rfPostCmdResult = RF_postCmd(Cc1310_CcRf_RfHandle_g, TxOperation, RF_PriorityNormal, &TxBlocksCallback, RF_EventTxEntryDone | IRQN_SYNTH_NO_LOCK );
但我注意到 RF.h 中没有为 SYNTH_NO_LOCK 定义事件(在 μ@名称射频内核事件部分中)、因此我想知道如果发生这种情况、是否甚至可以让射频内核触发我的代码中断。 无论哪种方式、我都不会看到 RF_cmdfs 合成器编程调用报告了任何错误：
RF_runCmd(Cc1310_CcRf_RfHandle_g, (RF_Op*)&RF_cmdFs, RF_PriorityNormal, NULL, 0)
始终返回 RF_EventLastCmdDone 和 RF_cmdFs.status、在之后始终读取0x0400 ("完成正常")。 无论如何、CC1310射频内核似乎都没问题-我只是在努力确定 PHY 的参数、以及其中任何一个参数可配置的程度。
我正在使用以下设置：
const rfc_CMD_RADIO_SETUP_t Cc1310_Rf900vol_PHY_900M_1333KSYM_8fsk_g =
{
.commandNo = CMD_RADIO_SETUP, // 0x0802
.status = 0x0000,
.pNextOp = 0x00000000,
.startTime = 0x00000000,
.startTrigger.triggerType = 0x0,
.startTrigger.bEnaCmd = 0x0,
.startTrigger.triggerNo = 0x0,
.startTrigger.pastTrig = 0x0,
.condition.rule = 0x1,
.condition.nSkip = 0x0,
.mode = 0x05,
.loDivider = 5,
// .config.frontEndMode = 0x0,
.config.biasMode = 0x1,
.config.frontEndMode = 0x02, // Single-ended Mode RFN.
.config.bNoFsPowerUp = 0,
.txPower = 0x23F,
.pRegOverride = (uint32_t*)PHY_900M_1333KSYM_hsm_pOverrides,
};
uint32_t PHY_900M_1333KSYM_hsm_pOverrides[] =
{
MCE_RFE_OVERRIDE(1,0,0,1,0,0),
ADI_HALFREG_OVERRIDE(0,61,0xF,0x0),
ADI_REG_OVERRIDE(1,4,0x9F),
ADI_HALFREG_OVERRIDE(1,7,0x4,0x4),
HW_REG_OVERRIDE(0x4038,0x003A),
HW_REG_OVERRIDE(0x4020,0x7F00),
HW_REG_OVERRIDE(0x4064,0x0040),
0x000604A3,
0xB1070503,
0x05330523,
0x0A480583,
0x7AB80603,
0x00108463,
0x02010403,
0x04B00243,
0x00038883,
0xC0040031,
(uint32_t) &shapeovr[0],
0xC0040021,
(uint32_t) (0x00000035),
0x000388A3,
HW_REG_OVERRIDE(0x50B4,0x6666),
HW_REG_OVERRIDE(0x50B8,0x000C),
/* RF Core monitors */
(uint32_t)0x008F88B3, // For RAT_GPO1
// Mod and Demod signals from the core do not work for > 2-FSK PHY, so no point wasting them when we could be using them for debug test points.
// TX (RAT_GPO0) to RFC_GPO2 RX (RAT_GPO1) to RFC_GPO3
HW_REG_OVERRIDE(0x1110, RFC_DBELL_SYSGPOCTL_GPOCTL2_RATGPO0 | RFC_DBELL_SYSGPOCTL_GPOCTL3_RATGPO1),
(uint32_t)0xFFFFFFFF,
};
static const RF_Mode RfSettings_RF_prop_hsm =
{
.rfMode = RF_MODE_PROPRIETARY_SUB_1,
.cpePatchFxn = 0,
.mcePatchFxn = &rf_patch_mce_hsp_4mbps,
.rfePatchFxn = &rf_patch_rfe_hsp_4mbps,
};
我们是否必须使用 RFC_CMD_RADIO_SETUP_t 来实现4Mbps、或者我们是否能够以某种方式改用更可配置的 RFC_CMD_PROP_RADIO_DIV_SETUP_t 或 RFC_CMD_PROP_RADIO_SETUP_t？
我注意到、与较低数据速率 PHY (即 RFC_CMD_PROP_RADIO_DIV_SETUP_t、如750ksym/s 4-FSK)相比、用于4Mbps 8-FSK PHY 的 RFC_CMD_RADIO_SETUP_s 可大幅"削减"。 例如、似乎没有方法可以配置调制类型、偏差或接收带宽。 这些参数中的任何一个是否可配置、如果可配置、如何配置？ 如果不是、它们的(固定)值是什么？
最后、我注意到从 RFC_CMD_RADIO_SETUP_t 文档(位于 rf_common_cmd.h 中)中删除了：
uint8_t mode；//！<短接要使用的主模式
//！< 0x00：BLE
//！< 0x01：IEEE 802.15.4
//！< 0x02：2Mbps GFSK
//！< 0x05：5Mbps 编码8-FSK
因此、我认为它是4Mbps PHY、实际上是5Mbps、还是误解了什么？ 我试图确定为什么我一直认为它是4Mbps 的所有这段时间!
TIA、
Sean。
