Tool/software:
Hi TI team,
I am using the CC1310 with the High-Speed Mode PHY (4Mbps) and am noticing some strange behaviour. Specifically, we have implemented a FHSS scheme in the 915MHz-927MHz band and I am finding that the receive radio CC1310 is hearing and successfully decoding the data packet from the transmitting radio CC1310 despite being considerably off-channel, not only in adjacent channels but at intervals of 4.25MHz away also.
Our FHSS scheme channel separation is 250kHz, which we now realise is woefully insufficient; when using the 4Mbps 8-FSK PHY, we require (according to Carson's Rule) 2 x (Deviation + Symbol Rate) = > 2.666MHz (I do not know the deviation of the 4Mbps 8-FSK PHY). This would explain why the receive radio decodes signals when in an "adjacent" channel (e.g. Txr = 915.25MHz, Rxr = 915.5MHz), since the channels are not actually adjacent at all but overlap by perhaps 80%+ - the signal bandwidth is an order of magnitude larger the channel separation width of 250kHz (!!). However, the spectrum still does not look as we'd expect it to - I would expect 8 equidistantly-spaced lobes/peaks, centred on the carrier (e.g. 915.25MHz).
Furthermore, the receiver perfectly decodes signals that are 4.25MHz away (is this some kind of frequency foldback or aliasing occurring within one of the filters?), as well as a few "channels" either side (i.e. +/- 500kHz either side) and the spectrum appears to drift considerably (> 1MHz), as though the PLL were not locked.
I have tried to get the TxOperation RF_postCmd to notify me if the Synth loses or cannot establish a lock with:
rfPostCmdResult = RF_postCmd(Cc1310_CcRf_RfHandle_g, TxOperation, RF_PriorityNormal, &TxBlocksCallback, RF_EventTxEntryDone | IRQN_SYNTH_NO_LOCK );
but I notice there's no event defined for SYNTH_NO_LOCK in RF.h (in the @name RF Core Events section), so I wonder if it's even possible to get the RF Core to trigger this interrupt to my code if this occurs. Either way, I do not see any errors reported by the RF_cmdFs synthesiser programming call:
RF_runCmd(Cc1310_CcRf_RfHandle_g, (RF_Op*)&RF_cmdFs, RF_PriorityNormal, NULL, 0)
which always returns RF_EventLastCmdDone and RF_cmdFs.status always reads 0x0400 ("DONE OK") afterwards. By all accounts, the CC1310 RF Core seems ok - I am just struggling to determine the parameters of the PHY and to what extent any of it might be configurable.
I am using the following settings:
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,
};
Must we use rfc_CMD_RADIO_SETUP_t to achieve the 4Mbps or can we somehow instead use the more configurable rfc_CMD_PROP_RADIO_DIV_SETUP_t or rfc_CMD_PROP_RADIO_SETUP_t?
I notice that rfc_CMD_RADIO_SETUP_s, which is used for the 4Mbps 8-FSK PHY is considerably "cut-down" as compared to the lower data rate PHYs (i.e. rfc_CMD_PROP_RADIO_DIV_SETUP_t for e.g. 750ksym/s 4-FSK). For example, there appears to be no way to configure the modulation type, deviation, or receive bandwidth. Are any of these parameters configurable and, if so, how? If not, what are their (fixed) values?
Finally, I notice from the documentation of rfc_CMD_RADIO_SETUP_t (in rf_common_cmd.h):
uint8_t mode; //!< \brief The main mode to use<br>
//!< 0x00: BLE<br>
//!< 0x01: IEEE 802.15.4<br>
//!< 0x02: 2 Mbps GFSK<br>
//!< 0x05: 5 Mbps coded 8-FSK<br>
Am I therefore incorrect in thinking it's a 4Mbps PHY, when it is in fact 5Mbps or have I misunderstood something? I am trying to determine why I've been thinking it's 4Mbps for all of this time!
TIA,
Sean.
