CC1352P: TI-15.4 collector exported from SDK v7.41 with custom phy cannot send data to sensor

I compared the auto-generated ti_radio_config.c file against the one we exported from SmartRF Studio, there seem to be some subtle differences. The following lines look particularly suspicious:

const rfc_CMD_PROP_TX_ADV_t RF_cmdPropRxAdv_custom =
{
    //......
    .condition.rule = 0x0,
    //......
};

// CMD_PROP_RX_ADV
// Proprietary Mode Advanced Receive Command
const rfc_CMD_PROP_RX_ADV_t RF_cmdPropTxAdv_custom =
{
    //.....
    .condition.rule = 0x0,
    //.....
};

They are different from the one we exported from SmartRF studio and also different from the autogenerated ti_radio_config.c when custom phy is turned off.

Once the content of ti_radio_config.c is replaced with export from SmartRF Studio, everything seems to work as expected again.

I just realized that adding the custom PHY for 15.4 is added to the lastest SDK, and I see that is uses the advanced commands and not the normal commands for WB-DSSS.

I will file a ticket on the problem related to the .condition.rule settings

Siri

I think the issue is more than the condition.rule lines. Changing those lines to 0x01 in TX and RX commands helps, to the degree that if I set polling interval at 2 seconds, sensor nodes will receive all data sent from collector, at least the 10s of data packet I tested. When condition.rule lines are set at 0x00, sensor nodes can only receive a handle of data sent from collector. But once I change the polling interval back to 1 minute, sensor nodes barely receive any data from collector. There are always premature dataCnfCb with status code 0xF0.

The other factor most likely is related to how soon cached data is purged. It seems once custom phy is turned on, a hard coded 5 seconds is used. When custom phy is off, the expiration time is mostly a function of CONFIG_POLLING_INTERVAL. 

Hope this bit of information can help you guys eventually support WB-DSSS in 15.4 stack officially.

Have you tested the default collector and sensor example from the 7.41 SDK with no other changes than enabling custom PHY and setting this to WB-DSSS?

Is this not working?

The reason I ask is that you talked about testing some "old radio based on 15.4 collector/sensor projects with the latest SDK v7.41 and custom phy" so I do not fully understand your setup.

Please provide steps for us to recreate the issue, using our LP, and running the sensor and collector example from the latest SDK.

Siri

I tried to slightly tinker the 15.4-collector/sensor example projects and didn't find an easy way to construct a minimum test case. On a high level, I believe the following is what's needed:

1) Enable custom phy

2) Change application settings: report interval to 90000, polling interval to 60000, tracking delay to 150000

The default polling interval is 2 seconds. With such a short interval and condition.rule set to 0x01, collector seems able to send data to sensor just fine So the long polling interval is probably key.

3) Enable power test mode, with Data and Ack profile on collector, and Polling Only on sensor

This step is probably not needed, but this is what did in our firmware.

4) Find a way to periodically send data from collector to sensor and output status code returned by dataCnfCb function through UART.

This is the step that I am not familiar with. It seems once power test mode is enabled, CUI is turned off all together. We replaced the CUI with a customized AT command system, so we can still track a whether sending data to sensor/collector has succeeded.

I just noticed there is a send toggle feature in collector example project, and this doesn't seem to work once the custom phy is enabled with polling interval at 60 seconds. So here is the minimum test case:

1) Export collector/sensor example.

2) Enable custom phy

3) Change polling interval to 60 seconds from default 2 seconds. I tested with report interval at 90 seconds, but this may not be necessary. Also any polling interval greater than 6 seconds probably will also be able to reproduce the problem.

4) Compile and load onto CC1352P1-launchpads.

5) Form and join network.

6) Trigger "Send Toggle" on collector and observe if the red LED on sensor node turns on/off.

When polling interval stayed at default 2 seconds, most of the time red LED on sensor node will toggle a few seconds after Send Toggle is pressed on collector. But occasionally the delay between send toggle and red toggle are more than 2 second polling interval, indicating failure of initial sending then retry. When polling interval is changed to 60 seconds, the red LED on sensor node doesn't toggle most of the times. I pressed Send Toggle 15 times, with 1 ~ 2 minutes in between. The red LED on sensor node toggled 4 times. I observed a Device nonresponding on collector CUI twice. Meanwhile, sensor node doesn't seem to have problem sending data to collector. 

Hi Zhiyong,

Thank you for posting the additional information.

We haven't run the full TI 15.4-Stack test suite on the custom PHY option, meaning that the PHY has been tested from a radio point of view and basic functionality but not all stack tests.

Can you try to look at the the collector statistics variable (Collector_statistics) and the return status from the send message API call to see if the collector is getting any errors?

Cheers,

Marie H

Hi Marie,

