Sub-1 GHz forum - Recent Threads

RE: CC1312R: CC1312R: Power_idleFunc

shingo sezaki — Fri, 31 Jul 2026 10:51:30 GMT

段階的にモジュールの追加をしていくことがいいアイデアということをおっしゃっていいるのですか？当然スタンバイに入る事は消費電流を確認したうえでの現象です。タイマー割り込みの340msの遅延については、実験していただけませんか？もしくはこちらの提供したソフトに問題があるのか回答いただけませんか？よろしくお願いします。

CC1312R: CC1312R: Power_idleFunc

shingo sezaki — Mon, 27 Jul 2026 00:55:16 GMT

Part Number: CC1312R

I am investigating the issue where a 1mA current draw occurs during `Power_idleFunc()`, using the sample code I received previously as a base.

I am using the LAUNCHXL-CC1312R1.
With code configured to enter standby mode and wake up only via a button press,
no abnormal current (1mA) was observed over a period of approximately three days.

I am now conducting further tests after modifying the code to keep the Timer module active.

There is a phenomenon I have been wondering about for some time:
it takes approximately 340ms from the moment the timer interrupt is started until the interrupt actually triggers.
I have verified this specifically by monitoring ports TP1 (DIO28) and TP2 (DIO27) with an oscilloscope.
Can this behavior be explained? I will provide the actual code.
Please let me know if there are any errors in how I am initializing or stopping the timer.

sleepTest1.zip

CC1312R: CC1312R RF Communication: How to Implement Fixed-Length Communication

Risei Taniguchi — Thu, 30 Jul 2026 08:25:29 GMT

Part Number: CC1312R

We are working to minimize RF communication time.
As part of this effort, we are attempting to reduce the RF communication time by decreasing the size of the packets being transmitted.
We are conducting RF communication using the standard packet format provided by TI.
We plan to reduce the packet size by eliminating the "Length field" within the standard packet format (i.e., setting it to 0 bytes).
We believed that setting the packet size to a fixed length (bVarLen=0) would allow us to eliminate the "Length field," so we tested this configuration; while the packets did reach the receiver, the content did not match the intended values.
We are currently investigating the cause of this issue.
One possible reason why the received value differs from the intended value is that the sender failed to transmit the intended value.
I would like to verify how the `pktLen` is configured on the sender side.
Is it correct to set `pktLen` to the packet data size?
For the following configuration—Preamble: 4 bytes, Sync word: 3 bytes, Payload: 5 bytes, fixed-length communication (Length field): 0 bytes, Address filtering disabled (Address): 0 bytes, and CRC: 2 bytes—is it correct to set pktLen to 14 bytes?

RE: CC1312R: CC1312R RF Communication: How to Implement Fixed-Length Communication

Risei Taniguchi — Fri, 31 Jul 2026 08:59:54 GMT

Hi Marie

Thank you for your reply.
I'll try again based on your answer.

RE: CC1201: CC1201 Modulation Formats 2-GFSK RX and 2-FSK TX

Diego P — Fri, 31 Jul 2026 08:31:43 GMT

Hi Etan,

At what signal level are you measuring the packet loss? Are you performing your measurements conducted or radiated?

CC1201: CC1201 Modulation Formats 2-GFSK RX and 2-FSK TX

Etan Bennett — Thu, 30 Jul 2026 22:32:01 GMT

Part Number: CC1201

I have been working with the CC1201 within development testing and I wanted to see if anyone has experienced improved link closure and reduced packet loss when using mis-matched modulation modes of the radio. It seems that when I use 2-FSK in TX and 2-GFSK in RX I nominally improve the connection between devices by 1-5% when monitoring packet loss rates.

EX:

625ksps 833.33kHz RX Filter BW 189.81kHz Deviation 2-GFSK RX / 2-FSK TX ~1% packet loss

625ksps 833.33kHz RX Filter BW 189.81kHz Deviation 2-GFSK RX / 2-GFSK TX ~5% packet loss

625ksps 833.33kHz RX Filter BW 189.81kHz Deviation 2-FSK RX / 2-FSK TX ~2% packet loss

CC1352P: CC1352 settings for 9600bps within 11.25kHz bandwidth

jeroen wilbers — Tue, 28 Jul 2026 14:28:36 GMT

Part Number: CC1352P

Hi All
I'm trying to find a setting for the CC1352 for 9600bps to fit in a 12.5kHz channel.
The allowed bandwidth is then 11.25kHz

I expect to be needed 4GFSK, but I cannot figure out what setting to set.

I'm looking for the specific deviation numbers.

If I apply Carsons rule with this, I get:

Symbol rate = 4800
BW = 2*(deviation+symbol rate) -> deviation = BW/2 - symbol rate = 825 kHz
Is this correct?

