CC1310: TI 15.4 Polling data issue

Hi Reno,

Can you capture a sniffer log of this happening?

Cheers,

Marie H

Hi Reno,

Could you share what is the security error code you get or a screenshot of both terminals?
Do you have the NV_RESTORE symbol enabled for both sensor and collector?

Does this happen on the first poll request every time? Could you flash erase the chip with UniFlash and flash a clean project again?

Best regards,

Daniel

Thank you for your quick reply and sorry for my late reply, we wanted to make one more test.

There was an issue due to a sequence and not because of poll / report period. The mistake that we made was that we were sending (polling) data from collector to sensor randomly. The poll data was in a buffer and the new report data arrived and did overwrite it (we assume).

We have changed the code so that we send poll data right after we receive report data, and now it works properly.

This does work now, but it will probably not work anymore with e.g. 20 sensors? Is there maybe a way to increase buffer size or something else, would that solve that potential issue? Thank you. 

Hi Reno,

Good to hear!. I'm not sure about your code changes, I believe the example project uses timers for both reporting and polling, and those work properly.

You could try increasing the buffer size by using MAC_CFG_TX_DATA_MAX, located in SDK_PATH/source/ti/ti154stack/high_level/mac_cfg.c. (You can redefine it in the project symbols).

Are you still using 6000ms for the reporting interval? It might get tight indeed, for 20 sensors, each has a 300ms window to report+ack, poll+ack. Can you share your data rate (PHY) and your payload size for a typical report and poll data? That would define how long is the air time of each packet.

Could you afford to increase the report and poll intervals?

Best regards,

Daniel

Hi Daniel,

thank you for your suggestion. We so send data from master MCU to CC1310, but this data is actually stored in our application buffer and when the callback activates poll function, we feed it with our buffered data, so there is theoretically no change to collector example code. For sensor side we have build our application on Sensor OAD example.

First of all, the result we go was not only with multiple sensors but also with only one sensor. We have increased MAC_CFG_TX_DATA_MAX from 2 to 20, is that enough? Is this a buffer size - how many different messages can be stored or how long the payload can be? But what worries me is that I haven't see any change in flash or ram consumption in the memory, I assume it goes to the SDK that we can not see. Are there any recommendations to what number we can increase this buffer so that there will be enough resources left?

Yes we are still using 6000ms. We actually need only 5 sensors max, but we will later add some sensors that will report data on 15min period so bigger number should not be a problem I assume. We are using

- PHY 133 so 200kbps because we want our device to consume less power. Is PHY 3 (50kbps) a better option regarding the reliability at same Rx RSSI?

- Payload is 34 bytes most of the time. In some cases it is 100 bytes.

Thank you.

Hi Reno,

Sorry for the delay, had been out of office.

For 5 sensors, setting MAC_CFG_TX_DATA_MAX to 20 might seem too much. But I'll double check and come back to you, since I'm not sure on what the limit is. However, if you intend to generate data faster than what the sensors poll, you will eventually run out of buffers no matter how big they are.

The packet size is defined in MAC_MAX_FRAME_SIZE in the same mac_cfg.c file.

If you have a good link, the 200 kbps and 50 kbps PHYs would give the same reliability. However, if you are close to the 200 kbps RSSI limit, you will start losing packets, while the 50 kbps PHY would still have a good link, so in this case it is more reliable. If you are close to the 50 kbps RSSI limit, you probably might not even have a link at all at 200 kbps. 

Best regards,

Daniel

Thank you. Any news regarding MAC_CFG_TX_DATA_MAX?

Also what number would you recommend? And on the sensor side is there any change needed for a buffer or only collector? My main concern are resources because compiler doesn't show how much the SDK takes (I can change this number and I do not see any change). Thank you.

Hi Reno,

Sorry I didn't update you. 

MAC_CFG_TX_DATA_MAX defines how many packages (data or control) the TI 15.4-Stack can hold in the buffer. Exceeding that value would cause the application to return an overflow error message. MAC_CFG_TX_DATA_MAX can be increased depending on RAM availability. However I don't have an specific number.

I believe you don't see any change in the memory allocation cause it is allocated into the heap. But I'll try to get a more specific answer if possible.

I don't think you need to increase it on the sensor side, however, take into account that the mac_cfg.c is linked from the SDK into both collector and sensor projects, so if you don't make a local copy, both projects will share the same mac_cfg.c configuration.

Regards,

Daniel

Hi Reno,

I've confirmed the buffer is dynamically allocated from the heap. The compiler reports the static allocation, so you will not see any changes there.

From experience, 7-10 is a good value. If the number is too big, you may run out of heap memory at run-time. Also it might give the application the wrong picture, to think the MAC can hold a lot of packets.

I would suggest you try it with these value and experiment if you get any issues.

Hope this has helped.

Regards,

Daniel

Hi, thank you for the reply. We are using CC1310 that doesn't have much ram. Is there a function to check status of a heap when in debug? How much more ram is needed if we increase the number by 1 e.g. from default 2 to 3 (is this like 100, 200, 300,... bytes?) so that we can check how much and where we can decrease to make sure we don't overflow.

I assume we will have to change:
MAC_CFG_TX_DATA_MAX
MAC_CFG_TX_MAX
MAC_CFG_RX_MAX

Any recommendation? For first one you suggested 7-10. I assume we have to change others as well.

Also what is a difference between MAC_CFG_TX_DATA_MAX and MAC_CFG_TX_MAX. Thank you.

Thank you. this helps a lot.