Thanks for your reply. How do I visualize the collector statistics variable in the unmodified collector example? I briefly went through CUI and didn't see any way even with:

// collector.opt
-DDISPLAY_PER_STATS
-DFEATURE_SYSTEM_STATS

In our customized AT command, we did utilize this statistics variable and track the status code returned by dataCnfCb(). When polling interval is set at 60 seconds, the returned status code is mostly 0xF0, as described in previous post.

On a side note, I noticed the naming of consts is a bit odd in generated ti_radio_config.h when custom phy is enabled:

extern const rfc_CMD_PROP_TX_ADV_t RF_cmdPropRxAdv_custom;
extern const rfc_CMD_PROP_RX_ADV_t RF_cmdPropTxAdv_custom;

But changing them to more consistent names doesn't seem to do any good. I guess it is just cosmetics.

Best,

ZL

Hi Zhiyong,

The easiest is probably to have an active debug session and add Collector_statistics in the expressions view (it's a global variable). 

My understanding is that the radio commands generated in ti_radio_config.h are not used directly by the TI 15.4-Stack. The stack generates its own RF commands in the mac files. (RF_cmdPropRadioDivSetup, RF_cmdFsRx, RF_cmdFsTx etc)

Cheers,

Marie H

Here is what I get from 15.4 collector/sensor example with custom phy enabled and polling interval = 60000, report interval = 90000, tracking delay = 150000.

After pressed Send Toggle on collector 3 times, with > 3 minutes in between. The 2nd Send Toggle did reach to sensor, but the first and last failed after 3 retries.

Judging how soon dataCnfCb() returns with status code 0xF0 in our modified code, my strong suspicion is that the changed polling interval is not passed to RF core, a hard coded default 2000ms is always used.

Marie H said:

The stack generates its own RF commands in the mac files. (RF_cmdPropRadioDivSetup, RF_cmdFsRx, RF_cmdFsTx etc)

I am quite certain the generated commands in ti_radio_config.c are being used. If I simply change the name of these constants to more conforming ones like:

extern const rfc_CMD_PROP_TX_ADV_t RF_cmdPropTxAdv_custom;
extern const rfc_CMD_PROP_RX_ADV_t RF_cmdPropRxAdv_custom;

in both ti_radio_config.h and ti_radio_config.c, collector will not run. So those commands must be utilized by closed source MAC files somehow.

Hi Zhiyong,

Thank you for posting the instructions for reproducing the issue and your analysis. I will make a bug ticket and send it over to the SW developers. Please note it will take around a week to get feed-back.

Regarding the RF commands, I believe certain values are extracted from the sysconfig commands, but I think the MAC commands are the ones actually sent to the radio. So if you want to look at the RF commands at runtime I think you need to look at the MAC commands.

Cheers,

Marie H

Collector seems to have no problem sending data to sensor with polling interval up to 50000ms, but once polling interval is set at 55000 or 59000, or 600000, collector starts spew out a lot of transaction time out status code. There seems to some sort of magic number between 50000 and 55000.

Hi Marie,

I tried 2000, 5000, 10000, 20000, 30000, 40000, 50000, 55000, 59000, 60000ms as polling interval. Collector only starts to have problem sending data to sensor when polling interval is greater than 50000ms and custom phy is enabled. When polling interval is set at 60000ms and in FH mode or non-beacon mode with non custom-phy is used, collector also has no problems sending data to sensors. 

If the pollingInterval received by sensor from collector exceeds MAX_POLLING_INTERVAL, sensor will fallback onto its own CONFIG_POLLING_INTERVAL. 

if((pollingInterval < MIN_POLLING_INTERVAL)
   || (pollingInterval > MAX_POLLING_INTERVAL))
{
    stat = Smsgs_statusValues_partialSuccess;
}
else
{
    configSettings.pollingInterval = pollingInterval;
    Jdllc_setPollRate(configSettings.pollingInterval);
}
configRsp.pollingInterval = configSettings.pollingInterval;

This should not lead to collector prematurely timeout cached message for sensor.

I still believe there is some sort of overflow either in the calculation of INDIRECT_PERSISTENT_TIME or how it is passed to MAC layer code.

/* MAC Indirevt Persistent Timeout */
#define INDIRECT_PERSISTENT_TIME (MAX((5 * 1000 * CONFIG_POLLING_INTERVAL / 2), MIN_PERSISTENCE_TIME_USEC)/ \
                                  (BASE_SUPER_FRAME_DURATION * \
                                   SYMBOL_DURATION_CUSTOM))

Best,

ZL

Hi Zhiyong,

Thank you for testing.

I'll pass it on but I'm not sure how much we can help here.

Cheers,

Marie H

No worries, I am good for now. Just trying to help you guys officially support WB-DSSS.