RE: CC1352P: CC1352 settings for 9600bps within 11.25kHz bandwidth

Diego P — Fri, 31 Jul 2026 08:27:06 GMT

Hi Jeroen,

For 2FSK Carson's rule is BW = symbol rate + 2*deviation and for 4FSK BW = symbol rate + 2* outer deviation.

Carson's rule is a good rule of thumb for perfect FSK signal. In you case since you are looking at using a gaussian filter the signal bandwidth would actually be lower.

In order to fit the signal in a 11.25 kHz BW, you could use an outer deviation of about 4.1 kHz using a gaussian filter of BT=0.5. With these settings the 99% occupied bandwidth is about 11 kHz.

RE: CC1312R: CC1312R: Power_idleFunc

Marie H — Fri, 31 Jul 2026 08:03:34 GMT

Hi Shingo,

That sounds like a good idea.

Please note: Adding a UART in callback mode will prevent the device from going to standby, since the device will need to listen for incoming UART transactions. This is usually solved by adding a GPIO handshake that can wake up the device in front of the UART transaction itself.

Cheers,

Marie H

RE: CC1312R: CC1312R RF Communication: How to Implement Fixed-Length Communication

Marie H — Fri, 31 Jul 2026 07:33:11 GMT

Hi Risei,

For CMD_PROP_TX with bVarLen=0, the pktLen field specifies only the number of bytes in the buffer pointed to by pPkt — it does not include preamble, sync word, or CRC. These fields are handled automatically by the RF core. In your case this one should be set to 5 (not 14).

On the RX side with CMD_PROP_RX and bVarLen=0, set maxPktLen = 5. The receiver will expect exactly 5 bytes after the sync word and before the CRC.

// TX side
RF_cmdPropTx.pktConf.bVarLen = 0;  // Fixed length, no length byte transmitted
RF_cmdPropTx.pktConf.bUseCrc = 1;  // Hardware appends CRC automatically
RF_cmdPropTx.pktLen = 5;           // Payload size only
RF_cmdPropTx.pPkt = &yourPayloadBuffer[0];  // 5-byte buffer

// RX side
RF_cmdPropRx.pktConf.bVarLen = 0;  // Fixed length
RF_cmdPropRx.maxPktLen = 5;        // Expect 5 bytes after sync, before CRC

Cheers,

Marie H

CC1312R: Wireless M-Bus support on CC1312R for Japanese 920 MHz band

Ibuki Endo — Tue, 14 Jul 2026 08:31:56 GMT

Part Number: CC1312R

Hi expert,

We are evaluating CC1312R for a smart metering application in Japan.

According to TI documentation, the Wireless M-Bus stack supports the European 868 MHz, 433 MHz, and 169 MHz bands. We could not find information regarding operation in the Japanese 920 MHz band.

Could you please clarify the following points?

1. Can the TI Wireless M-Bus stack (OMS v4.1.2) be configured to operate in the Japanese 920 MHz band on CC1312R?

2. If 920 MHz operation is not supported out of the box:

- Is there any recommended migration path?

- Can the existing Wireless M-Bus stack source/framework be reused as a starting point?

3. Would operation in the 920 MHz band require only RF parameter changes, or are there protocol/stack limitations that prevent such migration?

4. Has TI or Stackforce ever supported or evaluated Wireless M-Bus implementations on frequency bands other than the standard 868/433/169 MHz bands?

5. Are there any TI reference designs, evaluation boards, modules, or customer designs based on CC1312R/CC1312P that have obtained radio certification for operation in the Japanese 920 MHz band?

6. If customers want to evaluate CC1312R/CC1312P in Japan before certification, are there any recommendations from TI regarding the use of evaluation boards and regional regulatory requirements?

Our customer is interested in drive-by meter reading in Japan and is considering Wireless M-Bus as one of the candidate protocols.

Best regard,

Ibuki Endo

RE: CC1312R: Wireless M-Bus support on CC1312R for Japanese 920 MHz band

Ibuki Endo — Fri, 31 Jul 2026 06:15:24 GMT

Hi Zack-san,

Thank you for the friend request.

I tried to accept it, but I received a 403 error on my side and was unable to complete the request.

Just wanted to let you know.

Best regards,
Ibuki Endo

RE: CC1311R3: Is there a difference in maximum transmission power between 1.8V and 3.3V power supply

ZC — Thu, 30 Jul 2026 19:33:14 GMT

Hi,

Yes, the line below clarifies that a minimum VDDS (supply voltage) of 2.1 V is required for +14 dBm transmission (boost mode means boosting VDDR to 1.95 V to enabled the higher output power).

Otherwise, with a VDDS < 2.1 V (or with boost mode not enabled) the maximum TX Output Power is +12.5 dBm.

Regards,

Zack

