LAUNCHXL-CC1310: 15.4 STACK FH MODE: how to change the data rate

Hi Jing,

Yes, changing the CONFIG_PHY_ID in config.h should be he only required change. 

Please confirm that you changed the PHY ID on both the collector and sensor side.

Can you use a packet sniffer to confirm that the devices are actually sending packets?

My debug information:

THe collector board:

TI Collector
PHY_ID:128
IncomingICallMsg:8
Restarted
Freq. Hopping

PermitJoin-ON

sendAyncReq-0           //frameType = ApiMac_wisunAsyncFrame_advertisement
paS-1                           //Cllc_statistics.fhNumPASent, means the number of PA massage it sends
paR-0                           //Cllc_statistics.fhNumPASolicitReceived
pcS-0                           //Cllc_statistics.fhNumPANConfigSent
pcR-0                          //Cllc_statistics.fhNumPANConfigSolicitsReceived

IncomingICallMsg:17 //MAC_MLME_WS_ASYNC_CNF

sendAyncReq-2 //frameType = ApiMac_wisunAsyncFrame_config
paS-1
paR-0
pcS-1 //Cllc_statistics.fhNumPANConfigSent = 1
pcR-0
IncomingICallMsg:17

That's all. collector board sends two massage(one is ApiMac_wisunAsyncFrame_advertisement and the other one is ApiMac_wisunAsyncFrame_config),then there is no IncomingICallMsg to process.

For the sensor board:

TI Sensor
PHY_ID:128
State Changed: 1

SEND PAS PASintv=6000
sendAsync- 1          //frameType = ApiMac_wisunAsyncFrame_advertisementSolicit
paS=1                     //Jdllc_statistics.fhNumPASolicitSent
paR=0                    //Jdllc_statistics.fhNumPAReceived
pcS= 0                   //Jdllc_statistics.fhNumPANConfigSolicitsSent
pcR=0                    //Jdllc_statistics.fhNumPANConfigReceived

IncomingICallMsg:17               //MAC_MLME_WS_ASYNC_CNF
s=0                                          //pMsg->hdr.status = 0

SEND PAS PASintv=6000
sendAsync- 1
paS=2
paR=0
pcS= 0
pcR=0

IncomingICallMsg:17
s=0

SEND PAS PASintv=6000
sendAsync- 1
paS=3
paR=0
pcS= 0
pcR=0

IncomingICallMsg:17
s=0

SEND PAS PASintv=6000
sendAsync- 1
paS=4
paR=0
pcS= 0
pcR=0

IncomingICallMsg:17
s=0

SEND PAS PASintv=6000
sendAsync- 1
paS=5
paR=0
pcS= 0
pcR=0

IncomingICallMsg:17
s=0

SEND PAS PASintv=6000
sendAsync- 1
paS=6
paR=0
pcS= 0
pcR=0

IncomingICallMsg:17
s=0

SEND PAS PASintv=6000
sendAsync- 1
paS=7
paR=0
pcS= 0
pcR=0

........

The sensor board sends ApiMac_wisunAsyncFrame_advertisementSolicit periodly at every 6 seconds, but cannot receive the response from the collector, cause collector seems deaf that cannot "hear" the advertisementt Solicit.

But if I change the CONFIG_PHY_ID as APIMAC_STD_US_915_PHY_1, the deaf seems to be cured and the collector can hear and response to the sensor, and sensor can join to the network successful. I don't know why.

I am still stuck in this problem. Are there anyone can help me?

Hi Jing,

Can you try doing a flash erase on both devices before you program the new image? (I think stored information from the first network is the reson why you're not able to connect in the second case.

Nothing changed.Collector still stay in deaf that cannot "hear" the advertisementt Solicit.

Hi Jing,

Are you using the examples straight out of the SDK, or did you make any code changes?

I am not able to reproduce what you are seeing.

Thank you for your reply. I just change these parameters(mentioned in the first post of this problem)

when CONFIG_PHY_ID set to APIMAC_STD_US_915_PHY_1 or APIMAC_STD_ETSI_863_PHY_3, it works fine,the "deaf" problem disappear, but when the CONFIG_PHY_ID  set to APIMAC_GENERIC_CHINA_433_PHY_128 or APIMAC_GENERIC_US_915_PHY_132 or APIMAC_GENERIC_ETSI_863_PHY_133, the problem comes and make me crazy;

Even when I using the examples straight out of the SDK, just change these ttwo parameters:

#define CONFIG_PHY_ID                (APIMAC_GENERIC_CHINA_433_PHY_128)// default is  (APIMAC_STD_US_915_PHY_1)

#define CONFIG_FH_ENABLE            true//default is false

And the sensor is changed one more parameter:

#define CONFIG_RX_ON_IDLE          true//default is  false

The same problem will happen.

Hi Jing,

Here are the steps I followed. Please let me know if there are any differences between our approaches:

1) Open CCS 9.1.0