CC1311R3: Is there a difference in maximum transmission power between 1.8V and 3.3V power supply

Lumina Gui — Thu, 30 Jul 2026 14:17:31 GMT

Part Number: CC1311R3

Dear TI Engineer,

Can you help confirm that is there a difference in maximum transmission power between 1.8V and 3.3V power supply?

From the datasheet we can learned that the max output power is 14dBm with the VDDR = 1.95 V.

Thanks,

Best Regards

RE: CC1312R: Wireless M-Bus support on CC1312R for Japanese 920 MHz band

ZC — Thu, 30 Jul 2026 19:14:14 GMT

Hi Ibuki-san,

You may not be able to give information publically but Wireless M-Bus is typically a Europe-based standard (I may be missing something here). We might need more details to be able to help with this. I've looped in a colleague and also sent a friend request.

Regards,
Zack

CC113L: OOK not working

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

Part Number: CC113L

Hi Champs,

I am trying to transmit OOK messages from LP-EM-CC1354P10-1 to a custom CC113L custom board. Frequency is 433 MHz. I know it is not the frequency that the LP was designed to work best at. But I don't need long distance for this test. The boards are very close to each other on a table.

2 LP-EM-CC1354P10-1 boards work well in the test. 1 transmits and 1 receives. Again, at 433 MHz. But the CC113L custom board can't receive any message. I checked the RSSI value in CC113L. It goes up to -50 dBm when the transmitter (LP-EM-CC1354P10-1) transmits. When I stop the transmission, CC113L RSSI goes back to -90 dBm. So I guess it can detect the coming radio signal, but I don't know why it can not give any output message.

Below are the registers settings for CC113L. Generated by SmartRF Studio 7. Written to CC113L by an MSPM0 MCU, and verified.

I have some questions that need your help to address:

is my test case mentioned above workable? (LP-EM-CC1354P10-1 sends OOK messages to a CC113L custom board at 433 MHz)
If yes, what should I check/change to make the connection work?

CC113L settings:

IOCFG2 [0x00] = 0x29

IOCFG1 [0x01] = 0x2E

IOCFG0 [0x02] = 0x06

FIFOTHR [0x03] = 0x47

SYNC1 [0x04] = 0xD3

SYNC0 [0x05] = 0x91

PKTLEN [0x06] = 0xFF

PKTCTRL1 [0x07] = 0x04

PKTCTRL0 [0x08] = 0x05

ADDR [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

VERSION [0x31] = 0x18

MARCSTAT [0x35] = 0x0D

PKTSTAT [0x38] = 0x60

RXBYTES [0x3B] = 0x00

CC1354P10 settings for Tx board

smartrf_settings.h

smartrf_settings.c

Regards,

Kien

RE: CC113L: OOK not working

ZC — Thu, 30 Jul 2026 12:59:11 GMT

Hi Kien,

Has the customer confirmed a basic link with e.g. GFSK (to confirm a link to start with)?

It looks like Manchester Coding is enabled on the CC113L side, based on: MDMCFG2 [0x12] = 0x3B

The CC1101-based devices and the CC135x devices have differences in handling Manchester encoded packets: https://dev.ti.com/tirex/explore/content/simplelink_cc13xx_cc26xx_sdk_8_33_00_16/docs/proprietary-rf/proprietary-rf-users-guide/proprietary-rf/cc1101-migration.html?highlight=manchester%20encoding#cc1101-proprfdevice-using-manchester-coding

Also, frequency offset compensation is not supported for OOK on the CC113L. So, the current setting of FOCCFG [0x19] = 0x16 should be changed to FOCCFG [0x19] = 0x14 (i.e. set [1:0] FOC_LIMIT[1:0] = 0).

If I set the base frequency to 433.92 MHz in Studio, the FSCAL registers, etc. are set to different values than the customer is using; were these frequency synthesiser settings changes specifically found by the customer?

Has the customer confirmed the actual TX frequency of the CC1354P10? If there is a frequency offset, and FOC is not supported for the CC113L with OOK, then the RXBW might need to be increased.

There may be some other settings as well, so we would recommend checking the other settings on the CC113L side. I'm not sure if the customer is aware of this document? SWRA215 (CC110x CC111x OOK ASK Register Settings): https://www.ti.com/lit/swra215

Regards,

Zack

RE: CC1352P: Packet loss observed at 50Meter LOS

Amrit Dhaker — Thu, 30 Jul 2026 07:21:59 GMT

Dear sir,

Also suggest what optimal setting needs to configure for Transmitter side & receiver side.

In terms of inter beacon delay & scan, interval window etc...

Regards,

Amrit

CC1352P: Packet loss observed at 50Meter LOS

Amrit Dhaker — Fri, 24 Jul 2026 10:59:54 GMT

Part Number: CC1352P

Dear sir,

We observed Packet loss observed at 50Meter LOS.

With below seeting in transmistter

/// Default parameters for long range, connectable, advertising extension
#define GAPADV_PARAMS_AE_LONG_RANGE_CONN1 { \
.eventProps = GAP_ADV_PROP_CONNECTABLE, \
.primIntMin = 800, \
.primIntMax = 816, \
.primChanMap = GAP_ADV_CHAN_ALL, \
.peerAddrType = PEER_ADDRTYPE_PUBLIC_OR_PUBLIC_ID, \
.peerAddr = { 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa }, \
.filterPolicy = GAP_ADV_WL_POLICY_ANY_REQ, \
.txPower = GAP_ADV_TX_POWER_NO_PREFERENCE, \
.primPhy = GAP_ADV_PRIM_PHY_1_MBPS, \
.secPhy = GAP_ADV_SEC_PHY_CODED_S8, \
.sid = 0 \
}