2) Import TI 15.4-Stack sensor + collector from SDK 4.10.01.01

3) Set CONFIG_FH_ENABLE to true in config.h in both sensor and collector examples.

4) Do a test with default PHY. Start both devices. Press button on the collector to open the network. I can see the devices connect. (Success case).

5) Do a flash mass erase on both devices

6) Change the CONFIG_PHY_ID to APIMAC_GENERIC_US_915_PHY_132 in config.h for both the sensor and collector device.

6) Start both devices. Press button on the collector to open the network. I can see the devices connect. (Success case).

I don't know why your test result is different from me and may be the difference of our parameters is:

By the way, according to the comparison betweent different process while using different PHY_ID, I found that pOverrides( in  mac_user_config_cc13x0_rftable.h) make diffrence!!!!  When PHY_ID == APIMAC_STD_US_915_PHY_1 or APIMAC_STD_ETSI_863_PHY_3, the pOverrides point to pOverrides_fsk_CC1350[]( mac_user_config_cc13x0_rftable.h, line number stars from 67); When PHY_ID == APIMAC_GENERIC_US_915_PHY_132, the pOverrides point to pOverrides_fsk_200k_CC1350[]( mac_user_config_cc13x0_rftable.h, line number stars from 459).

I compared these two array and found tha the difference is as bellow:

so I just do some test:

1. shielding these two lines of code: ( in pOverrides point to pOverrides_fsk_CC1350[], line 114 and line 116)

// IEEE 802.15.4g: Fix incorrect initialization value for CRC-16 calculation (see TRM section 23.7.5.2.1)
// (uint32_t)0x00000943,
// IEEE 802.15.4g: Fix incorrect initialization value for CRC-16 calculation (see TRM section 23.7.5.2.1)
// (uint32_t)0x00000963,

and then test the connecting status when PHY_ID == APIMAC_STD_US_915_PHY_1,  the result is that sensor connect the network OK, so these two repeat lines  make no sense.

2. shielding these two lines of code (in  pOverrides_fsk_200k_CC1350[], line 493 and line 495)

// Synth: Set divider bias to disabled
//HW32_ARRAY_OVERRIDE(0x405C,1),
// Synth: Set divider bias to disabled (specific for loDivider=5)
//(uint32_t)0x18000200,

and then test the connecting status when PHY_ID == APIMAC_GENERIC_US_915_PHY_132,  the result is that sensor connect the network successful!!!!!!!!  That means these two lines  play an important part in the connecting process!

There comes the problem: what's the meaning of these two lines?  while the frequency band are the same for these two group of PHY_ID, the loDivider is 5 no matter PHY_ID=1,3,132 or 133， why it needs to add (uint32_t)0x18000200 when PHY_ID==132 or 133, but no need to add when PHY_ID=1 or 3?  "Set divider bias to disabled", can you tell me what the differece between the divider bias is enable and disable?

3. Are these two line make sense on the transmiting data rate?

// Tx: Configure PA ramping setting (0x10) for approximately 5 us PA ramp time. Rx: Set AGC reference level to 0x1C.
HW_REG_OVERRIDE(0x6088,0x101C),
// Tx: Configure PA ramping setting (0x08) for approximately 5 us PA ramp time
HW_REG_OVERRIDE(0x608C,0x0813),

Waiting for your reply.

Hi Jing,

RX on Idle define should not make a difference, but you can do a test where you set it to false.

Overrides need to change with the PHY. 

Cheers,

Marie H.

Hi Marie:

I'm glad to see your reply,thank you.

Can you help me to explain the question 2 and question 3 in my last post(the meaning of  four settings in Overrides)?

Hi TER:

Thank you for your reply and support, it really help me a lot!

But my two launchpads are in version 2.0(not rev A), show in the folllow picture:

I wonder whether the reply for question 2 suitful to my application.

Please update your SmartRF Studio version, the version you have is old, and recheck.

The app note I pointed to describe how to verify the PA ramping.