GapAdv_params_t advParamLegacy = GAPADV_PARAMS_AE_LONG_RANGE_CONN1;

SendBeacon()
{
GapScan_disable( );
GapAdv_destroy( advHandleLegacy , GAP_ADV_FREE_OPTION_DONT_FREE);
BeaconLen = UdateBeaconAdvertData_g( aBeaconData );
status = GapAdv_create(&SimpleBroadcaster_advCallback, &advParamLegacy,
&advHandleLegacy);

status = GapAdv_loadByHandle(advHandleLegacy, GAP_ADV_DATA_TYPE_ADV,
BeaconLen, aBeaconData);

status = GapAdv_enable( advHandleLegacy,
GAP_ADV_ENABLE_OPTIONS_USE_DURATION ,220u); /* 2200 ms brodcasting */
}

We have below quries.
o Are advertisements transmitted sequentially on advertising channels 37 → 38 → 39?
o Is the advertising channel order always fixed?
o Is it technically possible to configure the Primary PHY as LE Coded S8 (125 kbps) instead of 1 Mbps?
o Why variation observed in No. of beacon transmitted with above setting e.g. 4-5beacon

Regards,
Amrit

RE: CC1354P10: Configuring 2.4 GHz with high-PA

Marie H — Wed, 29 Jul 2026 08:53:46 GMT

Hi Alex,

For +20 dBm on 2.4-GHz, we have the CC1354P10-6 design. If you select this variant Studio can generate the settings. However I believe they may only work with the CC1354P10-6 LP.

Cheers,

Marie H

CC1354P10: Configuring 2.4 GHz with high-PA

Alex Lin — Wed, 29 Jul 2026 03:31:43 GMT

Part Number: CC1354P10

Hello,

We have a custom board using the CC1354P10-1 using the 2.4 GHz band. We want to use the high-PA path for transmit, so we referenced the antenna switch callback example code snippet generated by SysConfig to route the signal through the HIGH_PA pin on transmit. However, I'm missing the RF core configuration itself I believe. Both SysConfig and SmartRF only generate settings for the high-PA (20 dBm) for the sub-1 GHz band. What settings that are normally in ti_radio_config.c (such as the pOverridesTx20, txPowerTables, etc.) do I need to have to configure the RF core for 20 dBm at 2.4 GHz?

RE: CC1352P: Packet loss observed at 50Meter LOS

Amrit Dhaker — Wed, 29 Jul 2026 04:01:54 GMT

We have already set 8dBm power with 2dBi antenna gain in transmitter side. Can not set total power >10dBm as per regulatory compliance.

#if defined(CC13X2P)
#define DEFAULT_TX_POWER HCI_EXT_TX_POWER_P2_16_DBM_P4_8_DBM//HCI_EXT_TX_POWER_0_DBM

Will solve our low PER issue when change Primary PHY as LE Coded S8 (125 kbps)?

RE: CC1352P: Packet loss observed at 50Meter LOS

Jan — Tue, 28 Jul 2026 20:06:34 GMT

Hi,

In that case, increasing the txPower should be helpful so that could resolve the low PER behavior.

Best Regards,

Jan

RE: CC1314R10: Can I use XDS100v2 with CC1314R10

Marie H — Tue, 28 Jul 2026 13:32:44 GMT

Hi,

I have not tested but I believe it should work. For CCS 12.x:

1) Open your Project properties

2) Under General -> Connections select your debugger.

The specific JTAG I believe you can set in the Target Config.

Cheers,

Marie H

CC1314R10: Can I use XDS100v2 with CC1314R10

utkarsh singh — Tue, 28 Jul 2026 08:55:07 GMT

Part Number: CC1314R10

Wanted to know if there is any way to make the XDS100v2 work with the CC1314R10 board, any setting somewhere to switch from CJtag to Jtag.